Мониторинг безопасности и обнаружение вторжений: auditd, Suricata и Wazuh на практике

Зачем в 2026 году нужен эшелонированный мониторинг безопасности

Эшелонированный мониторинг безопасности собирается из трёх уровней: host-аудит системных вызовов и файловых операций (auditd), сетевой IDS/IPS (Suricata) и корреляция событий из всех источников в SIEM (Wazuh manager или Elastic Security). Внутри host-уровня работают два отдельных механизма: аудит syscall через auditd и контроль целостности файлов (FIM) в Wazuh. Инструментов получается четыре, уровней три. Каждый уровень видит то, что не видит соседний, и пропуск любого оставляет слепую зону.

Цифры 2026 года объясняют, почему сигнатурная защита в одиночку не справляется. FIRST прогнозирует 59 427 новых CVE за год, это одна уязвимость каждые девять минут. Более 23% известных эксплуатируемых уязвимостей применяют в день публикации или раньше, а среднее время до эксплуатации ушло в отрицательные значения: атака начинается до выхода бюллетеня безопасности. Патч, установленный через неделю после релиза, закрывает дыру, которой уже пользуются.

Отчёт Verizon Data Breach Investigations Report за 2026 год подтверждает: базовые практики кибергигиены остаются самым эффективным средством защиты. При этом в Европе за первые четыре месяца 2026 года атак программ-вымогателей стало на 55,1% больше год к году, среднемесячное число инцидентов выросло со 108 до 171. ESET в MDR Threat Report за первый квартал 2026 года отмечает: атакующие злоупотребляют легитимными инструментами и отключают защитные механизмы перед развёртыванием шифровальщика. Сигнатура антивируса молчит, потому что вредоносного кода на диске нет.

Какие угрозы не ловят классические средства защиты

Злоупотребление легитимными утилитами. curl, wget, systemctl, schtasks, certutil, ssh и tar выполняют повседневную работу администратора. Отличить загрузку полезной нагрузки через curl от планового деплоя по имени процесса невозможно. Нужен поведенческий контекст: кто запустил, из-под какой учётной записи, каков родительский процесс, куда ушло соединение.

Атаки на цепочки поставок. Злоумышленники выбирают поставщиков и сервис-провайдеров, чтобы через единственную точку входа добраться до множества жертв. Отчёт Black Kite выявил 64 организации, скомпрометированные через инциденты с участием третьих сторон. Группа Qilin действовала в 26 из 31 проанализированной страны. Файрвол и антивирус на стороне клиента не помогают, если обновление пришло от доверенного партнёра с валидной подписью.

Ransomware с предварительным отключением защиты. Производственный сектор дал 27,9% публично раскрытых инцидентов. Атака начинается с выключения аудита, остановки агентов и удаления теневых копий, и только потом шифруются данные. Если момент отключения средства защиты не зафиксирован, восстановление затягивается на дни, а причина сбоя остаётся неизвестной.

Три слоя мониторинга и их зоны ответственности

Слои складываются в цепочку доказательств. FIM показывает, что файл изменён, auditd показывает процесс, который это сделал, Suricata показывает, куда ушли данные, а SIEM собирает три сигнала в один алерт уровня 13 вместо трёх несвязанных записей. Пропустите любой уровень, и цепочка рассыпается: админ видит факт изменения, но не видит источник.

Аудит событий Linux с auditd: что и как логировать

auditd - подсистема аудита ядра Linux. Она перехватывает системные вызовы, операции с файлами и смену привилегий, а результат пишет в /var/log/audit/audit.log. В отличие от логирования приложений, auditd работает на уровне ядра и фиксирует вызовы любого процесса, включая те, что не пишут собственных логов.

Установка: apt install auditd audispd-plugins на Debian и Ubuntu, dnf install audit на RHEL-совместимых системах. Проверка состояния: systemctl status auditd. Конфигурация демона лежит в /etc/audit/auditd.conf, правила - в /etc/audit/rules.d/audit.rules. Применить правки после редактирования: augenrules --load, посмотреть активный набор: auditctl -l.

