journalctl (просмотр журнала systemd)

Что читает journalctl и как хранится журнал

systemd-journald собирает сообщения ядра, служб и всего, что пишет через syslog или стандартный вывод, и хранит их как индексированные бинарные записи. journalctl это просмотрщик этого хранилища. Каждая запись состоит из полей. Поля вроде MESSAGE и PRIORITY задаёт программа, которая пишет в журнал. Поля с префиксом подчёркивания, такие как _SYSTEMD_UNIT, _PID, _UID и _EXE, добавляет сам journald, и клиентский код не может их изменить, поэтому при расследовании им можно доверять больше, чем тексту сообщения (systemd.journal-fields(7)).

Где лежит журнал, определяет параметр Storage= в journald.conf(5). Значение volatile хранит журнал в памяти в /run/log/journal, persistent пишет его в /var/log/journal, а auto ведёт себя как persistent только если этот каталог уже существует. Значение по умолчанию выбирается при сборке systemd, поэтому не полагайтесь на него и задайте параметр явно. Читать системный журнал может root или участник групп systemd-journal, adm или wheel, см. journalctl(1).

Фильтры журнала: команды, которые нужны на практике

Обычно хватает нескольких фильтров в сочетании. -u выбирает службу, -p приоритет (один уровень включает и все более серьёзные, а FROM..TO задаёт диапазон), -S и -U окно времени, -b загрузку системы (-b -1 это предыдущая), -k сообщения ядра, а -g шаблон для поиска по тексту сообщения. -f показывает последние записи и продолжает выводить новые.

journalctl -u ssh --since "1 hour ago" -p warning
journalctl -u ssh --since yesterday --until today -g "Failed|Invalid user"
journalctl -b -1 -k
journalctl -f -u nginx
journalctl -u ssh -n 5 -o json-pretty --no-pager

Служба SSH называется ssh в Debian и Ubuntu и sshd в семействе RHEL. Форматы вывода, выбираемые через -o, включают short (по умолчанию), short-iso, verbose, json, json-pretty, export и cat. Команда -F _SYSTEMD_UNIT перечисляет все службы, которые писали в журнал, что быстро показывает, кто вообще ведёт записи. Добавляйте --utc, когда сравниваете время с логами других серверов.

Хранение, ограничение частоты и то, что журнал не доказывает

Энергозависимый журнал пропадает при перезагрузке, а после взлома он нужен именно тогда. Сделайте хранение постоянным и ограничьте размер с помощью drop-in файла, затем перезапустите systemd-journald:

# /etc/systemd/journald.conf.d/50-persistent.conf
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=3month

Без SystemMaxUse= журнал может занять до 10% файловой системы и оставляет свободными 15%, причём каждое значение ограничено 4G. Объём смотрите командой journalctl --disk-usage, а архивные файлы чистите через --vacuum-size=, --vacuum-time= или --vacuum-files=. Активные файлы не удаляются, а --rotate предварительно архивирует их. Кроме того, journald ограничивает частоту сообщений каждой службы, по умолчанию 10000 сообщений за 30 секунд, поэтому очень шумное событие может вытеснить собственные следы.

Помните о границах доверия. Root может удалить журнал, а Forward Secure Sealing позволяет обнаружить последующее изменение только если вы создали ключ командой --setup-keys; тогда файлы проверяет journalctl --verify. Локальный журнал это улика, а не доказательство.

Журнал в мониторинге и реагировании на инциденты

На сервере с systemd журнал это основной локальный источник событий аутентификации и служб, поэтому с него начинается мониторинг: ежедневный просмотр journalctl -u ssh -p warning --since yesterday и внимание к любому новому Accepted с незнакомого адреса. В нашем руководстве по мониторингу перечислено, за чем следить, а руководство по защите SSH от перебора объясняет, что означает шум неудачных входов и как fail2ban его блокирует.

Поскольку тот, кто получил root, может стереть локальный журнал, храните копию в другом месте. Передайте сообщения в rsyslog для пересылки или следуйте руководству по SIEM для небольшого сервера. При подозрении на взлом экспортируйте журнал до любых изменений (journalctl -o export с перенаправлением вывода в файл), скопируйте его с сервера и действуйте по руководству по реагированию на взлом. Для того, что журнал не фиксирует, например кто запустил какую команду или тронул какой файл, добавьте auditd.

Связанные термины: rsyslog, auditd, SIEM, fail2ban, Реагирование на инциденты.