Как правильно разместить сайт на Linux (папки сайта, пользователи, права и так далее)?

Правильно делать через docker.

Хорошо. Через докер. Расскажи, пожалуйста, какую структуру папок для сайта ты делаешь в этом случае?

Размещаешь данные сайта где? Кто владелец файлов сайта? Разрешено ли владельцу файлов сайта логиниться в bash ?

Ты заходишь под обычным линуксовым юзером, и в его домашнюю папку кидаешь docker-compose.yml или как?

Расскажи модель угроз. У тебя недоверенные пользователи? Это внутренние пользователи или внешние? Это разработчики или просто сайтовыкладыватели? Релевантны ли риски взлома http сервера или фиг с ними, из бэкапа накатим? Нужно ли uptime пять девяток или и так сойдёт?

Там почему все по-разному делают, потому что условия у всех разные.

...test, и от него сайт разместить – норм или не норм?

А ты сам-то как думаешь?

...круто делать?

Что значит «круто»?

Папку с логами для сайта где создавать?

Где удобно.

А, понял. Спасибо.

1. Модель угроз: минимизировать возможность получения прав суперпользователя в случае получения доступа к пользователю, от которого работает сайт.

Если можно так выразиться.

2. Пользователи – в основном, внешние. То есть, не пользователи системы Линукс.

3. Да, риски взлома http сервера релевантны, конечно.

4. uptime – 5 девяток, да.

А ты сам-то как думаешь?

По-разному, кто-то и так делает. Но я думаю, так делать плохо.

Что значит «круто»?

Хорошо так в плане безопасности или плохо? Какие подводные камни в таком случае?

Где удобно.

Понятно. Вполне логично.

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

Это редкость. Чаще через дыру в одном сайте, ломают другой на том же сервере.

Пользователи – в основном, внешние. То есть, не пользователи системы Линукс.

Имелось в виду другое, пользователи внутренние — это сотрудники организации, которым в случае чего, можно по голове настучать. А внешние это клиенты со стороны, к которым мало что предъявишь.

Да, риски взлома http сервера релевантны, конечно.

uptime – 5 девяток, да.

Ну тогда, действительно, докер. В non-privileged режиме. Если и взломают, получат данные из контейнера, да и только. Внешние read-only данные можно подключать read only. Для аптайма поднимать три сервера и городить между ними кластер.

Спасибо!

А как вы думаете: на сколько % улучшит безопасность сайта модуль owasp mod-security со стандартным набором правил owasp (которые поставляюся разработчиками)?

Если вопрос корректен.

Безопасности не бывает много. Бывает, что она становится слишком дорогой, и бывает, что она начинает мешать основной работе. Что делает её, опять же, слишком дорогой.

Поэтому надо всё измерить в деньгах. Например, у тебя там информация, которая нанесёт ущерб организации, если хакеры её опубликуют. Тогда надо вкладывать деньги в изоляцию: разносить кусочки информации на разные сервера, использовать уже не докер, а KVM, обезличивать данные в БД, хранить разные части в БД в разных местах. Считаем, сколько стоит публикация информации, в деньгах, какой ущерб она нанесёт, сколько будет стоить мероприятия по погашению эффекта.

Или там информация, которая боится пропадания. Клиенты будут недовольны, если их любимая коллекция хомячков пропадёт. (Или база данных документов правительства, хе-хе). Вкладываемся в бэкапы, бэкап раз в час дороже бэкапа раз в сутки, а бэкап раз в пять минут ещё дороже. Но если цель оправдывает средства — покупаем.

Или там биржевые боты, простой которых в один час приносит миллиард убытков. Ну тут уже кластеры, несколько разнесённых георграфически ДЦ, желательно собственные, резервные каналы, генераторы.

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

Поэтому. Пусть для тебя критично именно невозможность взлома http сервера. Пусть установка mod-security не потребует многих часов работы админа. Тогда можно предположить, что стоимость защиты сильно ниже стоимости информации и сделать вывод — ставить.

Спасибо.

А как вы думаете: на сколько % улучшит безопасность сайта модуль owasp mod-security со стандартным набором правил owasp (которые поставляюся разработчиками)?

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

Если ты вообще ни в чём не разбираешься, ставишь себе дырявые движки и не знаешь что с ними делать - возможно оно и заблокирует тебе какую-нить sql-инъекцию, в остальных случаях эта штука строго вредна.

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

Теперь ответы:

Как делать правильно? Зайти на сервер юзверем test, и от него сайт разместить – норм или не норм?

Для размещения сайта лучше использовать не шелл (bash итд) а другие инструменты. В идеале - система деплоя (некоторые её делают через систему контроля версий, некоторые другими инструментами), если же «клиенты» не хотят её осваивать - то sftp.

Я видел, что делали для каждого сайта отдельного юзера

Правильный подход.

которому запрещали заходить в баш

