Безопасность для начинающих 07. Журналы и обнаружение: что писать и о чём оповещать

В понедельник сотрудница бухгалтерии petrova говорит: «В пятницу вечером кто-то заходил на сервер под моей учётной записью». Вы открываете журнал безопасности FS1 и находите события только за последние дни: старые записи затёрты новыми. Часы на PC1 отстают от сервера на несколько минут, и найденные строки не складываются в цепочку. Расследовать нечего: заранее не решили, что записывать и где хранить.

Журнал (log) — запись событий в системе: вход пользователя, запуск службы, ошибка. Аудит — решение о том, какие действия система обязана записывать. Обнаружение — привычка и инструменты, которые замечают в записях необычное и зовут человека. В статье вы решите, какие источники важны небольшой сети, разберёте ключевые события Windows и Linux, настроите хранение, время и защиту журналов и получите оповещения в Zabbix.

Настройка аудита Windows и события 4624, 4625, 4740 разобраны в Windows Server с нуля 12, журналы Linux — в Linux для админа Windows 17. Здесь мы собираем из них систему.

Что нужно знать заранее

• Windows Server с нуля 12: политика аудита, события 4624, 4625, 4740, wevtutil.
• Linux для админа Windows 17: journalctl, auth.log, права на логи, rsyslog.
• Zabbix с нуля: узлы, элементы данных, триггеры, активные проверки. Узлы: lnx1 — сервер Zabbix, lnx2 — наблюдаемый Linux.
• Безопасность для начинающих 06: какие группы считать привилегированными.

Что записывать: политика на одной странице

Начните с листа бумаги, а не с настроек. Руководство CISA и партнёров (его разработал австралийский ACSC) рекомендует утверждённую политику журналирования: какие события пишем, как следим, сколько храним и когда пересматриваем набор. Небольшой организации хватит страницы с пятью ответами: что пишем, где лежит копия, сколько храним, кто смотрит, что считаем тревогой. Документ рассчитан на средние и крупные организации, поэтому берите принципы, а не масштаб. Важнее качество, чем объём.

Приоритетные источники для сети из наших примеров (по списку руководства):

Рабочие станции нельзя пропускать: первые признаки вторжения нередко появляются именно там. Практика автора: начните с серверов и рабочих мест администраторов. Журналы сетевого оборудования: Cisco, MikroTik.

Windows: политика аудита

Политика аудита — набор подкатегорий, для каждой из которых включают регистрацию успехов (Success), отказов (Failure) или обоих. В Windows Server 12 дан минимальный набор: Credential Validation — только Failure, Security Group Management — только Success, плюс Account Lockout и Directory Service Changes. Ниже расширенный набор по рекомендациям Microsoft для серверов: он нужен для оповещений 4719 и 4964. Записей станет больше, поэтому журнал придётся увеличить (см. ниже). Политику протестируйте до боевого применения. Названия в таблице — как в групповой политике; в выводе auditpol слово «Audit» в начале может отсутствовать.

Для рабочих станций Microsoft рекомендует для Credential Validation, User Account Management и Security Group Management только Success; остальные строки совпадают. На контроллерах домена дополнительно советуют Audit Directory Service Changes (в том числе событие 5136) и Failure для Audit Computer Account Management. Подкатегории Kerberos (события 4768, 4769, 4771) относятся к усиленным рекомендациям: включайте их позже. Политику применяют через GPO, как в Windows Server 12. Сначала сохраните текущее состояние и посмотрите его:

New-Item -ItemType Directory -Force C:\Backup\Evidence | Out-Null
auditpol /backup /file:C:\Backup\Evidence\auditpol-before.csv
auditpol /get /category:*

Откат — auditpol /restore /file:C:\Backup\Evidence\auditpol-before.csv; если политика пришла из GPO, отключите ссылку (Remove-GPLink) и выполните gpupdate /force. Если названия подкатегорий отличаются от английских, ориентируйтесь на GUID: auditpol /list /subcategory:* /v.

Командная строка процессов и PowerShell

Событие 4688 фиксирует запуск процесса, но поле командной строки в нём по умолчанию пустое. Заполняет его политика Administrative Templates → System → Audit Process Creation → «Include command line in process creation events». В командных строках бывают пароли и токены: ограничьте доступ к журналу и не передавайте секреты аргументами. Руководство советует и журналирование блоков сценариев PowerShell; включайте его на серверах и рабочих местах администраторов.

