На этой странице представлены базовые понятия работы с логами, поступающими в Wazuh. В данном сценарии Wazuh является сборщиком логов аналогичным Syslog-серверу. Это упрощенный вариант. Работа с правилами корреляции не рассматривается. Чтоб перейти к более сложным сценариям нужно сперва разобраться в простых вещах.

Установка Wazuh-сервера представлена тут и тут. Установка Wazuh-агента тут. Агент присылает логи с клиентского ПК в сервер. По умолчанию агент собирает стандартные журналы Windows и данные встроенных модулей мониторинга безопасности. Набор отправляемых событий зависит не только от настроек самого агента, но и от параметров аудита Windows, которые централизованно задаются через GPO. Для знакомства и тестов ничего дополнительного настраивать в агенте не нужно. Переходим к логам.

 

Анализ логов.

Просмотр логов возможен в GUI через Dashboard или в CLI, по SSH.

Заходим в Dashboard, авторизуемся со своей учетной записью. В боковом меню переходим в Explore >> Discover.

 

Discover – основной раздел Wazuh Dashboard, предназначенный для поиска, фильтрации и анализа событий, хранящихся в индексах OpenSearch. В данном разделе выполняется работа с логами. По умолчанию открывается индекс wazuh-alerts-*.

wazuh-alerts-* – это шаблон индексов, содержащих события, обработанные правилами Wazuh и признанные значимыми для мониторинга и безопасности. Эти события сохраняются в виде alert-ов и используются для обнаружения угроз, расследования инцидентов и контроля состояния систем. Примеры: неудачный вход в систему, запуск подозрительного процесса, изменение системного файла, обнаружение вредоносного ПО, нарушение политики безопасности.

Index Pattern (шаблон индекса) – это объект в системе визуализации OpenSearch, который с помощью wildcard (символа *) объединяет множество реальных индексов под одним логическим именем для удобного поиска, анализа и создания дашбордов. Простыми словами это «виртуальная папка», которая собирает вместе все индексы, начинающиеся с определенного префикса. Она не хранит логи, а только указывает интерфейсу, в каком наборе индексов искать и как отображать поля.

Index – это логическая база данных (специальная структура) для хранения и быстрого поиска событий. Внутри индекса каждый лог хранится как JSON-документ. Физически индексы лежат на диске внутри OpenSearch/Elasticsearch хранилища, но пользователь работает не с файлами напрямую.

Например, есть файлы на компьютере:

Индекс = конкретный файл: report_2026.05.31.pdf

Index Pattern = маска поиска: report_*.pdf (все файлы, которые начинаются на report_ и заканчиваются на .pdf)

wazuh-alerts-* – это маска, а не файл, которая означает показ данных из всех индексов, имя которых начинается с wazuh-alerts-.

Если в новой установке Wazuh уже сразу есть wazuh-alerts-* то, это логически означает, что сработали какие-то правила. Wazuh – это не пустой анализатор, а система с уже готовой базой знаний. Wazuh поставляется с обширным набором правил, которые называются stock rules или правилами по умолчанию. Их можно найти на сервере Wazuh в директории /var/ossec/ruleset/rules/. Эти правила разработаны командой Wazuh и сообществом для покрытия наиболее распространенных угроз и аномалий. documentation.wazuh.com

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

Как только система получает любые данные (например, стандартный системный лог с агента), она, вероятно, найдет для него подходящее правило с низким уровнем критичности и создаст запись в alerts-*. Поэтому индекс появляется практически сразу после начала работы. Правила – это отдельная тема, вернемся к ним позже.

Остальные предустановленные шаблоны.

wazuh—monitoring-* – содержит метрики состояния агентов: версия, статус подключения, время последней проверки, конфигурация. Используется для контроля целостности и работоспособности всех хостов.

wazuh—statistics-* – статистика производительности самого Wazuh-сервера: количество событий в секунду, загрузка анализаторов, очереди, ошибки обработки. Помогает мониторить здоровье и масштабирование платформы.

Существует еще один полезный функционал, но без предустановленного шаблона – wazuh-archives. Это встроенный механизм Wazuh для хранения ВСЕХ исходных событий. Его нужно активировать вручную после установки.

wazuh-archives-* – это шаблон индексов, содержащих исходные (raw) события, полученные и обработанные Wazuh. В эти индексы сохраняются все события независимо от того, было ли по ним сформировано предупреждение (alert). Используется для полного хранения логов, поиска событий, аудита и расследования инцидентов. Примеры: обычные входы пользователей, системные сообщения, события Windows, Syslog-сообщения, сетевые события и другие журналы активности.

