IDS и IPS на Suricata: установка, правила, обновление сигнатур и события в SIEM

Межсетевой экран пропускает или блокирует соединения по адресам и портам. Система обнаружения вторжений (IDS) смотрит дальше: читает содержимое трафика и сообщает, что по порту 443 идёт не обычный HTTPS, а канал управления вредоносной программы, а в запросе к вашему сайту передаётся шаблон атаки. Suricata — открытое решение для этого. Ниже куда её ставить, как установить, обновлять сигнатуры, подавлять шум, подключить события к SIEM и проверить, что она действительно видит атаки. Режим блокировки (IPS) в конце: включать его надо после того, как вы привыкли к потоку событий.

Куда уходят события дальше и как строить правила корреляции: журналы сетевых средств в Wazuh. Чем SIEM отличается от мониторинга: SOC и SIEM. Базовая защита периметра экраном: nftables и firewalld.

Как это работает

Suricata получает копию трафика, сопоставляет её с правилами и пишет события в файл eve.json. Дальше агент передаёт события в SIEM, где срабатывают правила и создаются заявки. Если эту цепочку не довести до реакции человека, IDS превращается в «лампочку на сервере», на которую никто не смотрит.

Шаг 1. Где поставить сенсор

Для небольшой компании разумное начало — первые два варианта в режиме обнаружения. Смотреть нужно трафик на границе (интернет — сеть) и, если возможно, между внутренними сегментами, потому что именно внутри видно передвижение злоумышленника. Нагрузка ориентировочно: ядро процессора на каждые несколько сотен мегабит и несколько гигабайт памяти; для канала 100–300 Мбит хватит скромной виртуальной машины. Зашифрованный трафик Suricata не расшифровывает: она видит заголовки, имена серверов и некоторые параметры соединения, но не содержимое.

Шаг 2. Установка и базовая настройка

sudo apt install suricata
sudoedit /etc/suricata/suricata.yaml

В файле настройки поправьте три места. Сети, которые вы защищаете, и сеть источника:

vars:
  address-groups:
    HOME_NET: "[192.0.2.0/24,198.51.100.0/24,203.0.113.0/24]"
    EXTERNAL_NET: "!$HOME_NET"

Интерфейс, с которого читается трафик (в разделе af-packet):

af-packet:
  - interface: eth1
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

И выключите контрольные суммы, если сенсор стоит на узле с аппаратной разгрузкой (иначе часть пакетов будет отброшена как «битая»): checksum-validation: no в разделе stream. Проверка конфигурации и запуск:

sudo suricata -T -c /etc/suricata/suricata.yaml -v
sudo systemctl enable --now suricata
sudo tail -n 20 /var/log/suricata/suricata.log

Ожидаемо: в конце проверки сообщение о том, что конфигурация загружена успешно; в журнале строки о запуске потоков. Имя интерфейса и параметры подставьте свои. Не запускайте на интерфейсе управления, если не хотите смотреть собственный трафик.

Шаг 3. Правила и их обновление

Без правил Suricata ничего не обнаруживает. Основной бесплатный набор — Emerging Threats Open; загружает и обновляет его утилита suricata-update:

sudo suricata-update list-sources | head
sudo suricata-update
sudo suricatasc -c ruleset-reload-nonblocking
ls -l /var/lib/suricata/rules/suricata.rules

Ожидаемо: suricata-update сообщает, сколько правил загружено и включено (обычно десятки тысяч), в каталоге правил появляется файл с свежей датой. Обновление должно идти автоматически, и расписание — это то, что вы потом показываете при проверке:

# /etc/cron.d/suricata-update
30 3 * * * root /usr/bin/suricata-update --quiet && /usr/bin/suricatasc -c ruleset-reload-nonblocking

Добавьте сигнал на сбой: если обновление не проходит несколько дней, правила устаревают, а вы об этом не знаете. Проверяйте возраст файла правил скриптом мониторинга (например, предупреждение, если файл старше трёх суток). Платные и специализированные наборы подключаются как дополнительные источники командой suricata-update enable-source; российские источники и правила под ваши сервисы пишутся вручную в файле локальных правил.

Шаг 4. Шум: что отключать и как