Три параметра auditd.conf удерживают диск от переполнения: max_log_file=50 (размер файла в мегабайтах), num_logs=10 (число ротаций), space_left_action=syslog и admin_space_left_action=single. На активном сервере без тюнинга auditd пишет несколько гигабайт в сутки, поэтому ротацию и лимиты настраивают до включения правил, а не после падения диска в ноль.

Базовый набор правил: доступ к критичным файлам и привилегии

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

• Учётные записи и привилегии: -w /etc/passwd -p wa -k identity, -w /etc/shadow -p wa -k identity, -w /etc/group -p wa -k identity, -w /etc/sudoers -p wa -k privilege, -w /etc/sudoers.d/ -p wa -k privilege.
• Конфигурации сервисов: -w /etc/ssh/sshd_config -p wa -k sshd_config, -w /etc/nginx/ -p wa -k web_config, -w /etc/systemd/ -p wa -k systemd_config.
• Запуск процессов от root: -a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec.
• Смена идентификаторов: -a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -F auid>=1000 -F auid!=4294967295 -k priv_change.
• Правка самих правил аудита: -w /etc/audit/ -p wa -k audit_rules.

Ключ -k задаёт метку, по которой события фильтруются позже: ausearch -k root_exec -i (флаг -i переводит uid в имена и раскладывает запись по строкам). Сводка по хосту: aureport --summary, отчёт по аутентификациям: aureport -au, неудачные операции: aureport --failed.

После проверки на стенде набор фиксируют в режиме immutable строкой -e 2 в конце audit.rules. Правила перестанут меняться до перезагрузки, что защищает от их удаления атакующим. Цена решения: пока режим активен, добавить правило на живой системе не получится.

Чтение логов и интеграция с journald

Основной поток событий идёт в /var/log/audit/audit.log. Дублирование в journald включается в /etc/audit/plugins.d/syslog.conf из пакета audispd-plugins, тогда события видны через journalctl -t audit; плагин au-remote отправляет их на удалённый коллектор. Параметр log_format=ENRICHED в auditd.conf добавляет к записи расшифровку uid и gid, что ускоряет разбор инцидента без ручного сопоставления номеров.

Рабочие команды поиска:

• ausearch -ts today -k root_exec - все запуски процессов от root за сутки.
• ausearch -ua 1000 - события конкретного пользователя по uid.
• ausearch -m USER_LOGIN - входы в систему.
• ausearch -ts recent -k privilege - изменения прав за последние 10 минут.

Без ротации и фильтров auditd на активном сервере генерирует десятки тысяч записей в час. Просмотр «сырого» файла глазами бесполезен: разбирайте события только через ausearch и aureport, они строят выборку по времени, ключу и типу записи.

Тюнинг: как не утонуть в событиях

Шум дают три источника: контейнеры, каталоги с постоянной записью и непривилегированные пользователи. Правило-исключение ставят перед общим и закрывают каталог целиком: -a never,exit -F dir=/var/lib/docker -F perm=wa. Для непривилегированных учётных записей набор ограничивают фильтром auid>=1000. Группировка через -k позволяет отключать шумные направления целиком, не переписывая весь файл правил.

Раз в месяц сверяйтесь с aureport --failed и aureport --summary: они показывают, какие правила срабатывают чаще всего и не растёт ли доля отказов. Контейнерные среды требуют отдельного слоя: auditd видит только хостовые вызовы, процессы внутри контейнера для него неотличимы от процессов хоста. В Kubernetes добавляют наблюдателя уровня ядра, например Falco или агент на eBPF.

Базовая настройка самого хоста, включая SSH, sudo и сетевые фильтры, разобрана в руководстве по защите Linux-сервера и аудиту конфигурации. Аудит имеет смысл после того, как закрыты очевидные дыры в доступах.

Обнаружение вторжений IDS/IPS: настройка Suricata

