Журналирование событий безопасности: что собирать и где это хранить

MAATRIX

Когда сервер уже взломан или в компанию пришёл запрос от регулятора, вопрос «а что у нас логируется» задают постфактум — и почти всегда выясняется, что либо не логируется вообще ничего сверх стандартного journald, либо логи есть, но лежат на том же сервере, который скомпрометирован, и злоумышленник их уже почистил. Журналирование событий безопасности — это не разовая настройка «для галочки», а система: понятный список того, что писать, защищённое от подмены хранилище и срок хранения, которого хватит на реальное расследование. Разберём, как выстроить это на практике, без привязки к конкретному дорогому SIEM.

Зачем это вообще нужно, если аудит не требуется

Даже если ваш проект не подпадает под формальные требования регулируемых систем (ГОСТ, PCI DSS, отраслевые нормативы для операторов персональных данных и связи), журналирование событий безопасности всё равно окупается на первом же инциденте. Разница между «сервер лежал полчаса, разобрались за десять минут по логам» и «сервер лежал полчаса, потом ещё два дня гадали, что произошло» — это ровно наличие вменяемых логов аутентификации, сети и привилегированных действий.

Есть и вторая, менее очевидная причина. Хорошее логирование безопасности — это не только про «поймать нарушителя», но и про самозащиту администратора: когда через полгода клиент или коллега спрашивает «кто удалил эту таблицу» или «почему упал firewall», у вас должен быть ответ, а не пожатие плечами. При подготовке сервера к аудиту безопасности проверяющие почти всегда начинают именно с вопроса «покажите логи за последние N дней».

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

Категория первая: аутентификация и авторизация

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

Что сюда входит:

• успешные и неуспешные попытки входа по SSH (пароль, ключ, MFA);
• вход в веб-панели администрирования (хостинг-панель, CMS, VPN-портал);
• смена паролей и добавление/удаление SSH-ключей;
• срабатывания двухфакторной аутентификации — успехи и отказы;
• блокировки учётных записей после превышения числа попыток.

На Linux-сервере основной источник — journalctl -u sshd или, если используется классический syslog, /var/log/auth.log (Debian/Ubuntu) и /var/log/secure (RHEL/AlmaLinux). Полезно сразу выделить отдельный фильтр для неуспешных попыток:

journalctl -u ssh --since "24 hours ago" | grep -E "Failed password|Invalid user"

Если у вас настроен вход по ключу без пароля, не забудьте, что сам факт использования конкретного ключа тоже стоит логировать: при инциденте важно понять не только «кто-то зашёл», а «зашли именно ключом сотрудника Х, а не общим deploy-ключом».

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

Категория вторая: изменения конфигурации

Второй по важности слой — кто и что менял в настройках системы. Атака редко ограничивается одним действием: получили доступ, потом что-то поменяли (добавили пользователя, ослабили firewall, отключили мониторинг), чтобы закрепиться.

Практический список файлов и действий, за которыми стоит следить:

• изменения /etc/passwd, /etc/shadow, /etc/sudoers, /etc/group;
• правки конфигов SSH (/etc/ssh/sshd_config), firewall (nftables/iptables, ufw), systemd-юнитов;
• установка и удаление пакетов через apt/dnf/yum;
• изменения в cron и systemd timers — классический способ закрепления;
• правки конфигов веб-сервера и обратных прокси (nginx, Apache).

Здесь обычного journald недостаточно — он видит только то, что явно логируют сами сервисы. Изменение файла через vi или sed пройдёт мимо journald, но будет видно ядру. Для этого уровня нужен auditd — подробно его настройка разобрана в статье про аудит логов через auditd: она хорошо дополняет журналирование безопасности именно на уровне файлов и системных вызовов. Минимальный набор правил для файлов конфигурации:

auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/shadow -p wa -k identity
auditctl -w /etc/sudoers -p wa -k privilege_escalation
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config

Флаг -p wa означает «писать при попытке записи (write) или смены атрибутов (attribute change)», -k — метка для последующего поиска через ausearch -k identity.

Категория третья: сетевые подключения

Сетевой уровень отвечает на вопрос «откуда и куда шёл трафик» — это критично при разборе как внешних атак, так и утечки данных изнутри.

Что стоит собирать:

• срабатывания правил firewall (deny/reject/accept для интересующих портов);
• исходящие соединения с сервера к внешним адресам — особенно если сервер обычно не должен ничего инициировать наружу;
• подключения к базе данных и другим внутренним сервисам с непривычных IP;
• VPN-подключения (кто, откуда, когда, сколько длилась сессия).

Для firewall на базе nftables/iptables логирование настраивается явным правилом логирования перед правилом блокировки:

nft add rule inet filter input log prefix "fw-drop: " drop

Для VPN (WireGuard, OpenVPN) сами протоколы не всегда пишут подробные логи подключений «из коробки». Практический момент: WireGuard в базовой конфигурации не пишет журнал подключений вообще, эту функциональность обычно добавляют отдельным скриптом или сторонним инструментом поверх — если вам нужен полноценный аудит VPN-доступа, закладывайте это заранее, а не постфактум.

Отдельно стоит логировать сетевые подключения на уровне контейнеров, если используется Docker — по умолчанию Docker может открывать порты в обход правил firewall на хосте, и это классическая ловушка. Логи такого рода подключений нужно собирать не только на уровне iptables, но и на уровне самого Docker daemon.

Категория четвёртая: действия с привилегированными правами

