Привет, Хабр! Меня зовут Федор Тышков. Я работаю в отделе сопровождения инфраструктуры небольшого банка. Мне поставили задачу протестировать работу open-source инструмента для отслеживания изменений в конфигурационных файлах. Перед стартом я изучил много отзывов и практически все они были положительными, поэтому, казалось, все должно было пройти «без сучка и без задоринки». Но обо всем по порядку.

Wazuh — популярная многофункциональная платформа с открытым исходным кодом для мониторинга событий безопасности. Она широко используется для отслеживания изменений файлов, анализа логов и обнаружения угроз.

Компоненты архитектуры

Wazuh состоит из нескольких ключевых компонентов:

• Агент. Устанавливается на конечные точки (рабочие станции, серверы, контейнеры) и собирает данные безопасности, передавая их на центральный сервер для анализа.

• Сервер (менеджер). Анализирует данные, полученные от агентов, декодирует их, сопоставляет с правилами обнаружения и генерирует алерты. Поддерживает кластерную конфигурацию для обеспечения отказоустойчивости и распределения нагрузки.

• Индексатор. Хранит данные в базе OpenSearch (форк Elasticsearch), обеспечивает долгосрочное хранение, полнотекстовый поиск и агрегацию.

• Дашборд. Веб-интерфейс для просмотра и фильтрации алертов в реальном времени, визуализации данных через графики, таблицы и карты, управления агентами, правилами и конфигурацией.

Для критичных ИТ-систем требуется надежное решение для отслеживания изменений конфигурационных файлов. Важна как полнота данных (отсутствие потери событий при детектировании и обработке), так и точность таких данных. Это необходимо для:

• Обнаружения несанкционированных изменений конфигурации наблюдаемой операционной системы (создание злоумышленником точек входа в систему) и прикладного ПО (корректность и стабильность работы системы)

• Контроля и мониторинга целостности системы

• Соответствия нормативным требованиям

• Оперативного выявления и реагирования на инциденты

В рамках поставленной задачи мне было необходимо проверить способность Wazuh обрабатывать реалистичное (не лабораторные или демонстрационные) количество событий без потери данных и задержек в обработке.

Методология тестирования

Окружение

• Сервер: Wazuh. Развернут и настроен как указано в описании тестов ниже

• Агенты: Windows и Linux

• Сценарий: Создание файла размером 16 МБ и последующее внесение 10 000+ изменений

Тестовый сценарий на Windows

Для Windows-клиента использовались три скрипта: run.cmd — скрипт для последовательного запуска скриптов test_1.cmd и test_2.cmd:

@echo off
start /wait test_1.cmd 
start /wait test_2.cmd
exit

test_1.cmd — создание файла 16 МБ путем многократного дублирования содержимого:

@echo off
echo "This is just a sample line appended to create a big file. " > test.txt
for /L %%i in (1,1,18) do (
type test.txt >> test.txt
)
Exit

test_2.cmd — добавление 10 000 строк с временными метками:

@echo off
for /L %%x in (1,1,10000) do (
echo %%x %date% %time% >> test.txt
)
Exit

Скрипты размещались в директории C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp, которая отслеживается Wazuh по умолчанию.

Тестовый сценарий на Linux

Для Linux-клиента предварительно была добавлена строка в файл конфигурации /var/ossec/etc/ossec.conf:

<directories check_all="yes" realtime="yes" whodata="yes">/tmp/test</directories>

После этого служба была перезапущена:

sudo systemctl restart wazuh-agent.service

run.sh — скрипт для запуска скриптов test1.sh и test2.sh:

#!/bin/bash
bash test1.sh
bash test2.sh

test1.sh — создание файла 16 МБ:

#!/bin/bash
dd if=/dev/urandom of=test.txt bs=1M count=16

test2.sh — добавление 10 000 строк с временными метками:

#!/bin/bash
for x in {1..10000}
do
    echo "$x $(date '+%d.%m.%Y %H:%M:%S')" >> test.txt
done

Скрипты размещались в директории /tmp/test/, мониторинг за которой был добавлен в файл конфигурации.

Результаты тестирования

Windows: критическое количество незарегистрированных событий изменения наблюдаемого объекта

Вывод: Wazuh зарегистрировал только 20 событий из ожидаемых 10 019. Это указывает на серьезные проблемы с обработкой большого количества изменений файлов в режиме реального времени.

Linux: лучше, но недостаточно

Вывод: Linux-клиент показал лучший результат (120 событий против 20 на Windows), однако потеря 98.8% событий остается неприемлемой для мониторинга событий на критичных системах.

Анализ проблем

1. Асинхронная постобработка событий
   
   Агент Wazuh использует ресурсы операционной системы для динамического (realtime) детектирования событий изменения и, фильтруя очередь журнала событий в буфере механизма журналирования ОС, производит самостоятельную постобработку событий (создание теневой копии контента и подсчет контрольной суммы измененного файла). Так как постобработка событий производится в асинхронном режиме, пока обрабатываются артефакты одного событий, другие события в очереди игнорируются.

2. Узкое место в локальном хранении зарегистрированных событий на агенте
   
   Агент Wazuh использует локальный буфер для накопления событий перед отправкой на сервер. При высокой интенсивности регистрации событий, доступное пространство буфера на агенте заполняется, и события теряются.

3. Отсутствие адаптивной обработки потока входящих событий на сервере
   
   Сервер Wazuh не имеет встроенного механизма для адаптации к всплескам потока входящих событий. Когда количество событий входящих с агентов событий превышает доступную пропускную способность сервера, события просто отбрасываются.

4. Отсутствие гарантий доставки
   
   Wazuh не гарантирует доставку каждого события. При перегрузке система предпочитает потерять события, чем замедлить обработку. Сравнение с требованиями регуляторов (национальные центральные банки, национальные и международные стандарты кибербезопасности) другие отраслевые регуляторы.

Для банковских систем обычно требуется:

• 100% отслеживание изменений конфигурационных объектов (файлов и ключей)

• Гарантированная доставка событий на сервер

• Минимальное влияние на быстродействие системы и приложений

• Регистрация всех наблюдаемых событий безопасности без исключения

• Масштабируемость при росте нагрузки

Результаты Wazuh:

• Потеря 98-99% событий

• Отсутствие гарантий доставки

• Неопределенная задержка обработки

• Критичные события могут быть пропущены

• Негарантированная масштабируемость

Возможные решения и рекомендации

Могу сказать, что результат тестирования был неожиданным, вспоминая все прочитанные положительные отзывы. Что я отметил для себя:

1. Потеря данных неприемлема: потеря событий недопустима для систем, требующих полного аудита

2. Отсутствие гарантий: Wazuh не гарантирует регистрацию каждого события

3. Масштабируемость ограничена: система не справляется с высокой интенсивностью отправляемых на сервер событий

Wazuh остается отличным выбором для организаций среднего размера с умеренными требованиями к мониторингу событий безопасности, но требует дополнительных инструментов для обеспечения полной защиты критичных систем.

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