Журналы и аудит входов на сервере
Журналы отвечают на три вопроса: что сломалось, кто заходил на сервер и что он делал. Ответ есть, только если журналы включены, хранятся достаточно долго и не лежат на том же сервере, который могли взломать. Разберём, где их искать в Linux, какие команды показывают входы, как настроить ротацию и что сделать заранее, чтобы после инцидента было что разбирать.
В Linux с systemd журналы пишут две системы. Служба journald из systemd собирает сообщения всех служб, ядра и входов в двоичный журнал. Служба rsyslog, если она установлена, раскладывает те же сообщения по текстовым файлам в /var/log. Веб-сервер, база данных и Docker ведут собственные журналы. Знать, где что лежит, нужно до инцидента, а не во время него.
Где лежат журналы
- journald. Читается командой
journalctl. Журнал хранится на диске, если существует каталог/var/log/journal, иначе только в памяти и пропадает при перезагрузке (journald.conf, параметрStorage=auto). Проверьте это на новом сервере:ls /var/log/journal. Если каталога нет, создайте его и перезапустите службу:systemctl restart systemd-journald. - Системные файлы. В Ubuntu входы и sudo пишутся в
/var/log/auth.log, общие сообщения — в/var/log/syslog. В AlmaLinux и Rocky Linux это/var/log/secureи/var/log/messages. В Debian 12 и новее rsyslog по умолчанию не ставится, и всё есть только в journald. - Веб-сервер. nginx пишет в
/var/log/nginx/access.logиerror.log, Apache — в/var/log/apache2/в Debian и Ubuntu или в/var/log/httpd/в AlmaLinux. Журнал доступа показывает каждый запрос: адрес, время, путь, код ответа, размер, браузер. Состав полей задаётся директивой log_format; если сайт стоит за CDN, настройте передачу настоящего адреса посетителя, иначе в журнале будут только адреса CDN (подробнее в статье CDN: когда нужен сайту). - Приложения и Docker. Базы данных пишут в свои каталоги в
/var/log, а контейнеры — в файлы Docker, которые читаются командойdocker logs.
Несколько команд journalctl, которых хватает в большинстве случаев: journalctl -u nginx --since "1 hour ago" — сообщения одной службы за час; journalctl -p err -b — ошибки с последней загрузки; journalctl -f — поток новых сообщений; journalctl --disk-usage — сколько места занимает журнал.
Кто входил на сервер
Каждый вход по SSH оставляет запись с именем пользователя, адресом и способом входа: ключом или паролем. Посмотреть успешные входы можно так:
- в journald:
journalctl -u ssh --since today | grep Accepted(в AlmaLinux служба называетсяsshd); - в файле:
grep Accepted /var/log/auth.logили/var/log/secure; - сводкой: команда
lastпоказывает входы и перезагрузки,lastb— неудачные попытки.
В Debian 13 команд last, lastb и lastlog больше нет: их старые файлы не умеют хранить даты после 2038 года. Вместо них предлагаются пакеты wtmpdb и lastlog2 (примечания к выпуску Debian 13). Записи Accepted в журнале остаются в любой версии.
Что проверять. Входы с незнакомых адресов и в необычное время. Входы по паролю, если вы настроили вход только по ключу: значит, настройка не применилась. Команды через sudo: в auth.log и в journald для каждой записано, кто и что выполнил. Новые ключи в ~/.ssh/authorized_keys и новые пользователи в /etc/passwd: их добавляют, чтобы вернуться на сервер позже. Если нужен подробный аудит изменений файлов и команд, в Linux есть подсистема аудита auditd, но её правила требуют отдельной настройки и места на диске.
fail2ban: что он даёт, кроме SSH
fail2ban читает журналы и временно блокирует адреса, которые раз за разом ошибаются при входе. Установка и защита SSH описаны в статье Первые 10 шагов после покупки VPS. По умолчанию адрес блокируется на 10 минут после 5 ошибок за 10 минут (jail.conf). Что стоит добавить:
- Длинные блокировки для повторных нарушителей. Правило
recidiveчитает журнал самого fail2ban и блокирует на неделю адрес, который попадался несколько раз за сутки. Параметрbantime.increment = trueудваивает срок с каждой новой блокировкой. - Правила для веб-сервера. Готовые правила
nginx-http-auth,nginx-limit-reqиnginx-botsearchреагируют на ошибки пароля на закрытых страницах, превышение лимита частоты запросов и перебор несуществующих адресов. - Свои адреса в исключениях. Параметр
ignoreipсо статическим адресом офиса избавит от блокировки самого себя.
fail2ban не защищает от распределённых атак с тысяч адресов и не заменяет вход по ключу. Его главная польза для аудита — короче журнал: в нём остаются осмысленные события, а не десятки тысяч одинаковых попыток подбора пароля. Список заблокированных адресов показывает fail2ban-client status sshd.
Ротация и место на диске
Журналы растут постоянно, а на недорогих VPS диск небольшой. По каталогу accsly.io на ноябрь 2026 года у тарифов VPS с 1 ГБ памяти медианный диск — 20 ГБ, а у 9% тарифов VPS диск 20 ГБ или меньше. Журнал доступа нагруженного сайта или контейнер, который пишет ошибку в цикле, заполняют такой диск за дни, после чего перестают работать база данных и сам сайт.
- journald по умолчанию занимает не больше 10% файловой системы и не больше 4 ГБ. Задать свой предел можно параметром
SystemMaxUse=в/etc/systemd/journald.conf, а срок хранения — параметромMaxRetentionSec=, который по умолчанию выключен. Разово освободить место:journalctl --vacuum-size=500Mили--vacuum-time=30d. - Текстовые файлы ротирует logrotate по правилам из
/etc/logrotate.d/. В Ubuntu 24.04 системные журналы ротируются раз в неделю, хранятся 4 старых файла, то есть около месяца. Журналы nginx из пакета AlmaLinux 9 — раз в сутки, 10 старых файлов. Параметрыrotate,dailyилиweekly,compressиmaxsizeменяют срок, сжатие и ротацию по размеру. Режимcopytruncateподходит программам, которые не умеют переоткрывать файл, но по документации может терять строки. Проверить правило без изменений:logrotate -d /etc/logrotate.d/nginx. - Docker по умолчанию пишет журналы контейнеров без ограничения размера (драйвер json-file). Задайте
max-sizeиmax-fileв/etc/docker/daemon.jsonи пересоздайте контейнеры: настройки применяются только к новым. Подробнее — в статье Docker на VPS: с чего начать.
Найти, что заняло диск: df -h покажет заполненный раздел, du -xh /var/log | sort -h | tail — самые большие каталоги. Не удаляйте файл журнала, который служба держит открытым: место не освободится, пока служба не перезапустится. Очистите его командой truncate -s 0. Предупреждение о заполнении диска лучше получать заранее — об этом статья Мониторинг сервера: аптайм, нагрузка, алерты.
Как хранить журналы для разбора инцидента
Если сервер взломали, первое, что делает взломщик с правами root, — правит или удаляет журналы. Поэтому копия, которая уходит с сервера сразу, ценнее любых настроек хранения на нём самом.
- Отправляйте журналы на другой сервер. rsyslog умеет пересылать сообщения по сети, у journald для этого есть служба systemd-journal-upload. Принимающий сервер — отдельный недорогой VPS с диском побольше или система сбора журналов вроде Loki, Graylog или OpenSearch; тарифы под неё собраны в подборке VPS для Elasticsearch.
- Решите, сколько хранить. Для разбора большинства инцидентов нужны журналы за 30–90 дней: взлом часто обнаруживают не в день проникновения. На самом сервере хватит недели-двух, остальное — на сервере сбора или в архиве.
- Синхронизируйте время. Без точного времени нельзя сопоставить события на разных серверах. Проверьте
timedatectl: строка «System clock synchronized» должна показывать yes. - Не держите в журналах лишнего. Пароли, токены и полные номера карт в журнал попадать не должны. IP-адреса и логины пользователей могут считаться персональными данными, поэтому срок хранения стоит прописать в политике обработки данных; подробнее в статье 152-ФЗ и хостинг.
- При инциденте сначала сохраните, потом чините. Скопируйте журналы и сделайте снимок диска у хостера до переустановки системы. Как устроены снимки и резервные копии, описано в статье Резервные копии VPS.
Если журналы нужны не только для разбора, но и для оповещений — о всплеске ошибок 500 или входе под root, — их собирают вместе с метриками на отдельном сервере мониторинга. Тарифы под такую задачу — в подборке VPS для мониторинга.