DC виснет на логоне: как я лечил переполнение Security Log у клиента

Привет! Я Семёнов Евгений Сергеевич, директор ITFresh. За пятнадцать лет обслуживания AD-доменов в Москве чего я только не видел. Сотни, если не тысячи, странных ситуаций с контроллерами домена — наша ежедневная практика. Пожалуй, самый подлый сценарий: DC внешне ведёт себя отлично, но каждое утро люди ждут по 3-5 минут, чтобы просто войти в систему. И знаете что? В 80% таких случаев виноват он — переполненный Security Log. Сегодня я расскажу, как мы в ITFresh находим эту проблему, как с ней боремся и что делаем, чтобы она больше не всплывала.

Первый звонок от клиента: «После 9:00 вся работа встаёт»

Помню, как-то в понедельник, ровно в 9:15 утра, мне раздался звонок. На линии был директор производственной фирмы из Химок: 42 рабочих места, два контроллера домена Windows Server 2019. Голос в трубке просто кипел: «Евгений, это просто кошмар с пятницы! Утром сотрудники приходят, пытаются войти — ждут по пять минут! Некоторые вообще не могут залогиниться. Бухгалтер рвёт и мечет, склад стоит. Что у вас там происходит?!» Ну, и мы с этим справились, конечно.

Не теряя ни минуты, я тут же сел за ноутбук, подключился по RDP к их основному контроллеру — DC01. Загрузка Windows заняла секунд 30, не больше. Всё работает, ничего не виснет, просто летает! Открываю Event Viewer, и тут же — первый "сюрприз": журнал Security оказался абсолютно пустым. Совсем. Ни одной записи. Странно, правда? Ага, думаю, надо копнуть глубже и проверить свойства этого журнала.

Log size: 20 MB
Current size: 20.00 MB
Oldest event: 08.04.2026 05:13:27
Retention policy: Overwrite events as needed

Что я увидел в свойствах? Размер лога всего 20 МБ, а последнее событие в нём было аж в 5 утра. А ведь у них 42 активных пользователя! При стандартных настройках аудита такой объём событий, как 15–25 тысяч, генерируется буквально за час. Получается, 20 МБ хватает лишь на 20–30 тысяч записей. Выходит, лог ротируется каждый час-полтора. Это, конечно, звучит вроде бы невинно, но на самом деле такая быстрая ротация нередко вызывает блокировку LSA-сервиса прямо во время записи. Вот где собака зарыта!

Почему DC зависает при переполненном логе

Проблема в архитектуре. Процесс LSASS (Local Security Authority), который обрабатывает все аутентификации в домене, при каждом успешном и каждом неуспешном логине вызывает API AuthzReportSecurityEvent для записи аудита в Security Log. Если лог переполнен и политика — «перезаписывать по мере необходимости», то LSASS:

1. Система забирает себе эксклюзивный lock на файл лога. Без него никак.
2. А потом она пытается отыскать самое старое событие. Зачем? Чтобы его перезаписать.
3. Но если индекс лога фрагментирован... Ох, тогда эта операция растягивается. От 500 до 1500 миллисекунд.
4. И пока длится этот lock, все остальные потоки LSASS просто стоят и ждут. Никто не работает.
5. А тут, параллельно, в 9:05 начинают активно логиниться 30 пользователей. И что происходит? Они все, как один, выстраиваются в длиннющую очередь.

И вот она, ужасающая картина: первый пользователь входит за какие-то 3 секунды. Отлично! А десятый? Он уже ждёт 40 секунд. А вот двадцатому сотруднику приходится ждать все 3 минуты. И что же с тридцатым? Он просто получает таймаут на своём компьютере. На экране выскакивает до боли знакомая ошибка: «Сервер отклонил попытку входа». Кошмар, да?

Диагностировать проблему помогает счётчик Security System-Wide Statistics\Authentication Packages и Performance Counter LSASS\PrivateBytes — если видите, что LSASS выжирает RAM и CPU при одновременных логонах — проблема точно в журнале или в дефрагментированной NTDS.

Диагностика: три команды, которые решают 80 % случаев

Когда мы сталкиваемся с подобной жалобой и приезжаем на место, наш первый шаг на контроллере домена всегда такой:

# 1. Размер и состояние Security Log
Get-WinEvent -ListLog Security | Format-List *

# 2. Статистика событий за последний час
Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=(Get-Date).AddHours(-1)} |
    Group-Object Id | Sort-Object Count -Descending | Select-Object -First 10

# 3. Конкретно что генерирует больше всего событий
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-1)} |
    Select-Object -ExpandProperty Properties |
    Group-Object Value | Sort-Object Count -Descending | Select-Object -First 10

У клиента в Химках вывод был таким: 73 % событий — это 4624 (успешный логон), причём 60 % от одной учётной записи sv_1c_agent. Оказалось, на сервере 1С стоял агент Zabbix, который раз в 10 секунд через WMI подключался к DC для чтения групп пользователей. 6 подключений в минуту × 60 × 24 = 8 640 событий в сутки только от одной учётки. Плюс ещё семь таких же сервисов — и получаем 60+ тысяч событий ежедневно.