Suricata - многопоточный IDS/IPS и сетевой монитор безопасности, который разбирает трафик по правилам формата Emerging Threats. Установка: apt install suricata или dnf install suricata. Конфиг проверяется до запуска командой suricata -T -c /etc/suricata/suricata.yaml, обновление правил выполняет suricata-update. Результат виден в трёх файлах: /var/log/suricata/eve.json (события в JSON, основа для SIEM), fast.log (короткие строки алертов) и stats.log (счётчики движка).

IDS или IPS: что выбрать для продакшена

IDS только пишет алерт, IPS блокирует пакет. Блокировка боевого трафика при непроверенном наборе правил роняет сервисы, поэтому рабочий порядок такой: две-четыре недели в режиме IDS, сбор baseline, затем точечное включение IPS для узкого списка правил (обращения к известным C2, эксплойты, сканирование с внешних адресов).

IPS включается в секции af-packet конфига параметрами copy-mode: ips и copy-iface. Альтернатива - NFQUEUE через iptables, но она добавляет задержку и усложняет отладку. Для внутренних сервисов, которые дают ложные срабатывания, заранее готовят pass-правила по IP и портам, иначе IPS начнёт резать мониторинг, бэкапы и репликацию базы.

Правила и источники: ET Open, собственные сигнатуры

suricata-update подтягивает наборы из нескольких источников: et/open (бесплатный базовый), et/pro (платная подписка), блок-листы abuse.ch по SSL, URLhaus и Feodo, а также фиды MISP. Внутренние правила подключают как локальные файлы, чтобы обновление внешних наборов их не затирало.

Правило состоит из действия (alert, drop, pass), заголовка (протокол, источник, порт, направление, назначение) и опций в скобках: msg, flow, content, dsize, sid, rev, classtype, reference, metadata. Пример детекта обращения к известному C2: alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL C2 beacon to known bad IP"; flow:to_server; sid:1000001; rev:1; classtype:trojan-activity;). Пример детекта DNS-туннеля: alert dns $HOME_NET any -> any 53 (msg:"LOCAL long DNS query suspected tunneling"; dns.query; pcre:"/^[a-z0-9]{40,}\./i"; sid:1000002; rev:1; classtype:bad-unknown;).

Локальные правила нумеруют в диапазоне выше 1000000 и держат в отдельном файле. При каждой правке rev увеличивают на единицу: это позволяет различать версии правила в алертах и отчётах.

Производительность и размещение сенсора

Для 1 Gbps трафика хватает 2-4 vCPU, для 10 Gbps нужен отдельный сервер с DPDK или XDP. Базовые настройки производительности: ring-size 20000 в секции af-packet, привязка потоков к ядрам через CPU affinity, отключение GRO на интерфейсе сенсора командой ethtool -K eth0 gro off, профиль detect-engine: high и увеличенный max-pending-packets.

Сенсор ставят на зеркальный порт коммутатора или на TAP, а на боевой интерфейс выводят только после того, как IPS отработал в мониторинге без ложных блокировок. Потери пакетов видны в stats.log: расхождение счётчиков capture.kernel_packets и decoder.pkts показывает, сколько трафика не дошло до движка. Это первый сигнал, что железо не тянет нагрузку.

Полную картину периметра даёт отдельная процедура: аудит сетевой инфраструктуры и правил межсетевых экранов показывает, какие порты и сервисы вообще видны снаружи, и помогает расставить приоритеты для правил Suricata.

Контроль целостности файлов и настройка Wazuh

Wazuh - открытая SIEM/XDR-платформа, объединяющая контроль целостности файлов, host-based обнаружение, поиск уязвимостей и корреляцию правил. Архитектура состоит из четырёх частей: manager (анализ событий и движок правил), indexer на базе OpenSearch (хранение), dashboard (веб-интерфейс) и агенты на хостах. Установка выполняется скриптом wazuh-install.sh для одиночного узла или через docker-compose для распределённой схемы. Агент ставится на каждый сервер, отправляет события на manager по 1514/tcp, регистрация проходит по 1515/tcp через manage_agents.

