Раздельные пользователи для сайтов. Правильно ли я настроил nginx?

Question

[Дмитрий]

Добрый день!
Настраиваю собственный веб-сервер для сайтов, никаких панелей управления, только консоль.
Linux, Nginx, php-fpm, mysql

Большая часть сайтов - простые, на html, часть сайтов работают на различных cms. Все они уже работают, все ОК.
Есть необходимость перенести на этот же веб-сервер NEXTCLOUD, но тут же возникает и вопрос обеспечения безопасности...
Владелец каталогов сайтов - www-data
Nginx работает от имени - www-data
Сокет для сайтов - php7.3-fpm.sock

Правильно ли я поступил проделав следующее:
1. Добавил в систему пользователя www-cloud из группы www-cloud, без возможности авторизации (пароль не задан);
2. Назначил на каталог, в котором лежит nextcloud, владельцем www-cloud:www-cloud;
3. Создал новый пул php-fpm -> /etc/php/7.3/fpm/pool.d/www-cloud.conf в котором:
user = www-cloud
group = www-cloud
listen = /run/php/php7.3-fpm-cloud.sock
listen.owner = www-data
listen.group = www-data
4. в конфигурационном файле хоста указал новый сокет
fastcgi_pass unix:/var/run/php/php7.3-fpm-cloud.sock;

Работают сайты, разумеется, под разными пользователями mysql,
Этого достаточно для разделения сайтов по пользователям? Очень уж не хочется в случае взлома сайта "подарить" кому-то и файлы из nextcloud!

Буду крайне признателен за советы!
Спасибо!

Answer 1

[Виктор Таран]

не не достаточно. В таком раскладе получается что если вирус поразит один из сайтов то ему хватит прав заразить и остальные.
я разделяю все сайты даже одного клиента на разных владельцев и групп.
В таком раскладе исключается даже теоретическая возможность поражения 1 вирусом двух сайтов ( в смысле через один доступ)
А так же некоторым сайтам требуется разная версия окружения, от версии php до вида его представления. И даже веб сервера на котором это счастье болтаетя. именно по этому рекомендую вам все-же использовать панели
Поскольку они хорошо убирают человеческий фактор из управления.
Если же вам хочется поковыряться и разобраться то вам идеально подойдет ispconfig3 ( чем и и пользую) ( установка по ману)
оч удобно.

Если же не хочется паритьс но чтоб все работало то
Bitrix VM - подойдет для любых сайтов ставится с 1 скрипта
vestacp - ставится с 1 скрипта, при инсталяции есть выбор варианта сборки, так же в 1 скрипт.
braynicp - дохрена умеет, реально дохрена неудобоный интерфейс проприетарная лицензия (но бесплатная). Но сап адекватный.

Comments

[Дмитрий]

Спасибо за ответ!

Не совсем понимаю, как вирь с одного сайта перелезет на другой, если:
"2. Назначил на каталог, в котором лежит nextcloud, владельцем www-cloud:www-cloud;"
а владелец каталога с сайтами www-data?

В перспективе - разделю все сайты, просто нужно с чего-то начинать. Вот, изучаю вопрос.
А за список панелей спасибо, но не хочу. У меня есть ispmanager, хочу голый cli

[Виктор Таран]

Дмитрий, достаточно просто он перелезет.
Ваш пример прав

site1.ru www-cloud:www-cloud
site2.ru www-cloud:www-cloud
site3.ru www-cloud:www-cloud
site4.ru www-cloud:www-cloud

Пример при котором у сайта нет прав на другие сайты

site1.ru user1: client1
site2.ru user2:client2
site3.ru user3:client3
site4.ru user4:client4

Вот при таком раскладе сайты действительно изолированны.
Сменить владельца они не могут поскольку это рутовая привилегия.
А вот chmod вирус с легкостью могут сделать, собственно и делают это постоянно.

[Дмитрий]

Виктор Таран, прошу прощения, мой уровень познаний оставляет желать лучшего.

site1.ru www-cloud:www-cloud
site2.ru www-cloud:www-cloud
site3.ru www-cloud:www-cloud
site4.ru www-cloud:www-cloud

У меня так:

