Как сделать chroot php-fpm (7.3) для использования с Apache 2.4.10?

Question

В целях безопасности я хотел бы изменить свою службу php-fpm на / var / www / html. У меня есть vhost в Apache 2.4.10, который выглядит следующим образом:

<VirtualHost *:8080>
        DocumentRoot /var/www/html
        DirectoryIndex index.php index.html /index.php /index.html

        <FilesMatch \.php$>
                SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost/"
        </FilesMatch>

</VirtualHost>

Моя проблема заключается в том, что, когда я устанавливаю chroot = /var/www/html в пуле .conf в php-fpm, пути к файлам, отправляемые из Apache, неверны(из-за DocumentRoot он установит для SCRIPT_FILENAME значение /var/www/html/index.php, когда php-fpm теперь будет ожидать /index.php). Я могу как-то обойти это, выполнив AliasMatch \.php$ /, чтобы получить мои php-файлы из папки DocumentRoot, но это мешает работе DirectoryIndex, потому что теперь Apache ищет /index.php в качестве индексного файла, который нене существуетЯ предполагаю, что это, вероятно, также довольно плохая форма ...

Есть ли способ справиться с этим? Я знаю, что nginx может обойти это, переписав SCRIPT_FILENAME, но это не вариант для меня. Я также знаю, что могу установить опцию doc_root php.ini, но я слышал, что это может быть проблемой, потому что это влияет на переменные $_SERVER, связанные с путем к скрипту в php.

На связанныхобратите внимание, насколько небезопасно запускать php-fpm не в chroot? (Я установил open_basedir в / var / www / html)

Answer 1

Я использую PHP для запуска в chroot, однако это реальная боль, а не огромные преимущества для безопасности. Самой большой проблемой, с которой я столкнулся, была попытка поместить все зависимые общие объекты в chroot и поддерживать их в актуальном состоянии после каждого обновления системы. В конце концов я сдался и в результате запустил обратный прокси-сервер с разными user: group для каждого vhost вместо попытки выполнить chroot. Если у вас есть 2 пула, работающие как www: site1 и www: site2, вы можете указать root: site1 / var / www / site1, а затем chmod 750 / var / www / site1. Это предотвратит перетекание взломанного виртуального хоста (site2) на других виртуальных хостов (site1). Большинство других файлов на сервере должны быть безопасными, но вы по-прежнему хотите иметь исходящие правила iptable и должны убедиться, что ваше хранилище сеансов использует режим 600, если вы используете механизм хранения файлов. Вы также можете использовать параметр ini disable_functions для дополнительной безопасности.