Размер журнала Security

Журнал безопасности ограничен по размеру. Microsoft называет значением по умолчанию 20 МБ (на ваших серверах оно может отличаться), а при заполнении новые события затирают старые: чем больше аудита, тем короче «память» сервера. Проверьте режим и размер (от имени администратора) и узнайте, на сколько времени хватает журнала:

Get-WinEvent -ListLog Security |
  Select-Object LogMode, MaximumSizeInBytes, RecordCount
(Get-WinEvent -LogName Security -Oldest -MaxEvents 1).TimeCreated

Circular в поле LogMode означает перезапись старых событий. Если дата самого раннего события близка к сегодняшней, журнал мал. Размер задают политикой Computer Configuration → Administrative Templates → Windows Components → Event Log Service → Security → «Specify the maximum log file size (KB)»: от 20 МБ до 2 ТБ, подберите по месту на диске. Режим «не перезаписывать» («Control Event Log behavior when the log file reaches its maximum size») не включайте: на заполненном журнале новые события теряются.

Ключевые события Windows

Справочник Microsoft «Events to monitor» оценивает важность событий. High: разбираться стоит с каждым. Medium и Low: только если событие неожиданно или их число заметно выше обычного.

Оценка общая, а «неожиданное» определяете вы. Один 4625 — опечатка в пароле, а десятки за несколько минут с одного адреса — повод посмотреть. Добавление участника в группу формально Low, но неожиданное добавление в привилегированную группу — повод реагировать, а за составом Administrators, Domain Admins, Enterprise Admins и Schema Admins стоит следить (Безопасность 06). Событие 4964 записывается только для групп, чьи SID вы заранее перечислили в значении SpecialGroups ветки реестра HKLM\System\CurrentControlSet\Control\Lsa\Audit; без списка его не будет. Если администраторам запрещён вход на рядовые компьютеры, внесите в список Domain Admins: тогда вход администратора на рядовой ПК (в лаборатории PC2; PC1 — административный хост, Безопасность 06) — повод проверить. Событие пишется при любом новом входе, в том числе сетевом, а сетевой вход в 06 разрешён, поэтому сверяйте тип входа в 4624: 2 и 10 на таком ПК — нарушение запрета.

В событии 4624 важны поле Logon Type и адрес источника (Source Network Address). Типы: 2 — вход за клавиатурой, 3 — по сети (например, открыта общая папка), 4 — пакетное задание, 5 — служба, 7 — разблокировка, 10 — удалённый рабочий стол, 11 — вход с кэшированными данными без контроллера. Тип 10 на FS1 с адреса вне 192.168.10.0/24 — повод проверить, не опубликован ли RDP в интернет (Безопасность 05).

Чтобы увидеть картину за сутки, сгруппируйте неудачные входы по адресу и имени (PowerShell 5.1 и 7, запуск от администратора):

$since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'; Id = 4625; StartTime = $since
} -ErrorAction SilentlyContinue | ForEach-Object {
  $d = ([xml]$_.ToXml()).Event.EventData.Data
  [pscustomobject]@{
    Account = ($d | Where-Object Name -eq 'TargetUserName').'#text'
    Source  = ($d | Where-Object Name -eq 'IpAddress').'#text'
  }
} | Group-Object Source, Account |
  Sort-Object Count -Descending |
  Select-Object -First 10 Count, Name

Пример вывода (значения вымышленные):

Count Name
----- ----
   41 203.0.113.50, administrator
   17 203.0.113.50, ivanov
    2 192.168.10.101, petrova

Много неудач с одного внешнего адреса под разными именами — перебор; две неудачи petrova с её компьютера — обычная жизнь.

Sysmon: когда журнала Windows мало

Sysmon (System Monitor) — служба и драйвер Microsoft, которые пишут в журнал Windows сведения о запуске процессов с полной командной строкой и хешем файла, загрузке драйверов, сетевых соединениях, создании файлов и DNS-запросах. Sysmon ничего не анализирует и не скрывается от злоумышленника: он только даёт материал для разбора. Записи лежат в Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.