site1.ru www-data:www-data
site2.ru www-data:www-data
nexcloud www-cloud:www-cloud

Ну и пхп-фпм пулы разные. Этого недостаточно?

[Виктор Таран]

Дмитрий, а с чего бы этого хватило ?
У вас пользователь имеет права на запись и чтения в этих папках. кто ему запретит это сделать ? Видел как реально боты ломают?
оп сути они не пишут только саму ломалку, далее они ложат софтинку, с веб мордой и АПИ у нее есть версионность комьюнити и тд ;)
та уже может и управлять ботам и и руками лазить по серверу можно. Типа вот такого https://news.netcraft.com/archives/2017/05/18/web-...
В общем легко могут, ну не совсем конечно легко но тем ни менее, полное разделение сайтов по групам и юзерам разрешают эту проблему на корню.
Но если у тебя скажем битрикс и их 5 штук, то разницы никакой, битрикс плохо ломается и скорее всего вы не увидите ни 1 вируса.
А вот если у вас joomla 1.5 то такая схема строго обязательна, даже если это 1 сайт из 5

[Дмитрий]

Виктор Таран,

а с чего бы этого хватило ?

владельцы каталогов разные, сокеты разные. Про какого именно пользователя речь, не понимаю. Разве при таком подходе сайты имеют доступ каталогам друг-друга?

Сейчас так:

site1.ru www-data:www-data
site2.ru www-data:www-data
nexcloud www-cloud:www-cloud

Будет так, например:

site1.ru www-data:www-data
site2.ru www-data2:www-data2
nexcloud www-cloud:www-cloud

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

[Виктор Таран]

Дмитрий, Да такой вариант самый надежный.
Но по факту часто встречается и ваш вариант.

Если тебе интересно поковыряться и разобраться то ставь ispconfig3, поставишь уже половину сервера выучишь ;)
Как поставишь сразу встанет вопрос а где nginx, тут я писал что-то по этому поводу https://klondike-studio.ru/blog/ispconfig3-nginx-a...
ну там у тебя уже будет сразу несколько вариантов представления пхп и вариантов серверов
nginx+fpm
nginx+apache+fpm
nginx +apache+mod_apache
apache+mod_apache
Nginx+apache+FastCGI
Nginx+apache+CGI
умножая все это на версии пхп гыгы, и все это в одной связке, по выбору под сайт ;)
На покрутить более чем зауши.

[Дмитрий]

Виктор Таран,

Да такой вариант самый надежный.
Но по факту часто встречается и ваш вариант.

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

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

Панели не хочу. Изучаю cli

[Виктор Таран]

Дмитрий, да идешь в правильном направление.
Вот только по панелям перемотри свое мнение, кодить в бинарных кодах ты же не собираешся, почему-то испльзуют высокоуровневые языки программирования.
Потому что так медленней не все видишь но скорость работы выше и КПД с этим
И с панелями тож-же самое
Они делают твою работу более быстрой.
А то что шаблон генериш ты или генератор разницы никакой.
Я например генераторы сразу переписываю под себя и живу в малине, никакой самоедятельности, человеческого фактора во моменте решения коммерческой задачи, тыц тцы все работает.
А отладка в вободное время, там и пилишь свои конфиги.
Другйо вопрос если ты разбираешся как он это делает и что пишет, но для изучения последнего тебе подойдет и тот вариант что я написал.
Главное же в этом это реальный опыт, то есть отладка на продакшене и коммерческие задачи.
Тут хочешь не хочешь а выучишь как и веб морды так и весь бэк, так чоне парься будет тебе cli

[Дмитрий]

Виктор Таран, у меня есть isp 5 лицензия, не хочу ей пользоваться. Мне интересно, я узнаю и учусь.

Дело в том, что, например, ковырять готовые конфиги isp интересно, но я с нуля написал свои. Теперь знаю как работает nginx, что и откуда берет.
То же самое и с отдельными пользователя. Да, я могу накатить на голый сервер ISP и за несколько минут добавить и хосты и пользователей и БД. Но зачем? Мне интереснее руками. Тем более, что я наваял скрипт добавления хостов, скрипт добавления бд и пользователя мускула. Теперь во с изоляцией сайтов разбираюсь...

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

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

