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

Если после включения inline IPS (Suricata nfqueue / TAP inline / пакет на периметре в IPS mode) отвалился легитимный сервис, найдите SID в eve.json с action drop/reject на этот 5-tuple. Переведите это правило в detect (alert) или exception на src/dst. Не systemctl stop suricata навсегда, не iptables -D ... NFQUEUE с оставлением дыры, не nft flush. Firewall filter должен продолжать drop по матрице.

Сначала докажите, что виноват IPS, а не обычный filter.

WAN 203.0.113.10, LAN 10.0.10.0/24, DMZ 10.0.30.0/24.

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

Включили IPS — 1С/обмен/TLS-инспекция/крупный upload умер. Выключили Suricata — ожило. В eve: alert.action drop, тот же timestamp. Counters nftables на allow растут (пакет до IPS дошёл).

ПроверкаIPSFilter
stop только suricata, nft active, сервис ожилданет
nft drop counter растётнетда
eve drop SIDданет
GeoIP/limitдругие статьи—

MikroTik не делает Suricata IPS на коробке. Если «IPS» = layer7/raw drop — смотрите filter, не eve. Не выдумывайте пакеты RouterOS.

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

  1. Сигнатура на «подозрительный» User-Agent/сканер ловит ваше ПО.
  2. HOME_NET неверный, внутренний обмен = exploit kit.
  3. MTU/stream reassembly, ложный match на бинарный протокол.
  4. Ruleset только что обновился — устаревшие/новые.
  5. IPS на LAN-интерфейсе, а не на WAN, режет SMB.
  6. Rate-limit рядом, путают с IPS.

Диагностика

  1. Зафиксируйте 5-tuple и время.
  2. На сенсоре:
sudo jq 'select(.event_type=="alert" and .alert.action!=null)' /var/log/suricata/eve.json | tail
# уточните фильтр по src_ip клиента
sudo grep -F '10.0.10.50' /var/log/suricata/eve.json | tail

Выпишите signature_id, signature, src_ip, dest_ip, alert.action.

  1. Режим:
sudo grep -nE 'nfqueue|af-packet|ips' /etc/suricata/suricata.yaml
sudo nft list ruleset | grep -i queue

Есть queue в nft — inline. Нет queue, только SPAN — это IDS, drop в eve не должен резать (тогда виноват не IPS).

  1. Параллельно counters filter — чтобы не лечить не то.

  2. Концептуальный GUI периметра: alert с blocked=yes, правило SID, интерфейс WAN. Скрин в заявку. Не выключайте весь «IPS package».

Не воспроизводите эксплойт. Не ищите CVE. Достаточно SID и потока.

Решение

Сценарий A. Точечный exception (предпочтительно)

Если поток легитимный (свой app 10.0.10.20 → API):

  • suppress/pass lists по документации Suricata для данного SID и IP.
  • либо insert pass перед drop в local.rules — только если понимаете синтаксис вашей версии.

Проверка -T, reload. Заявка: SID, IP, срок пересмотра 30 дней.

Сценарий B. Перевести правило в detect

В disable.conf / convert drop→alert для одного SID через механизм suricata-update (modify.conf: drop→alert для sid).

sudo cp -a /etc/suricata /root/suricata.bak.$(date +%F)
# modify.conf: пример директивы convert — сверьте man suricata-update вашей версии
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata

Трафик больше не режется этим SID, алерт остаётся — потом решите, нужен ли exception или сигнатура мусор.

Сценарий C. IPS только на WAN

Не гоняйте nfqueue на интерфейсе LAN с SMB/AD. WAN ens18 к 203.0.113.10 — типичное место. Внутренний обмен не должен попадать в exploit-классы.

nft: queue только iifname wan / oifname wan для new+established по политике, не iif lo.

Сценарий D. Аварийно сервис лежит

Краткий rollback:

# вернуть nft без queue из bak, filter drop/allow сохранить
sudo nft -f /root/nftables.conf.bak.pre-ips
sudo systemctl start nftables

Suricata можно оставить в IDS (af-packet) без queue. Не systemctl stop nftables.

Сценарий E. Ложное на TLS/VPN

Не отключайте IPS на 443 целиком. Exception на IP VPN-концентратора / конкретный SID «encrypted suspicious». Параллельно проверьте rate limit.

Как не перепутать stall NFQUEUE и drop SID

Если пакеты «висят» (timeout везде, eve пустой), это очередь без потребителя, не сигнатура. Проверьте systemctl is-active suricata и nft list ruleset | grep -i queue. Мёртвый suricata + queue без bypass = сетевой простой. Аварийный nft из bak без queue, filter drop/allow как в матрице. Потом поднимите Suricata в af-packet (detect) и разберите SID уже без nfqueue.

Если eve показывает drop SID на TLS к 10.0.30.10:443 с LAN 10.0.10.50, скопируйте полный JSON алерта в тикет: signature, flow_id, payload не нужен. Exception пишите на этот dst/port/SID, не на весь VLAN. Через неделю exception без обоснования — на пересмотр: либо приложение изменили, либо сигнатура полезна и ловит реально плохое.

MikroTik рядом: не FastTrack'айте тот же поток, который Linux IPS должен видеть — иначе картина «IPS молчит, сайт мёртв» будет из-за другого ящика.

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

  1. Бизнес-поток проходит при работающем Suricata.
  2. В eve этот SID либо alert без drop, либо не срабатывает на 5-tuple.
  3. Чужой шум на WAN (свой контролируемый скан своего IP) всё ещё детектится другими SID.
  4. nft list policy drop на input/forward на месте.
  5. Пользователи 1С/сайт подтверждают.

Повторите тот же клиент 10.0.10.50, тот же URL/порт.

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

  • Другой SID сразу подхватил тот же поток — смотрите новый топ.
  • Filter/GeoIP.
  • MTU, не IPS.
  • Кластер: правили один узел.
  • Приложение реально вредоносное — тогда exception нельзя, чините app.

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

  • IPS сначала в detect недели, потом drop на проверенных классах.
  • Lab-replay своего трафика перед promote ruleset.
  • Каждое convert/exception — тикет и expiry.
  • Мониторинг: drop-alerts vs тикеты «не открывается».
  • Не включать «все policy drop» с первого дня.

FAQ

Выключить IPS навсегда проще?

Проще и слепее. Оставьте detect. Filter всё равно нужен.

Можно ли whitelist весь 10.0.10.0/24 в IPS?

Тогда IPS не видит заражённый ПК, идущий в WAN. Whitelist узкий 5-tuple.

nfqueue и FastTrack MikroTik

Разные коробки. Не FastTrack'айте то, что должно идти в IPS на Linux. На MikroTik IPS в этом стеке нет — не ищите.

SID из блога про CVE

Игнор. Только ваш eve. CVE не выдумываем и не копируем «на всякий».

GUI «false positive» кнопка

Допустима, если пишет тот же suppress. Проверьте, что не disable entire ET DROP.