Безопасность хостинга на нескольких сайтах - убедитесь, что ни один скрипт не может работать как пользователь Apache, но только как пользователь каждого сайта

При настройке среды хостинга с несколькими сайтами, которые должны быть изолированы друг от друга, я сделал очевидный шаг - настроить PHP так, чтобы он работал как пользователь, связанный с каждым сайтом, а не как пользователь Apache, но есть ли какой-то способ быть уверенным, что ни один сайт не может запустить скрипт, написанный на другом языке (например, Python), как пользователь Apache? Я видел умные атаки, такие как атака по символической ссылке, которая использует правила.htaccess и символическую ссылку, чтобы обмануть Apache в предоставлении файлов PHP с других веб-сайтов в виде открытого текста (это не связано с вопросом, просто пример), и так как я не очень знаком с настройкой серверных языков, отличных от PHP, я не знал, что проверять и / или запрещать, например, через conf-файл Apache, чтобы убедиться, что скрипты, написанные на других языках, не могут быть запущены как пользователь Apache.

Например, даже если PHP настроен для работы в качестве пользователя веб-сайта, если веб-сайт был взломан, может ли хакер создать файл.htaccess, который устанавливает файлы.abc для запуска в качестве сценариев Perl, и если на сервере не все настроено должным образом тогда те запускаются как пользователь Apache?

Какой лучший способ подойти к этому?

Источник

2 ответа

Решение

Из прочтения http://httpd.apache.org/docs/2.4/misc/security_tips.html выясняется, что если suexec используется правильно, то сценарии CGI, выполняемые от имени пользователя Apache, не должны вызывать беспокойства, поскольку они будут выполняться вместо пользователя, определенного директивами suexec.

Источник

Таким образом, ваша главная проблема в том, что скомпрометированная одна учетная запись не может сделать ничего плохого для других учетных записей.

PHP и права доступа к файлам

Если PHP настроен для работы в качестве другого пользователя для каждого домена, тогда ваши каталоги должны быть настроены так, чтобы у них не было доступа на запись к чему-либо за пределами своего собственного домена. Затем, используя PHP (или любые другие команды, вызываемые через PHP), он не может причинить вред остальному серверу.

Лучше всего, чтобы скрипты принадлежали пользователю user1, а PHP - для запуска под user2. Для доступа клиентов FTP должен быть настроен для user1. Пользователю 2 следует предоставить доступ на запись только в определенные каталоги, где это действительно необходимо (директория кэша, генерация миниатюр, загрузка файлов через PHP).

Но многие люди начинают устанавливать Wordpress и другие CMS, не знают, что делать и дают доступ на запись ко всему (тогда плохо написанный плагин CMS может скомпрометировать все php-скрипты для этого домена). Wordpress и другие CMS в настоящее время поддерживают установку / обновление даже без прав записи для процесса PHP (они просто запрашивают FTP-вход и автоматически используют его).

Еще одна лучшая практика - блокировать прямой веб-доступ к тем каталогам, где у user2 есть доступ для записи. Загрузка файлов должна проверяться вашим сценарием и только если она действительна, перемещаться в каталог, доступный извне (в противном случае кто-то может загрузить сценарий PHP вместо изображения JPG и может обмануть ваш веб-сервер для его выполнения).

апаш

Используйте Apache's AllowOverride None директива отключить использование .htaccess файл, так что атакующие не могут настроить запуск других сценариев CGI. Apache должен иметь доступ только для чтения к обслуживаемым файлам (файлы конфигурации PHP, содержащие пароли, не требуют разрешения на чтение для Apache). С .htaccess отключено, пользователь не имеет возможности изменить конфигурацию Apache.

использование Options -FollowSymLinks (или же -SymLinksIfOwnerMatch) для предотвращения символической ссылки "атака".

устанавливать mod_security следить за подозрительной активностью и блокировать попытки взлома, такие как SQL-инъекция.

РЕДАКТИРОВАТЬ: Если .htaccess необходимо, вам нужно решить, какие опции ваш хостинг будет поддерживать и включать только те. Примеры часто используемых параметров, которые являются безопасными, включают (перечислите их в AllowOverride):

  • AuthConfig - включить базовую HTTP-аутентификацию
  • ErrorDocument - для определения собственного URL-адреса вместо ответа по умолчанию для ответа 404 (поскольку вы определяете только URL-адрес, можно использовать только уже доступный контент, поэтому нет риска)
  • Индексы - если вы хотите включить простые списки каталогов
  • Limit - ограничить доступ по IP-адресу (обычно используется Deny from all директива запретить доступ к части dirs)
  • RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule - для mod_rewrite
  • SymLinksIfOwnerMatch - необходим для mod_rewrite (в документации указано, что он нужен FollowSymLinks, но, похоже, работает и с этим); Помимо использования mod_rewrite, Apache будет следовать только по символической ссылке, если конечный файл /dir является владельцем того же пользователя, что и сама символическая ссылка.
Источник
Другие вопросы по тегам