wazuh-archives-* отсутствует в стандартной конфигурации, так как хранение всех событий отключено по умолчанию из-за значительного потребления дискового пространства. Так как архивы хранят ВСЕ логи. Это очень много данных. Без wazuh-archives по умолчанию Wazuh принимает все логи, анализирует их, но сохраняет только алерты. Правило сработало –  лог сохраняется. Правило не сработало – лог выбрасывается. Так сделано, чтобы не забивать диск и не перегружать OpenSearch.

Если Wazuh работает как syslog-сервер и только собирает логи, то включить архивы нужно обязательно. Можно настроить период хранения логов и удалять старые логи автоматически чтоб диск не переполнялся. Или отправлять набравшиеся логи в «холодное хранилище» – NAS, хранящий логи согласно сроков регламента.

wazuh-archives-* не случайное рандомное название. В стандартной архитектуре Wazuh используются именно такой префикс индексов. Он используются во всех модулях (Manager, Filebeat, Indexer, Dashboard) как часть стандартной конфигурации для схемы хранения данных.

 

Включение архива.

Просмотр текущего состояния.

 

Создание индекса.

Для включения необходимо изменить две настройки.

Включаем сохранение всех логов (в формате json). Эти действия можно выполнить через GUI.

Server Management >> Settings >> Edit configuration.

 

 

Изменяем конфигурацию, сохраняем и перезапускаем менеджер.

Такая настройка обязывает Wazuh сохранять все события в archives.json

 

Настройка через CLI.

Редактируем конфигурацию.

В строке

указываем YES.

Сохраняем, выходим.

ctrl+x

y

 

Перезапускаем manager

 

 

Включаем отправку archives в индексер.

Штатными средствами Wazuh Dashboard редактировать конфигурацию Filebeat не возможно. Поэтому настройка через CLI.

 

Открываем конфигурацию.

 

Указываем archives: enabled: true.

Сохраняем, выходим.

ctrl+x

y

 

Перезапускаем filebeat.

 

Проверка. Проверить можно косвенно.

Размер файла archives.json должен увеличиваться со временем.

 

Просмотр изменение размера в реальном времени (каждые 2 сек).

 

Просмотр логов в реальном времени.

Если появляются новые JSON-события – работает.

 

Просмотр размера папки archives.

 

Просмотр последних 20 логов.

 

С помощью этой команды можно смотреть размер архивов.

Нужно проверить несколько раз с интервалом 5мин и определить, с какой скоростью увеличивается объем архива.

В данном случае (на примере нашей организации) скорость роста архивов составляет 100 МБ за 10 минут в рабочее время (иногда быстрее), значит, объём данных составляет около 14,4 ГБ в сутки. Диск объёмом 1 ТБ будет заполнен архивными событиями примерно за 60-70 дней без учёта других данных системы.

Поэтому нужно хорошо подумать, нужны ли архивы в каждом конкретном случае.

Далее создаем шаблон индекса.

 

Создание шаблона индекса.

Настройка выполняется в Dashboard Management.

 

Переходим в шаблоны индексов.

 

Создаем новый шаблон.

 

Указываем название wazuh-archives-*

 

Настраиваем временное поле аналогично другим шаблонам.

@timestamp – техническое поле индекса для поиска и сортировки (рабочее время для базы данных).

 

Шаблон готов.

 

Проверяем в панели Discover.

 

Отключение архива.

Отключение параметра <logall_json> прекращает формирование новых архивных событий. Настройка Filebeat определяет только отправку архивов в OpenSearch и не влияет на их создание. Поэтому чтоб отключить наполнение архива, достаточно указать NO в строке

И перезапустить Wazuh Manager.

 

Использование меню поиска.

Переходим в Discover.

Левая панель (Fields Panel) – панель полей событий, используемая для поиска, фильтрации и отображения данных.

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

Таблица событий под графиком отображает результаты поиска и содержит подробную информацию о каждом событии.

Selected fields – поля, которые отображаются в таблице результатов. Например, сейчас _source означает показывать всё содержимое события.

Available fields – список всех полей, обнаруженных в выбранных индексах.

_source – это полный исходный JSON-документ события, сохранённый в индексе OpenSearch. То есть в таблице отображается весь JSON целиком со всеми его полями и строками.

Можно удалить _source, а добавить например timestamp, agent.ip, agent.name. Это влияет только на отображение результатов.

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

​

