Как можно изолировать vhost

Может есть какой-то супер простой способ?

А что - корня документов уже недостаточно?

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

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

rootless container. можно с docker, можно с podman

оверхед, конено, выше, чем «один пользователь и общая группа» на всё, но и надежность выше.

Опять докерофаги пытаются свой докер пропихнуть. Чем это надёжность выше то? А ничем, юзеры и группы, как выше предложили, полностью решают задачу.

Может есть какой-то супер простой способ?

Нет

/thread

У взломщика проникшего в контейнер не будет не только лишних прав, но ещё и лишних утилит/библиотек (так как там минимальное окружение под приложение, если Dockerfile правильно написан), что снизит поверхность атаки ещё сильнее, плюс ФС контейнера сбрасывается каждый перезапуск (даже если контейнер поломали, бекдор умрёт при его перезапуске, если не сможет проникнуть в хост систему). Поломал ты приложение, а попал в окружение, в котором даже shell нет, а один статический бинарник этого самого приложения под ограниченным пользователем (а ещё все изменения в ФС теряются при перезапуске контейнера). Очень неудобно будет бутстрапить полезную нагрузку в таких условиях. А без Docker у тебя, как правило, есть ФС с постоянным хранением данных, есть куча установленного софта, в котором может найтись 0day, есть всякие шеллы и интерпретаторы на выбор для удобного бутстрапинга (в какой-нибудь buffer overflow payload много не запихаешь, как правило там вызов какой-то системной команды, которая уже грузит основную нагрузку, если в системе нет никаких интерпретаторов и библиотек, то потребуется притащить с собой огромный payload, а это может не получиться).

Разумеется, это не что-то принципиальное. Но формально риски может снижать.

Также как и неправильное применение Docker (контейнеры с приложениями запущенными от root, контейнеры с кучей лишнего необновляемого ПО внутри и т. д.) может наоборот риски повысить.

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

Если всё под одним пользователем, то никакой изоляции не будет (есть, конечно, всякие policy kit, app armor и прочие, но, поверь, настраивать их гораздо сложнее, чем создавать пользователей, они нужны в первую очередь для графических сессий, где запуск приложений от разных пользователей создаёт проблемы).

Как максимум, опакетить каждый бекэнд в отдельный докер образ (обязательно с запуском не от root и крайне желательно на базе минимального образа с минимумом системных утилит или вообще без них, если технология конкретного бекэнда позволяет) и запускать так. Это ещё сильнее снизит поверхность атаки.

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

даже если контейнер поломали, бекдор умрёт при его перезапуске, если не сможет проникнуть в хост систему

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

Через proxy_pass это значит что скорее всего у тебя на стороне бэкенда либо PHP-FPM, либо Tomcat, либо NodeJS, либо ещё что-то, вот на их стороне и настраивай.

Код на NodeJS можно пускать от разных пользователей, а для PHP-FPM можно использовать профайлы с отдельными пользователями.

плюс ФС контейнера сбрасывается каждый перезапуск (даже если контейнер поломали, бекдор умрёт при его перезапуске, если не сможет проникнуть в хост систему).

А вот это уже страусиная безопастность. Тебя ломают, а ты вместо того что бы решить проблему тупо после каждого взлома откатываешься назад.

Вроде можно настроить nginx так, чтобы worker, назначенный определенному vhost запускался со своим тегом apparmor/selinux. Пых соответственно тоже можно так настроить, про все остальное не в курсе, но я думаю, что так уж точно не хуже.
Не жди, что настройка будет простой, MAC это боль моя дырка задница.

Хостам нельзя воркеров назначать. Они принимают коннект, ещё не зная какой там будет хост. Если же у тебя разные айпи-адреса (это не про автора темы), и ты хочешь им разные права, то проще и удобнее просто запустить разные nginx-ы для них.

Ну лишние библиотеки можно и простым chroot-ом спрятать.

Но зачем? Ты сам же через месяц не вспомнишь как этот костылинг сделан. Как в этом будет разбираться потенциальный наследник этого непотребства - вообще загадка.

Какой костылинг? Я не описывал конкретную реализацию, я только указал что для целей «спрятать библиотеки» полноценный контейнер избыточен.

Какой костылинг?

