Инфраструктура 6 июля 2026 · 16 мин чтения

Мониторинг Active Directory через Zabbix: как узнавать о падении контроллера домена и подборе пароля раньше пользователей

<p>За пять лет обслуживания корпоративных сетей на 20–50 рабочих мест я вывел одно правило: контроллер домена никогда не падает «вдруг». Перед этим всегда есть события в журналах — просто никто их не читает, пока не начнут звонить бухгалтерия и склад. С подбором пароля та же история: учётную запись блокируют за 40 минут до того, как об этом узнаёт сисадмин — если он в этот момент не сидит в Event Viewer. В этой статье разбираем нашу рабочую методологию: как мы разворачиваем Zabbix 7.0 LTS поверх Active Directory так, чтобы алерт о брутфорсе и алерт о деградации DC прилетали дежурному инженеру раньше, чем об этом напишет клиент.</p>

Почему «сервер пингуется» не значит «домен жив»

Типичная инфраструктура наших клиентов — 1–3 контроллера домена на Windows Server 2016–2022, файловый DFS, иногда 1С на терминальном сервере. Мониторинг при этом обычно уже есть: ICMP, диск, CPU, память. Но это мониторинг железа, не домена как сервиса. Контроллер может спокойно отвечать на ping и держать 40% CPU — а служба Netlogon в это время уже не устанавливает защищённый канал (secure channel) с рабочими станциями, потому что истёк или разошёлся пароль машинного аккаунта. Пользователи получают «Доверительные отношения между этой рабочей станцией и основным доменом не удалось установить». По ICMP — всё зелёное.

Вторая слепая зона — безопасность. Подбор пароля на административной или сервисной учётке почти никогда не выглядит как штурм. Атакующий — или скомпрометированный внешний сервис, RDP-гейт, VPN-шлюз — делает 3–5 попыток в минуту, чтобы не спровоцировать блокировку раньше времени. За рабочий день набегает 200–400 неудачных попыток входа, размазанных по журналу Security на контроллере домена. Без выборки по Event ID их физически не видно среди тысяч штатных записей аудита.

Zabbix в такой конфигурации мы используем не потому, что это единственный вариант — SIEM-решения делают то же самое, только глубже. Причина проще: у 90% наших клиентов Zabbix уже стоит для мониторинга серверов и сети. Добавить контроль AD — значит не покупать новый продукт, не обучать персонал новому интерфейсу и не увеличивать бюджет на мониторинг.

Четыре слоя мониторинга контроллера домена

Мониторинг DC мы делим на четыре уровня, каждый из которых ловит свой класс инцидентов. Ключевой момент: уровень 1 может быть полностью зелёным, пока уровень 4 уже кричит. Это разные измерения одной и той же машины — и путать их нельзя.

Уровень	Что проверяем	Механизм в Zabbix	Какой инцидент ловит
1. Сетевая доступность	ICMP, TCP 389 (LDAP), 636 (LDAPS), 88 (Kerberos), 53 (DNS), 135/49152–65535 (RPC)	icmpping, net.tcp.service[tcp,,389]	Полное падение сервера или сети
2. Критичные службы	NTDS, Netlogon, KDC, DFSR, DNS Server, W32Time, ADWS, IsmServ, Kdc	LLD service.discovery + service.info	Служба упала, но ОС жива
3. Производительность каталога	LDAP-запросы в секунду, длина очереди DRA, задержки NTDS	perf_counter_en / WMI-счётчики	Деградация до полного отказа (медленный логон)
4. События безопасности	Security-журнал: неудачные логоны, блокировки, Kerberos pre-auth	eventlog[Security,...]	Подбор пароля, атака на учётные записи

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

Разворачиваем Zabbix agent 2 и шаблон Windows by Zabbix agent

На контроллеры домена мы ставим Zabbix agent 2, не classic agent. Причина простая. Агент 2 — это один процесс на Go, плагин eventlog встроен и загружен по умолчанию, никаких дополнительных модулей Perl или сторонних DLL. Для активных проверок — в том числе eventlog — это снимает историческую проблему classic-агента с блокирующими потоками при большом объёме логов.

Минимальный конфиг агента для DC у нас выглядит так:

Server=10.10.10.5
ServerActive=10.10.10.5
Hostname=DC01
ListenPort=10050
LogFile=C:\Program Files\Zabbix Agent 2\zabbix_agent2.log
Plugins.WindowsEventlog.MaxLinesPerSecond=20