В первые дни IDS выдаёт сотни событий в час, большая часть которых — сканирования из интернета и срабатывания на нормальную работу ваших систем. Если ничего не делать, на сенсор перестанут смотреть уже через неделю. Порядок настройки:

1. Две недели просто собирайте события и смотрите, какие правила срабатывают чаще всего: jq -r '.alert.signature' /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20.
2. Для каждого частого правила решите: это реальная угроза, нормальная работа или шум. Нормальную работу отключайте точечно по идентификатору.
3. Не отключайте целыми категориями «чтобы стало тихо»: вместе с шумом пропадут нужные сигналы.

# /etc/suricata/disable.conf: отключить правило по номеру сигнатуры
2210054
# /etc/suricata/threshold.config: подавить для одного адреса
suppress gen_id 1, sig_id 2013028, track by_src, ip 192.0.2.30

sudo suricata-update --disable-conf /etc/suricata/disable.conf
sudo suricatasc -c ruleset-reload-nonblocking

Каждое отключение и подавление записывайте в журнал с причиной и датой: так вы потом отвечаете на вопрос «почему IDS не заметила». Раз в квартал просматривайте список отключённого.

Шаг 5. События в SIEM

Suricata пишет события в /var/log/suricata/eve.json: сигнатуры, DNS-запросы, HTTP, TLS и другое в формате JSON. Агент Wazuh читает файл и передаёт события на сервер, где для Suricata есть готовые декодеры и правила. На узле сенсора в конфигурации агента:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

sudo systemctl restart wazuh-agent
sudo grep -c '"event_type":"alert"' /var/log/suricata/eve.json

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

Шаг 6. Проверьте, что IDS видит атаки

Безопасный тестовый запрос, который вызывает срабатывание стандартного правила (из примеров документации Suricata). С любого узла за сенсором:

curl -s http://testmynids.org/uid/index.html
sudo tail -n 5 /var/log/suricata/fast.log

Ожидаемо: в fast.log появляется строка с сообщением о том, что ответ содержит результат команды id от пользователя root. Если её нет, сенсор не видит трафик: проверьте интерфейс, зеркало порта, HOME_NET. Для проверки состояния сенсора:

sudo tail -n 40 /var/log/suricata/stats.log | grep -E "kernel_packets|kernel_drops"

Ожидаемо: число потерянных пакетов kernel_drops мало по сравнению с принятыми. Рост потерь означает, что сенсор не справляется: нужно больше ядер, настройка потоков или отказ от разбора ненужных протоколов.

Режим IPS: блокировка

Suricata умеет не только сообщать, но и блокировать: через очередь NFQUEUE пакеты передаются на проверку и возвращаются с вердиктом. Включайте этот режим после нескольких месяцев наблюдения и только для проверенных правил. Схема для Linux-шлюза:

# в nftables: отправить пересылаемый трафик на проверку
table inet ips {
  chain forward {
    type filter hook forward priority -10; policy accept;
    queue num 0 bypass
  }
}
sudo suricata -c /etc/suricata/suricata.yaml -q 0

Слово bypass означает: если Suricata остановилась, трафик идёт дальше без проверки, а не блокируется. Это спасает от остановки сети, но означает «защита без предупреждения»: отслеживайте работу службы. Для блокировки правило нужно перевести из alert в drop в файле /etc/suricata/modify.conf. Начинайте с правил с высокой точностью (известные каналы управления) и откатывайте при любом ложном срабатывании, которое задело бизнес-трафик.

Что IDS даёт и чего не даёт

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

Диагностика

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

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

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

1. Тестовый запрос на testmynids.org вызывает срабатывание и запись в fast.log и в SIEM.
2. Файл правил обновлён не позднее трёх суток назад, расписание есть.
3. kernel_drops в stats.log малы по сравнению с принятыми пакетами.
4. Отключённые правила записаны с причиной.
5. Для высокого приоритета есть оповещение ответственному, и хотя бы один пример реакции.

Источники

• Документация Suricata: docs.suricata.io; quickstart и тестовый запрос.
• suricata-update: suricata-update.readthedocs.io.
• Emerging Threats Open: rules.emergingthreats.net.
• NIST SP 800-94, руководство по системам обнаружения и предотвращения вторжений: csrc.nist.gov.