[Виктор Таран]

isp 5

- голимая шляпа еще и пропреитарная, беее эту гадость я бы не посоветовал вообще никому.
я вам предлагал ispconfig3 а не ispmanager5 ;), там готовое есть но там установка 40 страниц мана да и отнють не все там готовое есть ;) остально докручивать и допиливать по этому само то дял обучения.

А подвигло вот что: у меня nextcloud на отдельной вм крутится, я решил оптимизировать ресурсозатраты и

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

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

гыгы ispconfig3 в руки ;) там с старта работает толкьо апачь +1 версия пхп +4 представления ;)
Все остальное своими ручками да еще и почти без манов и комьюнити ;)
На практике при использвание панели вы используете целую связку демонов
от fail2ban jailkit до PureFTP И иBIND9
И в жизни появляются именно эти связки, Так что все мелкие демоны и сервера желательно чтоб уже были отлажены и готовы. К примеру у меня настройка постфикс 3 страницы под кажыдй сайт. вы сами будете вечность в нем разбираться посколку там и подключение к бд и спам фильтр прикручен и DKIM DMARC PRR SPF и Fail2ban с ним до кучи в связке, интересные моменты проксирования при определенных условиях в общем бардак. Но он весь нужен и если вы возьметесь за самую основу боюсь что вы ооочень долго будете идти до полного понимания как работают веб сервера.
По сути у вас сейчас скорее всего lamp и все.
Вы на тестирования оптимального варианта кеширования для разных видов представления пхп уже дошли? а ведь без этого никак ;)
или вот например
у вас innodb_flush_log_at_trx_commit = 2 - стоит ? а это скорость сайта до 50 раз ! при определенных условиях

[Дмитрий]

По сути у вас сейчас скорее всего lamp и все.

Как бы LEMP. Апача у меня на веб-сервере нет)

у вас innodb_flush_log_at_trx_commit = 2

а тут MariaDB. У них настолько одинаковые конфиги?

[Дмитрий]

В любом случае спасибо за ответы.
Для себя понял, что иду правильным путем. Облако от сайтов изолировано (опустим тот факт, что сайты пока в одной куче).

Меня интересовало именно то, правильно ли:
site - владелец каталога www-data:www-data, сокет - php-fpm
nextcloud - владелец каталога www-cloud:www-cloud, сокет - php-fpm-cloud
Ну и права на каталоги 755, а на файлы 644.

По этому же принципу разделю ВСЕ сайты.

[Дмитрий]

Виктор Таран, Есть еще что-то, что явно нужно сделать для обеспечения безопасности облака на уровне веб-сервера?

[Виктор Таран]

Дмитрий, не, нормально

Answer 2

[Vitaly Karasik]

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

Comments

[Дмитрий]

Так у меня владелец директории с сайтами - www-data, а владелец nextcloud www-cloud. Права на каталоги 755, а на файлы 644.
Об этом речь? Или я не понял чего-то?

[Vitaly Karasik]

Дмитрий,
Да, речь об этом. (об этом же написал и Виктор)
При таких правах хакер, который взломает другой сайт, может:
1) менять файлы в директории nextcloud
2) читать файлы, включая конфиги с паролями к базе данных

Поэтому - наверно нужно отдельный инстанс nginx с другим пользователем\группой и оставить права только для owner.
Или отдельную виртуалку.

[Дмитрий]

Извините, но не понимаю, если:
сайт1 www-data:www-data. Права на каталоги 755, а на файлы 644.
сайт2 www-data:www-data. Права на каталоги 755, а на файлы 644.
nextcloud www-cloud:www-cloud. Права на каталоги 755, а на файлы 644.

Работают сайт1 и сайт2 от php-fmp пула www-data,а облако от пула www-cloud.

Это не безопасно? Я чего-то упускаю в понимании разграничения прав на каталоги?

[Vitaly Karasik]

сайт1 www-data:www-data. Права на каталоги 755, а на файлы 644.
сайт2 www-data:www-data. Права на каталоги 755, а на файлы 644.
nextcloud www-cloud:www-cloud. Права на каталоги 755, а на файлы 644.