Параметр Plugins.WindowsEventlog.MaxLinesPerSecond отдельно выставляем на 20–50 (по умолчанию в документации Zabbix — ограничение, аналогичное общему MaxLinesPerSecond): в момент реальной атаки Security-журнал на DC генерирует событий 4625/4771 гораздо больше, чем в спокойном режиме, и без явного повышения лимита агент начнёт закономерно резать поток, что для задачи детекта брутфорса неприемлемо — именно пиковые события нам и нужны.

Дальше на хост привязываем официальный шаблон Windows by Zabbix agent (для Zabbix 7.0 требует agent версии 7.0 и новее; для более старых агентов используем вариант Windows by Zabbix agent active). Шаблон уже содержит правило низкоуровневого обнаружения (LLD) служб Windows — discovery опрашивает WMI/SCM и создаёт item, триггер и график на каждую обнаруженную службу, попавшую под фильтр регулярного выражения в макросе LLD-правила.

По умолчанию фильтр служб в шаблоне довольно общий, поэтому на DC мы расширяем список макросом на уровне узла, добавляя туда явно: Netlogon, NTDS, Kdc, DFSR, DNS, W32Time, ADWS, IsmServ, Winmgmt. Это те службы, отказ которых напрямую превращается в «пользователи не могут войти» или «GPO не применяются».

Отдельно закрываем канал между агентом и сервером: поскольку речь идёт о событиях безопасности контроллера домена, передавать их открытым текстом по сети мы считаем неприемлемым даже внутри локального периметра. В конфиге агента и на стороне узла в Zabbix Server включаем шифрование по преразделённому ключу — параметры TLSConnect=psk, TLSPSKIdentity и TLSPSKFile с путём к файлу ключа. Это штатная возможность Zabbix, не требующая полноценной инфраструктуры сертификатов, и на неё уходит буквально 10 минут на узел при первичном разворачивании.

Какие события Security-журнала мы берём под контроль

Дальше — ядро задачи: выборка нужных Event ID из журнала Security через ключ eventlog[]. Синтаксис ключа: eventlog[name,<regexp>,<severity>,<source>,<eventid>,<maxlines>,<mode>]. Мы заводим отдельный item на каждый интересующий Event ID — так проще писать триггеры и не путать причины разных инцидентов.

Event ID	Где пишется	Что означает	Зачем мониторим
4625	Security (DC и рабочая станция)	Неудачная попытка входа	Первичный сигнал перебора паролей и атак на RDP/VPN через домен
4771	Security на DC	Kerberos pre-authentication failed — отказ на этапе получения TGT	Самый чистый сигнал именно подбора пароля: пишется на контроллере, содержит IP-адрес источника
4740	Security на DC, инициировавшем блокировку	Учётная запись заблокирована (Account Lockout)	Порог lockout уже достигнут — критично, пользователь не может работать
4776	Security на DC	Неудачная NTLM-проверка учётных данных	Легаси-протокол: часто используется старыми сервисными интеграциями и почтовыми клиентами, тоже цель перебора

Для события 4771 отдельно смотрим на код ошибки Kerberos внутри тела события (Failure Code): 0x18 — неверный пароль (собственно, попытка подбора), 0x12 — учётная запись заблокирована/отключена/просрочена, 0x6 — такого принципала нет в базе (перебор логинов, а не паролей). По нашей практике именно рост доли 0x18 от разных IP на один и тот же account_name — самый надёжный индикатор именно атаки, а не забывчивости сотрудника.

Пример item для 4771 (в интерфейсе Zabbix — Data collection → Hosts → Items):

Key: eventlog[Security,,,,4771,,skip]
Type: Zabbix agent (active)
Update interval: 1m
History storage period: 90d

Флаг skip в последнем параметре режима означает, что при первом запуске мониторинга агент не будет ретроспективно вычитывать весь накопленный журнал — это важно, иначе на DC с большим Security-журналом первый запуск создаст лавину исторических значений и собьёт последующие триггеры.

Триггер на брутфорс: считаем всплеск, а не единичное событие

Единичное 4625 или 4771 — это норма: сотрудник ошибся паролем, забыл переключить раскладку, у него истёк пароль. Триггер должен реагировать не на факт события, а на частоту событий в скользящем окне. В Zabbix для этого есть функция агрегации count(), которая считает число значений в history за период.

Наш типовой триггер на попытки подбора по Kerberos на основе Event ID 4771 выглядит так:

Trigger name: Возможный подбор пароля через Kerberos на {HOST.NAME}
Expression: count(/DC01/eventlog[Security,,,,4771,,skip],5m)>=15
Severity: High

Порог «15 событий за 5 минут» — это наша практическая оценка, не значение из документации. Мы калибруем его индивидуально под каждого клиента: смотрим на фоновый уровень срабатываний за спокойную неделю. Обычно первые 5–7 дней после внедрения работаем в режиме «только сбор данных, без действия по триггеру» — снимаем baseline, смотрим на распределение и от него строим порог с запасом x3–x5.

Отдельный триггер — на сам факт блокировки учётной записи. Здесь порог lockout policy домена (Account lockout threshold) уже сработал у Windows, и ждать нечего:

Trigger name: Учётная запись заблокирована из-за подбора пароля
Expression: count(/DC01/eventlog[Security,,,,4740,,skip],10m)>=1
Severity: Disaster

Третий триггер мы обычно ставим на широту атаки — когда неудачные попытки идут не по одной учётке, а веером по разным логинам (перебор имён пользователей, типичный для внешних сканеров, если DC случайно виден изнутри VPN-периметра шире, чем нужно). Для этого недостаточно чистого count() — мы выносим имя учётной записи из тела события через препроцессинг item (шаг «Regular expression» над полем Message) в отдельное значение и уже по нему в дальнейшем строим отчёт в Zabbix (не триггер, а панель на дашборде), потому что аномальная широта — это скорее повод для ручного разбора инженером, чем для автоматической эскалации на телефон.

Как не утонуть в ложных срабатываниях

Первая неделя после включения этих триггеров у любого клиента с активным пользователем 1С или терминального сервера почти гарантированно даёт несколько ложных тревог. Это нормально. Вот что мы делаем, чтобы привести систему к рабочему состоянию за 1–2 итерации.

Включаем расширенный аудит на контроллерах. Событие 4625 без включённой политики Advanced Audit Policy Configuration (в GPO «Default Domain Controllers Policy» → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Logon/Logoff → Audit Logon, и Account Logon → Audit Kerberos Authentication Service) может не содержать IP-адрес источника и рабочей станции — тогда отличить сотрудника от внешнего адреса невозможно в принципе, приходится гасить триггер вручную.
Разделяем сервисные и человеческие учётные записи в анализе. Сервисные аккаунты 1С, почтовых коннекторов и резервного копирования при смене пароля без обновления везде, где он прописан (Windows Service, IIS Application Pool, scheduled task), дают ровный фон 4625 каждые несколько минут — это выглядит как атака, но является банальной рассинхронизацией пароля. Решение — не отключать триггер, а фиксировать проблему как отдельный тикет на исправление конфигурации сервиса.
Используем регэксп-фильтр внутри самого ключа eventlog. Если у клиента есть заведомо шумный, но безопасный источник (например, старый принт-сервер с NTLM), исключаем его на уровне регулярного выражения в параметре <regexp> ключа, а не глушим весь item.
Разносим по времени суток. Ночные попытки входа в 2–4 часа по московскому времени на DC, который обслуживает только офис 9:00–19:00, статистически подозрительнее, чем те же попытки в 10 утра понедельника. Мы делаем два набора триггеров с разным порогом по времени через встроенные функции даты в выражении триггера.

Практический ориентир по нашему опыту: за первые две недели у клиента на 30–40 рабочих мест мы обычно донастраиваем 3–5 исключений. После этого система выходит на стабильный режим — 0–1 ложное срабатывание в месяц. Это наблюдение по реальным проектам, не гарантия для любой инфраструктуры.

Падение контроллера домена: сигналы раньше первого звонка

Отдельная категория триггеров — деградация, не безопасность. Задача — поймать проблему на стадии «служба легла» или «репликация встала», а не тогда, когда никто уже не может залогиниться.

Базовый набор, который мы разворачиваем на каждом DC:

Триггер на остановку служб NTDS, Netlogon, Kdc, DFSR через LLD-триггеры шаблона (state=Stopped дольше, чем один интервал опроса, чтобы не ловить штатный рестарт службы при обновлении).
Триггер nodata() на сами eventlog-item’ы — если агент вообще перестал присылать данные (например, служба Zabbix Agent 2 упала вместе с сервером), это отдельный, более тревожный случай, чем просто недоступность по ICMP, потому что означает полную потерю телеметрии с узла.
Проверка LDAP-порта снаружи от самого DC — TCP 389 с соседнего узла или с Zabbix-прокси, ключ net.tcp.service[ldap,,389]: бывают ситуации, когда служба NTDS формально запущена, но LDAP не отвечает из-за перегрузки очереди DRA (репликации).
Периодический прогон dcdiag /q и repadmin /showrepl через запланированное задание на самом DC с отправкой результата в Zabbix через zabbix_sender как trapper-item — это единственный способ дотянуться до диагностики, которую сам Zabbix-агент штатными счётчиками не покрывает (например, ошибки репликации метаданных USN между DC).
Служба времени W32Time — расхождение времени между DC больше порога Kerberos (штатно 5 минут максимального допустимого дрейфа) само по себе обрушивает аутентификацию по всему домену; мы ставим отдельный триггер на счётчик рассинхронизации, получаемый через w32tm /monitor в том же trapper-подходе.

На практике связка «LLD по службам + nodata() по eventlog + внешняя TCP-проверка LDAP» закрывает подавляющее большинство сценариев отказа DC, с которыми мы реально сталкивались. Банальный обрыв диска под NTDS.dit — да. Зависший lsass.exe, при котором ОС формально жива, а каталог уже не отвечает — тоже. Именно эта комбинация, а не какой-то один метод, даёт нормальное покрытие.

Пример из практики: как выглядит инцидент от первого события до закрытия

Расскажу про типовой сценарий — мы наблюдали его не раз на объектах с внешним RDP-шлюзом или опубликованным веб-доступом к 1С поверх домена. Схема каждый раз разворачивается примерно одинаково. Именно поэтому её удобнее ловить триггерами, чем рассчитывать на то, что администратор сам что-то заметит.

Шаг 1: в 03:14 ночи на контроллере домена начинают появляться события 4771 с кодом ошибки 0x18 для учётной записи одного из бухгалтеров — логин совпадает с шаблоном «фамилия.имя», который легко перебрать по открытым базам сотрудников компании в соцсетях. Частота — примерно раз в 8–10 секунд, IP-адрес источника один и тот же (внешний, не из диапазона офиса).

Шаг 2: item eventlog[Security,,,,4771,,skip] получает вторую запись за минуту, счётчик count(...,5m) проходит порог — в течение часа накапливается больше 15 событий, триггер «Возможный подбор пароля через Kerberos» переходит в состояние Problem. Zabbix Server через Action отправляет сообщение в Telegram-канал дежурных с тегом ad-security и severity High.

Шаг 3: дежурный инженер получает алерт в 03:16, открывает Zabbix и смотрит на график по item'у. Атака идёт с одного IP на одну учётную запись — не веерная. Инженер блокирует внешний IP на периметровом firewall или VPN-шлюзе. Всё это происходит ещё до того, как достигнут порог lockout threshold и учётка реально заблокируется.

Шаг 4: предположим, инженер не среагировал за 10 минут — ночь, бывает. Атака продолжилась, порог Account lockout threshold политики домена достигнут. Срабатывает второй триггер по событию 4740, severity Disaster. Это уже гарантированная эскалация на второго инженера и уведомление руководителя направления. Почему Disaster? Потому что заблокированная учётная запись бухгалтера с утра — это конкретный простой конкретного человека и, вполне возможно, срыв платежей.

Главное в этом сценарии вот что: без eventlog-мониторинга весь путь от 03:14 до утра прошёл бы незамеченным. О блокировке узнали бы только по звонку бухгалтера в 9:00 — почти через 6 часов после начала атаки. С мониторингом — через 2 минуты после первого подозрительного всплеска. Разница ощутимая.

Эскалация: от триггера в Zabbix до звонка дежурному

Триггер без нормально выстроенной цепочки уведомлений — пустая трата времени. Событие просто повиснет в списке проблем, который никто не откроет до утра. Мы настраиваем Action в Zabbix отдельно от общих серверных алертов — со своими условиями и тегами, не смешивая потоки.

Структура действия «AD Security Incidents»:

Условие: тег component = ad-security (мы проставляем этот тег на уровне триггера через раздел Tags, чтобы не собирать условия по имени хоста или item’а — это упрощает сопровождение при добавлении новых DC).
Операция шаг 1 (сразу): уведомление дежурному инженеру через медиатип Telegram — webhook-интеграция, бот получает chat_id дежурного через пользовательский профиль в Zabbix (Users → Media).
Операция шаг 2 — через 10 минут, если проблема не подтверждена и не закрыта: эскалация на второго инженера и письмо руководителю направления.
Recovery operation: отдельное сообщение «проблема устранена» с указанием длительности инцидента. Это нужно не для галочки — без этого нормальный разбор по SLA просто невозможен.

