Настраиваем автоматическое реагирование в Wazuh
habr.comПривет, Хабр!Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.В SIEM обнаружение угроз зависит не от количества логов (иначе это уже не SIEM, а помойка хранилище для логов), а от того, могут ли правила точно определить: «какое событие представляет угрозу, насколько серьёзна угроза и что делать дальше».Wazuh, как народный SIEM с открытым исходным кодом, использует правила в формате XML в качестве ядра механизма обнаружения атак.
Многие статьи ограничиваются демонстрацией синтаксиса, но на практике написание, тестирование, переопределение и настройка реагирования для правил представляют собой замкнутый цикл, и любое звено в этом цикле может привести к неработоспособности правила.В этой статье мы рассмотрим написание пользовательских правил, их последующее тестирование с помощью wazuh-logtest, затем поговорим о переопределении встроенных правил и в завершение затронем вопросы активного реагирования на обнаруженные инциденты.Для начала давайте немного поговорим об основах написания правил корреляции (не путаем с правилами нормализации (декодерами), которые тоже живут неподалёку).Итак, все пользовательские правила должны быть размещены в /var/ossec/etc/rules/local_rules.xml, при этом категорически не следует напрямую изменять файлы в /var/ossec/ruleset/rules/, так как эти файлы будут перезаписаны при обновлении.Пользовательские правила используют диапазон ID 100000–120000, чтобы избежать конфликтов со встроенными правилами.В качестве примера давайте посмотрим на правило для обнаружения неудачных входов по SSH:Здесь у нас присутствует поле level, в котором мы определяем шкалу приоритетов в диапазоне 0–15:0–3 — информационные;4–7 — низкий приоритет;8–11 —
