Я хочу настроить PHP-FPM с Apache в среде общего хостинга. В рекомендуемый способ использовать mod_proxy_fcgi.
У каждого клиента есть собственный пул FPM, в котором процессы PHP выполняются под его собственным системным пользователем. Это обеспечивает хорошую изоляцию. Предположим, что сокеты unix для доступа к их пулам FPM хранятся как /run/php-fpm/{user1,user2,...}.sock.
Apache работает под управлением одного системного пользователя для всех клиентов, скажем www-data. Поскольку его единственные задачи - обслуживать статические файлы и передавать соединения с FPM, это в основном нормально. Однако все сокеты FPM unix должны быть доступны для www-data.
.htaccess Файлы - это хороший способ для клиентов виртуального хостинга настроить такие вещи, как перенаправления, базовая аутентификация, заголовки управления кешем и т. д. Фактически, единственная причина, по которой я придерживаюсь Apache в моей настройке, заключается в том, что я хочу поддерживать эти предоставленные клиентом файлы конфигурации . Чтобы защитить Apache от вредоносных .htaccess файлы, AllowOverride и AllowOverrideList может быть использован. Здесь я могу исключить несколько директив, которые не должны использоваться, например Action и SetHandler что позволит вам выполнять сценарии cgi как www-data.
Одна особенно полезная директива: RewriteRule из mod_rewrite модуль. Он используется многими приложениями для украшения URL-адресов, например имея /foo вместо того /index.php/foo как URI. Но есть еще [P] флаг что приводит к тому, что запросы обрабатываются mod_proxy. Если RewriteRule разрешено в .htaccess файлы, то злоумышленник (user2) может сделать что-то вроде
RewriteRule "/evil" "unix:/run/php-fpm/user1.sock|fcgi://localhost/home/user2/evil.php" [P]
Это запускает вредоносный файл /home/user2/evil.php (предоставляется пользователем user2) в пуле FPM user1, то есть как системный пользователь user1. Следовательно, он имеет доступ ко всем файлам в /home/user1, он может, например, выгружать секреты базы данных из файлов конфигурации wordpress. Единственное требование - чтобы пользователь user1 (жертва) мог прочитать этот вредоносный файл, но это не проблема, потому что user2 (злоумышленник) может просто chmod его собственный домашний каталог и злой файл с o+rx.
Возникает вопрос: как можно смягчить эту атаку?
RewriteRule в .htacces (не совсем вариант ...)mod_rewrite источники удалить [P] флаг (это сделает обновления безопасности раздражающими)Изменить: Патч для mod_rewrite (относится к версии пакета Debian 2.4.25-3+deb9u7)
--- a/modules/mappers/mod_rewrite.c
+++ b/modules/mappers/mod_rewrite.c
@@ -4928,6 +4928,11 @@ static int hook_fixup(request_rec *r)
if (l > 6 && strncmp(r->filename, "proxy:", 6) == 0) {
/* it should go on as an internal proxy request */
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "attempt to make proxy request from mod_rewrite "
+ "in per directory context: %s", r->filename);
+ return HTTP_FORBIDDEN;
+
/* make sure the QUERY_STRING and
* PATH_INFO parts get incorporated
* (r->path_info was already appended by the
Интересно, что у них есть проверить, есть ли mod_proxy доступен в hook_uri2file (имеет дело с RewriteRules в контексте сервера), но не в hook_fixup (имеет дело с RewriteRules в контексте каталога).
Вместо удаления [P] flag Я решил остановить его прямо перед тем, как запрос будет передан в модуль прокси. Следовательно, он также должен улавливать ситуации, когда вам каким-то образом удается получить proxy:... как переписанное имя файла. Кроме того, он по-прежнему позволяет использовать [P] или proxy: в контексте сервера, т.е. непосредственно в <VirtualHost> блок.
Но, как отмечалось выше, при каждом обновлении пользовательский патч утомляет. Пожалуйста, дайте мне знать, если есть лучшие решения, которые работают только путем изменения файлов конфигурации. Как с этим справляются крупные игроки? Надеюсь, ответ не «совсем нет».