Правила обнаружения Wazuh 4.14 - синтаксис и логика

Правила Wazuh определяют логику обнаружения угроз: какие события считать значимыми, какой уровень серьезности назначить и какие метаданные добавить к алерту. Каждое правило описывается в формате XML и содержит условия срабатывания, описание и классификацию. В этом руководстве подробно рассмотрен синтаксис правил, система уровней, составные правила и инструменты тестирования.

Структура XML-правила

Каждое правило заключено в элемент <rule> внутри контейнера <group>:

<group name="syslog,sshd,">
  <rule id="100001" level="5">
    <decoded_as>sshd</decoded_as>
    <match>Failed password</match>
    <description>SSH authentication failure.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failed,pci_dss_10.2.4,</group>
  </rule>
</group>

Атрибуты элемента rule

Элементы условий срабатывания

Сопоставление с содержимым

match - поиск подстроки или паттерна в теле лога:

<match>Failed password</match>

Поддерживает атрибуты negate="yes" (инверсия) и type (osmatch, osregex, pcre2):

<match type="pcre2" negate="yes">successful|accepted</match>

regex - поиск по регулярному выражению:

<regex>Failed password for (\S+) from (\S+)</regex>

decoded_as - срабатывание при совпадении с определенным декодером:

<decoded_as>sshd</decoded_as>

category - срабатывание по категории декодера:

<category>firewall</category>

Сопоставление с извлеченными полями

field - проверка значения поля, извлеченного декодером:

<field name="log_type">error</field>

srcip / dstip - сопоставление по IP-адресу источника или назначения (поддерживает CIDR):

<srcip>192.168.1.0/24</srcip>
<srcip negate="yes">10.0.0.0/8</srcip>

srcport / dstport - порт источника или назначения:

<dstport>22</dstport>

user - имя пользователя:

<user>root</user>

hostname - имя хоста источника:

<hostname>web-server-01</hostname>

program_name - имя программы из заголовка syslog:

<program_name>sshd</program_name>

action - действие, извлеченное декодером:

<action>blocked</action>

status - статус события:

<status>403</status>

url - URL из события:

<url type="pcre2">/admin|/wp-login\.php</url>

protocol - протокол транспортного уровня:

<protocol>TCP</protocol>

Временные фильтры

time - диапазон времени суток (формат hh:mm-hh:mm):

<time>22:00-06:00</time>

weekday - день недели:

<weekday>weekend</weekday>

Метаданные и описание

description - человекочитаемое описание правила (обязательно):

<description>Multiple SSH authentication failures from same source.</description>

info - дополнительная информация:

<info type="link">https://attack.mitre.org/techniques/T1110/</info>
<info type="text">Possible brute force attack detected.</info>

group - теги для группировки и фильтрации (через запятую, завершающая запятая обязательна):

<group>authentication_failed,brute_force,pci_dss_10.2.4,</group>

mitre - маппинг на техники MITRE ATT&CK:

<mitre>
  <id>T1110</id>
  <id>T1078</id>
</mitre>

options - дополнительные флаги поведения:

<options>no_log</options>
<options>alert_by_email</options>

Классификация уровней правил (0-15)

Wazuh использует 16 уровней серьезности. Корректное назначение уровня критически важно для приоритизации алертов.

Правила с уровнем 12 и выше генерируют уведомления в реальном времени (при настроенной интеграции с системами оповещения).

Порядок выполнения и перезапись правил

Порядок загрузки

Wazuh загружает правила в следующем порядке:

1. Стандартные правила из /var/ossec/ruleset/rules/ (в алфавитном порядке файлов)
2. Пользовательские правила из /var/ossec/etc/rules/ (включая local_rules.xml)

Пользовательские правила обрабатываются после стандартных и могут их переопределять.

Перезапись стандартных правил

Для изменения поведения стандартного правила используйте атрибут overwrite:

<!-- Перезапись стандартного правила 5710 (изменение уровня) -->
<rule id="5710" level="10" overwrite="yes">
  <decoded_as>sshd</decoded_as>
  <match>illegal user|invalid user</match>
  <description>SSH: attempt to login using a non-existent user.</description>
  <mitre>
    <id>T1110.001</id>
  </mitre>
  <group>authentication_failed,pci_dss_10.2.4,</group>
</rule>

Перезаписанное правило должно содержать полное определение, а не только измененные поля.

Подавление ложных срабатываний

Для подавления ложного срабатывания создайте дочернее правило с уровнем 0:

<rule id="100100" level="0">
  <if_sid>5710</if_sid>
  <srcip>10.0.0.50</srcip>
  <description>Suppress SSH invalid user alert from monitoring system.</description>
</rule>

Составные правила (корреляция)

Составные правила позволяют обнаруживать паттерны на основе последовательности или частоты событий.

Связь с родительским правилом (if_sid)

if_sid - правило срабатывает только если ранее сработало указанное правило:

<rule id="100010" level="10">
  <if_sid>5710</if_sid>
  <same_source_ip />
  <description>Multiple SSH invalid user attempts from same source.</description>
</rule>

if_group - правило срабатывает при совпадении группы:

<rule id="100011" level="8">
  <if_group>authentication_failed</if_group>
  <match>root</match>
  <description>Authentication failure for root account.</description>
</rule>

