При настройке среды хостинга с несколькими сайтами, которые должны быть изолированы друг от друга, я сделал очевидный шаг, настроив PHP так, чтобы он работал как пользователь, связанный с каждым веб-сайтом, а не как пользователь Apache, но есть ли способ чтобы быть уверенным, что один сайт не сможет запустить сценарий, написанный на каком-то другом языке (например, Python) в качестве пользователя Apache? Я видел умные атаки, такие как атака по символической ссылке, которая использует правила .htaccess и символическую ссылку, чтобы обмануть Apache для обслуживания файлов PHP с других веб-сайтов в виде открытого текста (это не связано с вопросом, просто пример), и поскольку я не очень знаком с настройкой серверных языков, отличных от PHP, я не знал, что проверять и / или запрещать, например, через файл конфигурации Apache, чтобы убедиться, что сценарии, написанные на других языках, не могут быть запущены как пользователь Apache.
Например, даже если PHP настроен на запуск от имени пользователя веб-сайта, если веб-сайт был взломан, может ли хакер создать файл .htaccess, который устанавливает файлы .abc для запуска в качестве сценариев Perl, и если что-то не настроено должным образом на сервере , тогда те запускаются как пользователь Apache?
Как лучше всего подойти к этому?
Итак, ваша основная проблема заключается в том, что скомпрометированная одна учетная запись не может сделать ничего плохого для других учетных записей.
PHP и права доступа к файлам
Если PHP настроен для работы под разными пользователями для каждого домена, тогда ваши каталоги должны быть настроены так, чтобы у него не было доступа на запись ни к чему за пределами его собственного домена. Затем, используя PHP (или любые другие команды, вызываемые через PHP), он не может причинить никакого вреда остальной части сервера.
Лучше всего, чтобы скрипты принадлежали пользователю user1, а PHP выполнялся под пользователем user2. Для доступа клиентов FTP должен быть настроен для user1. Пользователю User2 следует предоставить доступ на запись только к определенным каталогам, где это действительно необходимо (каталог кеша, создание миниатюр, загрузка файлов через PHP).
Но многие люди начинают устанавливать Wordpress и другие CMS, не зная, что делать, и дают доступ на запись ко всему (тогда плохо написанный плагин CMS может скомпрометировать все скрипты php для этого домена). Wordpress и другие CMS в настоящее время поддерживают установку / обновление даже без разрешений на запись для процесса PHP (они просто запрашивают вход по FTP и автоматически используют его).
Еще одна передовая практика - заблокировать прямой веб-доступ к тем каталогам, в которых user2 имеет право записи. Загрузки файлов должны проверяться вашим скриптом и, только если они действительны, перемещаться в каталог, доступный извне (в противном случае кто-то может загрузить скрипт PHP вместо изображения JPG и может обмануть ваш веб-сервер для его выполнения).
Apache
Используйте Apache AllowOverride None директива для отключения использования .htaccess файл, чтобы злоумышленники не могли настроить выполнение других сценариев CGI. Apache должен иметь доступ только для чтения к обслуживаемым файлам (файлы конфигурации PHP, содержащие пароли, не нуждаются в разрешениях на чтение для Apache). С участием .htaccess отключено, пользователь не имеет возможности изменить конфигурацию Apache.
Использовать Options -FollowSymLinks (или -SymLinksIfOwnerMatch), чтобы предотвратить "атаку" символической ссылки.
Установить mod_security для отслеживания подозрительной активности и блокировки попыток взлома, например SQL-инъекций.
РЕДАКТИРОВАТЬ: Если .htaccess необходимо, вам нужно решить, какие опции будет поддерживать ваш хостинг, и включить только те. Примеры широко используемых безопасных опций включают (перечислите их в AllowOverride):
Deny from all директива о запрете доступа к части директорий)FollowSymLinks, но вроде работает и с этим); Помимо использования mod_rewrite, Apache будет следовать по символической ссылке только в том случае, если целевой файл / каталог принадлежит тому же пользователю, что и сама символическая ссылка.Из чтения http://httpd.apache.org/docs/2.4/misc/security_tips.html Похоже, что если suexec используется должным образом, то сценарии CGI, выполняемые от имени пользователя Apache, не должны вызывать беспокойства, поскольку вместо этого они будут выполняться под пользователем, определенным директивами suexec.