Быстрое решение: расширяем лог и чистим

Чтобы немедленно снять эту острую боль, мы сразу увеличиваем размер Security Log до внушительных 4 GB. А ещё меняем политику ведения журнала: теперь он должен не перезаписывать старые события, а «архивировать при заполнении».

# Увеличиваем размер до 4 GB
wevtutil sl Security /ms:4294967296

# Автоматически архивировать при заполнении
wevtutil sl Security /ab:true /rt:false

# Создаём папку для архивов
New-Item -Path C:\EventLogArchive\Security -ItemType Directory -Force

# Прописываем путь архивов через реестр
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Security" `
    -Name "AutoBackupLogFiles" -Value 1 -Type DWord

# Экспортируем текущий лог в архив
wevtutil epl Security C:\EventLogArchive\Security\Security-$(Get-Date -Format yyyy-MM-dd).evtx

# Чистим активный лог
wevtutil cl Security

Что происходит после этих простых шагов? Пользователи мгновенно начинают входить в систему без проблем. Вся эта процедура занимает от 3 до 5 минут. И самое главное — клиенту моментально возвращаются деньги, ведь мы спасли ценное рабочее время его команды.

Долгосрочное решение: снижаем шум в логе

Конечно, просто расширить журнал — это лишь борьба с симптомом. Корень проблемы кроется глубже: это избыточный аудит. На контроллерах домена по умолчанию включено огромное количество категорий, но, откровенно говоря, для небольшого офиса половина из них абсолютно бесполезна. Поэтому мы всегда пересматриваем advanced audit policy и безжалостно отключаем всё, что не нужно. Зачем перегружать систему?

В gpedit, конкретно для GPO Default Domain Controllers Policy, мы всегда идём по следующему пути:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies

Вот наша проверенная стандартная конфигурация для офисов с числом пользователей от 20 до 60:

Результат применения такой политики впечатляет: объём событий, генерируемых на типичном контроллере домена, снижается в 5–10 раз! Помните клиента из Химок? После этих перенастроек их Security Log стал заполняться не каждые 90 минут, а примерно раз в 18 часов. Это колоссальная разница!

Централизованный сбор логов: Wazuh или WEF

Но что, если речь идёт уже не о пятидесяти сотрудниках, а гораздо большем штате? Или, например, у компании есть строжайшие требования compliance? Тогда, конечно, одного лишь локального журнала будет явно недостаточно. В таких случаях без централизованного сбора событий просто не обойтись. Из нашей обширной практики мы можем выделить два по-настоящему надёжных варианта:

Windows Event Forwarding (WEF) — встроенное в Windows решение. Один сервер-коллектор собирает Subscription-события со всех DC и серверов. Плюс: бесплатно, нативно, работает стабильно. Минус: нет встроенного поиска и алертов — нужны сторонние парсеры.

Wazuh — open-source SIEM, бесплатный и мощный. Ставится на отдельный Linux-сервер (2 vCPU, 4 GB RAM хватает для офиса 50 ПК), на DC ставится Winlogbeat или Wazuh Agent, события шифрованно отправляются в SIEM. Поиск по логам через Kibana, готовые алерты на brute-force, изменение admin-групп, несанкционированные логины в нерабочее время.

Кстати, для того самого клиента в Химках, о котором мы говорили, я развернул Wazuh прямо на виртуалке Hyper-V. И теперь они получили:

• Знаете, Security Log на вашем DC — он не резиновый. В него помещается всего около 8 часов активных событий. Это примерно 1 гигабайт данных.
• Как только лог заполняется, система сама, автоматически, создаёт его архивную копию. Мы позаботились, чтобы ничего не терялось.
• Все эти данные через WEF аккуратно собираются в Wazuh. Он, кстати, стоит на отдельном сервере.
• А в Wazuh у нас настроены очень важные алерты прямо в Telegram. Что мы отслеживаем? Ну, например: событие 4740 — это если вдруг заблокирован аккаунт. Или 4625 — неуспешные попытки входа, причём больше 20 раз в минуту (это уже тревожный звоночек!). И, конечно, 4728 — когда кто-то добавляется в admin-группу. Мы всегда в курсе.

Мониторинг, который предупреждает проблему заранее

Знаете, есть одна истина, которую я постоянно повторяю: лучшая стратегия — это, безусловно, профилактика. Именно поэтому на каждом клиентском контроллере домена у нас обязательно работает Zabbix-агент, а к нему мы прикручиваем стандартный шаблон «Template OS Windows by Zabbix agent». Но мы в ITFresh пошли ещё дальше! К этому шаблону я всегда добавляю три своих, абсолютно кастомных элемента мониторинга:

# Использование Security Log (%)
UserParameter=security.log.percent,(Get-WinEvent -ListLog Security).FileSize / `
    (Get-WinEvent -ListLog Security).MaximumSizeInBytes * 100

# Events per hour (последний час)
UserParameter=security.events.hourly,(Get-WinEvent -FilterHashtable @{LogName='Security'; `
    StartTime=(Get-Date).AddHours(-1)}).Count

# Время ответа LSASS на аутентификацию
UserParameter=lsass.logon.time,(Measure-Command { `
    Test-ComputerSecureChannel }).TotalMilliseconds

Триггеры:

• Если Security Log заполнен уже более чем на 80% — это, считайте, жёлтый свет! Сразу получаем warning в Telegram. Пора принимать меры.
• А вот если Security Log забит уже более чем на 95% — всё, это настоящий disaster! Тут уже не до шуток: срочно отправляется SMS-сообщение прямо директору ITFresh. Мы не спим!
• Представьте: вдруг у вас сыпется больше пятидесяти тысяч событий в час. Что это, если не аномалия? Мы всегда помечаем такое количество как серьезный warning – тут надо не просто посмотреть, а буквально бросаться разбираться, что там происходит.
• LSASS тупит? Если время его ответа перевалило за три секунды — это чистой воды warning. Знаете, что это значит? Скорее всего, пользователей ждет неприятный сюрприз: их логин просто зависнет. Кто любит ждать? Никто.

Знаете, благодаря нашему тщательному мониторингу, мы с гордостью можем заявить: вот уже 14 месяцев ни один из наших клиентов не сталкивался с той самой неприятной историей, когда «DC виснет по утрам». Нет, такого больше не повторялось!

Что я изменил в стандарте обслуживания после этого случая

Кстати, тот самый случай — помните? — стал для нас идеальным толчком, чтобы полностью перетряхнуть и переделать наш внутренний чек-лист для первичного аудита AD-инфраструктур. И теперь, каждый раз, когда к нам обращается новый клиент, мы в первую очередь смотрим на:

1. Мы всегда тщательно мониторим, сколько места занимают все Event Log'и на ваших контроллерах домена. Речь идет о журналах Security, System, Application и, конечно, Directory Service. Это не просто цифры: их размер может подсказать, насколько активно логируется что-то важное или, наоборот, ненормальное.
2. Что насчет политик аудита? Мы буквально перетряхиваем их: нет ли случайно избыточно включенных категорий, которые только зря засоряют логи? Потому что чем больше мусора, тем сложнее найти по-настоящему важное событие.
3. Наш взгляд всегда падает на те учетные записи, у которых вдруг выскочило аномально высокое количество логонов. Знаете, кто чаще всего там мелькает? Эти вечно забытые сервисные аккаунты, которые, кажется, никто не трогает, но они почему-то бешено активны. Это всегда повод задуматься, что происходит.
4. Наличие процесса архивирования логов.
5. Не забываем, конечно, и про последнюю проверку времени отклика LSASS. Но самое главное: как он повел себя именно под нагрузкой? Только в таких условиях мы видим реальную картину и можем быть уверены в стабильности вашей системы.

Представьте: к нам приходит новый клиент. У него больше 30 пользователей, естественно, есть AD. Для такой компании аудит займёт всего каких-то два часа. И да, это важно: мы его проводим абсолютно бесплатно, ведь он уже входит в стоимость первичного обследования. Хотите знать, что мы чаще всего видим? В семи случаях из десяти мы либо находим откровенно раздутый аудит, либо натыкаемся на переполненные логи. Главное, мы успеваем всё это починить ещё до того, как проблемы начнут реально портить жизнь вашему бизнесу!

FAQ — частые вопросы по Security Log

Почему Security Log на DC может переполниться?

Стандартный размер Security Log — 20 MB, это хватает на 20–40 тысяч событий. На DC с 50+ пользователями при стандартном аудите лог заполняется за 2–3 часа, после чего система начинает тормозить.

Какой оптимальный размер Security Log для DC?

Для домена до 100 пользователей я ставлю 2 GB, для 100–500 — 4 GB, для 500+ — 8 GB. Политика перезаписи — «перезаписывать по мере необходимости», если нет требований по хранению логов по compliance.

Опасно ли очищать Security Log?

Если нет требований на сохранение — безопасно. Перед очисткой я всегда делаю экспорт в .evtx для архива. В регулируемых отраслях (финансы, медицина) лог чаще отправляется в SIEM-систему и хранится там.

Нужен ли централизованный сбор логов через SIEM?

Для офиса до 50 человек обычно нет — достаточно увеличить размер локального лога. Для средних компаний (50–200 человек) рекомендую Wazuh или ElasticSearch + Winlogbeat — бесплатно и решает задачу compliance.

Как предотвратить повторение проблемы?

Мониторинг свободного места в логе, алерты при заполнении на 80 %, автоматический архивный экспорт при ротации. В Zabbix есть готовый шаблон для Windows Event Log мониторинга.