Time Range Filter (фильтр по времени) – выбор временного диапазона для поиска и анализа событий безопасности. Можно выбрать как относительный период («Последние 24 часа»), так и абсолютный диапазон дат и времени.

 

Примеры поиска.

Начнем с простого. Нужно найти все события с указанного IP-адреса клиентского ПК.

Выбираем шаблон индекса, период и в поле поиска вводим нужный IP-адрес. По умолчанию выбрано поле поиска _source.

В процессе поиска происходит следующее:

-Dashboard выполняет поиск по всем индексам, входящим в шаблон wazuh-alerts-*;

-поиск выполняется среди индексируемых полей документов выбранных индексов;

-в результат попадают только события, содержащие значение 192.168.5.27 в одном или нескольких полях;

-поскольку выбран _source, каждое найденное событие отображается как полный JSON-документ.

В результате видим все события с полным содержанием. Нужно помнить, что это не абсолютно все события, а только отмеченные по правилам, потому что выбран шаблон wazuh-alerts-*. Чтоб увидеть ВСЕ события с определенного IP, нужно выбрать шаблон wazuh-archives-*.

 

Пример просмотра wazuh-archives-*.

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

*(звёздочка) – показать все документы, попадающие под текущий фильтр времени. То есть фактически показ всех событий из wazuh-archives-* за выбранный период.

Основной источник роста архива это Windows Event Log. Из примерно 100 строк 90-95% занимают события EventChannel. Это означает что Wazuh Agent на Windows собирает все журналы и отправляет их на Manager. В архив попадает каждое событие Windows. Не только важные, например, информационные события, успешный вход, запуск службы, остановка службы, Task Scheduler и тп. Это приводит к быстрому росту объёма хранилища.

Можно вычислить более конкретно, что создает много логов. Добавляем поисковое поле data.win.system.eventID

В результате анализ показывает, что основной объем логов создают не все компьютеры одинаково, а несколько очень шумных источников. В первую очередь это сервера. Но есть так же несколько обычных пользовательских ПК которые генерируют подряд десятки событий за доли секунды.

 

Полезная шпаргалка по Windows Event ID (наиболее распространенные события).

4624 Успешный вход.

4625 Неудачный вход.

4627 Назначение групп безопасности пользователю.

4634 Выход пользователя.

4648 Вход с явным указанием учётных данных.

4672 Выданы привилегии администратора.

4688 Запуск процесса.

4689 Завершение процесса.

4720 Создан пользователь.

4726 Удалён пользователь.

4740 Блокировка учётной записи.

6167 Событие Microsoft Defender.

4776 Проверка учётных данных контроллером домена.

Для определения причины необходимо проанализировать типы событий (Event ID) и их содержимое. Только после этого принимается решение о дополнительной проверке рабочей станции или корректировке настроек аудита.

 

Неудачный вход в Windows – одно из самых популярных событий для поиска в Wazuh. Найдем его.

Открываем Discover.

Выбираем индекс wazuh-archives-*.

В боковом меню находим поле data.win.system.eventID. Добавляем его.

В таблице появляется отдельная колонка EventID.

Смотрим, какие коды вообще встречаются: 4624, 4625, 4634, 4648, 4688, 4689 и тп.

Далее в поисковой строке вводим код для события неудачного входа в систему: 4625.

Раскрываем лог и изучаем его содержимое.

 

Наиболее значимые поля.

eventID: 4625 – неудачная попытка входа в систему.

agent.name: WAZUH-TEST-PC – компьютер, на котором зафиксировано событие.

agent.ip: 192.168.5.27 – IP компьютера, приславшего лог.

targetUserName: pc360local – пользователь, под которым пытались войти.

ipAddress: 192.168.5.4 – источник подключения.

logonType: 3 – сетевой вход (доступ по сети).

authenticationPackageName: NTLM – использовался протокол NTLM.

failureReason: неизвестное имя пользователя или неверный пароль – причина отказа.

Status: 0xC000006D – ошибка аутентификации.

subStatus: 0xC000006A – неверный пароль.

Wazuh не просто сохранил лог, а применил правило rule.description Logon Failure — Unknown user or bad password. То есть Rule Engine определил это событие безопасности – неудачная аутентификация.

Уровень важности rule.level = 5. Это средний уровень. Не критично, но заслуживает внимания.

Произошло раз rule.firedtimes = 3. Очень интересное поле. Означает что это правило уже сработало 3 раза. То есть ошибка пароля повторяется.

