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

> Синтаксис правил Wazuh 4.14 - XML-элементы, уровни классификации 0-15, составные правила, MITRE ATT&CK маппинг, списки CDB и тестирование

Source: https://opennix.org/docs/wazuh/rules-decoders/wazuh-rules/


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

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

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

```xml
<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

| Атрибут | Обязательный | Описание |
|---|---|---|
| `id` | Да | Уникальный числовой идентификатор (1-999999) |
| `level` | Да | Уровень серьезности алерта (0-15) |
| `frequency` | Нет | Количество совпадений для срабатывания |
| `timeframe` | Нет | Временное окно в секундах для `frequency` |
| `ignore` | Нет | Время подавления повторных алертов (секунды) |
| `maxsize` | Нет | Максимальный размер события |
| `noalert` | Нет | Если `1`, правило срабатывает без генерации алерта |
| `overwrite` | Нет | Если `yes`, перезаписывает правило с тем же `id` |

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

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

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

```xml
<match>Failed password</match>
```

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

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

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

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

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

```xml
<decoded_as>sshd</decoded_as>
```

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

```xml
<category>firewall</category>
```

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

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

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

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

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

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

```xml
<dstport>22</dstport>
```

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

```xml
<user>root</user>
```

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

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

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

```xml
<program_name>sshd</program_name>
```

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

```xml
<action>blocked</action>
```

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

```xml
<status>403</status>
```

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

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

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

```xml
<protocol>TCP</protocol>
```

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

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

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

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

```xml
<weekday>weekend</weekday>
```

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

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

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

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

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

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

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

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

```xml
<mitre>
  <id>T1110</id>
  <id>T1078</id>
</mitre>
```

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

```xml
<options>no_log</options>
<options>alert_by_email</options>
```

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

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

| Уровень | Название | Описание |
|---|---|---|
| 0 | Ignored | Событие игнорируется, алерт не генерируется. Используется для подавления ложных срабатываний |
| 2 | System low priority notification | Системные уведомления без значимости для безопасности |
| 3 | Successful/Authorized events | Успешные авторизованные действия (вход, разрешение файрвола) |
| 4 | System low priority error | Ошибки конфигурации, незначительные системные проблемы |
| 5 | User generated error | Ошибки аутентификации (неудачный вход, неверный пароль) |
| 6 | Low relevance attack | Неэффективные атаки, частые срабатывания IDS без реальной угрозы |
| 7 | Bad word matching | События с подозрительными ключевыми словами, но без четкой классификации |
| 8 | First time seen | Действие выполняется впервые (первый вход, новый процесс) |
| 9 | Error from invalid source | Действия с неизвестных или подозрительных источников |
| 10 | Multiple user generated errors | Множественные ошибки аутентификации (возможна brute-force атака) |
| 11 | Integrity checking warning | Изменение бинарных файлов, обнаружение rootkit |
| 12 | High importance event | Критические системные предупреждения, атаки на уровне приложений |
| 13 | Unusual error (high importance) | Паттерны, характерные для методологий атак |
| 14 | High importance security event | Корреляционные алерты, вероятные атаки |
| 15 | Severe attack | Подтвержденная атака, требуется немедленное реагирование. Ложные срабатывания исключены |

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

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

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

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

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

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

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

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

```xml
<!-- Перезапись стандартного правила 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:

```xml
<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** - правило срабатывает только если ранее сработало указанное правило:

```xml
<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** - правило срабатывает при совпадении группы:

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

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

```xml
<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` секунд:

```xml
<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** - аналогично, но по группе правил:

```xml
<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>
```

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

| Элемент | Описание |
|---|---|
| `<same_source_ip />` | IP-адрес источника совпадает в коррелируемых событиях |
| `<different_source_ip />` | IP-адрес источника различается |
| `<same_dst_ip />` | IP-адрес назначения совпадает |
| `<different_dst_ip />` | IP-адрес назначения различается |
| `<same_user />` | Имя пользователя совпадает |
| `<different_user />` | Имя пользователя различается |
| `<same_id />` | Идентификатор совпадает |
| `<same_location />` | Источник лога совпадает |
| `<same_protocol />` | Протокол совпадает |
| `<different_protocol />` | Протокол различается |

## Списки CDB (Constant Database)

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

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

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

```
192.168.1.100:known_scanner
10.0.0.50:monitoring_system
172.16.0.0/12:
```

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

```xml
<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`):

| Тип | Описание |
|---|---|
| `match_key` | Точное совпадение ключа |
| `not_match_key` | Ключ отсутствует в списке |
| `address_match_key` | Совпадение IP-адреса (с поддержкой CIDR) |
| `not_address_match_key` | IP-адрес отсутствует в списке |
| `match_key_value` | Совпадение ключа и значения |

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

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

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

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

```bash
/var/ossec/bin/wazuh-control reload
```

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

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

| Файл | Категория | Примеры правил |
|---|---|---|
| `0015-ossec_rules.xml` | Wazuh internal | Статус агентов, ошибки менеджера |
| `0095-sshd_rules.xml` | SSH | Аутентификация, brute force, invalid user |
| `0100-syslog_rules.xml` | Syslog | Системные события Linux |
| `0200-attack_rules.xml` | Attacks | Обнаружение типовых атак |
| `0210-pam_rules.xml` | PAM | Аутентификация через PAM |
| `0230-postfix_rules.xml` | Mail | Почтовый сервер Postfix |
| `0240-apache_rules.xml` | Apache | Веб-сервер Apache |
| `0250-nginx_rules.xml` | Nginx | Веб-сервер Nginx |
| `0350-amazon_rules.xml` | AWS | CloudTrail, GuardDuty |
| `0470-windows_rules.xml` | Windows | Журнал событий Windows |
| `0575-win-firewall_rules.xml` | Windows Firewall | Windows Defender Firewall |
| `0620-win-security_rules.xml` | Windows Security | Аудит безопасности Windows |
| `0800-sysmon_rules.xml` | Sysmon | Мониторинг процессов Windows |
| `0840-docker_rules.xml` | Docker | События контейнеров |

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

## Маппинг MITRE ATT&CK

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

```xml
<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](https://attack.mitre.org/).

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

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

```xml
<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` позволяет протестировать правила в интерактивном режиме.

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

```bash
/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']'
```

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

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

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

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

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

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

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

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

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

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

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

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

| Диапазон | Назначение |
|---|---|
| 100000-109999 | Общие правила безопасности |
| 110000-119999 | Правила для конкретных приложений |
| 120000-129999 | Мониторинг AI/ML-пайплайнов |
| 147000-147999 | Целостность файлов и YARA |
| 191000-191999 | Эскалация привилегий |

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

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

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

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

- [Декодеры Wazuh](/docs/wazuh/rules-decoders/wazuh-decoders/) - извлечение данных из логов
- [Анализ журналов](/docs/wazuh/capabilities/wazuh-log-data-collection/) - сбор и обработка логов
- [Активное реагирование](/docs/wazuh/capabilities/wazuh-active-response/) - действия при срабатывании правил
- [Устранение неполадок](/docs/wazuh/operations/wazuh-troubleshooting/) - диагностика проблем с правилами