Разделяемый хостинг: проблема безопасности Apache RewriteRule [P]

Я хочу настроить 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 (не совсем вариант...)
• Запустите отдельный процесс Apache для каждого клиента, используя своего собственного системного пользователя (но: потребление ресурсов и необходимость в другом обратном прокси-сервере для разделения портов 80 + 443)
• заплата 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> блок.

Но, как отмечено выше, пользовательское исправление раздражает работу по обслуживанию в каждом обновлении. Поэтому, пожалуйста, дайте мне знать, если есть лучшие решения, которые работают только путем изменения файлов конфигурации. Как крупные игроки справляются с этим? Надеюсь, ответ не "совсем нет".