Итог разбора такой. На компьютере WAZUH-TEST-PC была зафиксирована неудачная сетевая попытка входа (Event ID 4625). Источник подключения –  192.168.5.4. Для учётной записи pc360local был указан неверный пароль. Wazuh автоматически классифицировал событие как «Logon Failure» и сформировал предупреждение уровня 5.

 

Пример с сигнатурой вируса.

EICAR Test File – стандартный безопасный тестовый файл, используемый для проверки работы антивирусных решений без запуска реального вредоносного кода.

Увидит ли Wazuh запуск EICAR зависит от того, какие источники логов собираются. Сам по себе Wazuh не анализирует содержимое файлов как антивирус.

Обычно сценарий такой:

Пользователь создает файл EICAR >> Microsoft Defender обнаруживает угрозу >> Defender записывает событие в Windows Event Log >> Wazuh Agent читает журнал >> Wazuh генерирует alert.

То есть Wazuh увидит не сам файл EICAR, а событие от Defender.

По умолчанию агент не собирает события Microsoft Defender. Добавим в конфигурацию агента строки, которые назначают ему это делать.

 

Действия на ПК с агентом. 

Находим файл конфигурации и редактируем в блокноте.

 

Добавляем блок.

 

Перезапускаем службу Wazuh-агента через GUI или CLI.

 

Далее создаем файл с тестовым вредоносным кодом с названием eicar.txt.

Содержание.

Сохраняем.

Defender сразу срабатывает и удаляет файл как вредоносный.

 

Проверяем журнал на клиенте. Смотрим ветку каталогов

Event Viewer

└Applications and Services Logs

└Microsoft

└Windows

└Windows Defender

└Operational

Находим следующие события.

1116 – обнаружение угрозы Microsoft Defender.

1117 – выполнение действия по нейтрализации угрозы (карантин, удаление, блокировка).

1121 – блокировка действия приложений механизмом «Контролируемый доступ к папкам» (защита от программ-вымогателей).

В результате 1116 – угроза обнаружена, 1117 – угроза помещена в карантин или удалена.

 

Через PowerShell.

Создание файла.

 

Проверка наличия журнала.

 

Проверка последних 10 событий 1116.

 

Поиск события в Wazuh.

Переходим в менеджер Wazuh.

Выполняем поиск в индексе wazuh-alerts-*.

В поля поиска добавляем agent.name. Можно, но не обязательно добавить data.win.system.providerName.

Временной промежуток выбираем последний час, чтоб было меньше событий для перебора.

Среди появившихся в таблице событий добавляем на плюс + агента по имени ПК. Он появится в строке фильтра как доп. параметр поиска.

Далее рассматриваем события или в поисковой строке вводим код события, если он известен. В данном случае 1116.

 

В результате появляется только наше искомое событие.

 

Можно его раскрыть и изучить.

 

Более продвинутый и быстрый вариант с использованием выражений.

В поисковой строке вводим data.win.system.providerName:»Microsoft-Windows-Windows Defender»

 

Пример разбора логов в CLI.

Действия выполняются в Wazuh по SSH.

Для примера выведены последние 20 логов из индекса архива.

Рассмотрим их для понимания.

Каждая строка { … } это одно событие в JSON формате.

Пример записи.

timestamp – время события.

agent – какой агент отправил лог.

manager – какой manager обработал.

id – уникальный ID события.

full_log – исходный raw log.

decoder – какой decoder распознал лог.

location – источник события.

Самое главное поле full_log. Это исходное содержимое лога. В данном случае в этом поле df -P. Это Linux-команда, которая показывает диски, свободное место, % использования. То есть Wazuh согласно лога собирает системную информацию о разделах, размере дисков, свободном месте. Это попало в archives потому что настроено logall_json – yes и теперь Wazuh сохраняет всё, и даже системные команды.

 

Еще один лог. Он содержит last -n 20.

Это Linux-команда которая показывает последние логины пользователей.

Например wazuh pts/0 192.168.5.4 означает что пользователь wazuh подключился с IP 192.168.5.4. Это уже полезно для мониторинга безопасности, потому что можно отслеживать входы, расследовать инциденты, искать подозрительные IP.

 

Третий пример opensearch-dashboards[848].

Это лог самого Wazuh Dashboard/OpenSearch. Кто-то с IP 192.168.5.4 открыл страницу /app/data-explorer/discover и Dashboard ответил «statusCode»:200, что означает запрос успешен.

В логах нет rule.level потому что archives хранит сырые логи. Уровни содержатся в алертах.

 

Время в Wazuh.

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

В логе можно встретить несколько разных полей времени.

systemTime – исходное время события из журнала Windows клиента. Записывается операционной системой в формате UTC и отражает момент фактического возникновения события.

