LINUX.ORG.RU

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

 , , ,


1

2

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

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

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

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

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

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

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



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

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

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

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

truebin
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где удобно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

firkax ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

папке

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

firkax ★★★★★
()

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

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

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

truebin
() автор топика

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

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

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

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

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

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

круто

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

красиво

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

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

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


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

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

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

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

sudo

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

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

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

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

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

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

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

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

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

Никак.

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

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

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

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

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 1)

Есть папка с файлами сайта и 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 пользоваться не советую, этот протокол не гарантирует полную передачу файла

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

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

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

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

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

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

3-2-1 + incremental local + full local + incremental remote + full remote + validation. Одна или несколько полных копий являются R/O зеркалом на других серверах, или R/W и с них тоже делаются бэкапы по той же схеме. Ему же 99.999% SLA нужон, так что стоимость обслуживания этого всего должна быть второстепенна.

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

Я было подумал блочный\файловый уровень копирования)

Если это контейнер или виртуалка, можно дополнительно сделать блочный уровень, лишним не будет. (% Но на SLA это не повлияет. (=

Хотя если сделать ротацию контейнеров/виртуалок за балансировщиками, можно и на этом сыграть, только сильно дороже выйдет.

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

только сильно дороже выйдет.

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

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

Почему-то думаю что у автора всё проще

Я думаю что и SLA ему такой высокий не нужен, но раз заявлено… (%

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

Это же форум, я пишу сразу с прицелом на то, что кому-нибудь другому в будущем может пригодиться. Топикстартеры приходят и уходят, знания — остаются! :3

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

Это же форум, я пишу сразу с прицелом на то, что кому-нибудь другому в будущем может пригодиться. Топикстартеры приходят и уходят, знания — остаются! :3

Ну это да. За то и любим :)

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

Топикстартеры приходят и уходят

Я если ухожу, то только как центральный персонаж на своей аватарке. :)

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

Топикстартеры приходят и уходят

Я если ухожу, то только как центральный персонаж на своей аватарке. :)

