Рубрика: Основы Debian

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

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

Чтобы добавить такое исключение, нужно создать условную запись на основе map_module. Результат вычисления условной записи не будет записываться в лог, если будет равен 0. Правило будет выглядеть так:

map $remote_addr $loggable {  "127.0.0.1" 0;  "::1" 0;  default 1; }

То есть, по-умолчанию результат равен 1, а для указанных ip — 0, и они не будут записаны в лог. Поддерживаются версии протокола 4 и 6. Обратите внимание, здесь первая переменная — это адрес подключившегося клиента. А вторую переменную нужно записать в параметрах access лога.

access_log /var/log/nginx/access.log combined if=$loggable;

Блок map можно прописать как на уровне http конфига nginx, так и на уровне server.

Исключение других данных из логов

Отключение логгирования конкретных ip — это только один пример из множества. Можно использовать различные переменные из стандартных.

Давайте отключим, в качестве примера, запись в лог страницы error.html. Для этого создадим такой блок:

map $request_uri $loggable {  ~*error.html 0;  default 1; }

И пропишем, как выше, параметр if в качестве аргумента для параметра access_log. После перезапуска nginx все запросы error.html не будут записаны. Включая вариации типа error.html?q=search. Для точного совпадения нужно прописать другое регулярное выражение.

Казалось бы, что может быть проще, чем добавить пользователя на сервере? Напечатал в консоли команду adduser, ответил на пару вопросов о пароле и другой информации, и вот, можно заходить с полученным логином и паролем, размещать файлы и т.д.

Затем, вручную, приходится создавать папки. Например, одну для сайта. Другую — для временных файлов, чтобы не бросать их в общий /tmp в целях защиты. Ещё одну — для сессий, если не настроено кэширование в Redis. А ещё же нужно скопировать нужные файлы настроек, типа публичного ssh ключа для аутентификации.

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

Первичные настройки, определяемые при использовании команды adduser, берутся из файла /etc/adduser.conf.

Изменяем домашнюю папку

Изначально домашние папки всех пользователей размещаются в разделе /home. Но мы можем заранее переопределить местоположение, используя любую другую папку, например /var/www. Для этого отредактируем параметр DHOME.

DHOME=/var/www

Следует обратить внимание на параметр SKEL=/etc/skel. Он определяет, откуда будут скопированы файлы настроек и папки для каждого конкретного пользователя. Наверняка вы видели в папках пользователей своего сервера файлы .profile, .bashrc. Они как раз скопированы из этого источника. :)

Добавление пользователей в единую группу

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

Когда создаётся юзер для размещения сайтов, право на редактирование/удаление файлов должно принадлежать только ему. Веб-сервер, будь то nginx или apache, должны запускаться от имени другого пользователя, которому доступно только чтение файлов. Остальные же пользователи никаких прав иметь не должны.

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

Общей группой станет группа пользователя www-data. Он специально создан для запуска веб-серверов, имеет максимально ограниченные права и не может пользоваться шелл-ом.

В файле adduser.conf нам нужно сначала отключить создание одноимённой группы при создании пользователя.

USERGROUPS=no

А, затем, указать ID группы www-data.

USERS_GID=33

Как правило, идентификатор равен 33. Но следует перепроверить командой, запускаемой от root: id www-data.

И последний параметр, изменяемый в этом конфигурационном файле:

DIR_MODE=0710

Он определяет права на домашнюю папку пользователя /var/www/username. Тут мы разрешаем все действия владельцу файлов, только исполнение для группы и не даём никаких прав всем остальным.

Права для конкретного пользователя и дополнительные файлы

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

umask 027

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

А для файлов 0640: чтение/изменение для владельца и только чтение для группы. Рекомендую самостоятельно изучить статью о правах доступа в Linux.

Также не забываем в каталоге /etc/skel обновить права на существующие файлы и папки командой chmod.

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

/etc/skel   -.ssh/   --authorized_keys   -sessions/   -tmp/   -www/   -.bashrc   -.profile

Всё это будет скопировано в домашний каталог пользователя при его создании.