timestamp – время обработки события системой Wazuh и записываемое в документ события. Отображается с учетом локального часового пояса сервера Wazuh.

systemTime – источник времени, а timestamp – его отображение в интерфейсе. Обычно они указывают на один и тот же момент времени.

Time (колонка Discover) – время события, отображаемое пользователю в интерфейсе Discover с учетом временной зоны браузера. Что именно показывает колонка Time зависит от настроек Index Pattern. Во всех шаблонах выбрано @timestamp.

fields.timestamp – индексированное поле времени, используемое OpenSearch для поиска, сортировки и построения временных графиков. Хранится в формате UTC. Его можно увидеть только в коде JSON.

 

@timestamp – служебное временное поле OpenSearch, используемое для индексации, поиска, сортировки и построения временных графиков. Используется во всех шаблонах индексов (Index Pattern). Wazuh часто скрывает служебное поле @timestamp и показывает пользователю более удобное поле timestamp. Если выбрано в шаблонах, то отображается в Time (колонка Discover).

Рассмотрим на примере произвольного лога.

Клиент Windows настроен на GMT+3. Пользователь видит 14:39:58. В этот момент Windows генерирует событие Security 4625.

Windows Event Log хранит время в UTC. Поэтому в событии Wazuh появляется data.win.system.systemTime 2026-06-01T11:39:58.8894167Z.

Z = UTC = GMT+0. То есть, 11:39 UTC = 14:39 MSK (+3)

Когда событие создается, Windows записывает его в UTC. Это стандарт Windows Event Log.

Далее агент Wazuh практически ничего не меняет. Он читает событие systemTime = 11:39 UTC и отправляет его менеджеру.

Сервер Wazuh получает событие. В архиве и в индексе сохраняется systemTime = 2026-06-01T11:39:58Z

Wazuh Manager обрабатывает событие, выполняет декодирование и проверку правил, после чего документ передается в OpenSearch для индексации.

Во время индексации OpenSearch формирует служебное временное поле @timestamp, которое используется для поиска, сортировки и построения графиков.

В данном примере @timestamp = 11:39:58 UTC. В Discover в таблице Time | _source отображается Jun 1, 2026 @ 14:39:58.017. Это не время, хранящееся в индексе, а время после автоматического преобразования UTC в локальную временную зону браузера пользователя (GMT+3).

При создании шаблона wazuh-archives-* было выбрано @timestamp. Следовательно колонка Time фактически показывает @timestamp в локальной временной зоне браузера.

В конце документа присутствует поле timestamp = 2026-06-01T14:39:58.017+0300. Это поле, сформированное Wazuh. Оно хранит тот же момент времени, но уже с указанием локального смещения часового пояса (+0300).

В JSON также можно увидеть

systemTime = 11:39:58.889 UTC

fields.timestamp = 11:39:58.017 UTC

Время практически совпадает. Разница составляет менее одной секунды и связана с обработкой и индексацией события.

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

OpenSearch всегда хранит время в UTC. Это нормальная практика. Wazuh не нужно специально переводить в местное время. Местное время устанавливается только в ОС для Wazuh (Ubuntu в данном случае).

При расследовании инцидентов основным временным полем является @timestamp. Оно используется OpenSearch для поиска, сортировки, построения графиков и временной корреляции событий. Поле systemTime применяется как источник исходного времени события и используется для проверки задержек доставки и обработки логов.

Например, бывает ситуация:

systemTime = 10:00:00

@timestamp = 10:07:15

Тогда сразу видно, что лог дошёл до SIEM с задержкой 7 минут. В таком случае именно systemTime покажет момент реального возникновения события.

 

Если очень нужно, то настроить отображение время можно в расширенных настройках дашборда.

dateFormat – формат отображения даты и времени.

dateFormat:dow – первый день недели в календарях и графиках. Если поставить Monday, то календарь и недельные графики будут начинаться с понедельника.

dateFormat:scaled – автоматический формат времени на графиках разных масштабов.

dateFormat:tz – часовой пояс отображения времени в Dashboards. Browser означает показывать время в часовом поясе браузера пользователя.

Эти настройки относятся только к отображению времени в интерфейсе OpenSearch Dashboards. Они не изменяют время в логах, не меняют время на агентах, не меняют данные в индексах.

Понимание механизма обработки времени в Wazuh критически важно. Без корректного времени невозможно определить последовательность событий и восстановить хронологию инцидента.

 

Анализ логов в документации Wazuh. documentation.wazuh.com