Которыми ты предлагаешь это в chroot прятать. Что бы ты для этого не придумал, это будет очередной велосипед, единстванная причина существования которого «чтоб не докер»

По одному пользователю и группе на сайт

А как? В nginx работает от одного пользователя user нельзя прописать в vhost

Скрипты запускаются от этого пользователя

Если http сервер запускать который проксируется? Тоже вариант, но не совсем удобно конечно... Обновление через ssh... заводить 10 пользователей

у многозвездочного ТС, судя по всем его предыдущим темам напрочь отсутствует понимаение как работают вебы в реальном мире. Докеры тут - идеальное решение.

И да. контейнеры, когда умеешь их готовить и понимаешь, когда их стоит применить - хорошо и правильно. А вот явное и последовательное отрицание правильного - это симптом. Я таких симптомов в своей жизни застал множество. Я помню, как говорили, что iptables плохо, а ipchains хорошо, потому что *tables нифига не *tables. я помню как говорили, что юникод плохо, потому что одного байта всем хватит, а на китайцев наплевать. я помню как говорили systemd плохо (до сих пор, кстати, говорят). Я готов повторить - научитесь готовить контейнеры, поймите, куда они годятся, а где они не нужны, и ваша жизнь станет немного легче.

В случае ТС - контейнеры нужны.

А как? В nginx работает от одного пользователя user нельзя прописать в vhost

Вам же MrClon написал «пользователь nginx добавляется в группу каждого сайта»

Обновление через ssh... заводить 10 пользователей

Если обновление автоматизированно, то какая разница 1 или 10 пользователей? Если вручную то в принципе теже и сбоку.

Я помню, как говорили, что iptables плохо, а ipchains хорошо

Да небыло такого. Были темы в виде тяжести перехода с ipchains на iptables, это реально было ниразу не просто. Ещё вроде было что-то, что на ipchains реализовывалось легко и непринужденно, а у iptables на тот момент это было костылестроение, но вот это не точно.

сейчас такое же костылестроение в nftables (или там уже починили ipset?). проблема не в том, что новое - это плохо. проблема в том, что новому надо учиться. а вот это плохо. трудно. нипанятна. сложна.

сейчас такое же костылестроение в nftables

Полностью согласен. Это вот три перехода ipfwadm -> ipchains, ipchains -> iptables, iptables -> nftables. Из них простым был только первый.

А как? В nginx работает от одного пользователя user нельзя прописать в vhost

Создаёшь юзера, делаешь chown -R your_new_user:your_new_user website.com. Потом делаешь usermod -a -G your_new_user nginx. И так с каждым юзером.

У взломщика проникшего в контейнер не будет не только лишних прав, но ещё и лишних утилит/библиотек

Все что нужно взломщику он загрузит сам на сервер. И ему будет до фени в докере он или нет. Далее, уже вопрос о безопасности ядра. Если в нем есть дыра, то получить права рута на хосте не составит труда. В итоге, докер в данном случае – ненужная лишняя сущность. Сайты достаточно изолировать правами файловой системы и в 99% случаев этого достаточно.

А если уж так сильно хочется избавиться от доступа к юзерспейс утилитам, до достаточно запускать в chroot-те – тоже самое что и докер, но намного проще.

Это всё абстрактные рассуждения, а если рассуждать конкретно?

Например, у нас в приложении buffer overflow дающий RCE. Это позволяет загрузить и выполнить несколько сотен байт машинного кода, может килобайт. Переполнишь буфер слишком сильно - затрешь что-то нужное или выйдешь за пределы выделенной процессу памяти и он упадёт раньше, чем выполнит твой эксплойт.

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

В эти сотни байт или килобайты будет зашит exec curl url полезной нагрузки. А если у тебя в контейнере curl нет, wget нет, bash нет, питона нет, perl нет, ничего нет, то выходит, то что то что пробило софт должно быть способно в полностью автономном режиме без посторонней помощи докачать куски себя (использовать функции из статически слинкованного приложения, как правило затруднительно, так как там всё по разным адресам и без имён, остаются одни syscall).

Взломщику сильно усложняется жизнь.

Полноценный контейнер просто работает, Dockerfile пишется в несколько строк и запускается/собирается одной командой.

