Обсудить проект
11 сентября, 2026 · Безопасность

Сбор и нормализация логов: Windows, Linux, сетевое оборудование

SIEM хорош ровно настолько, насколько хороши данные, которые в него попали. Можно купить лучшую платформу и написать сотню правил, но если на srv-dc01 не включён аудит входов, а маршрутизатор rtr-edge01 шлёт время в локальной зоне без даты, обнаружение будет слепым или лживым. В этой статье мы пройдём весь путь журнала: что включить на источниках, как доставить события на srv-siem01 и как привести их к единому виду, чтобы одно правило работало для разных систем. Примеры привязаны к лаборатории itpages.lab.local, сеть 192.168.10.0/24.

Всё в статье относится к защите: что настроить и как проверить. Атакующие техники упоминаются только как названия тактик и признаки в журналах.

Что такое нормализация и зачем она нужна

Один и тот же факт «пользователь не смог войти» выглядит по-разному: событие 4625 в Windows, строка «Failed password» в журнале SSH, сообщение «authentication failed» на маршрутизаторе. Нормализация приводит их к общим полям: время, источник, пользователь, адрес клиента, результат, тип действия. Тогда одно правило «много неудачных входов с одного адреса» работает для всех источников, а аналитик не учит десять форматов. Популярные схемы полей: Elastic Common Schema (ECS), в Wazuh встроенные декодеры и поля, у Splunk модель CIM. Не так важно, какую выбрать, важно держаться её последовательно.

Шаги: от источника до SIEM

Шаг 1. Единое время и часовой пояс

Первое, что нужно сделать везде, прежде чем собирать любые журналы, это синхронизировать время. Источник времени в лаборатории один: srv-dc01 для Windows-хостов (он по умолчанию раздаёт время в домене), а внешний NTP-источник для самого контроллера. Для Linux-серверов:

sudo timedatectl set-timezone UTC
sudo timedatectl set-ntp true
timedatectl status | grep -E "synchronized|Time zone"

Для контроллера домена проверь и при необходимости настрой внешний источник:

w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /query /status

На маршрутизаторе включи NTP и метки времени с датой и миллисекундами (команды условные): ntp server 192.168.10.10 и service timestamps log datetime msec year. Без года и миллисекунд журнал сложно сопоставлять с остальными.

Шаг 2. Windows: включи аудит и выбери каналы

В Windows важные события по умолчанию не пишутся. Расширенную политику аудита раздавай через групповую политику, а для проверки используй auditpol. Минимальный набор для защитника:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

Чтобы события создания процессов содержали командную строку (очень полезно для расследования), включи соответствующий параметр:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Журнал Security по умолчанию небольшой и перезаписывается. Увеличь его, иначе события пропадут быстрее, чем ты их прочитаешь:

wevtutil sl Security /ms:1073741824
wevtutil gl Security | findstr /i "maxSize retention"

Многим организациям также пригодится Sysmon: служба от Microsoft Sysinternals, которая пишет подробные события процессов, сетевых соединений и изменений. Конфигурацию для неё бери из проверенных публичных наборов правил и подгоняй под себя, а не включай всё подряд. Журнал Microsoft-Windows-Sysmon/Operational затем добавляется в сбор как отдельный канал.

Какие события обычно нужны в первую очередь:

  • 4624 / 4625: успешный и неуспешный вход. Тип входа и адрес источника в них самое ценное.
  • 4672: вход с особыми привилегиями.
  • 4720, 4722, 4724, 4728, 4732: создание и изменения учётных записей и групп.
  • 4768, 4769, 4771: Kerberos на контроллере домена.
  • 4698, 4702: создание и изменение запланированных задач.
  • 1102 и System 104: очистка журналов.
  • 7045: установка новой службы.

Шаг 3. Windows: доставка журналов

Вариантов три: агент SIEM (проще всего, как Wazuh agent или Elastic Agent), штатная пересылка событий Windows Event Forwarding (WEF) на коллектор, либо сторонний агент, например NXLog. Для лаборатории с одним контроллером хватает агента, но стоит знать про WEF: он удобен в больших доменах, потому что не требует агентов на каждой рабочей станции. Если используешь агент, фильтруй на источнике, чтобы не отправлять шум. Пример запроса в формате XPath для канала Security, который передаёт только нужные события:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4624 or EventID=4625 or EventID=4672 or EventID=4720 or EventID=4732 or EventID=4698 or EventID=1102)]]
    </Select>
  </Query>
</QueryList>

Шаг 4. Linux: журналы аутентификации, auditd и syslog

В Linux основные источники: журнал аутентификации (/var/log/auth.log в Debian-подобных или /var/log/secure в RHEL-подобных системах), systemd-journal, auditd и журналы приложений (nginx, база данных). Проверь, что нужные записи вообще появляются:

sudo journalctl -u ssh --since "today" | tail -n 5
sudo ausearch -k identity --start today | tail -n 5
ls -l /var/log/nginx/

Для пересылки на SIEM можно использовать агент или rsyslog. Пример конфигурации rsyslog для отправки журналов аутентификации и приложений на srv-siem01 по TCP с очередью на случай обрыва связи:

# /etc/rsyslog.d/60-siem.conf
module(load="imfile")
input(type="imfile" File="/var/log/nginx/access.log" Tag="nginx-access:" Severity="info" Facility="local6")

action(type="omfwd"
       target="192.168.10.30" port="514" protocol="tcp"
       queue.type="LinkedList" queue.filename="siem_fwd"
       queue.maxdiskspace="1g" queue.saveonshutdown="on"
       action.resumeRetryCount="-1")