FIM: какие директории мониторить и как настроить частоту

Базовый список путей: /etc, /bin, /sbin, /usr/bin, /usr/sbin, /boot, /root/.ssh, а для веб-серверов ещё /var/www, /etc/nginx и /etc/systemd. Секция syscheck в ossec.conf собирается из нескольких параметров:

• frequency - период планового сканирования в секундах, по умолчанию 43200 (12 часов); для критичных путей его снижают до 300-600 секунд.
• scan_on_start - сканирование сразу после старта агента, нужно для сверки с эталоном.
• realtime - отслеживание изменений через inotify; в Linux по умолчанию доступно ограниченное число каталогов (256), лимит поднимают отдельно.
• report_changes - сохранение diff по изменённым файлам: даёт контекст, но расходует место и замедляет сканирование.
• nodiff - исключение бинарников и больших файлов из diff, чтобы не хранить мегабайты нечитаемых различий.

Отдельно настраивают ignore для каталогов с постоянной записью: /var/log, /var/run, кэши и каталоги баз данных. Без исключений FIM выдаёт десятки тысяч изменений в час и полностью перекрывает полезные алерты.

Правила Wazuh: от готовых к своим

Правило описывается полями id, level (от 0 до 15), if_sid (родительское правило), match или regex для строки лога, decoder, description и mitre с идентификатором техники ATT&CK. Готовые правила лежат в /var/ossec/ruleset/rules, свои - в /var/ossec/etc/rules/local_rules.xml. Локальным правилам присваивают id от 100000, чтобы не столкнуться с обновлениями набора.

Три правила, которые стоит добавить в первую очередь:

• Создание учётной записи: level 10, срабатывает на события useradd и строку "new user" в /var/log/auth.log.
• Правка /etc/sudoers: level 12, срабатывает на изменение FIM по этому пути.
• Серия неудачных проверок пароля по SSH: level 10, на базе встроенного правила 5720.

Отладка идёт через wazuh-logtest: утилита принимает строку лога, показывает, какое правило совпало, и позволяет править regex без перезапуска сервиса. Manager перечитывает локальные правила автоматически, но проверка через wazuh-logtest экономит время на поиске опечаток в регулярных выражениях.

Интеграция с auditd и Suricata через Wazuh

Оба источника подключаются как localfile в ossec.conf агента или manager. Для auditd указывают location /var/log/audit/audit.log и log_format audit: встроенный декодер разберёт ключи, uid и тип записи. Для Suricata указывают location /var/log/suricata/eve.json и log_format json: декодер Suricata превратит JSON в поля alert.signature, src_ip, dest_ip, а уровень алерта подставит готовое правило.

После этого события host-аудита, сетевого сенсора и FIM попадают в один индекс indexer и доступны для поиска по общим полям agent.name, src_ip и timestamp. Это техническая основа корреляции: без неё три слоя остаются тремя независимыми логами на трёх разных экранах.

Правила корреляции SIEM: как связать события в один инцидент

Корреляция - это правила, которые срабатывают не на одно событие, а на последовательность или комбинацию событий из разных источников в заданном временном окне. В Wazuh для этого служат директивы if_matched_sid (ссылка на ранее сработавшее правило), same_source_ip (привязка к тому же источнику), frequency и timeframe. В Elastic Security ту же задачу решают correlation rules на языке EQL. Правила Sigma переносятся в нужный бэкенд конвертером. Без корреляции администратор получает несколько сотен алертов в сутки и перестаёт их читать, что обнуляет пользу от трёх уровней мониторинга.

Практические сценарии корреляции

Сценарий 1: brute-force с успешным входом. Правило 5720 фиксирует серию неудачных аутентификаций, правило 5715 - успешный вход по SSH. Дочернее правило 100030 с if_matched_sid 5720, same_source_ip, timeframe 600 и level 12 срабатывает, когда после серии провалов с того же IP вход всё-таки состоялся. Это приоритетный сигнал: пароль подобран.