Для инцидентов уровня Disaster (например, срабатывание по 4740 — блокировка учётной записи, или падение службы NTDS) мы не даём шага ожидания подтверждения — первый шаг эскалации сразу идёт и в Telegram-канал дежурных, и отдельным сообщением директору по работе, потому что цена простоя всего домена для компании 30–50 рабочих мест исчисляется часами простоя всего бизнеса, а не одного рабочего места.

Отдельно скажу про смешивание потоков — делать этого не стоит. Алерты безопасности и инфраструктурные алерты — это разные вещи по психологическому весу. Когда дежурный видит в одном чате «диск заполнен на 85%» рядом с «подбор пароля администратора домена», внимание к критичным сообщениям неизбежно снижается. Это не теория — на нашей практике именно так и происходит.

Помимо реактивной эскалации мы обязательно заводим для руководителя клиента (или для директора по IT на стороне заказчика) недельный отчёт — штатный механизм Zabbix Reports/Scheduled reports с рассылкой дашборда по расписанию на почту. В отчёт включаем количество и severity инцидентов по тегу ad-security за неделю, среднее время до подтверждения (acknowledge) и среднее время до закрытия проблемы. Это превращает мониторинг из чёрного ящика «что-то мигает у айтишников» в измеримую метрику качества сервиса, которую можно положить в основу SLA по инцидентам безопасности.

Частые вопросы

Нужен ли для этого отдельный Zabbix-сервер или прокси, если у нас уже есть Zabbix для серверов и сети?: Нет, отдельный сервер не нужен. Мы добавляем контроллеры домена как обычные хосты в существующий Zabbix, привязываем шаблон Windows by Zabbix agent и заводим eventlog-item’ы поверх уже работающей инфраструктуры мониторинга. Отдельный Zabbix proxy имеет смысл только если DC находится в изолированном сегменте сети без прямой связи с Zabbix Server — тогда прокси нужен просто как транзитный узел, а не по требованиям самого мониторинга AD.
Чем такой мониторинг отличается от полноценного SIEM (например, Microsoft Sentinel или Wazuh)?: SIEM-системы делают корреляцию событий безопасности глубже: сопоставляют события из разных источников, строят цепочки атаки (kill chain), хранят события безопасности годами для расследований и комплаенса. Zabbix-подход, который мы описали, — это операционный алертинг: быстро узнать о конкретном инциденте и среагировать. Для компании на 20-50 рабочих мест без выделенного SOC это обычно достаточный и кратно более дешёвый уровень защиты, чем внедрение SIEM. Если у клиента есть требования по комплаенсу (например, хранение журналов безопасности несколько лет), мы обсуждаем SIEM отдельно.
Не потеряет ли Zabbix события при реальной массовой атаке, если событий 4625/4771 станет очень много?: Риск есть на уровне лимита Plugins.WindowsEventlog.MaxLinesPerSecond у агента 2 — если оставить значение по умолчанию, агент начнёт сознательно отбрасывать часть строк, чтобы не перегружать канал до Zabbix Server. Мы заранее повышаем этот лимит на контроллерах домена (обычно до 20-50 строк в секунду) именно потому, что для задачи детекта брутфорса важны пиковые интервалы, а не ровный фон.
А что если сам Zabbix Server или Zabbix agent зависит от того же домена (DNS, аутентификация), который мы мониторим?: Валидный риск, который мы закрываем на этапе проектирования: Zabbix Server и Zabbix agent на DC используют IP-адреса, а не имена, в параметрах Server и ServerActive, чтобы не зависеть от собственного DNS домена в момент его деградации. Учётная запись, под которой работает служба Zabbix Agent 2 на Windows, — локальная (Local System), не доменная, чтобы служба продолжала стартовать и работать даже при недоступности контроллеров домена.
Сработает ли эта схема на старых контроллерах домена, например Windows Server 2012 R2?: Ключ eventlog[] и структура событий 4625/4740/4771/4776 в Security-журнале одинаковы начиная как минимум с Windows Server 2008 R2 — механизм аудита логонов и Kerberos не менялся принципиально. Единственное ограничение — актуальный шаблон Windows by Zabbix agent для Zabbix 7.0 рассчитан на Zabbix agent версии 7.0 и новее; для старых или EOL-версий Windows Server мы используем более старую версию агента и, соответственно, более ранний вариант шаблона или ручную настройку item без привязки к officially maintained template.