Wazuh без ограничений дашборда: как работать напрямую с индексами через OpenSearch
Когда Wazuh используется "по умолчанию", встроенные дашборды действительно закрывают большинство повседневных задач: посмотреть алерты, оценить состояние агентов, выгрузить базовую сводку. Но у этого подхода есть потолок - интерфейс показывает ровно те представления, которые заложены разработчиками. Как только появляется запрос на нестандартную аналитику (сложный отчет, статистика по всей инфраструктуре, нетиповой алертинг, выгрузка в BI), начинаются обходные маневры: кто-то ставит Grafana и долго подбирает датасорс, кто-то вручную экспортирует CSV из Discover, кто-то усложняет правила лишь бы "влезть" в формат дашборда. Между тем данные уже лежат там, где их проще всего забирать и агрегировать - в OpenSearch.
Ниже - практичная логика: не бороться с ограничениями UI, а работать с тем уровнем, где реально хранятся события и состояния. В этом контексте особенно важна корректная wazuh opensearch настройка: доступ, права, запросы и аккуратная нагрузка на кластер.
Что выбирать: Server API или Indexer
В Wazuh легко перепутать два разных "входа" - они решают разные задачи:
- Wazuh Server API (порт 55000) - это управление платформой: агенты и их группы, конфигурации, перезапуск компонентов, состояние кластера. Через syscollector-эндпоинты он умеет отдавать инвентарь, но чаще всего - по одному агенту за запрос. Технически можно собрать "все пакеты на всех хостах", но практически это превращается в сотни/тысячи запросов и длительное ожидание.
- Wazuh Indexer (порт 9200) - это OpenSearch, где лежат сами данные: алерты, архивы событий, инвентарь, уязвимости, служебные индексы. Здесь же доступны агрегации, и один запрос способен за секунды ответить на вопрос уровня "топ-20 уязвимых пакетов по парку из 3 000 хостов".
Простое правило: нужно что-то изменить - идем в Server API. Нужно что-то посчитать или выгрузить - идем в Indexer.
Какие индексы чаще всего нужны (логика 4.14)
В версии 4.14 данные в индексере разнесены по назначению. На практике чаще всего трогают поток событий:
- `wazuh-alerts-4.x-*` - основной "рабочий" индекс алертов: события, которые сработали по правилам.
- `wazuh-archives-4.x-*` - "все подряд", включая то, что не попало ни под одно правило. Обычно отключен по умолчанию, потому что объем быстро растет.
Дальше идут индексы состояний/инвентаря и результаты модулей вроде управления уязвимостями, контроля целостности и т. д. Смысл один: все, что потом нужно анализировать "в разрезах", удобнее и быстрее брать именно из индексера.
Готовим доступ и клиент (и почему это важно)
Прямой доступ к OpenSearch - это почти всегда HTTP(S) + учетные данные + ограничения прав. В продакшене важно не только "подключиться", но и сделать это безопасно: минимальные роли, доступ только к нужным индексам, контроль сетевого периметра. Если в компании планируется масштабное wazuh внедрение, лучше заранее продумать RBAC и то, кто именно будет выполнять аналитические запросы (SOC, инженеры, аудиторы, BI-команда).
В Python обычно используют официальный клиент OpenSearch/Elasticsearch-совместимые библиотеки: вы получаете нормальную работу с пагинацией, timeouts, повторными попытками, а главное - стандартизированные query DSL и агрегации.
Что внутри алерта и как его читать
Документы в `wazuh-alerts-*` - это JSON со временем, данными об агенте/хосте, метаданными правила, уровнем, полями декодера и полезной нагрузкой события. Чтобы построить свой отчет, важно не "вытягивать все поля всегда", а отбирать нужное через `_source`/`fields` и фильтровать по времени, агентам, уровням и типам событий.
Три рабочих способа выгрузки документов
1) Обычный `search`
Подходит, когда данных немного и достаточно стандартной пагинации. Плюс - просто. Минус - на больших периодах и объемах упретесь в лимиты и стоимость запросов.
2) `helpers.scan`
Правильный путь, когда нужно забрать "все документы" за период (экспорт, миграция, аудит). Scan использует scroll-механику и аккуратнее проходит по массивам данных.
3) `search_after`
Оптимален для возобновляемой выгрузки: можно продолжать с последней точки, не держа scroll-контекст, и надежнее переживать сетевые сбои. Это удобно, если вы строите регулярные выгрузки в DWH/даталейк.
Агрегации: ради чего обычно и идут в индексер
Индексер ценен тем, что вместо "ручного листания" дашбордов можно получить аналитические ответы одной конструкцией aggregation DSL. Типовые примеры:
- Топ атакующих IP за неделю (terms-агрегация по полю источника + фильтр по времени).
- Динамика по часам с разбиением по уровням (date_histogram + sub-aggregation по уровню/правилу).
- Уязвимости по критичности и по хостам (комбинация terms-агрегаций, чтобы увидеть и распределение, и "самые проблемные" узлы).
И именно здесь становится понятно, почему вопросы "что выгоднее: готовые отчеты или свои?" часто упираются не в функциональность Wazuh, а в то, как организованы данные и доступ к ним - включая ожидания по wazuh siem цена в части сопровождения, ресурсов и трудозатрат на аналитику.
Собираем практику: отчеты, алертинг и запись обратно
Когда данные доступны через OpenSearch, сценариев становится больше:
- Еженедельный отчет в Excel: агрегируете нужные показатели, выгружаете в таблицу, добавляете контекст (владельцы систем, критичность сервиса), отправляете заинтересованным.
- Свой алертинг с дедупликацией: например, не "спамить" одинаковыми срабатываниями, а склеивать по ключу (хост + правило + интервал времени) и поднимать инцидент только при устойчивой тенденции.
- Запись обратно в отдельный индекс: можно создать собственный индекс с обогащением - добавлять сведения из CMDB, теги критичности, бизнес-владельца, географию, результаты внешних проверок. Это особенно полезно, когда SOC нужно быстро фильтровать "шум" и фокусироваться на важном.
Чтобы все это не "уронило" кластер, держите в голове две вещи: объемы (особенно если включены archives) и стоимость запросов. Большие выгрузки лучше делать в непиковое время, ограничивать диапазон времени, выбирать только нужные поля и следить за timeouts/батчами.
Что поменяется в Wazuh 5.0
Переход на Wazuh 5.0 требует внимательности: индексы переименованы целиком, поэтому скрипты, которые жестко завязаны на шаблоны `wazuh-alerts-4.x-*`, придется адаптировать. Если у вас уже есть кастомные отчеты, BI-выгрузки или собственный алертинг, лучше заранее вынести названия индексов в конфигурацию и добавить проверку доступности шаблонов при старте.
Несколько дополнительных рекомендаций, которые экономят часы
Во-первых, если вы планируете масштабироваться, сразу задайте правила хранения (retention) и жизненный цикл индексов: без этого даже идеальная аналитика быстро упирается в стоимость диска и производительность.
Во-вторых, разделите роли: тем, кто расследует инциденты, достаточно чтения `wazuh-alerts-*`; тем, кто строит отчеты, может понадобиться доступ к уязвимостям/инвентарю; запись в свои индексы лучше выделить отдельному сервисному пользователю.
В-третьих, подумайте о сопровождении. На практике "поставить" и "эксплуатировать" - разные истории: обновления, контроль нагрузки, корректные маппинги, TLS, ротация ключей, мониторинг. Если важна стабильность, заранее планируйте wazuh поддержка - хотя бы в формате ответственных и регламентов.
Наконец, вопрос "wazuh купить или собрать полностью самостоятельно" обычно не про лицензию (платформа open source), а про то, готовы ли вы оплачивать труд команды: внедрение, интеграции, хранение, сопровождение, реакцию на инциденты. Хорошая новость в том, что при грамотном доступе к индексеру вы перестаете зависеть от ограничений дашборда и превращаете Wazuh в полноценную "витрину данных" для SOC и аналитики - ровно так, как показано в разборе подхода работы с индексами Wazuh через OpenSearch.