Свой список IoC в правилах Wazuh без TI-платформы

Когда в журнале появляется адрес или домен из прошлого инцидента, правило должно поднять уровень оповещения, а не ждать покупки платформы Threat Intelligence. Ниже свой список индикаторов компрометации (IoC) в Wazuh: файл CDB, подключение в конфигурации, одно правило и проверка через wazuh-logtest. Это не лента из интернета «под ключ» и не MISP.

Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Установка: Wazuh в Docker. Свои правила по сценарию, не по списку: пять правил на Linux. Контекст уязвимостей — отдельно: KEV в Wazuh.

Что класть в список

Индикатор — значение, которое вы уже видели в своём инциденте или в бюллетене, которому доверяете: адрес источника, домен в журнале почты или прокси. Не кладите туда целые частные сети и не подписывайтесь на случайные выгрузки «миллион хэшей» без разбора: ложные срабатывания убьют канал оповещений за неделю.

Источник записи	Брать	Не брать
Свой инцидент	Адрес и домен из карточки, после разбора	Сырой дамп «на всякий случай»
Бюллетень НКЦКИ, вендора, CERT	То, что относится к вашим системам	Весь вложенный архив индикаторов
Публичный репозиторий	Ничего автоматически	Импорт по cron без рецензии

После добавления адреса из инцидента ведите разбор по классификации, а не блокируйте «сразу весь офис».

Событие сверяется со своим списком IoCПоле события сравнивается с файлом CDB; совпадение поднимает своё правило, промах остаётся обычным событием.1. Событиеполе srcip или домен2. Список CDBсвои ключи, не GitHub3. Правилооповещение или тишина

Список из своего инцидента и проверенного бюллетеня; чужая лента без разбора даст шум.

Файл CDB

Wazuh сравнивает поле события с константной базой (CDB). Файл — текст: ключ, двоеточие, необязательное значение. Адреса пишите в нотации, которую понимает движок: один узел как 192.0.2.55:, подсеть как префикс с точкой, см. документацию CDB. Примеры только из учебного диапазона.

# /var/ossec/etc/lists/local-ioc-ip
192.0.2.55:
198.51.100.10:

Ожидаемо: две строки, без пробелов вокруг двоеточия. Домены — отдельный файл, ключ без схемы https://:

# /var/ossec/etc/lists/local-ioc-domain
phishing.example.com:

В Docker кладите файлы в том /var/ossec/etc, иначе они пропадут при пересоздании контейнера. Имя контейнера как в статье про установку: single-node-wazuh.manager-1.

printf '192.0.2.55:\n198.51.100.10:\n' | docker exec -i single-node-wazuh.manager-1 \
  tee /var/ossec/etc/lists/local-ioc-ip

Ожидаемо: те же две строки на экране. Список пересобирается при старте анализатора: после правки перезапустите менеджер (ниже). Краткий обрыв разбора событий на время перезапуска — держите второе окно с журналом, если идёт разбор инцидента.

Подключение в конфигурации

В блоке <ruleset> укажите относительный путь без ведущего /var/ossec/. На хосте стека это файл config/wazuh_cluster/wazuh_manager.conf.

<list>etc/lists/local-ioc-ip</list>
<list>etc/lists/local-ioc-domain</list>

Ожидаемо: после перезапуска менеджер поднимается без ошибки про отсутствующий список. Проверка синтаксиса:

docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-analysisd -t

Ожидаемо: тихий выход или сообщение об успешной проверке, не «Unable to open list».

docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart

Правило

Идентификатор из диапазона 100000–120000, чтобы не пересечься со встроенными. Родитель 5760 — неудачная аутентификация SSH в типовом наборе Wazuh 4.x; на своей версии сначала прогоните строку без списка и посмотрите фактический ID.

<group name="local,svictor,ioc,">
  <rule id="100520" level="10">
    <if_sid>5760</if_sid>
    <list field="srcip" lookup="address_match_key">etc/lists/local-ioc-ip</list>
    <description>Неудачный вход SSH с адреса из своего списка IoC</description>
  </rule>
</group>

Для домена в поле журнала прокси или почты используйте lookup="match_key" и имя вашего поля после декодирования, не копируйте srcip вслепую. Как писать и ставить файл правил: пять правил.

Проверка logtest

docker exec -it single-node-wazuh.manager-1 /var/ossec/bin/wazuh-logtest

Вставьте одну строку (дата любая, адрес из списка):

Oct 19 09:00:00 web sshd[1234]: Failed password for invalid user admin from 192.0.2.55 port 22 ssh2

Ожидаемо: в фазе 3 срабатывает ваше правило 100520, не только встроенное 5760. Если видите только родителя — список не подключён, поле не srcip или менеджер не перезапускали. Событие с адресом 203.0.113.5 правилом 100520 идти не должно.

Диагностика

Симптом	Причина и что делать
Unable to open list при старте	Путь в `<list>` неверный или файл вне тома. Проверьте `ls /var/ossec/etc/lists/` в контейнере
logtest ловит 5760, не 100520	Нет перезапуска, опечатка в `lookup` или родитель другой. Снимите дерево правил без списка
Срабатывает на весь офис	В список попала ваша сеть. Удалите ключ, разберите ложное, правило не отключайте целиком
Список «как у всех из GitHub»	Шум. Вернитесь к своим инцидентам и бюллетеням

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

Материал относится к направлению «Мониторинг кибербезопасности» (хаб: мониторинг, карта: карта зрелости). Гигиена — журналы, правила и реакция на свои индикаторы. Коммерческая платформа TI — другой уровень; её не имитирует папка с чужими списками. Аналог в CIS Control 13: сеть смотрят и сопоставляют с известными признаками, не обещая продукт.

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

В списке есть хотя бы один учебный или боевой ключ, файл лежит в томе /var/ossec/etc/lists/.
wazuh-analysisd -t не ругается на список; после restart logtest на ключе даёт правило 100520.
Есть журнал: кто добавил ключ, откуда, дата снятия.
Срабатывание идёт в классификацию, не в слепую блокировку всей подсети.