Это самая чувствительная категория — всё, что делается от имени root или через sudo. Именно здесь чаще всего прячутся как злонамеренные действия, так и банальные человеческие ошибки с необратимыми последствиями.

Что логировать:

• каждый вызов sudo — кто, какую команду, от чьего имени;
• прямые входы под root (если они вообще разрешены — что само по себе стоит пересмотреть);
• изменение прав доступа к файлам (chmod, chown) для системных каталогов;
• запуск и остановку системных сервисов;
• любые действия внутри баз данных под административной ролью (создание/удаление пользователей БД, изменение прав).

sudo по умолчанию пишет в syslog/journald каждую вызванную команду — это часто недооценивают. Проверить, что логирование действительно работает, можно так:

journalctl _COMM=sudo --since "7 days ago"

Если в выводе пусто, а sudo активно используется — значит, логи sudo либо перенаправлены не туда, либо их вообще стирает более агрессивная ротация. Это реальная и частая проблема: по умолчанию многие системы не сохраняют достаточно контекста, чтобы через месяц ответить на вопрос «кто именно это сделал», и выясняется это обычно в худший момент.

Отдельная рекомендация: для критичных серверов стоит настроить sudo так, чтобы полная командная строка попадала в лог без сокращений (Defaults log_input,log_output в /etc/sudoers — это пишет не только команду, но и весь ввод/вывод сессии, что полезно при расследовании, но ощутимо увеличивает объём логов, так что для этого нужен трезвый расчёт места).

Хранение: защита от изменения, срок, централизация

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

Защита от изменения (immutability). Локальные логи должны быть максимально сложно перезаписать даже тому, у кого есть root на этом сервере. Базовый уровень — атрибут chattr +a (append-only) на файлы логов, чтобы их можно было только дописывать, а не редактировать задним числом:

chattr +a /var/log/auth.log

Это не панацея (root может снять атрибут обратно), но поднимает планку и оставляет след — сама попытка снять +a тоже логируется через auditd, если на неё настроено правило. Более надёжный вариант — отправка логов сразу на удалённый сервер, куда у скомпрометированной машины нет прав на удаление уже принятых записей (write-only канал). Подробнее о вариантах защиты — в статье «как хранить логи, чтобы их нельзя было переписать».

Срок хранения. Универсального числа тут нет — обычно требуется хранить логи не менее определённого срока, уточняйте в требованиях к конкретной системе (для регулируемых сфер — в применимой нормативке, для внутренних нужд — исходя из того, за какой период вы реально готовы расследовать инцидент). Подробнее вопрос сроков разбирался в материале «сколько хранить логи» — там же практический ориентир для собственной пользы: хранить оперативные логи (быстрый доступ) 30–90 дней, а архив в сжатом виде — от полугода до года, если позволяет место. Это не юридическая норма, а рабочий баланс между полезностью и объёмом хранения, который стоит скорректировать под вашу ситуацию.

Централизация. Если у вас больше одного сервера, логи должны стекаться в одно место — иначе при инциденте вы будете вручную обходить каждую машину, теряя время, которого при активной атаке может не быть. Практическая схема сбора логов с нескольких серверов разбиралась отдельно в статье «сбор логов с нескольких серверов»: вкратце, каждый сервер отправляет логи через syslog-forwarding (rsyslog/journald с ForwardToSyslog) или через агент (Filebeat, Promtail) на центральный коллектор — Graylog, Grafana Loki или аналог.

Практическая организация: собираем всё в одном месте

Разберём минимальную рабочую схему на одном VPS с централизованным приёмником логов на отдельном сервере — именно отдельном, чтобы компрометация продакшена не означала автоматом компрометацию логов.

Шаг 1 — включаем auditd на всех серверах, которые нужно аудировать, с правилами из разделов выше (identity, sudoers, sshd_config, плюс отслеживание execve для привилегированных пользователей).

Шаг 2 — настраиваем пересылку журналов на центральный сервер. Для systemd-based дистрибутивов проще всего через rsyslog, даже если основной журнал — journald:

# /etc/rsyslog.d/60-remote-forward.conf
*.* @@logs.example.com:514

Двойной @@ означает TCP (надёжнее UDP, где пакеты можно потерять при нагрузке или атаке). Если нужен TLS — rsyslog поддерживает и его через модуль omfwd с параметрами StreamDriver.

Шаг 3 — на стороне коллектора поднимаем Graylog или Grafana Loki. Разница в основном в модели хранения и запросах: для небольшой инфраструктуры (до 5–10 серверов) Loki обычно легче по ресурсам, для более сложных сценариев с богатым поиском по полям — Graylog.

Шаг 4 — настраиваем алерты на конкретные паттерны, а не «на всё подряд» (иначе алерты быстро начнут игнорировать) — например:

• больше N неуспешных попыток входа за минуту с одного IP;
• любое изменение /etc/sudoers или /etc/passwd;
• вход под root напрямую (если это вообще происходит);
• отключение самого auditd или rsyslog-пересылки — это первое, что отключает злоумышленник, закрепившийся на сервере.

Отдельно стоит учитывать объём: подробное журналирование быстро генерирует значимый поток данных, и вопрос «сколько это будет стоить в диске и трафике» стоит прикинуть заранее, а не после того, как диск на коллекторе внезапно закончился — расход растёт нелинейно вместе с числом серверов и глубиной аудита, и его стоит пересчитывать при каждом заметном росте инфраструктуры.

Частые вопросы