Тут стоит скорее подумать не про заход в баш как таковой. Точнее, так: само по себе разрешение подключиться по ssh (при уже имеющемся разрешении запускать пхп-скрипты от того же юзера) критического влияния на безопасность не оказывает. Однако, от определённой категории тупых проблем случайно уберечь может. Например, взломщик уже украл пароль, попытался подключиться с ним по ssh, не смог, а на фтп зайти не догадался.

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

Если так делать, то неудобно новые файлы сайта заливать – правильно или нет?

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

Папку с логами для сайта где создавать?

Есть два подхода:

1) на фтп рядом со скриптами в /home

2) в отдельном месте в /var

Вот я создал папку с логами вот тут /var/log/nginx/test.site – а потом думаю: А если домен сайта поменяется? Некрасиво же будет, что логи будут в папке со старым доменом. А руками тоже переделывать не очень.

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

папке

На такое принято отвечать фразами по мамку. Это называется директория, на самом деле. Папка - виндузятничество.

...так делать плохо.

Так точно!

Хорошо так в плане безопасности или плохо?

Да нормально. Но учти, что периодически надо будет выполнять аудит ИБ.

Попросите, пожалуйста, санитаров скорее запереть пациента подальше от общества. (%

1. Файлы по умолчанию размещаются в /var/www/html 2. пользователя трогать не надо. Сайт работает по умолчанию от пользователя www-data 3. Безопасность и скорость будет если использовать генератор статических сайтов. Например Astro . 4. Это большая тема. Начни с чего нибудь.

У тебя датацентр по питанию-то о пять девяток обеспечит?

Что тебе не понравилось?

Я знаю, что в мод-секьюрити можно отключать отдельные правила. Например, он блокирует нужный урл – пишет причину. И можно просто прописать в конфиге, чтобы он не блокировал конкретный урл.

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

Что тебе не понравилось?

По пунктам? (=

папка с файлами

норм или не норм?

круто

неудобно новые файлы сайта заливать

красиво

Папку с логами
папку с логами
в папке

руками тоже переделывать не очень

структуру папок
домашнюю папку

Ну а теперь по делу:

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

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

с юзером test (юзер создался при установке, состоит в группе sudo)

sudo

Вот это ОЧЕНЬ плохо. Особенно учитывая что sudo повышает привилегии посредством пароля самого пользователя.

неудобно новые файлы сайта заливать

Удобство всегда противоположно безопасности.

Удобно ли хранить ружьё в прихожей? Удобно — на выходе взял и пошёл. Безопасно ли? Нет — любой может его схватить и направить на тебя.

Папку с логами для сайта где создавать?

Туда, где пользователь, от которого крутится веб-сервер (не бэкенд!), может писать. Логи бэкенда — отдельно.

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

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

Как изначально сделать структуру максимально гибкой

Никак.

uptime – 5 девяток, да.

Настраивать HA на нескольких физически разных серверах с разными провайдерами. Бэкапы по гибридным схемам.

на сколько % улучшит безопасность сайта

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

Есть папка с файлами сайта и Ubuntu 24,04 LTS с юзером test (юзер создался при установке, состоит в группе sudo), которому разрешено заходить в bash.

sudo дает по паролю самого юзера test доступ ко всей системе, так делать нельзя.

Как делать правильно? Зайти на сервер юзверем test, и от него сайт разместить – норм или не норм?

Норм

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

bash/sh от задачи зависит. Если есть автодеплой и ни чего руками делать не надо, то можно не давать доступ. Если разработчику надо еще что-то руками потрогать, сделать запросы в БД, посмотреть какие есть файлы, то запрещение доступа по ssh создаст ему проблемы. Всякие uwsgi, php-fpm и т.п. должны запускаться в докере.

Короче, надеюсь, мой вопрос понятен: Как красиво и правильно размещать сайт на линуксе. Папку с логами для сайта где создавать?

Где угодно, лишь бы веб-сервер эти логи не раздавал

Вот я создал папку с логами вот тут /var/log/nginx/test.site – а потом думаю: А если домен сайта поменяется? Некрасиво же будет, что логи будут в папке со старым доменом. А руками тоже переделывать не очень.

Домены меняются прям очень редко. Может быть, что на один и тот же сайт может иметь несколько доменов.

Как изначально сделать структуру максимально гибкой и безопасной?

Если у тебя много сайтов, то лучше делать по принципу 1 сайт – 1 сервер. Тогда есть возможность стандартизировать названия логов, места, где хранятся файлы.

Еще я бы не советовал, чтобы порты всяких баз данных торчали наружу. Вход по ssh только по ключу. Для root можно оставить пароль, но очень длинный. 5 ошибочных ввода пароля по ssh – блокировка на 1 день IP адреса.

Бекапы нужно делать ежедневные, раз в месяц бекап всего сервера через консоль хостера.

FTP пользоваться не советую, этот протокол не гарантирует полную передачу файла

Бэкапы по гибридным схемам.

Это как?

FTP пользоваться не советую, этот протокол не гарантирует полную передачу файла

Это вы путаете с http.