Хостовая защита видит только то, что происходит на самой машине. Но атака сначала идет по проводу: сканирование, эксплойт, выгрузка данных наружу. Задача этого урока - научиться ставить уши на сетевой трафик. Разберем, чем NIDS отличается от NIPS, как работают Suricata и Snort, как читать и обновлять правила, как руками ковырять пакеты через tcpdump, tshark и Wireshark, и зачем рядом с сигнатурным движком держать Zeek. В конце поговорим про самое важное и самое заваливаемое на практике - куда физически воткнуть сенсор.
Как это работает
NIDS (Network Intrusion Detection System) - это пассивный наблюдатель. Он получает копию трафика, прогоняет каждый пакет или поток через набор правил-сигнатур и при совпадении пишет алерт. Сам трафик он не трогает, задержку не вносит, упасть может без последствий для сети. NIPS (Network Intrusion Prevention System) - тот же движок, но включенный в разрыв (inline): он не просто видит пакет, а решает, пропустить его или дропнуть. Цена за это - он становится точкой отказа и источником задержки.
Сигнатурный подход прост: есть база описаний известных атак (байтовые последовательности, аномалии заголовков, URI эксплойтов), движок ищет совпадение. Минус очевиден - новую, еще не описанную атаку он не увидит. Поэтому современные сенсоры дополняют сигнатуры поведенческим анализом и логированием метаданных, чтобы было что разбирать постфактум.
Suricata и Snort решают одну задачу разными способами. Snort 3 - наследник классики, однопоточное ядро детекта в основе, свой обновленный формат правил, родная база - Talos. Suricata (актуальна ветка 8.x на 2026) изначально многопоточная: модель worker-потоков раскладывает обработку пакетов по всем ядрам и масштабируется почти линейно с ростом числа CPU. Suricata понимает большинство правил Snort 2.x и Emerging Threats, выдает структурированный лог eve.json и умеет вытаскивать файлы из потока. На практике на одном железе Suricata держит больше включенных правил и шумит больше алертов.
Zeek (бывший Bro) - не про сигнатуры. Это движок сетевого мониторинга: он не ищет атаки по шаблону, а превращает сырые пакеты в богатые структурированные логи. conn.log - каждое соединение, dns.log - все DNS-запросы, http.log, ssl.log, files.log. Это золото для threat hunting и расследований: даже если в момент атаки сигнатуры не было, у вас остается полная история того, кто с кем и когда говорил. Классическая боевая связка - Suricata как быстрый сигнатурный детектор плюс Zeek как контекстный регистратор.
Команды и примеры
Установка. В Debian 13 / Ubuntu 24.04 пакеты есть в репозиториях, но для свежей ветки лучше PPA OISF:
Код: Выделить всё
# Debian/Ubuntu
apt install suricata suricata-update
# свежее - из официального PPA OISF
add-apt-repository ppa:oisf/suricata-stable && apt update && apt install suricata
# RHEL 10 / Fedora 41+
dnf install suricata
# Snort 3 в Fedora
dnf install snort3
Код: Выделить всё
suricata-update update-sources # список доступных источников
suricata-update enable-source et/open # включить Emerging Threats Open
suricata-update # скачать и собрать правила
Код: Выделить всё
kill -USR2 $(pidof suricata)
Код: Выделить всё
suricata -T -c /etc/suricata/suricata.yaml -v # тест конфигурации
suricata -i ens3 -c /etc/suricata/suricata.yaml # IDS на интерфейсе
Код: Выделить всё
# nftables: отправить форвардящийся трафик в очередь 0
nft add rule inet filter forward queue num 0
# Suricata в inline-режиме на этой очереди
suricata -q 0 -c /etc/suricata/suricata.yaml
Код: Выделить всё
alert tcp any any -> $HOME_NET 22 (msg:"SSH brute force attempt"; \
flow:to_server; threshold:type both,track by_src,count 5,seconds 30; \
classtype:attempted-admin; sid:1000001; rev:1;)
Ручной анализ трафика. tcpdump - захват и BPF-фильтры:
Код: Выделить всё
tcpdump -i ens3 -nn -s0 -w capture.pcap 'tcp port 443 and host 10.0.0.5'
Код: Выделить всё
tshark -r capture.pcap -Y 'http.request.method == "POST"' -T fields -e ip.src -e http.host
Частые грабли
- Путают BPF и display-фильтры. В tcpdump и в ключе -f tshark - синтаксис BPF (port 443). В поле -Y tshark и в строке фильтра Wireshark - синтаксис дисплея (tcp.port == 443). Перепутал - либо ошибка, либо тихо ничего не отфильтровалось.
- Сенсор на обычном порту коммутатора видит только свой бродкаст и трафик к себе. Без зеркалирования или TAP половина пакетов до движка просто не доходит.
- Забывают про офлоадинг сетевой карты. GRO/LRO/TSO склеивают сегменты, и движок видит несуществующие в проводе гигантские пакеты. Перед захватом - ethtool -K ens3 gro off lro off tso off.
- suricata-update только собирает правила в файл. Чтобы движок их применил, нужен USR2 или рестарт. Скачал и думаешь что заработало - а оно нет.
- IPS в разрыве без продумывания отказа. Упал процесс или забил очередь - и весь сегмент сети встал. Нужны fail-open bypass или хотя бы тестирование на отключение.
- Хешируете прохождение по SPAN-порту, а он перегружен и молча дропает пакеты при превышении пропускной способности. Алертов нет не потому что чисто, а потому что пакеты не дошли.
- Поднимите два пакета: Suricata в Ubuntu 24.04 и (опционально) Snort 3 в Fedora.
- Выполните suricata-update, включите источник et/open, соберите правила и проверьте конфиг через suricata -T.
- Добавьте свое правило с sid:1000001 на детект ICMP (alert icmp any any -> any any (msg:"PING"; sid:1000001;)) и перечитайте правила сигналом USR2.
- Запустите Suricata в IDS-режиме на интерфейсе, с другой машины пингуйте стенд и найдите алерт в /var/log/suricata/fast.log и в eve.json.
- Параллельно снимите трафик tcpdump в файл, откройте его в tshark с display-фильтром icmp и сверьте, что видите те же пакеты.
- Заверните трафик в nftables NFQUEUE, запустите Suricata с -q 0 и замените действие правила на drop - убедитесь, что пинг теперь блокируется.
- Дополнительно: установите Zeek, прогоните тот же pcap через zeek -r capture.pcap и посмотрите conn.log.
- Чем принципиально отличается размещение NIDS от NIPS в топологии сети и какие риски добавляет inline-режим?
- Почему Suricata масштабируется на многоядерном железе лучше, чем классическое ядро Snort?
- Какой инструмент обновляет правила Suricata, куда он кладет результат и что нужно сделать, чтобы движок применил новые сигнатуры без полного рестарта?
- В чем разница между BPF-фильтром tcpdump и display-фильтром tshark/Wireshark, приведите пример одного и того же условия в обоих синтаксисах.
- Зачем в зрелом SOC держать Zeek рядом с сигнатурным движком, какую задачу он закрывает, которую сигнатуры не решают?
- Что такое SPAN-порт и сетевой TAP, в чем их слабые места при высокой нагрузке?
