rsyslog (системный журнал syslog)

Как rsyslog обрабатывает сообщение

rsyslog устроен как конвейер из трёх этапов, он описан в документации по базовой структуре. Входы принимают сообщения, например imuxsock для локального сокета syslog и imtcp для сети. Каждое сообщение попадает в набор правил (ruleset), где правила проверяются сверху вниз, а каждое правило связывает фильтр с действиями, такими как запись в файл или пересылка на сервер. Главный файл это /etc/rsyslog.conf, который обычно подключает фрагменты из /etc/rsyslog.d/. Для новых настроек проект рекомендует синтаксис RainerScript, а старые стили sysklogd и директив с долларом считает устаревшими.

Классический фильтр это селектор вроде authpriv.*. Объект (facility) называет подсистему, которая писала в журнал, например auth, authpriv, cron, daemon, kern, mail и от local0 до local7. Приоритет идёт от debug до emerg. Приоритет в селекторе соответствует этому уровню и всем более серьёзным, а знак = выбирает только указанный уровень. Нумерация следует RFC 5424. Шаблоны определяют, в каком формате сообщение уходит на выход.

Пересылка логов на центральный сервер

Пересылку выполняет встроенный выход omfwd, который отправляет данные по UDP, TCP или TLS. В его документации советуют TCP с TLS вместо простого TCP или UDP и очередь, чтобы недоступный сервер не блокировал локальное журналирование. Пример для отправителя:

global(workDirectory="/var/spool/rsyslog")
action(type="omfwd" target="logs.example.com" port="6514" protocol="tcp"
  StreamDriver="ossl" StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.com"
  StreamDriver.CAFile="/etc/ssl/rsyslog/ca.pem"
  StreamDriver.CertFile="/etc/ssl/rsyslog/client.pem"
  StreamDriver.KeyFile="/etc/ssl/rsyslog/client.key"
  action.resumeRetryCount="-1" queue.type="LinkedList"
  queue.filename="fwd_logs" queue.saveOnShutdown="on")

Порт 6514 выделен в RFC 5425 для syslog поверх TLS. Принимающая сторона загружает imtcp с теми же настройками потокового драйвера и списком PermittedPeer, где перечислены допустимые клиенты. Перед перезапуском службы проверьте файл командой rsyslogd -N1.

Строки очереди важны. action.resumeRetryCount="-1" повторяет попытки без ограничения, а queue.filename позволяет неотправленным сообщениям сбрасываться на диск, когда память заполнена, так что короткий простой лог-хоста не должен приводить к потере сообщений. Проверьте это: остановите приёмник на некоторое время и запустите снова.

Надёжность, доверие и типичные ошибки

Обычный syslog не рассчитан на враждебные сети. В NIST SP 800-92 отмечено, что UDP не гарантирует доставку записей, что в большинстве реализаций нет контроля доступа и любой хост может писать на сервер, и что атакующий может забросать его поддельными данными. Поэтому ограничьте доступ к порту приёмника межсетевым экраном и используйте TLS с PermittedPeer, чтобы принимались только ваши серверы.

TCP лучше UDP, но потерь не исключает. Для подтверждаемой доставки в rsyslog есть RELP через omrelp и imrelp. В документации imrelp сказано, что он намного надёжнее простого TCP, хотя возможен редкий дубль или потеря при остановке. Дисковые очереди помогают при простоях, но queue.saveOnShutdown работает только при штатной остановке, а не при сбое или потере питания.

Ещё две ловушки: короткие устаревшие формы пересылки, начинающиеся с одного или двух символов «коммерческое at», обходят очереди, поэтому пишите явную форму action(), а имена файлов, собранные из значений от отправителя, например имя хоста, требуют опции secpath-replace, чтобы отправитель не выбирал путь.

Почему логи вне сервера важны после взлома

Локальному логу можно доверять ровно настолько, насколько защищён root на машине, где он лежит. В NIST SP 800-92 подчёркнуто, что многие руткиты специально меняют логи и стирают следы своей установки. Тот, кто получил root, может править или удалять файлы в /var/log либо остановить демон. Копия, уже лежащая на другом хосте, сохраняет всё, что произошло до этого момента, а сервер, внезапно замолчавший в центральном журнале, сам по себе сигнал.

Держите лог-хост отдельно от серверов, которые он записывает: свои учётные данные, никаких общих административных аккаунтов и доступ только у тех, кто расследует. В нашем руководстве по мониторингу объясняется, что искать, когда логи собраны в одном месте, а руководство по SIEM для небольшого сервера показывает следующий шаг. Во время инцидента центральная копия это улика, которой ещё можно верить, поэтому используйте её в хронологии реагирования на взлом. Локальный журнал читают через journalctl, записи по командам и файлам даёт auditd, а SIEM сопоставляет объединённый поток.

Связанные термины: journalctl, auditd, SIEM, Реагирование на инциденты, Контроль целостности файлов.