Я это изначально написал. (=

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

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

Та ладно. Я нормальный человек. Просто пошутил.

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

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

Ну, привык я называть папки папками. Inode типа «директория» в Linux – или как правильно?

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

Ладно бы, если бы в Линуксе все работало всегда так, как пишется в доках. Или всегда доки были нормальные по всему. Лично я вижу обратное: часто надо тестировать разное ПО в Линуксе. Проверять, а так ли оно работает, как написано в доке. (У меня лично ситуация обстоит таким образом). Линукс – для меня просто ОС. Как и Windows.

Мне на десктопе Линукс не нужен. Я не наяриваю на него нефритовый стержень. Система хорошая, не спорю.

truebin
() автор топика
Последнее исправление: truebin (всего исправлений: 4)

Я, когда охота сделать нормально, а не тяп ляп, делаю так:

Сам сервер приложений, шаблоны, конфиги и прочее исполняемое и полуисполняемое лежит где-то, куда писать может только рут.

Сервер приложений запускается под отдельным пользователем. Если серверу приложений надо куда-то писать файлики, то где-то в /var или /srv делаю отдельную папочку куда можно писать этому пользователю.

nginx в роли реверс-прокси и раздавалки статики в дистрах обычно с адекватными правами изначально настроен.

Когда лень делать по-нормальному, это прототип и всякое такое, то сваливаю куда-то в /home/myuser и от этого myuser, на котором и сижу как человек, всё и запускаю.

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

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

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

Я нормальный человек.

Как быстро ты переобулся. xD

Просто пошутил.

Я тоже. (=

Ну, привык я называть папки папками.

На ЛОРе за «папки» бьют ссаными тряпками, привыкай. (=
Единственное, где они действительно "папки" (folders) — электронная почта. Вот так вот. (=

Мне на десктопе Линукс не нужен.

Мне он и на сервере не нужен. (%
Ведь есть божественная FreeBSD! :3

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

На ЛОРе за «папки» бьют ссаными тряпками, привыкай. (=

Просто это очень привязанные люди. Это люди, которые испытывают привязанности к Линуксу. :)

Будда не одобряэ. Их проблемы, тассать. :)

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

Ведь есть божественная FreeBSD! :3

Ооой. А расскажи. Расскажи, пожалуйста, про нее. Что, в ней нет зоопарка утилит для настройки одного и того же? Она более стабильна в каких-то отношениях?

Чем лично тебе она нравится?

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

Это люди, которые испытывают привязанности к Линуксу. :)

Увы, нет. Они привязаны к своему маленькому загончику в этом бескрайнем линукс-зоопарке: дистрибутив, DE… И постоянно воюют между собой: GNOME vs. KDE, Vim vs. Emacs…

Что, в ней нет зоопарка утилит для настройки одного и того же?

За исключением трёх файерволлов (на выбор) — нет. (%

Она более стабильна в каких-то отношениях?

Сама система — да. Но прикладной софт из портов/пакетов тот же что и в линуксе, так что проблемы с ним всё те же (иногда другие из-за отличий в платформе, но с этим обычно сталкиваются только мейнтейнеры).

Чем лично тебе она нравится?

Простотой.

У меня дома FreeBSD и на десктопе, и на ноуте, и на сервере и даже на маршрутизаторе. Единственная железка, где всё ещё Linux — беспроводной роутер с OpenWrt, куда FreeBSD просто не влезет. Ну и смартфон с iOS (в которой немало от FreeBSD, хоть и со своим ядром и большей частью юзерспейса). (=

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

Ясненько. Спасибо за ответ. А какими программами на Десктопе ты пользуешься? Если не секрет.

Просто на Windows – раз, и скачал нужную программу. Захотелось Фотошоп скачать – качай. И так далее.

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

Просто на Windows – раз, и скачал нужную программу. Захотелось Фотошоп скачать – качай. И так далее.

Скачать-то ты можешь что угодно на любой ОС… (%
Большинство UNIX-like заимствовали централизованный репозиторий с софтом ещё из оригинальной Berkeley Software Distribution, и Linux и уж тем более FreeBSD не стали исключением. Иногда можно найти бинари, собранные для FreeBSD (и других платформ) на том же Github, но это скорее исключение.

А какими программами на Десктопе ты пользуешься? Если не секрет.

Не секрет, но вряд ли тебе это будет действительно интересно, так как подавляющее большинство это софт с TUI или CLI. Из графического только qutebrowser, gimp, zathura для просмотра PDF и kid3 для редактирования тегов мультимедии. Это на самом деле исчерпывающий список установленного у меня графического софта. Того, что с TUI/CLI, гораздо больше.

mord0d ★★★★★
()
Ответ на: комментарий от truebin
  • angband (рогалик по Толкину)
  • atool (обёртка для архивов)
  • gomuks (Matrix-клиент)
  • htop (менеджер процессов)
  • isync + notmuch + neomutt + msmtp (почта)
  • ncmpcpp + mpd (музыка)
  • numbat (калькулятор)
  • pass (пароли)
  • ranger (файловый менеджер)
  • rclone (для монтирования WebDAV, SFTP и прочего)
  • taskwarrior + tudu (+ tatuin) (задачи)
  • git + tig (последний используется только для просмотра)
  • tmux + zsh (мультиплексор и шелл)
  • vim (текстовый редактор)
  • zap (бэкапы с ZFS)

И ещё куча штатных утилит из базовой системы FreeBSD.

Всё это запускается либо в ядерной консоли (tty), либо в эмуляторе терминала tym (поделка азиатского студента, в которой нет ни вкладок, ни контекстного меню, ни каких-либо красивостей, что и было решающим при его выборе), который в свою очередь запускается в AwesomeWM.


А ещё на домашнем сервере крутится немало всякого, в том числе с веб-интерфейсом, некоторое даже торчит в интернеты через несколько реверс-прокси. Несколько nginx потому, что белого IP дома нет, а на VPS всё не поместится (общее количество данных трудно подсчитать, более 1.2 терабайта, наверное) и VPS слишком слабое (текущее потребление всех домашних сервисов — 153 гигабайта оперативной памяти). Да и не стал бы я хранить свои данные "где-то там" у левого дяди (хотя хостера и его команду я знаю, классные ребята).

mord0d ★★★★★
()