Сценарий 2: изменение файла вместе с запуском процесса от root. Правило FIM 550 (контрольная сумма изменилась) на /etc/passwd, затем событие execve от euid=0 в течение 300 секунд. Составное правило уровня 13 показывает, что вместе с правкой файла запускался привилегированный процесс, а не просто обновился конфиг. Привязку к тому же агенту задают через same_field с полем agent.name, доступность директивы проверьте в своей версии через wazuh-logtest.

Сценарий 3: сетевой алерт плюс исходящее соединение. Алерт Suricata по C2-адресу с локальным sid 1000001, следом соединение с того же хоста на нестандартный порт в течение 120 секунд. Уровень 14 и признак активной стадии вторжения, а не фонового сканирования.

Сценарий 4: отключение средств защиты. Остановка auditd или агента Wazuh (правила 501-503 отслеживают состояние агента) и любая административная активность после этого. Уровень 15: попытка ослепить мониторинг перед основным ударом.

Для каждого сценария фиксируйте sid родительского и дочернего правила, timeframe и уровень. Без этих трёх параметров правило не отладить через wazuh-logtest, а ложные срабатывания невозможно отличить от настоящих.

Sigma и MITRE ATT&CK как основа правил

Sigma задаёт vendor-neutral формат описания детекта, который конвертируется в правила Wazuh, Elastic и Splunk через sigma-cli и бэкенды pySigma. В публичном репозитории SigmaHQ есть наборы под конкретные техники: T1110 (brute force), T1078 (valid accounts), T1562 (impair defenses), T1059 (command and scripting interpreter), T1486 (data encrypted for impact).

Каждое своё правило привязывайте к технике ATT&CK через поле mitre в Wazuh. Это даёт две практические выгоды: triage ускоряется, потому что по технике сразу понятна стадия атаки, а отчётность строится по покрытию техник, а не по количеству строк в local_rules.xml.

Тюнинг: снижение ложных срабатываний

Рабочие приёмы снижения шума: white_list по IP, пользователю и пути; понижение level для событий, которые в вашей инфраструктуре повторяются ежедневно (плановые таймеры systemd, ротация бэкапов, запуск сканеров); замена одиночных срабатываний на связку frequency и timeframe; пересмотр правил раз в месяц по статистике из dashboard.

Ориентир по нагрузке: 10-20 алертов уровня 10 и выше в сутки на инфраструктуру из 20-50 серверов. Всё, что выше, либо реальный инцидент, либо неоттюненное правило. Если алертов больше, смотрите топ-10 по частоте и закрывайте их исключениями, а не понижением общего уровня чувствительности.

Переход от ручного разбора к автоматическим действиям (блокировка IP, оповещения в Telegram и Slack, оркестрация ответов на базе корреляционных правил) разобран в руководстве по автоматизации реагирования на угрозы.

Проверка работоспособности: тестовые сценарии для каждого слоя

Запущенный агент и заполненный dashboard ещё не доказывают, что детект срабатывает. Каждый слой проверяют отдельно, затем вместе, на заранее подготовленных тестах.

• auditd: создайте тестовую учётную запись (useradd testuser) и проверьте событие командой ausearch -k identity -i. Если записи нет, правило не загружено: сверьтесь с auditctl -l.
• Suricata: добавьте локальное правило на DNS-запрос к тестовому домену, который вы контролируете, и вызовите его через dig. Алерт должен появиться в fast.log и eve.json в течение нескольких секунд.
• Wazuh FIM: измените файл в /etc (добавьте комментарий в конфиг) и дождитесь алерта правила 550 в dashboard. Задержка зависит от frequency и включённого realtime.
• Корреляция: сымитируйте brute-force через hydra на тестовый SSH-порт (например, 2222) с заведомо неверным списком паролей и убедитесь, что сработало правило уровня 12, а не только базовое 5720.
• Каналы оповещений: проверьте доставку алертов уровня 10 и выше в Telegram, Slack или почту. Алерт в dashboard без уведомления ночью не работает.

