Журналы сетевых средств защиты в Wazuh: экран, IDS, прокси, WAF и правила оповещения

Сеть генерирует событий больше, чем любая другая часть инфраструктуры: экран отбрасывает пакеты, IDS замечает атаки, прокси блокирует сайты, WAF останавливает запросы к веб-приложению. Пока эти журналы лежат на самих устройствах, они бесполезны: никто не открывает десять консолей, а при взломе злоумышленник удаляет локальные записи первым делом. Нужно собрать всё в одном месте и научить систему замечать то, что важно: сканирование портов, подбор паролей, срабатывания IDS. Ниже какие источники подключать, как принять syslog, как написать декодер и правила, как проверить и как настроить оповещения.

Сам Wazuh и первые правила: установка в Docker, правила обнаружения атак. Проверка, что события вообще доходят: проверка доставки событий. Какие события писать и как долго хранить: политика журналирования.

Что собираем и откуда

Начинайте с трёх источников, которые дают больше всего пользы: экран, IDS и журнал входа (SSH, VPN, RADIUS). Остальное добавляйте по мере готовности.

Шаг 1. Приём syslog от устройств без агента

На сетевое оборудование агент не поставишь, но syslog они отправляют почти всегда. Включите приём на сервере Wazuh в /var/ossec/etc/ossec.conf и ограничьте адреса отправителей:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.0.2.0/24</allowed-ips>
</remote>

sudo systemctl restart wazuh-manager
sudo ss -ulpn | grep 514

Ожидаемо: порт 514 слушает служба менеджера. Если Wazuh запущен в контейнере, порт нужно опубликовать в конфигурации Docker. На устройствах укажите адрес сервера и протокол; UDP не гарантирует доставку, поэтому для важных источников выберите TCP, если устройство умеет. Для экрана на Linux проще поступить иначе: поставить на него агента и читать файл журнала: так события подписаны именем узла и не теряются.

Шаг 2. Файлы журналов через агента

На узле с экраном, прокси, IDS и WAF в конфигурации агента перечисляем нужные файлы:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/kern.log</location>
</localfile>
<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>
<localfile>
  <log_format>squid</log_format>
  <location>/var/log/squid/access.log</location>
</localfile>

sudo systemctl restart wazuh-agent
sudo tail -n 20 /var/ossec/logs/ossec.log | grep -i "analyzing file"

Ожидаемо: в журнале агента строки «Analyzing file» для каждого подключённого файла. Если строки нет, проверьте путь и права: агент должен уметь читать файл. Формат squid подходит для стандартного формата журнала; если вы задали свой logformat, как в статье про прокси, используйте syslog и пишите свой декодер.

Шаг 3. Декодер и правила для nftables

Строка журнала экрана с нашим префиксом выглядит так (из правил, описанных в статье про nftables):

Oct 18 03:12:44 fw kernel: nft-drop-in: IN=eth0 OUT= MAC=... SRC=198.51.100.77 DST=192.0.2.10 LEN=60 PROTO=TCP SPT=51544 DPT=22 SYN

Wazuh эту строку сам не разберёт, поэтому пишем декодер в /var/ossec/etc/decoders/local_decoder.xml:

<decoder name="nft-drop">
  <prematch>nft-drop-in: </prematch>
</decoder>

<decoder name="nft-drop-fields">
  <parent>nft-drop</parent>
  <regex type="pcre2">SRC=(\S+) DST=(\S+) .*PROTO=(\w+) SPT=\d+ DPT=(\d+)</regex>
  <order>srcip,dstip,protocol,dstport</order>
</decoder>

И правила в /var/ossec/etc/rules/local_rules.xml. Номера из диапазона от 100000 зарезервированы для локальных правил:

<group name="local,network,firewall,">
  <rule id="100100" level="3">
    <decoded_as>nft-drop</decoded_as>
    <description>nftables: входящий пакет отброшен</description>
  </rule>

  <rule id="100101" level="10" frequency="20" timeframe="60">
    <if_matched_sid>100100</if_matched_sid>
    <same_source_ip />
    <description>nftables: сканирование портов, 20 отброшенных пакетов за минуту с одного адреса</description>
    <mitre><id>T1046</id></mitre>
  </rule>
</group>

Проверьте до перезапуска с помощью встроенного теста: запустите sudo /var/ossec/bin/wazuh-logtest, вставьте тестовую строку и убедитесь, что поля разобраны и сработало правило 100100. Только после этого перезапустите менеджер.

sudo /var/ossec/bin/wazuh-logtest
# вставьте строку из примера выше
sudo systemctl restart wazuh-manager

Ожидаемо: в выводе теста есть фазы декодирования с полями srcip, dstport и фаза правила с номером 100100. Порог «20 пакетов за минуту» условный: для вашего периметра он может быть слишком мал или велик, подберите по обычному фону, иначе получите постоянные ложные тревоги от интернет-сканеров. Для периметра, на который ходят все подряд, оповещайте о сканировании только при попытке на закрытые порты управления или внутри сети.

Шаг 4. Что действительно стоит ловить

Не создавайте правил «на всё». Для каждого оповещения должен быть человек и действие. Если ответ на вопрос «что делать при срабатывании» — «ничего», правило не нужно.

Шаг 5. Оповещения ответственным

Оповещение должно дойти до человека, который за него отвечает. Самый простой способ — письмо по порогу серьёзности. В ossec.conf менеджера:

<global>
  <email_notification>yes</email_notification>
  <smtp_server>mail.example.com</smtp_server>
  <email_from>wazuh@example.com</email_from>
  <email_to>secops@example.com</email_to>
</global>
<alerts>
  <email_alert_level>10</email_alert_level>
</alerts>

Ожидаемо: после перезапуска письма приходят только по событиям уровня 10 и выше. Для мессенджеров и трекеров используют интеграции Wazuh (отправка в вебхук); настройка зависит от версии, посмотрите раздел интеграций документации. Определите заранее порядок: кто получает, как быстро отвечает, что делает при критичном: внутренние уведомления при инциденте.

Недельный отчёт

Раз в неделю смотрите сводку, а не только оповещения: она показывает тренды, которых не видно по отдельным событиям.

# самые частые источники отброшенных пакетов (на узле экрана)
sudo grep "nft-drop-in" /var/log/kern.log | grep -o "SRC=[0-9.]*" | sort | uniq -c | sort -rn | head

# самые частые сигнатуры Suricata
jq -r 'select(.event_type=="alert") | .alert.signature' /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head

Ожидаемо: два списка. Добавьте к ним числа из прокси (серии блокировок) и RADIUS (отказы). Сводка на одну страницу для руководителя ИБ и список принятых решений — материал для разбора процесса.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Сетевая безопасность» (хаб: сетевая безопасность, карта: карта зрелости), смежное направление — мониторинг. На втором уровне журналы средств защиты сети собираются и анализируются централизованно: выявляются аномалии, строится корреляция, настроено уведомление ответственных о сканировании портов и множественных неудачных попытках аутентификации. На пятом уровне к этому добавляется анализ сетевого трафика (NTA) и его интеграция с SIEM.

Как проверить

1. Для каждого источника из таблицы в Wazuh есть событие за последние сутки.
2. Тестовая строка проходит через wazuh-logtest и вызывает правило 100100.
3. Условное сканирование портов с тестового адреса на закрытые порты вызывает оповещение уровня 10.
4. Письмо или сообщение с оповещением дошло до ответственного, и он знает, что делать.
5. Есть недельная сводка за последний месяц.

Источники

• Wazuh, декодеры и правила: documentation.wazuh.com.
• Wazuh, приём syslog: documentation.wazuh.com.
• CIS Control 8, управление журналами аудита: cisecurity.org/controls.
• CIS Control 13, мониторинг и защита сети: cisecurity.org/controls.