Делать руками chroot значит изобретать и поддерживать велосипед (надо самому составить минимальный root, надо самому поддерживать его актуальность, надо написать скрипты запуска/перезапуска/остановки сервисов, там есть всякие нюансы типа что смонтировать в chroot, обработки граничных случаев типа конкурентных запусков одного и того же сервиса и т д). За который тебя проклинет коллега, который придёт на проект после тебя. Потому что Docker он знает (а если нет, то мануалов полон Интернет), а в чужих скриптах и их багах разбираться придётся самому.

Если уж дошло до chroot/lxc, то по умолчанию должен идти Docker, а что-то своё только если доказано, что Docker не способен эффективно решить задачу. Не наоборот.

если доказано, что Docker не способен эффективно решить задачу

Так это по умолчанию так. Докер - блоатварь, засоряющая собой любой проект куда его всунут. Надо максимально избегать.

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

Как правило самое подозрительное происходит именно в момент взлома - крашится приложение, качаются файлы с левых хостов и т. д.

А потом активность может быть умеренная и не такая заметная, если это не майнер выжравший 100% CPU.

Так вам и написали:

А если уж так сильно хочется избавиться от доступа к юзерспейс утилитам, до достаточно запускать в chroot-те – тоже самое что и докер, но намного проще.

И я с этим тезисом полностью согласен.
У докера другие «плюсы» в виде версионности, деплоя и т.д. Хотя для меня лично это тоже сомнительные плюсы.

Dockerfile пишется в несколько строк и запускается/собирается одной командой.

Делать руками chroot значит изобретать и поддерживать велосипед (надо самому составить минимальный root, надо самому поддерживать его актуальность,

вот тут я не совсем понимаю: в случае docker кто составит минимальный root и будет поддерживать его актуальность?

Если уж дошло до chroot/lxc, то по умолчанию должен идти Docker, а что-то своё только если доказано, что Docker не способен эффективно решить задачу. Не наоборот.

Вы предлагаете лишнюю сущность пихать в каждую дырку? Кажется кто-то забыл про KISS. chroot/lcx это KISS, а докер это уже комбайн.

как? В nginx работает от одного пользователя

Каждому сайту своего пользователя. Типа

Name  Owner   Group  Mod
site1 user1   nginx 0750
site2 user2   nginx 0750

Nginx читает все сайты, но его доступ ограничивается корневым каталогом root из location и правами только на чтение.

Скрипуха для каждого сайта запускается под своим пользователем.

Для чего на каждый сайт делается свой пул (это для php), в настройках которого

user = usern
group = nginx

Гостевой доступ выключен.

Как-то так.

Чутка подробней

[pooln]
user = usern
group = nginx
listen = /var/run/pooln.sock
php_admin_value[error_log] = /.../siten/log/error.log

server {
    listen 80;
    server_name siten.loc;
    root   /var/www/siten/html;

access_log /var/log/nginx/siten.access.log;
error_log /var/log/nginx/siten.error.log;


   location / {
      try_files @backend;
}
   @backend{
fastcgi_pass unix:/var/run/pooln.sock;
}

Твоя конфигурация даст сайтам штатно воровать друг у другая данные. Группы у всех должны быть разные, юзер nginx должен состоять во всех группах сразу. Группа «nginx» не нужна.

да так лучше

Name  Owner   Group  Mod
site1 user1   user1 0750
site2 user2   user2 0750

[pooln]
user = usern
group = usern

nginx состоит во всех usern

ехал докер через докер

Спасибо брат!

Во, вы сейчас коллективно переизобрели мой дефолтный конфиг веб-сервера. Даже странно что это не всеобщий дефолтный конфиг.

P.S. остаётся добавить что если используется СУБД, то но каждый сайт/приложение/базу (это уж как в вашем случае уместнее) нужен отдельный юзер с доступом только к ней

P.S. остаётся добавить что если используется СУБД, то но каждый сайт/приложение/базу (это уж как в вашем случае уместнее) нужен отдельный юзер с доступом только к ней

Ну а ещё уместнее использовать разных юзеров в зависимости от выполняемых функций, как минимум разделить на имеющих право вносить изменения в данные и только чтение. И ещё обращаю внимание, что даже в случае как вы описали «одного юзера», этот юзер не должен иметь право вносить изменения в метаданные.