Linux auditd как аналог Sysmon: детектирование execve, ptrace и сетевых событий

Когда в прошлом квартале мы развернули Sysmon на Windows-хостах клиентов и начали получать в ELK читаемые события создания процессов, сетевых соединений и изменения реестра - стало неловко смотреть на Linux-часть инфраструктуры. Там журнал аудита либо вообще не настроен, либо ограничен стандартным набором «кто куда логинился». На Linux-серверах крутятся веб-приложения, базы данных, CI-агенты - и всё это молчит.

Антропологически ситуация понятна: Linux-администраторы привыкли доверять системе. Sysmon появился потому что Windows без него реально слепая. Но когда начинаешь разбирать инциденты - а у нас был эпизод с компрометацией CI-агента через уязвимый Jenkins - понимаешь, что auditd тоже надо настраивать как следует, а не оставлять дефолтным.

Что такое auditd и где он живёт

auditd - это демон Linux Audit Framework, часть ядра с версии 2.6. Пишет события в /var/log/audit/audit.log в собственном формате. Из коробки он есть на RHEL/CentOS и дистрибутивах на их базе; на Debian/Ubuntu устанавливается через apt install auditd.

Правила загружаются через auditctl или прописываются в /etc/audit/rules.d/. При перезапуске системы augenrules компилирует файлы из этой директории в итоговый набор. Важный момент: правила auditd - это фильтры для системных вызовов ядра, а не парсинг лог-файлов. Это принципиально отличает подход от, скажем, мониторинга bash_history - историю можно очистить, перехват syscall на уровне ядра обойти значительно сложнее.

Набор правил: что мы считаем важным

За основу взяли публичный набор правил от laurianne-lapsley/audit-userspace и несколько рекомендаций из CIS Benchmark для RHEL 7. Дополнили под свои задачи.

Базовая структура файла /etc/audit/rules.d/99-adg.rules:

## Буфер и режим
-b 8192
-f 1

## Запуск процессов (execve) - самое важное
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec

## Изменение привилегий (setuid/setgid)
-a always,exit -F arch=b64 -S setuid -S setgid -k priv_esc
-a always,exit -F arch=b32 -S setuid -S setgid -k priv_esc

## ptrace - отладка чужих процессов (red flag при атаке)
-a always,exit -F arch=b64 -S ptrace -k ptrace
-a always,exit -F arch=b32 -S ptrace -k ptrace

## Сетевые соединения
-a always,exit -F arch=b64 -S connect -k net_connect
-a always,exit -F arch=b32 -S connect -k net_connect

## Изменения в /etc/passwd, /etc/shadow, /etc/sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity

## Изменения cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Загрузка модулей ядра
-a always,exit -F arch=b64 -S init_module -S finit_module -k modules
-a always,exit -F arch=b32 -S init_module -S finit_module -k modules

## Блокировка изменений правил (обязательно в конце)
-e 2

Флаг -e 2 в конце переводит auditd в «immutable mode» - правила нельзя изменить без перезагрузки системы. Это важная деталь: злоумышленник, получив root, не сможет тихо отключить аудит без реboot, который сам по себе событие.

Нагрузка на систему: честные наблюдения

Главный вопрос, который задают сразу: не положим ли мы сервер детальным аудитом? Честный ответ - зависит от нагрузки на execve.

На типичном веб-сервере (nginx + PHP-FPM, несколько десятков запросов в секунду) auditd с полным набором правил добавляет 2-5% CPU. На CI-агенте, где каждый билд это сотни fork+exec - нагрузка заметно выше, мы видели всплески до 15% во время активных сборок. Для CI-хостов пришлось сделать отдельный, более аккуратный набор правил без перехвата всех execve - только изменения чувствительных файлов и ptrace.

Буфер -b 8192 покрывает всплески событий. Если буфер переполняется, поведение определяется флагом -f: при -f 2 (panic mode) система падает в kernel panic, при -f 0 события теряются молча, при -f 1 ядро пишет в printk и продолжает работу. Для продакшна мы используем -f 2 на серверах с данными и -f 0 там где потеря части событий лучше падения сервиса. Вопрос приоритетов, который стоит обсудить с клиентом заранее.

Пересылка в ELK через Filebeat

Формат audit.log - это ключ-значение в одну строку, нечитаемое без парсинга. В Filebeat для этого есть модуль auditd:

filebeat.modules:
  - module: auditd
    log:
      enabled: true
      var.paths: ["/var/log/audit/audit.log"]

output.logstash:
  hosts: ["logstash.internal:5044"]

Модуль сам парсит события, нормализует поля и добавляет метаданные. На выходе в Elasticsearch получаем структурированные документы с полями auditd.data.cmd, auditd.data.syscall, process.pid, user.name и так далее. Kibana-дашборд Filebeat для auditd тоже есть из коробки - ставится через filebeat setup --dashboards.

В Logstash мы добавили enrichment: для событий с auditd.data.syscall == "execve" подтягиваем имя хоста и метку среды (prod/staging), чтобы в дашборде сразу было видно контекст. Для connect-событий - фильтр по внутренним диапазонам, чтобы не засорять картину легитимным трафиком между сервисами.

Что это даёт в SIEM-контексте

Связка auditd + Filebeat + ELK даёт достаточно сырья для базовых правил корреляции:

• Запуск интерпретаторов от веб-процессов. execve python/perl/bash с parent process nginx или php-fpm - классический признак эксплуатации веб-уязвимости.
• Неожиданный connect из веб-процесса. PHP-FPM не должен сам устанавливать исходящие соединения на 443 к незнакомым IP.
• Изменение /etc/passwd или sudoers. Любое изменение этих файлов должно быть либо объяснено тикетом, либо вызывать тревогу.
• ptrace от непривилегированного пользователя. Редкий syscall в продакшне, почти всегда означает либо отладку разработчика не в том окружении, либо что-то хуже.

Ни один из этих паттернов не сработает сам по себе без настройки корреляции в ELK. Но сырьё теперь есть - и это принципиальный шаг вперёд по сравнению с ситуацией «всё что происходит на Linux-серверах ночью нам неизвестно».

Текущее состояние: правила развернуты в рамках managed-мониторинга на нескольких клиентских площадках, корреляция в Kibana работает в базовом варианте. До полноценных alert-правил и автоматических уведомлений - ещё несколько итераций.