if_level - правило срабатывает при определенном уровне предыдущего события:

<rule id="100012" level="12">
  <if_level>10</if_level>
  <same_source_ip />
  <description>High severity event followed by another from same source.</description>
</rule>

Правила частоты (frequency + timeframe)

if_matched_sid - срабатывает, если указанное правило сработало frequency раз за timeframe секунд:

<rule id="100020" level="10" frequency="5" timeframe="120">
  <if_matched_sid>5710</if_matched_sid>
  <same_source_ip />
  <description>SSH brute force: 5 invalid user attempts in 2 minutes.</description>
  <mitre>
    <id>T1110.001</id>
  </mitre>
  <group>brute_force,pci_dss_11.4,</group>
</rule>

if_matched_group - аналогично, но по группе правил:

<rule id="100021" level="10" frequency="8" timeframe="300">
  <if_matched_group>authentication_failed</if_matched_group>
  <same_source_ip />
  <description>Multiple authentication failures from same IP in 5 minutes.</description>
</rule>

Элементы корреляции полей

Списки CDB (Constant Database)

Списки CDB позволяют проверять значения полей по внешним справочным таблицам (списки IP-адресов, IoC, разрешенные процессы).

Формат списка

Файл списка содержит пары ключ:значение (значение необязательно):

192.168.1.100:known_scanner
10.0.0.50:monitoring_system
172.16.0.0/12:

Использование в правилах

<rule id="100030" level="12">
  <if_sid>5710</if_sid>
  <list field="srcip" lookup="address_match_key">etc/lists/malicious-ips</list>
  <description>SSH login attempt from known malicious IP.</description>
</rule>

Типы поиска (lookup):

Регистрация списков

Списки должны быть зарегистрированы в ossec.conf:

<ruleset>
  <list>etc/lists/malicious-ips</list>
</ruleset>

После добавления или изменения списка перезагрузите менеджер:

/var/ossec/bin/wazuh-control reload

Стандартный набор правил

Стандартные правила Wazuh организованы по категориям в отдельные файлы.

Полный список файлов правил доступен в /var/ossec/ruleset/rules/.

Маппинг MITRE ATT&CK

Wazuh поддерживает маппинг правил на техники и тактики MITRE ATT&CK. Это позволяет визуализировать покрытие матрицы ATT&CK в дашборде.

<rule id="100050" level="12">
  <if_sid>5710</if_sid>
  <frequency>10</frequency>
  <timeframe>60</timeframe>
  <same_source_ip />
  <description>SSH brute force attack detected.</description>
  <mitre>
    <id>T1110.001</id>  <!-- Brute Force: Password Guessing -->
  </mitre>
</rule>

Идентификаторы техник необходимо верифицировать по официальной матрице MITRE ATT&CK .

Группы для стандартов соответствия

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

<group>pci_dss_10.2.4,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,tsc_CC6.1,</group>

Тестирование правил с wazuh-logtest

Утилита wazuh-logtest позволяет протестировать правила в интерактивном режиме.

Интерактивный режим

/var/ossec/bin/wazuh-logtest

Введите лог-строку и получите результат анализа:

Type one log per line

Mar  5 10:15:01 server sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 22 ssh2

**Phase 1: Completed pre-decoding.
       full event: 'Mar  5 10:15:01 server sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 22 ssh2'
       timestamp: 'Mar  5 10:15:01'
       hostname: 'server'
       program_name: 'sshd'

**Phase 2: Completed decoding.
       name: 'sshd'
       parent: 'sshd'
       srcip: '192.168.1.100'
       srcport: '22'
       srcuser: 'admin'

**Phase 3: Completed filtering (rules).
       id: '5710'
       level: '5'
       description: 'sshd: Attempt to login using a non-existent user.'
       groups: '['syslog', 'sshd', 'invalid_login', 'authentication_failed']'

Пакетный режим

Для тестирования набора логов из файла:

cat test-logs.txt | /var/ossec/bin/wazuh-logtest -q

Проверка конкретного правила

Для проверки, что определенное правило срабатывает на определенный лог, используйте флаг -U:

echo "test log line" | /var/ossec/bin/wazuh-logtest -U 100001:5:sshd

Команда вернет код 0, если правило с id=100001, level=5 и декодером sshd сработало.

Подробный вывод

Для отладки используйте флаг -v:

/var/ossec/bin/wazuh-logtest -v

Диапазоны идентификаторов правил

При создании пользовательских правил используйте идентификаторы из диапазона 100000-999999 для избежания конфликтов со стандартными правилами.

Контрольный список создания правила

При создании нового правила убедитесь, что выполнены все пункты:

• Идентификатор правила (id) в корректном диапазоне
• Уровень (level) соответствует серьезности события
• Описание (description) понятно и содержит информацию для действий
• Маппинг MITRE ATT&CK (mitre/id) указан и верифицирован
• Декодер извлекает необходимые поля до срабатывания правила
• Правило протестировано с wazuh-logtest
• Отсутствует риск катастрофического бэктрекинга в регулярных выражениях
• Теги групп (group) заполнены и завершаются запятой

Связанные разделы

• Декодеры Wazuh - извлечение данных из логов
• Анализ журналов - сбор и обработка логов
• Активное реагирование - действия при срабатывании правил
• Устранение неполадок - диагностика проблем с правилами