Блокировка NTLM и миграция на Kerberos: как безопасно уйти от наследия 90-х
Привет! Меня зовут Семёнов Евгений Сергеевич, я директор ITFresh. Знаете, больше 15 лет я погружён в мир корпоративных AD-инфраструктур, и вот что меня до сих пор удивляет: из последних десяти аудитов у восьми клиентов их контроллеры домена всё ещё обрабатывают Windows NTLMv1. Вдумайтесь только – на дворе 2025 год, это же не 2005-й! NTLM по своей сути – открытая дверь для атак типа pass-the-hash и NTLM-relay. Злоумышленники, кстати, успешно пользуются этим почти в 90% инцидентов, связанных с компрометацией Active Directory. Мы в ITFresh всегда, просто всегда, настаиваем на полной миграции на Kerberos. В этой статье я поделюсь нашим пошаговым планом, как это сделать, и главное – без простоя для вашего бизнеса.
Чем опасен NTLM и зачем его отключать
NTLM появился вместе с Windows NT ещё в середине 90-х. Его задумывали как улучшение для старого LAN Manager. Но даже его «современная» версия, NTLMv2, до сих пор не избавилась от фатальных архитектурных просчётов. Представьте: никакой взаимной аутентификации! Клиент просто не проверяет сервер. Да и защиты от relay-атак нет вовсе, где любой злоумышленник с лёгкостью перехватит challenge-response и затем просто «проиграет» его на другом компьютере. Плюс, используются слабые хэши, да ещё и без «соли», что делает их до ужаса уязвимыми.
Что ж, давайте посмотрим, какие классические атаки на NTLM до сих пор отлично работают в 2025 году:
- Pass-the-Hash — злоумышленник снимает NTLM-хэш из LSASS и логинится на другие машины без знания пароля.
- NTLM Relay — перехватывает аутентификацию с одной машины и пересылает на другую, получая доступ под перехваченной учёткой.
- Kerberoasting на NTLM-путях — если сервис отказывается от Kerberos, сыпется TGS через NTLM и хэши ловятся оффлайн-брутом.
- Downgrade — принудительный откат от Kerberos к NTLM через манипуляции с сетевыми именами.
Kerberos же – совсем другая история. Он даёт всё, что нужно для по-настоящему надёжной защиты: взаимную аутентификацию, MIC (Message Integrity Code), привязку к именам сервисов через SPN и мощное шифрование AES256. Он стал стандартом аутентификации в AD ещё в 2000 году. Так что, согласитесь, давно пора перевести на него абсолютно всё.
Этап 1: Аудит существующего NTLM-трафика
С чего начать? Для начала нам нужно понять, кто вообще в вашей сети продолжает «говорить» на NTLM. Мы предлагаем включить аудит на всех контроллерах домена и рядовых серверах, конечно, через GPO. На нашей практике мы всегда оставляем его активным минимум на 14 дней. Почему так долго? Просто чтобы поймать всё: ежемесячные задачи, резервные копирования и, конечно, те самые квартальные отчёты, которые могут запускаться не каждый день.
# На DC — GPO "NTLM Audit"
Computer Configuration → Policies → Windows Settings → Security Settings →
Local Policies → Security Options:
Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit allПосле применения политики в Event Viewer появляется специальный журнал: Applications and Services Logs → Microsoft → Windows → NTLM → Operational. Ключевые события:
- 8001 — исходящий NTLM-запрос. Видно, с какого клиента, на какой сервер, какая учётка.
- 8002 — входящий NTLM-запрос на сервер.
- 8003 — доменный DC обработал NTLM-запрос. Это главный источник истины на DC.
Мы собираем эти события в Elasticsearch или Graylog. Группируем их по связке client+server+user. В итоге получаем чёткий список всех NTLM-источников. Типичная картина, с которой мы сталкиваемся: от 50 до 200 уникальных источников. И знаете, 80% из них обычно приходятся на три-четыре категории: это либо старые сканеры с SMBv1, либо самописное ПО на VBScript, либо кто-то обращается по IP вместо FQDN, либо, что часто бывает, вложенные скрипты со скрытыми учётками.
Этап 2: Разбор источников и починка SPN
Первая типовая причина NTLM — обращение к серверу по IP-адресу. Kerberos-клиент проверяет SPN вида HOST/server.domain.ru, и если в запросе IP — SPN не находится, тикет не выпускается, клиент откатывается на NTLM. Лечение: фиксируем обращения по DNS-именам.
Вторая причина — отсутствие SPN у сервисной учётки. Например, SQL Server запущен под доменной учёткой svc_sql1c, а SPN MSSQLSvc/sql01.corp.ru:1433 на эту учётку не зарегистрирован. Клиент 1С спрашивает Kerberos-тикет для сервиса, не находит его и падает на NTLM.
# Проверка SPN для учётки
setspn -L svc_sql1c
# Регистрация SPN
setspn -S MSSQLSvc/sql01.corp.ru:1433 CORP\svc_sql1c
setspn -S MSSQLSvc/sql01.corp.ru CORP\svc_sql1c
# Проверка дубликатов SPN — главный враг Kerberos
setspn -X -FДубликаты SPN (когда одно и то же имя сервиса зарегистрировано на двух учётках) — классическая причина отказа Kerberos. setspn -X показывает конфликты, их нужно чистить в обязательном порядке.
Этап 3: Типовые источники NTLM и их лечение
| Источник | Причина | Как починить |
|---|---|---|
| Старые сканеры Kyocera/Ricoh | Scan-to-SMB с SMBv1 и NTLMv1 | Обновить прошивку, включить SMBv2, создать отдельную учётку с Kerberos |
| Самописные скрипты VBS/PowerShell | Обращение по IP или NetBIOS-имени | Переписать с использованием FQDN |
| Приложения с runas /netonly | Принудительный NTLM | Использовать gMSA или CredSSP с Kerberos |
| IIS с Anonymous + NTLM | Дефолтная конфигурация | Включить Negotiate, SPN на app pool identity |
| Сервисные учётки без SPN | Администратор не прописал | setspn -S для всех клиентских подключений |
| Подключение SMB по IP | Fallback на NTLM | Исправить скрипты/GPO, DNS-алиасы |
Этап 4: Исключения для того, что починить нельзя
Конечно, всегда остаются те самые 3–5% трафика, которые просто невозможно «починить». Ну никак. Это может быть какой-нибудь старый робот, самописный контроллер или, например, унаследованный MSSQL 2008. Что делать в таких случаях? В GPO предусмотрены специальные параметры: «Add server exceptions in this domain» и «Add server exceptions for NTLM authentication». Это, считайте, наша последняя линия обороны.
# GPO "NTLM Exceptions"
Network security: Restrict NTLM: Add server exceptions in this domain:
scanner01.corp.ru
scanner02.corp.ru
legacyapp.corp.ru
10.10.5.42 # если действительно нужен IP
# После добавления — делаем аудит ещё неделю, чтобы убедиться,
# что список полныйМы в ITFresh всегда ведём исключения как отдельный GPO-объект. Это очень важно – держать их отдельно от основной политики блокировки. Так при необходимости их гораздо проще отозвать. А главное, сразу видно, кто, когда и зачем это исключение добавил.
Этап 5: Переход в режим «deny audit only»
Дальше включаем режим «отказывать, но только логировать». Это такая промежуточная фаза, своего рода «черновик». Все NTLM-запросы, которые не попали в список исключений, в логах помечаются как «would be blocked», но по факту они пока что всё ещё проходят. Мы обычно держим систему в этом режиме пару недель. За это время чётко видно, какие ещё источники умудрились случайно просочиться и требуют нашего пристального внимания.
Network security: Restrict NTLM: NTLM authentication in this domain
= Deny all except for server exceptions — Audit only
Network security: Restrict NTLM: Incoming NTLM traffic
= Deny all except for server exceptions — Audit onlyЕсли две недели прошли без новых событий «would be blocked», значит, можно переключаться на финальный режим – «Deny». Это уже блокирующая политика: NTLM больше не работает. Всё, что не Kerberos, получает отказ.
Мини-кейс: миграция для юридической фирмы, 120 РМ
В марте 2026 года к нам за помощью обратилась одна юридическая фирма прямо из центра Москвы. У них было два контроллера домена на Windows Server 2019, 120 рабочих мест, плюс полный набор: файловый сервер, 1С, MSSQL и Exchange 2016. Основная задача была очень конкретной: подготовиться к проверке регулятора и полностью закрыть все NTLM-подключения. Срок, между прочим, у нас был всего два месяца.
Что же мы сделали? В первую и вторую неделю включили аудит и собрали целых 43 000 событий NTLM. Когда сгруппировали их, выявили 18 уникальных источников. Среди них, кстати, были 4 сканера Kyocera, 7 самописных скриптов планировщика, 3 службы 1С, пара старых серверов с MSSQL 2012. Ну и, конечно, не обошлось без нескольких подключений удалёнщиков через неправильно настроенный VPN.
На 3–4 неделе зарегистрировали SPN для MSSQL и 1С (это 5 записей), переписали 7 скриптов с IP-адресов на FQDN, обновили прошивки у трёх из четырёх сканеров. Четвёртый, увы, не обновлялся – его пришлось занести в список исключений.
Пятая неделя: включили «Audit only deny». И что вы думаете? Поймали ещё 3 источника! Это оказались неочевидные скрипты на Linux-машинах, использующих samba-клиент. Конечно, мы их починили.
И вот, шестая неделя – мы перешли к финальному режиму «Deny all». В первые 2 часа получили всего 4 обращения в саппорт. Все они были решены быстрой консультацией по правильному URL. Кстати, наш контроллер домена с Dell Xeon Platinum 8280 обрабатывает входящие тикеты Kerberos на порядок быстрее, чем раньше NTLM-хэши. А что по стоимости? Весь комплекс работ обошёлся в 180 000 рублей за 6 недель полного сопровождения.
Подводные камни и как их обойти
За годы в ITFresh мы сталкивались с самыми разными проектами. И знаете что? Накопился целый список «граблей», на которые почему-то вечно наступают! Делимся, чтобы вы их обошли.
- NTLM на трастах между доменами. При наличии лес-траста NTLM может идти по межлесовым запросам. Нужно настраивать Selective Authentication и разрешать Kerberos-through-trust.
- UPN suffix не совпадает с FQDN. Kerberos ищет SPN по FQDN из UPN, при несоответствии ломается.
- Machine account password более 30 дней. У локальных учёток компьютеров пароль меняется автоматически, но если машина долго не в сети — password mismatch, Kerberos не работает.
- Использование NetBIOS-имён. NetBIOS даёт короткое имя без домена, SPN не находится. Лечится запретом использования NetBIOS в корпоративной сети и переходом на полные имена.
- Старые принтеры с NTLMv1. В сети это последний источник, не отдаёт NTLMv2. Либо меняем на современное железо, либо заносим в исключения и ограничиваем VLAN.
- LmCompatibilityLevel на клиентах. Убедитесь, что на всех ПК уровень 5 (Send NTLMv2 only, refuse LM and NTLMv1).
Мониторинг после миграции
Миграция закончилась? Поздравляем! Но расслабляться, к сожалению, ещё рано. Мы в ITFresh всегда используем continuous-аудит по NTLM прямо в SIEM-системе. Зачем? Это наш страховой полис от любых попыток downgrade-атак, который даёт полную уверенность в вашей безопасности.
- Любое событие 8001/8002 на доменных контроллерах? Мы получаем моментальный алерт! И каждую неделю наши специалисты внимательно проверяют и дотошно разбираются с каждым таким случаем. Ничего не остаётся незамеченным.
- У нас есть отдельный, очень важный дашборд. На нём график «NTLM attempts over time». Когда эта линия стремится и падает до нуля? Это наш сигнал: все настройки работают как часы, и миграция прошла успешно!
- Когда нужно добавить запись в исключения, мы не просто её добавляем. Любое такое изменение тщательно фиксируется и обязательно проходит через согласование с IT-отделом. Это помогает нам сохранять порядок и контролировать безопасность на каждом шагу.
- А что насчёт устаревших исключений? Каждый квартал мы проводим их тотальный пересмотр. Проверяем всё: ушло ли старое "железо", обновилось ли необходимое ПО. Можно ли, наконец, убрать какую-то запись, которая давно неактуальна? Это помогает поддерживать систему в чистоте и порядке.
Поможем уйти от NTLM без простоя бизнеса
Я готов провести полный аудит вашего NTLM-трафика, найти все проблемные источники, поправить SPN и скрипты, настроить GPO и, конечно, проконтролировать всю миграцию до финального Deny-режима. Я работаю с офисами от 50 рабочих мест, а срок выполнения работ обычно составляет от 4 до 8 недель, в зависимости от сложности вашей инфраструктуры.
Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш
FAQ — частые вопросы по миграции NTLM → Kerberos
- Чем плох NTLM в 2025 году?
- NTLM уязвим к pass-the-hash и relay-атакам, не поддерживает взаимную аутентификацию, использует устаревшие алгоритмы. Microsoft официально рекомендует отключать NTLM и переходить на Kerberos, где возможно.
- Можно ли полностью отключить NTLM в среднем офисе?
- Да, но после тщательного аудита. Обычно 95% трафика можно увести в Kerberos, а оставшиеся 5% (старое ПО, подключения по IP, сканеры документов) — занести в список исключений политики «Add server exceptions».
- Сколько времени занимает миграция?
- В среднем офисе на 100–200 ПК — от 2 до 6 недель. Две недели на сбор аудита, 1–2 недели на исправление SPN и настройку исключений, неделя на блокировку в режиме «audit» и ещё неделя на финальный «deny».
- Что такое SPN и зачем он нужен?
- Service Principal Name — уникальное имя сервиса в AD, привязанное к учётной записи компьютера или сервисной учётки. Без корректного SPN клиент не сможет получить Kerberos-тикет и упадёт на NTLM, что нам нежелательно.
- Как включить аудит NTLM?
- Через GPO «Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM». Три параметра: Audit Incoming, Audit NTLM authentication, Audit Outgoing NTLM. Логи появляются в Event Viewer → Applications and Services → Microsoft → Windows → NTLM.