LINUX.ORG.RU
ФорумAdmin

nginx изоляция виртуальных хостов

 


0

4

У апача есть mpm-itk, который позволяет запускать воркеры для каждого вхоста от отдельного пользователя. А в nginx все бежит от одного пользователя и этот пользователь должен иметь доступ ко всем виртуал хостам. Т.е. если в nginx будет уязвимость, то атакующий в теории сможет считать файлы всех вхостов.

В интернетах я нашел одно упоминание этой проблемы, но решение там предложено довольно мудреное, хотя и безопасное, - запускать отдельный экземпляр nginx для каждого вхоста и перед ними ставить общий реверс-прокси.

Вот и стало интересно кто как обходит данную проблему, а если не обходят, то почему.

★★★★★

Подпишусь.

Для разнообразия хочу разобраться со своим шлаком на пыхпых, пока придумал только разбивать по контейнерам из шаблона, на фронте nginx и дальше рулим на контейнеры по хосту.

Правда у меня их дофига, но в принипе написать restful для отслеживания такой фишки не проблема.

Думаю lxc круче для этого, хотя я лучше умею готовить Docker.

invokercd ★★★★
()
Ответ на: комментарий от invokercd

и этот пользователь должен иметь доступ ко всем виртуал хостам.

Только к статике которая и так через web всем доступна, да и то многие статику вообще на отдельный сервер убирают. Так что имхо проблема надумана.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

Да, точняк. Но это если этой твой апп, и ты можешь его хоть немного менять под себя.

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

invokercd ★★★★
()

а если не обходят, то почему.

Да когда вы уже поймёте, что nginx и есть reverse proxy, это его основная задача, и не нужно совать его в любую подходящую нишу под бой пионерских барабанов :)

router ★★★★★
()

там предложено довольно мудреное, хотя и безопасное, - запускать отдельный экземпляр nginx для каждого вхоста и перед ними ставить общий реверс-прокси.

мудреное

Очевидное же. Мудреное это лезть во внутренности nginx.

melkor217 ★★★★★
()

на хост сервере нгинкс в роли хттп-прокси, на каждой виртуалке свой нгинкс. работает не первый год.

Renegade
()
Ответ на: комментарий от TDrive

Спасибо. Это не совсем ответ на вопрос, однако он указывает верное направление мысли. и router еще в тему пишет.

prizident ★★★★★
() автор топика

А когда в последний раз в nginx находили уязвимость позволяющую выполнить произвольный код, или ещё что-то такое?
Наверняка что-то такое было, но я вспомнить не могу.

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Возможно никогда, но это не значит что и не найдут. За последний год нашли столько уязвимостей в казалось бы простых местах, что зарекаться не стоит.

prizident ★★★★★
() автор топика
Ответ на: комментарий от prizident

«Простые места» это вроде openssl?
Всё-таки серьёзная уязвимость в Nginx это далеко не самая главная вероятность факапа.

MrClon ★★★★★
()

Потому что nginx зачастую раздает только статику. Динамические же запросы проксируются на бекенд, который обычно запущен с правами вполне конкретного пользователя и имеет вполне конкретные системные права. Реальные и чоткие.

Komintern ★★★★★
()
Последнее исправление: Komintern (всего исправлений: 1)
Ответ на: комментарий от invokercd

(пых пых на fpm)

Что мешает запускать php-fpm от разных юзеров (или в разных контейнерах) и проксировать одним nginx'ом каждый вирт. хост к своему php-fpm'у?

dexpl ★★★★★
()
Ответ на: комментарий от dexpl

Это и было единственным пока что решением, которое намыслил.

Наверное главное что мешает - их дофига, вручную это будет геморрно :)

Ну и по контейнерам я не решил что юзать, в принципе варианта два - Docker или LXC. В докере все предельно круто, кроме сети...

invokercd ★★★★
()
Ответ на: комментарий от invokercd

ядро не катит, да и не нравится мне оно

Дело хозяйское, конечно, но судя по моему (непродолжительному) опыту работы в одном IT-аутсорсере, nginx и php-fpm внутри ovz-контейнера — вполне себе промышленное решение.

dexpl ★★★★★
()
Ответ на: комментарий от prizident

openssl это ни разу не простое место, это адский комбайн.
Да и bash не так уж прост.

Названные факапы были громкими, шуму от них было много. А кроме них регулярно находят кучи гораздо менее шумных уязвимостей в других приложениях.

Веростность быть сбитым автомобилем всё-ещё выше чем вероятность разбиться в самолёте, несмотря на то что о крушениях самолётов трубят во всех СМИ, и их почему-то принято бояться.

MrClon ★★★★★
()
15 февраля 2016 г.
Ответ на: Статья от VYanchuk

Ты это к чему? Настройка виртуальных хостов прекрасно описана в документации самого nginx, но здесь-то разговор не об этом.

MrClon ★★★★★
()
Ответ на: Статья от VYanchuk

Пихаешь ссылку во все сайты, где видишь слово nginx? Мне в блоге несколько часов назад ссылку закинул, спамер.

Amet13 ★★★★★
()
Ответ на: комментарий от Deleted

нет, там изолируются инстансы php, но nginx бежит от одного пользователя, который имеет доступ ко всем файлам всех хостов. т.е. экспулуатируем уязвимость в nginx, и получаем доступ ко всем вхостам.

prizident ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.