Hardening Windows и Active Directory: типовые слабые места и как их закрыть

Active Directory — это сердце большинства корпоративных сетей Windows. Контроллер домена знает всех пользователей, все компьютеры и все права. Поэтому его защита определяет безопасность всей организации: если кто-то получил контроль над доменом, дальше защищать уже нечего. Хорошая новость в том, что большинство реальных проблем AD не экзотика, а набор повторяющихся слабых мест: устаревшие протоколы, избыточные права, забытые учётные записи и отсутствие журналирования.

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

Оценка и первоочередные меры

Шаг 1. Инвентаризация привилегированных групп

Начни с вопроса: кто в домене может всё? Членство в группах Domain Admins, Enterprise Admins, Schema Admins и Administrators должно быть минимальным и объяснимым. Типичная картина в старых доменах — десятки «временных» администраторов, которые так и остались навсегда.

Import-Module ActiveDirectory
foreach ($g in 'Domain Admins','Enterprise Admins','Schema Admins','Administrators') {
    "== $g"
    Get-ADGroupMember -Identity $g -Recursive |
      Select-Object Name, SamAccountName, objectClass
}

Для каждого участника ответь: зачем ему эти права, пользуется ли он ими ежедневно, есть ли у него отдельная административная учётная запись. Администратор должен читать почту и открывать браузер под обычной учёткой, а для управления серверами использовать отдельную. Это называется разделением учётных записей и сильно снижает ущерб от компрометации рабочей станции.

Шаг 2. Поиск «мёртвых» и рискованных учётных записей

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

# Не входили более 90 дней
$cut = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cut} `
  -Properties LastLogonDate | Select Name, LastLogonDate

# Пароль без срока действия
Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
  Select Name, SamAccountName

# Учётные записи с SPN (сервисные), проверить сложность паролей
Get-ADUser -Filter {ServicePrincipalName -like "*"} `
  -Properties ServicePrincipalName, PasswordLastSet |
  Select Name, PasswordLastSet

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

Шаг 3. Отказ от устаревших протоколов

Старые протоколы аутентификации оставлены ради совместимости, но делают сеть уязвимой для перехвата и подмены. Основные кандидаты на отключение: SMBv1, LM и NTLMv1, а также анонимный перебор общих ресурсов. Сначала включи аудит и посмотри, кто ими пользуется, потом отключай.