это значит что каталоги и файлы доступны для чтения всем.

[Дмитрий]

Vitaly Karasik, а, понял, наконец. На файлы выставить 640, а на каталоги 750?

[Vitaly Karasik]

Дмитрий,
Да, правильно.
Сорри, что я сам не написал об этом, был погружен в работу.

[Дмитрий]

Vitaly Karasik, а я все догнать пытался в чем дело. Думал разделение сайтов реализую неверно, а тут вон чего)))
Да, согласен, для other - 0

[Дмитрий]

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

Сейчас у меня все настроено таким образом:
site1 - владелец www-site1:www-data, пхп-фпм пул www-site1, права выставлены 750 и 640
site2 - владелец www-site2:www-data, пхп-фпм пул www-site2, права выставлены 750 и 640

Вчера через админку обновил site2, так владельцем всех измененных файлов стал www-site2:www-site2, при этом, если назначить владельцем всего каталога сайта www-site2:www-site2 - сайт ложится.

Что я делаю не так снова?
Заранее благодарю за ответ!

[Vitaly Karasik]

Дмитрий, а под каким пользователем запущен вебсервер?
он должен иметь права на чтение.

[Дмитрий]

Vitaly Karasik, под пользователем www-data, если я правильно понял вопрос

[Vitaly Karasik]

Дмитрий, Да, про это я и спрашивал.
Сейчас вебсервер не имеет прав не чтение второго сайта, поэтому и не работает.
Есть два варианта решения:
1)

при этом, если назначить владельцем всего каталога сайта www-site2:www-site2 -

Назначить группу www-data, как и для первого сайта
2) более безопасный, но немного труднее - запустить еще один инстанс nginx, под группой www-site2

[Дмитрий]

Назначить группу www-data, как и для первого сайта

Дело в том, что у всех сайтов группа www-data, т.е.:
www-site1:www-data
www-site2:www-data

При этом, сайты работают, но файлы в директориях сайтов, после их изменения nginx'ом, получают владельца www-siteX:www-siteX. Почему?

Есть предположение, что виной всему конфиги пхп-фпм пулов, они у меня выглядят так:

[www-cloud]
user = www-cloud
group = www-cloud
listen = /run/php/php7.3-fpm-cloud.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
env[PATH] = /usr/local/bin:/usr/bin:/bin

Можетт, группа должна быть www-data в конфигах?

[Vitaly Karasik]

При этом, сайты работают, но файлы в директориях сайтов, после их изменения nginx'ом, получают владельца www-siteX:www-siteX. П

Честно говоря, не знаю как объяснить почему.

Но вы же писали что для site1 все работает, а для site2 нет? Тогда я бы сравнил в чем разница.

[Дмитрий]

Vitaly Karasik, возможно я неверно выразился или допустил ошибку в комментарии.
Конфиги сайтов одинаковые, конфиги их пулов одинаковые.
У всех сайтов наблюдается изменение группы владельца.

[Vitaly Karasik]

Дмитрий,

site1 - владелец www-site1:www-data,

Я думал site1 работает нормально.

Вчера через админку обновил site2

можно подробнее?

[Дмитрий]

Vitaly Karasik, постараюсь.
site1 - www-site1:www-data, php-fpm-site.1conf
site2 - www-site2:www-data, php-fpm-site2.conf
Оба сайта работают. Конфиги php-fpm вот такого вида:

[www-site1(2)]
user = www-site1(2)
group = www-site1(2)
listen = /run/php/php7.3-fpm-site1(2).sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
env[PATH] = /usr/local/bin:/usr/bin:/bin

Если зайти в админку любого из сайтов и, например, установить новую тему, то файлы этой темы будут www-site1(2):www-site1(2). Группа меняется с www-data на www-site1(2).
Разумеется, при таком поведении сайт рано или поздно, но неизбежно - ложится.

Как мы с Вами выяснили ранее, nginx работает от www-data, в группы www-site1(2) не входит, как и пользователи www-site1(2) не в группе www-data.

[Vitaly Karasik]

Дмитрий,

Да, надо использовать одну и ту же группу

group = www-data