Очередь IDS красная от мусора: suppress и HOME_NET, не выключать сенсор

Короткий ответ

Шумный IDS бесполезен: люди ставят правило «игнор всё». Не выключайте Suricata/Snort и не ставьте alert→off на весь ruleset. Снимите топ SID из eve.json за сутки, отключите или suppress конкретные сигнатуры на известные сканеры/сети, поправьте HOME_NET (10.0.10.0/24, 10.0.30.0/24, 10.0.99.0/24). Firewall nftables/RouterOS остаётся в силе: IDS — датчик, не замена filter.

Не выдумывайте CVE и не копируйте «отключите SID 1:12345» с форума — берите SID из ваших логов.

WAN 203.0.113.10 — внешний сенсор; не сканируйте чужие сети, чтобы «наполнить» IDS.

Симптомы и как отличить

SIEM: 50k alert/день, из них 40k одно правило про ICMP или DNS. Реальные brute SSH тонут. Диск под eve.json растёт как журналы FW, но причина — content, не только retention.

Возможные причины

1. HOME_NET = any — внутренний трафик классифицируется как внешняя атака.
2. Сенсор на SPAN видит обе стороны и дубли.
3. Нет suppress на nagios/zabbix/nmap своего периметра.
4. Включены test/policy rulesets.
5. Истёкшие/кривые правила после обновления.
6. GeoIP/reputation параллельно орёт в ту же очередь.

Диагностика

На Ubuntu-сенсоре (типичный Suricata):

sudo systemctl is-active suricata
sudo jq -r 'select(.event_type=="alert")|.alert.signature_id' /var/log/suricata/eve.json \
  | sort | uniq -c | sort -nr | head
sudo jq -r 'select(.event_type=="alert")|[.alert.signature_id,.src_ip,.dest_ip,.alert.signature]|@tsv' \
  /var/log/suricata/eve.json | head

Если jq нет — Python/grep по файлу; не выдумывайте бинарные утилиты вендора.

Проверьте HOME_NET в /etc/suricata/suricata.yaml (или include): должны быть ваши RFC1918 зоны и VIP, не any.

sudo grep -n HOME_NET /etc/suricata/suricata.yaml
sudo suricata -T -c /etc/suricata/suricata.yaml

-T — тест конфига, не атака.

RouterOS не заменяет IDS: /log firewall — counters drop, другая статья. Не пытайтесь «снизить шум IDS» disable filter.

На концептуальном периметре с пакетом Suricata: смотрите топ alerts в GUI, те же SID, interface WAN vs LAN (на LAN будет шум сканеров учёта).

Свой nmap на 203.0.113.10 ожидаемо плодит scan-сигнатуры — suppress на IP сканера из mgmt, не отключайте класс SCAN целиком, если хотите видеть чужие сканы.

Решение

Сценарий A. Топ SID — ваш мониторинг

В /etc/suricata/threshold.config (стандартный механизм Suricata):

# пример формы; sid возьмите из своего jq, не с потолка
# suppress gen_id 1, sig_id <SID_ИЗ_EVE>, track by_src, ip 10.0.99.20

Перечитайте документацию вашей ветки Suricata по точному синтаксису suppress/threshold. После правки:

sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata || sudo systemctl restart suricata

Reload если unit это умеет; иначе короткий restart в окно. Не kill -9.

Сценарий B. Мусорный класс policy/info

Отключите категорию через suricata-update disable conf, не весь ET.

sudo suricata-update list-enabled-sources
# правьте /etc/suricata/disable.conf : re:группа или sid
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata

Запись в заявке: какая категория, почему, кто владелец.

Сценарий C. HOME_NET

# идея, адреса ваши:
# HOME_NET: "[10.0.10.0/24,10.0.30.0/24,10.0.99.0/24,203.0.113.10]"

После смены — тест -T, restart. Ожидайте изменение профиля алертов: внутренний DNS перестанет быть «атакой на any».

Сценарий D. Дубли SPAN

Один tap, одна сторона, checksum. Иначе каждый поток ×2. Это сеть SPAN, не SID.

Сценарий E. Шум совпал с логами FW

Коррелируйте: drop на RouterOS vs alert. Часто достаточно log drop без 15 сигнатур «scan». Не дублируйте одно и то же в три системы без suppress.

Откат: git/копия disable.conf и threshold.config.

Практическая чистка топа за один час

Возьмите eve.json за последние 24 часа, не «за всё время» — иначе старый мусор исказит топ. Выгрузите 15 SID, для каждого запишите: сигнатура текстом, доля событий, типичный src, типичный dst, класс (policy/scan/dos). Три корзины: (1) свой мониторинг/сканер 10.0.99.20 — только suppress by_src; (2) внутренний DNS/NTP как «атака» — HOME_NET и disable категории policy; (3) реальный WAN-шум на 203.0.113.10 — оставить.

Не смешивайте корзины в одном disable.conf regex на всё ET. После каждого изменения — suricata -T и 15 минут наблюдения: если топ сдвинулся на новый SID, повторите цикл, не отключайте engine. На RouterOS в это время смотрите, не пытается ли кто «помочь» disable filter: counters WAN drop должны жить независимо от eve.

Храните diff threshold.config в той же заявке, что и цифры «было 40k, стало 4k». Без цифр чистка не воспроизводима на втором сенсоре.

Как проверить, что проблема устранена

1. Топ SID за час: нет вашего zabbix как №1.
2. Объём alert − заметно (цель: можно читать очередь).
3. Контрольный свой скан WAN с 10.0.99.20 либо suppress, либо ожидаемый единичный класс.
4. Тестовый известный шум (подключение на закрытый 22 WAN) всё ещё виден, если это не suppress.
5. suricata -T ok, unit active.

sudo jq -r 'select(.event_type=="alert")|.alert.signature_id' /var/log/suricata/eve.json \
  | sort | uniq -c | sort -nr | head

Сравните с baseline в заявке (цифры до).

Если не помогло

• eve.json не ротируется — диск, не шум правил.
• SIEM парсит fast.log и eve дублем.
• IPS mode: «шум» = drop легитима — другая статья.
• Ruleset не обновился, вы правите старые sid.
• На MikroTik нет Suricata — вы смотрите web-proxy log, это не IDS.

Профилактика

• Еженедельный отчёт топ-10 SID, владелец подписывает suppress.
• Новый мониторинг сразу в whitelist threshold.
• Обновление ruleset по процедуре с diff шума.
• HOME_NET в SCM.
• Хранилище eve на отдельном узле.

FAQ

Отключить все SCAN-сигнатуры?

Нет. Suppress свой nmap. Чужие сканы WAN — как раз сигнал к проверке периметра.

Threshold vs disable

Threshold/suppress — «не для этого IP». Disable — «правило бесполезно всем». Начинайте с suppress.

Можно ли увеличить volume до 1 alert в минуту глобально?

Глобальный rate потеряет burst атаки. Режьте топ SID.

Snort 3 вместо Suricata

Та же методика: топ gid:sid из лога, suppress в local. Не выдумывайте CLI пакетов GUI.

IDS на самом шлюзе Ubuntu vs отдельный сенсор

Отдельный SPAN/TAP не грузит FW. На шлюзе следите за CPU. Не отключайте nft из‑за CPU IDS — вынесите сенсор.