Сетевые соединения (событие 3) и загрузка образов (событие 7) выключены по умолчанию, полный сбор создаёт много записей. Команды ниже — для автономного Sysmon: скачивайте его только со страницы Sysinternals на Microsoft Learn (ссылка в источниках) и сначала поставьте на одном тестовом сервере; на 64-разрядной системе утилита называется sysmon64. На Windows 11 и Windows Server 2025 есть и встроенный Sysmon, их не смешивают (см. врезку «Состояние»). Установка с настройками по умолчанию и откат:

sysmon -accepteula -i
sysmon -u

Фильтры задают файлом конфигурации (sysmon -c файл.xml), образец есть на странице Sysmon. Чужие конфигурации не вставляйте не читая: правила решают, что вы увидите, а что пропустите.

Пересылка событий и копии журналов

Получив права на машину, злоумышленник может изменить или стереть её локальный журнал: по данным руководства, часть атакующих так и делает. Поэтому журналы собирают в отдельное место, а право менять и удалять их дают немногим. В Windows для этого есть Windows Event Forwarding (WEF): выбранные события пересылаются на сервер сбора (Windows Event Collector, WEC). Важно знать:

• WEF пассивна: она не включает аудит и не меняет размер журнала, а только читает существующие события. Политику аудита и размеры вы настраиваете отдельно;
• проще всего подписка, инициируемая источником: клиентов настраивают групповой политикой; в домене соединение шифруется Kerberos;
• локальный журнал источника служит буфером при потере связи; если события затёрты раньше пересылки, сборщик об этом не узнает.

Пошаговую настройку берите из документации, пробуйте на двух тестовых машинах. Сборщик станет ценной целью: защищайте его как контроллер домена. Для Linux аналог — rsyslog (Linux 17); обычный TCP без шифрования годится только в доверенной сети.

Linux: что смотреть

journalctl и /var/log/auth.log хранят входы по SSH, использование sudo и смену пользователей. Быстрая проверка за сегодня:

sudo journalctl -u ssh --since today -g 'Invalid user|Failed' -o short-iso
sudo journalctl -t sudo --since today -o short-iso

Пример вывода (значения вымышленные, строки сокращены; формат зависит от версий OpenSSH и sudo):

2026-11-10T09:14 lnx2 sshd[2217]: Invalid user admin from 203.0.113.50
2026-11-10T10:02 lnx2 sudo: admin-lab : USER=root ; COMMAND=/usr/bin/apt update

Эти записи показывают, кто вошёл и что запустил с повышенными правами, но не покажут, кто изменил файл учётных записей или настройки SSH. Для этого нужен auditd — подсистема аудита ядра Linux: её правила-наблюдатели (watches) фиксируют обращения к выбранным файлам. Установите пакет, если его нет (sudo apt install auditd), и создайте файл /etc/audit/rules.d/60-local.rules:

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config

Строка читается так: -w — следить за путём, -p wa — за записью (write) и изменением атрибутов (attribute), -k — метка для поиска. Для каталога наблюдение рекурсивное. Файлы *.rules из rules.d объединяет в общий набор скрипт augenrules. Загрузите правила, проверьте их, затем создайте тестового пользователя, найдите запись по метке и уберите за собой:

sudo augenrules --load
sudo auditctl -l
sudo adduser --disabled-password --comment 'Audit test' audittest
sudo ausearch -k identity -ts recent -i
sudo deluser --remove-home audittest
sudo rm /etc/audit/rules.d/60-local.rules
sudo augenrules --load

Опция -ts recent ограничивает поиск последними десятью минутами, -i заменяет числа именами. Правила по системным вызовам (-S) замедляют систему, а число наблюдателей за файлами на производительность не влияет, поэтому начинайте с них. Режим -e 2 блокирует конфигурацию до перезагрузки, а -f 2 останавливает ядро при ошибках аудита: оставьте значения по умолчанию. В /etc/audit/auditd.conf проверьте размер журнала и действия при нехватке места: на полном диске аудит может замолчать.

Время, хранение и защита журналов

