Как я приручил Wazuh: от сотен ложных срабатываний к рабочему набору правил

Вот важная новость с фронта ИИ: Cloud4Y 56 минут назад Как я приручил Wazuh: от сотен ложных срабатываний к рабочему набору правил 5 мин 2. 4K Блог компании Cloud4Y Информационная безопасность * Системное администрирование * Серверное администрирование * DevOps * Кейс Задача пришла в формулировке, знакомой многим: «Wazuh работает, но сигналов столько, что не разобрать, где ложные срабатывания, а где реальные атаки. Надо что-то с этим сделать».

Для контекста: Wazuh – это open-source SIEM, который собирает логи, детектирует подозрительную активность и умеет на неё реагировать. Инструмент хороший, но дефолтный набор правил – как швейцарский нож: вроде и режет, и открывает, а под конкретную задачу всё равно приходится подтачивать. Он рассчитан на «среднюю» инфраструктуру и без адаптации генерирует много шума.

Технические детали

Моя задача сводилась к тому, чтобы отделить этот шум от значимых событий, не потеряв при этом сами атаки. Ниже – методология и грабли, на которые я наступил. Будет полезно тем, кто настраивает Wazuh впервые, и тем, кто хочет разгрузить аналитиков от потока ложных тревог.

Знакомство с правиламиДефолтные правила Wazuh лежат в /var/ossec/ruleset/rules/ – тысячи строк XML. Формат многословный (готовьтесь к закрывающим тегам в промышленных количествах), но к нему быстро привыкаешь, а главное – менять эти файлы напрямую не нужно. Все локальные правки выносятся в local_rules.

xml и в дополнительно загружаемые файлы. Удобнее работать через веб-интерфейс: он проверяет структуру XML на лету (парные теги, корректность вложенности) и не даст случайно сломать рабочую конфигурацию – наломать дров можно только в своей «песочнице». Типовые ложные срабатыванияЧаще всего нас будили три сценария:SSH-брутфорс с localhost.

Отраслевые последствия

Ansible выполняет ssh localhost в ходе provisioning, а Wazuh уверенно трактует это как попытку перебора. Кажется, что атака, а на деле штатный провижининг. Healthcheck'и мониторинга обращаются к эндпоинтам раз в 30 секунд – для правила это выглядит как подозрительная HTTP-активность.

На практике это просто Prometheus занимается своим делом. Изменения файлов в /tmp. CI/CD оставляет там артефакты вроде wget-log.

42, а FIM-модуль реагирует на каждое изменение как на потенциальную компрометацию – и тревожит дежурного инженера в три ночи ради лога wget. Все три – классический фоновый шум, который маскирует реальные инциденты. Как пишутся локальные правилаМинимальное правило выглядит так: ssh 127.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.