Базовая конфигурация suricata.yaml

%YAML 1.1
---
# Интерфейс для захвата трафика
af-packet:
  - interface: eth0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

# Включение EVE JSON logging
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert:
            metadata: yes
            payload: yes
            payload-printable: yes
        - http:
            extended: yes
        - dns:
            query: yes
            answer: yes
        - tls:
            extended: yes

# Правила: включение emerging-threats
rule-files:
  - suricata.rules
  - emerging-threats.rules

# Пороги для снижения шума
threshold-config: /etc/suricata/threshold.config

Ключевые моменты: af-packet обеспечивает zero-copy захват, EVE JSON упрощает интеграцию с SIEM, threshold.config фильтрует повторяющиеся события от одного источника.

Пример правила для детектирования SQL-инъекции

alert http any any -> any any (msg:"SQL Injection Attempt - UNION SELECT"; 
flow:to_server,established; 
uricontent:"/"; 
content:"UNION"; nocase; 
content:"SELECT"; nocase; 
distance:0; within:20; 
pcre:"/unions+select/i"; 
classtype:web-application-attack; 
sid:1000001; rev:1;)

# Пояснение компонентов правила:
# flow:to_server — только запросы к серверу
# uricontent + content — поиск паттерна в URI и теле
# distance/within — ограничение расстояния между токенами
# pcre — регулярное выражение для сложных паттернов
# classtype — категоризация для корреляции в SIEM
# sid — уникальный идентификатор правила

Я тестирую каждое правило в shadow mode перед активацией: запускаю Suricata с опцией -T для валидации синтаксиса, затем анализирую срабатывания на тестовом трафике.

Пример: правило для детектирования аномального доступа к БД

  601
  ^admin$
  ^3$
  ^10.0.0.
  Admin logon from external network via RDP
  authentication_failed,pci_dss_10.2.4,

# Объяснение:
# if_sid:601 — наследование от базового правила Windows logon
# targetUserName — фильтрация по имени учётной записи
# logonType:3 — сетевой вход (RDP, SMB)
# srcip negate — исключение внутренних подсетей
# level:12 — высокий приоритет для alert
# group — категоризация для корреляции и compliance

Чеклист настройки правил

[✓] Тестирование правила на исторических логах — почему: подтверждает что правило не генерирует false positive на легитимной активности

[✓] Документирование логики правила — почему: упрощает аудит, передачу знаний и последующую модификацию

[✓] Настройка threshold для снижения шума — почему: предотвращает alert fatigue при повторяющихся событиях от одного источника

[✓] Интеграция с обогащением контекста — почему: добавление geoip, user risk score ускоряет расследование

[ ] Регулярный пересмотр правил — почему: инфраструктура меняется, устаревшие правила создают шум или пропускают новые угрозы

Методы фильтрации событий

Thresholding — ограничение частоты alert от одного источника. Правило срабатывает только после N событий за временное окно. Это отсекает сканирование и brute-force с низкой интенсивностью.

Whitelist легитимной активности — исключение внутренних сканеров, backup-систем, мониторинга. Whitelist должен быть максимально конкретным: IP + порт + сигнатура, а не просто подсеть.

Контекстная корреляция — правило требует совпадения нескольких условий из разных источников. Например: failed login + успешный вход с того же IP + доступ к чувствительному ресурсу.

Метрики для оценки качества правил

[✓] Precision — доля true positive среди всех alert — почему: показывает точность детектирования, высокий false positive перегружает аналитиков

[✓] Recall — доля обнаруженных реальных инцидентов — почему: низкий recall означает пропуск угроз, критично для high-severity сценариев

[✓] Mean investigation time — среднее время расследования alert — почему: долгий анализ снижает эффективность SOC, указывает на сложность правил

[ ] Coverage — процент критичных активов под мониторингом — почему: пробелы в покрытии создают слепые зоны для атакующих