Применяй изменения командой sudo rsyslogd -N1 && sudo systemctl restart rsyslog: первая часть проверяет синтаксис. Также настрой logrotate, чтобы журналы не заполнили диск, но и не ротировались слишком часто, чтобы не терять данные.

Правила auditd для отслеживания критичных изменений (идентификация, права, автозапуск) мы уже приводили в статье про MITRE ATT&CK. Здесь добавим только общее: после установки правил ставь им метки (-k), чтобы потом легко искать, и следи, чтобы правила были неизменными: строка -e 2 в конце файла блокирует изменение правил до перезагрузки.

Шаг 5. Сетевое оборудование: syslog, NetFlow и аутентификация

Маршрутизаторы и коммутаторы шлют syslog по UDP или, где поддерживается, по TCP или TLS. Помни, что UDP не гарантирует доставку. Для лаборатории это приемлемо, для продуктивной сети лучше TCP или TLS. Что включить на rtr-edge01:

! логирование на SIEM
logging host 192.168.10.30
logging trap informational
logging source-interface Vlan10
service timestamps log datetime msec year
service timestamps debug datetime msec year
!
! события входа и изменения конфигурации
login on-failure log
login on-success log
archive
 log config
  logging enable
  notify syslog contenttype plaintext
!
! отказанные пакеты на правилах доступа
ip access-list extended OUTSIDE-IN
 deny ip any any log

Что полезно получать с сетевого оборудования: попытки входа на управление, изменения конфигурации, срабатывания ACL, смену состояния интерфейсов и протоколов маршрутизации. Дополнительно собирай поток данных (NetFlow или IPFIX): он показывает, кто с кем и сколько общался, и помогает заметить необычно большие исходящие передачи. Приём потоков можно организовать на srv-siem01 отдельным коллектором.

Шаг 6. Нормализация на стороне SIEM

Когда события дошли, их нужно разобрать на поля. В Wazuh это делают декодеры, а в Elastic ingest-конвейеры. Проверить разбор строки в Wazuh можно командой wazuh-logtest. Для собственных форматов, например журнала внутреннего приложения, пишут свой декодер. Пример: допустим, приложение пишет строки вида 2026-10-13T10:15:02Z app=billing user=ivanov action=login result=fail src=192.168.10.105.

<decoder name="itpages-app">
  <prematch>^\S+ app=\w+ user=</prematch>
</decoder>
<decoder name="itpages-app-fields">
  <parent>itpages-app</parent>
  <regex>app=(\w+) user=(\S+) action=(\w+) result=(\w+) src=(\S+)</regex>
  <order>app, srcuser, action, result, srcip</order>
</decoder>

Целевая схема полей у тебя должна быть записана. Простая таблица соответствия, которой удобно пользоваться при написании правил:

Смысл            Windows (4625)         Linux (sshd)           Сеть (rtr-edge01)      Общее поле
Время            TimeCreated            timestamp              timestamp              @timestamp (UTC)
Пользователь     TargetUserName         user                   username               user.name
Адрес клиента    IpAddress              rhost                  source ip              source.ip
Результат        Keywords (Failure)     "Failed password"      "login failed"         event.outcome=failure
Хост             Computer               hostname               device name            host.name

Шаг 7. Проверка качества и объёмов

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

sudo jq -r '.agent.name' /var/ossec/logs/alerts/alerts.json | sort | uniq -c | sort -rn
df -h /var/ossec /var/lib/wazuh-indexer 2>/dev/null

Если один источник даёт девяносто процентов объёма (часто это журналы доступа веб-сервера или отказанные пакеты на межсетевом экране), подумай об агрегации, выборочном сборе или отдельном хранилище с коротким сроком. Задай политику хранения: например, 90 дней в оперативном хранилище и 12 месяцев в архиве для событий безопасности, а сроки уточни у юриста, если действуют требования регуляторов.

Шаг 8. Защити сами журналы

Журналы это улики, и их целостность важна. Основные меры: отправка событий на отдельный сервер (локальный журнал можно очистить, а копия на srv-siem01 останется), ограничение прав на запись в хранилище, шифрование канала доставки там, где это возможно, регулярные резервные копии индексов и оповещение об очистке журналов и остановке агентов. Тревога по событию «служба агента остановлена» или «журнал очищен» это один из самых точных сигналов в вашем арсенале.

Минимальный чек-лист для каждого нового источника

Чтобы подключение не превращалось в импровизацию, держи короткий список вопросов. Какая цель сбора и какие правила или отчёты будут использовать эти события? Включён ли аудит на источнике и проверено ли это командой, а не на словах? Синхронизировано ли время и в какой зоне пишутся метки? Как защищён канал доставки и что произойдёт при обрыве связи: потеряются события или накопятся в очереди? Разобраны ли поля в SIEM и совпадают ли они с общей схемой? Какой ожидаемый объём в сутки и какая политика хранения? Кто владелец источника и как с ним связаться, если он замолчит?

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

Частые ошибки и как их избежать

  • Включили сбор, но не включили аудит. Агент работает, дашборд зелёный, а события входа не пишутся, потому что политика аудита по умолчанию выключена. Проверяй auditpol /get /category:* и наличие конкретных идентификаторов событий в SIEM, а не только статус агента.
  • Разные часовые пояса и форматы времени. События «за один час» оказываются в разных сутках, корреляция не срабатывает. Используй UTC везде, NTP на всех хостах и метки времени с датой и годом на сетевых устройствах.
  • Сбор без фильтрации и контроля объёма. Диск переполняется, индексатор останавливается, и вы теряете именно те события, ради которых всё затевалось. Планируй объём заранее, фильтруй шум на источнике, мониторь свободное место и настрой оповещение о нехватке.

Что дальше

Защита строится из нескольких слоёв — вот соседние темы серии:

Автор — Команда IT-Pages