Время. NIST приводит пример: из-за неточных часов записи могут показать, что событие A произошло на 45 секунд раньше B, когда на деле оно случилось на две минуты позже. Все системы берут время из общего источника. Руководство советует UTC (всемирное координированное время), формат ISO 8601 (например, 2026-11-10T09:14:02Z) и по возможности несколько источников. В домене клиенты берут время у контроллеров, а эмулятор PDC (главный контроллер домена) — у внешнего источника (Windows Server 03, старая статья про время в домене). Проверка: w32tm /query /status на Windows и timedatectl status на Linux (System clock synchronized: yes).

Срок хранения. Универсального числа нет. В руководстве 2024 года сказано, что сроки по умолчанию часто недостаточны, и приведены оценки: на обнаружение инцидента иногда уходит до 18 месяцев, а вредоносная программа может прожить в сети от 70 до 200 дней до заметного ущерба (цифры из материала CISA «First 48», на который ссылается руководство). Для критичных систем другой документ CISA (см. Безопасность 10) советует хранить журналы не менее года, если возможно: это иной ориентир, а не противоречие. Срок зависит от ваших рисков и внешних требований (спросите юриста). Практика автора: умножьте суточный объём журналов на желаемый срок и сравните с местом; если мало, входы, группы и изменения политик храните дольше, а подробное, вроде командных строк, короче.

Защита. Копия журналов лежит вне машины, которую могут взломать, а право удалять и менять журналы есть только у тех, кому это нужно по работе. Сигналы 1102 и 4719 должны будить вас сразу. Ручная выгрузка wevtutil epl описана в Windows Server 12.

Оповещения: на что реагировать сразу

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

В Zabbix для Windows подходят ключи eventlog[] и eventlog.count[]; они работают только как активные проверки, а журнал «Forwarded events» агент не читает, поэтому элементы создавайте на самих источниках, а не на сервере WEF. Накопление неудачных входов и редкое событие 1102:

eventlog.count[Security,,,,^4625$,,skip]
eventlog.count[Security,,,,^1102$,,skip]

Триггеры (пороги условные): sum(/DC1/eventlog.count[Security,,,,^4625$,,skip],5m)>30 и sum(/DC1/eventlog.count[Security,,,,^1102$,,skip],10m)>0. Тип элемента — «Zabbix agent (active)», тип данных числовой; на агенте нужны ServerActive и верный Hostname (Zabbix с нуля). Фильтруя по названию группы (Domain Admins), помните, что в русскоязычной системе она называется иначе.

Для Linux есть активный ключ log.count:

log.count[/var/log/auth.log,"Invalid user|Failed password",,,skip]

Файл ротируется logrotate: если счётчик после ротации ведёт себя странно, используйте logrt.count (синтаксис — на странице Zabbix agent items). Если агент не может прочитать файл, элемент станет неподдерживаемым. Файл читают root и члены группы adm (Linux 17): если агент работает от пользователя zabbix и в adm не входит, выдайте доступ осознанно (sudo usermod -aG adm zabbix, перезапуск агента). Это открывает все файлы из /var/log; откат — sudo deluser zabbix adm. На сервере только с ключами SSH сообщений «Failed password» не будет: подберите шаблон по своим записям в journalctl. Триггер nodata(/lnx2/log.count[...],30m)=1 сообщает, что элемент перестал присылать значения (агент или файл недоступны, элемент стал неподдерживаемым); он не говорит, что в журнале нет подходящих строк.

Шум и пороги (практика автора). Включите элементы, но триггеры на неделю-две оставьте выключенными: посмотрите обычный уровень и только потом ставьте порог выше него. Через месяц пересмотрите, что срабатывало зря и что пропущено.

Практика: проверка за полчаса

На тестовых машинах:

1. На тестовом сервере выполните auditpol /get /category:*, сохраните копию политики, проверьте размер и режим журнала Security.
2. Введите неверный пароль тестовой учётной записи на PC1 три раза (запись может заблокироваться) и найдите события 4625 запросом из статьи.
3. На тестовом ПК с агентом Zabbix создайте элемент eventlog.count[Security,,,,^4625$,,skip], повторите шаг 2 и убедитесь, что значение выросло.
4. С PC1 подключитесь к lnx2 несуществующим пользователем (ssh nouser@192.168.10.21) и найдите запись Invalid user в journalctl.
5. Проверьте правила auditd на тестовом пользователе и откатите их. В конце удалите тестовые элементы, триггеры и учётные записи.