Чек-лист приёмки мониторинга

1. auditd пишет события, ausearch находит их по ключам.
2. Suricata обновляет правила через suricata-update и пишет eve.json.
3. Агенты Wazuh на всех хостах в статусе Active, ни один не числится Never connected.
4. FIM сканирует критичные пути и выдаёт алерт на тестовое изменение.
5. Корреляционные правила срабатывают на тестовых сценариях из списка выше.
6. Алерты уровня 10 и выше приходят в канал on-call.
7. Runbook написан минимум для трёх первых сценариев.

Что делать после алерта: минимальный runbook

1. Подтвердить алерт: сверить время корреляции и проверить, не совпадает ли событие с плановой работой или деплоем.
2. Изолировать хост: закрыть сетевой доступ правилом ACL, остановить подозрительный сервис, при необходимости вывести узел из балансировки.
3. Собрать артефакты: выгрузку audit.log за нужное окно, eve.json, список процессов, таблицу соединений, изменённые файлы из FIM.
4. Определить вектор: SSH brute-force, эксплуатация веб-приложения, компрометация ключа или учётной записи, злоупотребление легитимной утилитой (LOLBin). Для веб-вектора помогает анализ логов Nginx и Apache командами grep и awk: он быстро показывает сканирование, подбор путей и аномальные всплески запросов.
5. При подтверждении эскалировать и восстановить сервис из проверенного бэкапа, после чего сменить все ключи и пароли, к которым имел доступ скомпрометированный узел.

Разбор артефактов ускоряется, если выгрузить обезличенный фрагмент логов в ИИ-ассистент и попросить выделить цепочку событий. Агрегатор API вроде AiTunnel даёт единый доступ к нескольким моделям без VPN и с оплатой в рублях, но перед отправкой удаляйте из логов имена внутренних хостов, адреса и ключи.

Что выбрать: сравнение open-source стеков для мониторинга

Для инфраструктуры до 50 серверов рабочая связка - auditd, Suricata и Wazuh: лицензий нет, все компоненты развиваются активно, документация покрывает большинство задач. Альтернативы подходят под другие вводные и другой бюджет времени.

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

Требования к ресурсам и типовые ошибки развертывания

Ориентиры по железу: Wazuh manager с indexer на базе OpenSearch требует минимум 4 vCPU, 8 GB RAM и 100 GB SSD для 20-50 агентов; indexer отзывчив к памяти и диску, поэтому 16 GB RAM и NVMe заметно ускоряют поиск. Suricata на 1 Gbps съедает 2-4 vCPU, auditd по CPU почти незаметен, но требует дискового запаса под аудит-лог.

Пять ошибок, которые повторяются чаще всего:

1. Все компоненты на одном хосте без резерва: падение узла ослепляет мониторинг целиком.
2. Ротация логов не настроена: auditd и eve.json заполняют диск, сервисы останавливаются.
3. IPS включён сразу после установки, без периода сбора baseline: первые ложные срабатывания блокируют рабочий трафик.
4. Правила не тюнятся: количество алертов растёт, реакция падает.
5. Мониторинг самого мониторинга отсутствует: остановившийся агент Wazuh не сообщает о себе.

Последняя ошибка лечится просто: алерт на отсутствие heartbeat с агента за 10 минут и проверка состояния управляющего сервера внешним чекером. Для размещения самого стека подходит облачный VDS с быстрым диском: Timeweb Cloud даёт серверы с настраиваемыми ресурсами, что удобно при росте числа агентов, когда дисковое пространство под логи приходится увеличивать без переустановки системы.

Практический порядок действий такой: включите auditd с базовым набором правил и ротацией, поднимите Suricata в режиме IDS на зеркальном порту, разверните Wazuh с FIM на критичных путях, затем добавьте четыре корреляционных правила из этой статьи. На такой конфигурации видно изменение файла, процесс, который его выполнил, и соединение, куда ушли данные.