# Проверка и отключение SMBv1
Get-SmbServerConfiguration | Select EnableSMB1Protocol
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# Требовать подпись SMB
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# Уровень аутентификации LAN Manager: только NTLMv2 (значение 5)
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa `
  -Name LmCompatibilityLevel -Value 5

Для массового применения вместо ручных команд используй групповые политики: Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Подпись LDAP на контроллере также стоит сделать обязательной, предварительно проверив журнал событий с идентификаторами 2886-2889, которые показывают клиентов с небезопасным подключением.

Шаг 4. Модель администрирования по уровням

Классическая идея tiered administration: делим ресурсы на три уровня. Tier 0 — контроллеры домена и всё, что управляет идентификацией. Tier 1 — серверы приложений. Tier 2 — рабочие станции. Администратор более высокого уровня никогда не входит на машины более низкого: иначе его учётные данные окажутся в памяти ненадёжного узла.

Практически это реализуется так: создай группы T0-Admins, T1-Admins, T2-Admins; добавь в политики «Запретить локальный вход» и «Запретить вход через службы удалённых рабочих столов» для групп более высокого уровня на машинах нижнего. Добавь привилегированных пользователей в группу Protected Users, чтобы для них отключались слабые способы аутентификации и кэширование.

Add-ADGroupMember -Identity 'Protected Users' -Members 'adm.ivanov'

Перед добавлением проверь, что учётной записи не нужны NTLM и делегирование: в Protected Users они недоступны.

Шаг 5. Локальные администраторы и LAPS

Если на всех рабочих станциях и серверах одинаковый пароль локального администратора, компрометация одной машины открывает остальные. Решение — Windows LAPS: каждый компьютер получает уникальный пароль, хранящийся в AD и обновляемый по расписанию.

Update-LapsADSchema
Set-LapsADComputerSelfPermission -Identity 'OU=Servers,DC=itpages,DC=lab,DC=local'
# Просмотр пароля уполномоченным администратором
Get-LapsADPassword -Identity srv-web01 -AsPlainText

Доступ на чтение паролей выдавай узкой группе и логируй. Затем в групповой политике включи LAPS, задай длину не менее 16 символов и срок смены 30 дней.

Шаг 6. Журналирование и обнаружение

Укрепление без наблюдения — половина работы. Включи расширенную политику аудита и собирай события в центральное хранилище. Особенно важны входы (4624, 4625), блокировки (4740), изменения в привилегированных группах (4728, 4732, 4756), создание и изменение учётных записей (4720, 4738), очистка журнала (1102).

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Directory Service Changes" /success:enable
wevtutil sl Security /ms:536870912

Последняя команда увеличивает размер журнала безопасности примерно до 512 МБ, чтобы события не затирались слишком быстро. Для PowerShell включи журналирование блоков скриптов (Script Block Logging) и модулей: оно пригодится при расследовании. Настрой пересылку событий на сервер сбора, например на srv-scan01, через Windows Event Forwarding, и создай оповещения хотя бы на изменение состава Domain Admins и очистку журнала.

Шаг 7. Резервные копии и восстановление

Защита должна включать план восстановления. Делай регулярные копии состояния системы контроллеров домена и храни хотя бы одну копию вне домена, в изолированном месте, недоступном с администраторских учёток. Проверь процедуру восстановления в тестовой среде: непроверенная копия — это надежда, а не защита.

wbadmin start systemstatebackup -backuptarget:E: -quiet
wbadmin get versions

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

Шаг 8. Регулярная самопроверка

Используй бесплатные инструменты оценки состояния AD, которые показывают конфигурационные недочёты и дают баллы риска: например, PingCastle и Purple Knight. Они работают в режиме чтения и подходят для периодического контроля. Запускай их раз в квартал, сравнивай результаты и отслеживай тренд. Все найденные пункты вноси в общий список задач вместе с отчётами сканера уязвимостей.

Шаг 9. Групповые политики и безопасные базовые настройки

Ручная настройка каждого сервера не масштабируется. Используй базовые конфигурации безопасности Microsoft (Security Baselines) и применяй их через групповые политики к организационным подразделениям. Начни с тестового подразделения, затем расширяй. Особое внимание: политика паролей и блокировки, брандмауэр Windows во всех профилях, запрет автозапуска со съёмных носителей, защита учётных данных (Credential Guard) там, где позволяет оборудование.

Get-NetFirewallProfile | Select Name, Enabled, DefaultInboundAction
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True -DefaultInboundAction Block
Get-MpComputerStatus | Select AMServiceEnabled, RealTimeProtectionEnabled
gpresult /r /scope computer

Последняя команда показывает, какие политики реально применились к узлу: так ты поймёшь, почему настройка не действует. Для Windows Server srv-dc01 отдельно проверь, что на контроллере нет лишних ролей и программ: чем он «скучнее», тем лучше. Не запускай на нём браузеры, почтовые клиенты и сторонние службы без необходимости.

Шаг 10. Шаблоны сертификатов и службы Kerberos

Если в домене развёрнут центр сертификации (AD CS), ошибки в шаблонах сертификатов нередко становятся путём к повышению привилегий. Проверь, кому разрешено запрашивать сертификаты, кто может задавать произвольные имена субъекта и нужны ли вообще устаревшие шаблоны. Инструменты оценки (PingCastle, Locksmith) покажут рискованные шаблоны в режиме чтения. Для Kerberos включи шифрование AES и отключи RC4 там, где нет зависимости, а пароль служебной учётной записи krbtgt меняй по плану, дважды с интервалом, достаточным для репликации.

Шаг 11. Процесс, а не разовая акция

Укрепление домена нельзя завершить за выходные. Оформи его как план на квартал: первый месяц — привилегированные группы, устаревшие протоколы и аудит, второй — LAPS, политики и модель уровней, третий — резервные копии, проверка восстановления и самооценка. После каждого этапа замеряй результат тем же инструментом оценки, чтобы видеть динамику. Важно согласовывать изменения с владельцами приложений: многие «странные» настройки существуют потому, что от них зависит старая система учёта или принтер. Лучше найти такую зависимость на стадии аудита, чем во время аварии. Назначь ответственного за домен и раз в месяц проводи короткую встречу, где разбираются новые находки, изменения в привилегированных группах и результаты проверок журналов. Так защита становится привычкой команды, а не заданием, которое все откладывают.

Не забывай и про рядовые серверы: srv-web01 и другие узлы, включённые в домен, должны получать те же базовые политики, обновления и аудит. Часто именно забытый файловый сервер на старой версии Windows становится слабым звеном, через которое учётные данные попадают в чужие руки. Составь список всех систем в домене, отметь версию ОС и дату последнего обновления, а устаревшие либо обнови, либо изолируй в отдельный сегмент с жёсткими правилами межсетевого экрана и отдельной учётной записью обслуживания.

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

• Вход администратора домена на рядовые машины. Один вход под Domain Admins на заражённую рабочую станцию — и данные учётной записи могут оказаться доступны чужим. Строго разделяй уровни и используй отдельные учётки.
• Отключить протокол без предварительного аудита. Резкое отключение NTLM или SMBv1 ломает старые принтеры, сканеры и приложения. Сначала включай аудит, составляй список зависимых систем, потом переходи на замены и только затем запрещай.
• Забытые сервисные учётные записи. Пароль в десять лет и права администратора домена «чтобы работало» — классика. Инвентаризируй такие записи, давай минимум прав и переводи на gMSA.

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