Состояние на ноябрь 2026 года (проверьте актуальность). По документации Microsoft встроенный Sysmon — необязательный компонент Windows 11 и Windows Server 2025; автономный и встроенный Sysmon на одном устройстве не работают, автономный нужно удалить до включения встроенного. Версия автономного Sysmon по странице Sysinternals — 15.22. NIST SP 800-92 Rev. 1 остаётся проектом (первичный проект от 11 октября 2023 года), поэтому опираемся на редакцию 2006 года. Руководство ASD ACSC, CISA и партнёров опубликовано 21 августа 2024 года.

Типичные ошибки и недоразумения

• Включили всё сразу. Через неделю журнал занимает диск, а читать его некому. Начинайте с базового набора.
• Журнал Security остался на 20 МБ. События за выходные могут быть уже затёрты. Проверьте дату самого старого события.
• Оповещение на каждый 4625. Пользователи опечатываются, и вы перестаёте реагировать. Ставьте порог по накоплению.
• Журналы только на самом сервере. Взломщик стирает их первыми. Нужна копия вне машины.
• Оповещения никогда не проверялись. Создайте тестовое событие и убедитесь, что письмо пришло.

Проверьте себя

1. Почему событие 4625 само по себе оценивается как Low и когда на него стоит реагировать? Одна неудача — обычная опечатка. Low и Medium: разбирайтесь, если событие неожиданно или их число заметно выше обычного.
2. Какие два события стоит вынести в немедленные оповещения? 4719 (изменена политика аудита, оценка High) и 1102 (очищен журнал Security, оценка Medium или High).
3. Что происходит с журналом Security при заполнении и какой режим включать не стоит? Новые события затирают старые (Circular). Режим «не перезаписывать» не включают: новые события будут теряться.
4. Почему событие 4964 само по себе не появится после включения подкатегории Special Logon? Оно записывается только для групп, чьи SID заранее перечислены в значении SpecialGroups в реестре.
5. Что сообщает триггер nodata на элементе log.count? Что элемент перестал присылать значения, а не что в журнале нет подходящих строк.

Что дальше

• Безопасность для начинающих 10 — что делать, когда оповещение оказалось настоящим, и как сохранить журналы как доказательства.
• Безопасность для начинающих 06 — привилегированные группы, за которыми нужно следить.
• Безопасность для начинающих 08 — закалка Linux-сервера lnx2, чьи журналы вы теперь читаете.
• Zabbix с нуля: установка, первые узлы и уведомления — активные проверки и каналы уведомлений.

Источники

• System audit policy recommendations — базовая политика аудита для серверов и рабочих станций, принципы выбора событий для оповещений
• Appendix L: Events to monitor — номера событий, оценки важности, смысл оценок
• 4624(S): An account was successfully logged on (архив, Windows 10) — типы входа и поля события
• 4964(S): Special groups have been assigned to a new logon (архив, Windows 10) — список SpecialGroups в реестре
• 4688(S): A new process has been created (архив, Windows 10) — командная строка в событии и политика её включения
• auditpol set — управление политикой аудита; соседние страницы get, list, backup, restore
• Policy CSP: EventLogService — размер журнала Security по умолчанию, пределы, поведение при заполнении
• Use Windows Event Forwarding to help with intrusion detection — устройство WEF, подписки, шифрование, ограничения
• Sysmon — загрузка, установка, события, журнал, конфигурация
• Sysmon overview — встроенный Sysmon и совместимость с автономным
• Best Practices for Event Logging and Threat Detection — руководство ASD ACSC, CISA и партнёров: политика, приоритеты источников, время, хранение, защита логов
• NIST SP 800-92, Guide to Computer Security Log Management — инфраструктура журналов, единый источник времени
• auditctl(8), Ubuntu 24.04 — правила -w, -p, -k, режимы -e и -f; поиск ausearch и сборку augenrules описывают соседние man-страницы
• Windows agent items, Zabbix 7.0 — eventlog[], eventlog.count[], ограничения
• Zabbix agent items, Zabbix 7.0 — log.count[], logrt.count[], права доступа к файлу