Я хочу настроить сервер NGINX, на котором можно размещать несколько веб-сайтов, которые отделены друг от друга, поэтому vhosta
не может получить доступ к файлам из vhostb
.
Я установил новый сервер Debian 7.5 и установил NGINX и PHP FPM из пакетов debian по умолчанию.
Потом я добавил 2 новых пользователя vhosta
и vhostb
и добавил пользователя веб-сервера NGINX www-data
группе каждого пользователя.
Затем я создал следующую структуру каталогов.
var/
|---www/
|---vhosta
|---httpdocs (permissions 750 - owner: vhosta - group: vhosta)
|---vhostb
|---httpdocs (permissions 750 - owner: vhostb - group: vhostb)
Я настроил отдельный пул PHP FPM для каждого виртуального хоста, чтобы разделить процессы PHP для каждого виртуального хоста. Конфигурация следующая (показано только для vhosta
)
[vhosta]
listen = /var/run/php5-fpm-vhosta.sock
user = vhosta
group = vhosta
listen.owner = vhosta
listen.group = vhosta
Насколько мне известно, эта конфигурация должна разделять vhosta
от доступа к файлам в vhostb's
каталог httpdocs, поскольку vhosta
не имеет прав доступа к папке httpdocs из vhosta
. Я проверил это, попытавшись создать простой скрипт PHP в vhosta
, который пытается получить доступ к файлам в vhostb's
каталог httpdocs.
Все идет нормально. Я установил приложение PHP (CMS) в vhosta
и провел некоторое тестирование производительности с помощью ApacheBench.
Как правило, все работает более гладко и быстро, чем с Apache2, и я получаю следующий результат.
Requests per second: 31.62 [#/sec] (mean)
Time per request: 316.209 [ms] (mean)
Time per request: 31.621 [ms] (mean, across all concurrent requests)
Transfer rate: 430.58 [Kbytes/sec] received
Что ж, 31,62 запроса в секунду для меня сейчас нормально.
Последний я хочу ограничить доступ vhosta
и vhostb
в подмножество каталогов, поэтому они не имеют доступа к другим системным файлам, доступным для чтения. Я делаю это с помощью директивы PHP open_basedir.
Я добавил следующее к каждому пулу PHP FPM виртуальных хостов (просто показываю vhosta
)
php_admin_value[open_basedir] = /var/www/vhosta/httpdocs/:/tmp/
При этом у vhosts не должно быть доступа, например, / etc / passwd. Я создал простой скрипт PHP, который проверяет, что vhosts не может получить доступ к файлам извне из настроенных каталогов.
Наконец, я повторил тест производительности и получил следующий результат.
Requests per second: 11.82 [#/sec] (mean)
Time per request: 8460.087 [ms] (mean)
Time per request: 84.601 [ms] (mean, across all concurrent requests)
Transfer rate: 161.18 [Kbytes/sec] received
Похоже, что добавление директивы open_basedir в пул PHP FPM приводит к значительному снижению производительности. Время доступа и количество запросов в секунду теперь довольно схожи по сравнению с настройкой с использованием Apache2 с mod_php.
Мои вопросы следующие:
Можно ли считать созданную мной настройку «безопасной», чтобы отдельные виртуальные хосты не могли получить доступ друг к другу? Если нет, то что лучше всего сделать и что мне не хватает?
Почему при использовании open_basedir так сильно падает производительность? Или это спасение, чтобы не использовать open_basedir, поскольку файлы, подобные / etc / passwd, в любом случае доступны для чтения всем?
Если вы действительно хотите, чтобы они не имели доступа к чему-либо реальному в системе, настройте chroot для php-fpm, создав таким образом «поддельный» / etc / passwd и так далее. Или, что еще проще, используйте докер!
1) Я не уверен, как вы настроили статические файлы для загрузки с этих хостов, потому что они не должны загружаться в этом случае, возможно, только если вы передадите все в php-fpm, который откроет вам другой вид атакует и снижает производительность. Обычно вы устанавливаете такие разрешения (учитывая, что nginx - это пользователь, запускающий процесс nginx):
2) Я не уверен на 100%, однако, если у вас сложное приложение, которое загружает огромное количество файлов, и ваш ввод-вывод не обеспечивает хорошей производительности, тогда это может иметь смысл. Ограничения open_basedir делают такие вещи, как проверка, не являются ли файлы символической ссылкой или внутри символической ссылки, и так далее, делая много запросов ввода-вывода, что увеличивает IOPS вашего диска. Еще одна причина использовать docker или хотя бы chroot.