Відключення застарілих протоколів (NTLMv1, LLMNR): що ламається і як замінити

Що ви насправді виправляєте (модель загроз, не емоції)

Відключення NTLMv1 і LLMNR — це не стільки про «сучасність», скільки про припинення двох класів ризиків:
(1) слабка або відтворювана аутентифікація, і (2) поведінка вирішення імен, що дозволяє атакуючим вбудовуватися в ваш трафік.

NTLMv1: слабкий challenge/response, застарілі за промовчанням налаштування і довгий хвіст «воно ж працює»

NTLM — це сімейство протоколів аутентифікації Windows. NTLMv1 — найстаріша і найслабша форма, яку ще бачать у реальних підприємствах.
Проблема не тільки в криптографічній силі; проблема в тому, наскільки легко NTLM-трафік змусити, ретейлити або знижувати версію, коли у вас змішані клієнти і лояльні політики.

Коли дозволено NTLMv1, ви створюєте м’яку посадкову смугу для старих клієнтів і неправильно налаштованих додатків. Частина з цих «додатків»
— це насправді планові завдання, принтери, NAS-пристрої й загадкові сервіси, встановлені в 2014 році і ніколи не чіпані, бо «воно ж працює».

LLMNR: корисний у малих мережах, небезпечний у реальних

LLMNR (Link-Local Multicast Name Resolution) — те, що машини роблять, коли DNS не спрацьовує або не налаштований правильно, але їм потрібно розв’язати fileserver чи printer-7.
Він використовує мультикаст на локальному сегменті. Зручно. Але це також подарунок для тих, хто запускає інструменти типу responder в тій же мережі.

Якщо ви відключите LLMNR, але залишите DNS у безладі, користувачі скаржитимуться, що «мережа зламалась». Мережа не була зламана.
Вона імпровізувала.

Одна правило надійності діє тут жорстко: зробіть вирішення імен детерміністичним, а аутентифікацію — суворою. Все інше — театральна частина.

Одна цитата, переказана ідея: думка Джина Кранца (парафраз): «Будь суворий і компетентний» — системи не слухають відмовок, лише результат.

Жарт #1: Відключення NTLMv1 — як прибирати горище: знайдете багато старого мотлоху і принаймні одну річ, що шипить.

Цікаві факти та історія для нарад

• NTLM старіший за вашу хмарну стратегію. NTLM бере свій початок у проєктах Windows NT; Kerberos з’явився з Active Directory як заміна для доменної автентифікації.
• NTLMv1 використовує старі конструкції на базі DES. Це одна з причин, чому його вважають суттєво слабшим за NTLMv2, особливо у сценаріях перехоплення й розшифровки.
• NTLM зберігається через «це просто SMB-автентифікація». Багато думають, що NTLM стосується лише файлових шарів. Він з’являється в HTTP, LDAP-bind, RPC і в дивних куточках.
• LLMNR задумувався, щоб зменшити залежність від DNS у малих мережах. Це фактично «поведінка, як DNS» без адміністративного навантаження, і саме тому він стає костилем.
• LLMNR часто йде в парі з NBT-NS. На Windows-мережах відключення одного, але залишення іншого, все ще дозволяє отруєння імен і спроби захоплення облікових даних.
• Атаки на примус облікових даних люблять мультикаст. Коли кінцеві точки питають «who is FILESERVER?», атакуючий може відповісти швидше за реальний сервер і спровокувати аутентифікацію.
• Kerberos може «ламається» через нудні причини. Зриви часу, помилки SPN і помилки DNS можуть змусити клієнтів переключитися на NTLM-шлях, якщо ви не закриєте цю можливість.
• Хардення ламало речі задовго до того, як з’явилась «Zero Trust». Більшість відмов при відключенні застарілої аутентифікації походять від не виявлених залежностей, а не від самої зміни протоколу.

Що ламається при відключенні NTLMv1 і LLMNR

Коли ви відключаєте NTLMv1: що насправді перестає працювати

«Відключити NTLMv1» звучить просто, доки ви не усвідомите, що більшість середовищ не мають «клієнтів тільки NTLMv1». Вони мають
кілька пристроїв і сервісів, що все ще обговорюють пониження версії, часто тихо. Типові режими зламу:

• Старі NAS і прилади, приєднані до AD: деякі вбудовані SMB-стеки все ще пробують NTLMv1 або некоректно підтримують підпис/шифрування.
  Симптом: повторні запити аутентифікації або «The specified network password is not correct.»
• Застарілі сканери/принтери з функцією «сканувати в папку»: вони часто зберігають облікові дані і намагаються аутентифікуватися SMB за старими діалектами.
  Симптом: скани перестають приходити; у інтерфейсі пристрою — «login failed».
• Кастомні додатки, що використовують старі бібліотеки: особливо ті, що роблять інтегровану автентифікацію через HTTP до IIS або зворотних проксі.
  Симптом: цикли 401, відкат аутентифікації або додаток тихо переходить на «локальні облікові записи».
• Старі версії Windows або неправильно налаштовані політики безпеки: деякі кінцеві точки будуть погано домовлятися про протокол, якщо політики непослідовні.
  Симптом: раптові сплески дзвінків у службу підтримки після зміни GPO, що впливають на підмножину машин.
• Службові облікові записи без потрібних SPN: якщо Kerberos недоступний, клієнти можуть спробувати NTLM; якщо ви надто агресивно блокуєте сімейство NTLM, сервіс виглядає недоступним.
  Симптом: «server not available», але тільки для доменних користувачів.

Коли ви відключаєте LLMNR: що насправді перестає працювати

LLMNR більше про «люди перестають знаходити речі за відчуттями», ніж про «злам автентифікації».
Конкретно — все, що покладалося на короткі імена, односегментні імена хостів або застарілий DNS.

• Користувачі, що підключають мережеві диски за короткими іменами: \\fileserver\share працювало, поки DNS був хибним і LLMNR рятував ситуацію.
• RDP до коротких імен хостів: люди вводять rdp fileserver і воно «працювало» завдяки мультикасту або cached junk.
• Скрипти, що використовують некваліфіковані імена: автоматизація, що припускає локальне бродкаст-резолвінг, тепер швидко падає.
• Багатопідмережні середовища: LLMNR не переходить через маршрутизатори так, як DNS. Якщо він «допомагав», у вас вже була ширша проблема з дизайном DNS.

Вимкнення LLMNR не створює базової помилки. Воно робить її видимою. Це тип поломки, який ви хочете в продакшені:
зламане припущення, а не зламаний протокол.

Чим замінити (робочі альтернативи)

Замініть NTLMv1 на: перш за все Kerberos, NTLMv2 як контрольований fallback

Практична ціль — не «ніколи NTLM» у перший день. Це:

1. Вбити NTLMv1 скрізь, де можете.
2. Вимагати NTLMv2 там, де NTLM ще існує.
3. Сприяти впровадженню Kerberos через виправлення DNS, SPN і синхронізації часу.
4. Обмежувати та моніторити NTLM за допомогою аудиту, білого списку та поступового блокування.

Якщо ваше середовище підтримується AD і ви не можете зробити Kerberos надійним, у вас не проблема «протокол аутентифікації».
У вас проблема з фундаментами: правильністю DNS, часом і гігієною ідентичностей.

Замініть LLMNR на: правильний DNS і коректну поведінку клієнтів

LLMNR існує, бо DNS часто не викликає довіри у кінцевих точок. Тому заміна нудна:

• Точні DNS A/AAAA записи для серверів і приладів.
• Послідовні пошукові суфікси через DHCP або GPO, щоб односегментні імена вирішувалися передбачувано (або взагалі не вирішувалися).
• Перестаньте використовувати односегментні імена у скриптах і інструкціях; використовуйте FQDN.
• Вимикайте LLMNR і NBT-NS разом, де можливо, і вимірюйте наслідки.

Контрзаходи безпеки, що полегшать перехід

• SMB-підписування там, де можливо, особливо для адміністративних шарів і сервер-серверного доступу.
• LDAP-підписування/канальне бандування щоб відрізати шляхи пониження версії і реле, що часто супроводжують зловживання NTLM.
• Сегментація фаєрволом щоб випадкові кінцеві точки не могли говорити з випадковими кінцевими точками по SMB/HTTP/RPC і «допомагати» аутентифікації.
• Credential Guard / захист LSA на кінцевих точках, щоб зменшити витік матеріалів облікових даних.

Жарт #2: LLMNR — як запитати в переповненій кімнаті, хто ваш друг, а потім віддати гаманець першому, хто відповість.

Швидкий playbook діагностики (перші/другі/треті перевірки)

Ви відключили NTLMv1 або LLMNR і тепер щось ламається. Не починайте з відкату політики «аби запустити понеділок».
Почніть з доведення, що саме зламалося і де живе залежність. Ось найшвидший шлях.

Перше: визначте, чи це вирішення імен або автентифікація

• Чи клієнт може розв’язати сервер через DNS? Якщо ні — раніше це підлатував LLMNR/NBT-NS.
• Чи клієнт може дістатись до сервера на очікуваному порту? Якщо ні — це маршрутизація/фаєрвол, а не автентифікація.
• Чи помилка «access denied» чи «host not found»? Це чітко розділяє проблему.

Друге: визначте, який протокол автентифікації було спробовано

• Kerberos чи NTLM? Перевірте події захисту Windows, логи серверів або захоплення пакетів на тестовій машині.
• NTLMv1 чи NTLMv2? Якщо ви все ще дозволяєте NTLMv2, єдиною причиною поломки мають бути справді прадавні клієнти або некоректна домовленість.

Третє: знайдіть залежність і оберіть заміну

• Якщо це прилад, перевірте прошивку/налаштування SMB і чи підтримує він NTLMv2 або Kerberos.
• Якщо це додаток, перевірте, чи може він використовувати Kerberos/Negotiate, сучасні бібліотеки або SPN.
• Якщо це звичка користувача, виправте інструкції та скрипти і змусьте використовувати FQDN.

«Вузьке місце» в таких інцидентах рідко CPU чи мережа. Це неоднозначність: невизначене вирішення імен і тихий відкат протоколу автентифікації.
Ваше завдання — прибрати неоднозначність.

Практичні задачі: команди, виводи й рішення

Нижче наведені практичні задачі, які ви можете виконати з Linux-адмінхоста (або VM для розслідування), що в тій самій мережі і має доступ до сервісів AD.
Деякі завдання також перевіряють поведінку Windows через інструменти Samba. Для нативних команд Windows зазвичай використовують PowerShell;
тут ми фокусуємося на командах, які реально можна виконати з shell у режимі інциденту.

Задача 1 — Виявити LLMNR у мережі (чи клієнти ще «кричать»?)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:31:02.114890 IP 10.20.1.45.56724 > 224.0.0.252.5355: UDP, length 62
12:31:02.114932 IP 10.20.1.71.57811 > 224.0.0.252.5355: UDP, length 62
5 packets captured

Що це означає: Ви бачите LLMNR-мультикаст (224.0.0.252:5355). Клієнти все ще намагаються його використовувати.

Рішення: Якщо ви планували вимкнути LLMNR, перевірте область дії GPO/MDM; також упевніться в коректності DNS, щоб клієнти припинили потребувати його.

Задача 2 — Виявити NBT-NS (інший вектор отруєння імен)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 137 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:32:19.901220 IP 10.20.1.45.137 > 10.20.1.255.137: NBT UDP PACKET(137): QUERY; REQUEST; name="FILESERVER<00>"
5 packets captured

Що це означає: Широковещальні запити NetBIOS Name Service ще в грі.

Рішення: Плануйте відключити NetBIOS over TCP/IP де можливо, або ізолювати його за допомогою сегментації. Відключення тільки LLMNR — не повна історія.

Задача 3 — Перевірити, чи DNS може розв’язати хост, який користувачі вводять

cr0x@server:~$ getent hosts fileserver

Що це означає: Відсутній вивід зазвичай означає, що ім’я не розв’язується через налаштовані резолвери/пошукові домени.

Рішення: Виправте DNS-записи і/або конфігурацію пошукових суфіксів. Якщо ви хочете заборонити односегментні імена, змусьте скрипти використовувати FQDN і впровадьте це культурно.

Задача 4 — Перевірити DNS через конкретний резолвер (припиніть здогадки)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example A +noall +answer
fileserver.corp.example. 300 IN A 10.20.5.20

Що це означає: DNS знає відповідь і TTL — адекватний.

Рішення: Якщо DNS правильний, але клієнти все ще використовують LLMNR, перевірте список DNS-суфіксів на клієнтах і чи вони звертаються до правильних DNS-серверів.

Задача 5 — Перевірити зворотний DNS (корисно для Kerberos і логування)

cr0x@server:~$ dig @10.20.0.10 -x 10.20.5.20 +noall +answer
20.5.20.10.in-addr.arpa. 300 IN PTR fileserver.corp.example.

Що це означає: PTR існує. Це допомагає з аудитами, деяким інструментам і зменшує операційні болі через «незрозумілі IP».

Рішення: Відсутність зворотного DNS не завжди зламає Kerberos, але ускладнить швидку діагностику. Виправте все одно.

Задача 6 — Перевірити синхронізацію часу на Linux (бо Kerberos не любить подорожей у часі)

cr0x@server:~$ timedatectl status
               Local time: Tue 2026-02-05 12:35:10 UTC
           Universal time: Tue 2026-02-05 12:35:10 UTC
                 RTC time: Tue 2026-02-05 12:35:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Час синхронізовано. Добре.

Рішення: Якщо автентифікація загадково не працює, перевірте час на клієнтах, серверах і контролерах домену. Виправте зсув часу перед тим, як звинувачувати Kerberos.

Задача 7 — Отримати Kerberos-квиток для доменного користувача (доказ роботи шляху Kerberos)

cr0x@server:~$ kinit user1@CORP.EXAMPLE
Password for user1@CORP.EXAMPLE:

Що це означає: Якщо команда повернулась до промпту без помилки, ви отримали TGT.

Рішення: Якщо це не вдається, перевірте DNS до KDC, зсув часу, конфігурацію realm і фаєрволи до DC, перш ніж чіпати політики NTLM.

Задача 8 — Подивитись кеш квитків (підтвердити realm/KDC)

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user1@CORP.EXAMPLE

Valid starting     Expires            Service principal
02/05/26 12:36:20  02/05/26 22:36:20  krbtgt/CORP.EXAMPLE@CORP.EXAMPLE

Що це означає: У вас є TGT; базовий Kerberos працює.

Рішення: Якщо клієнти все ще використовують NTLM, проблема, ймовірно, у конфігурації SPN/сервісу, а не в «Kerberos впав».

Задача 9 — Перевірити доступ до CIFS-сервісу через Kerberos (SMB з Kerberos)

cr0x@server:~$ smbclient -k -L //fileserver.corp.example -m SMB3
Anonymous login successful

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share
SMB1 disabled -- no workgroup available

Що це означає: Параметр -k використовує Kerberos. Побачити шари означає, що аутентифікація Kerberos пройшла (незважаючи на збиваючу стрічку «Anonymous login successful», яку smbclient інколи друкує).

Рішення: Якщо Kerberos працює з тестового хоста, але Windows-клієнти відкотяться на NTLM, перевірте SPN і як клієнти розв’язують ім’я сервера.

Задача 10 — Примусово увімкнути NTLMSSP у smbclient (щоб довести, що NTLM ще використовується десь)

cr0x@server:~$ smbclient -U 'CORP\user1' -L //fileserver.corp.example -m SMB3 --option='client use spnego=no'
Password for [CORP\user1]:

	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	share           Disk      Team share

Що це означає: Ви щойно аутентифікувалися з використанням NTLMSSP (сім’я NTLM). Чи було узгоджено v1 чи v2 — залежить від політики клієнта/сервера.

Рішення: Якщо вимкнення NTLMv1 ламає це, у вас проблема зі старою домовленістю — часто старий прилад або серверний параметр.

Задача 11 — Перелічити підтримку діалектів SMB (знайти пастки SMB1)

cr0x@server:~$ smbclient -L //fileserver.corp.example -m SMB1
protocol negotiation failed: NT_STATUS_INVALID_NETWORK_RESPONSE

Що це означає: SMB1 не підтримується/відключений на сервері (добре). Багато утримувачів NTLMv1 корелюють із пристроями епохи SMB1.

Рішення: Якщо ваш прилад підтримує лише SMB1 — не «робіть виняток». Замініть або ізолюйте його. Винятки стають постійними.

Задача 12 — Просканувати на LLMNR-репондери (хочете нуль)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 5355 -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:40:11.004321 IP 10.20.1.45.5355 > 224.0.0.252.5355: 1234+ A? wpad. (34)
12:40:11.006002 IP 10.20.1.200.5355 > 10.20.1.45.5355: 1234* 1/0/0 A 10.20.1.200 (50)

Що це означає: Хост (10.20.1.200) відповів на LLMNR-запит для wpad. Це або помилка конфігурації, або активний ризик отруєння.

Рішення: Негайно ідентифікуйте цей хост. Якщо він не санкціонований резолвер — ізолюйте і розслідуйте. Також: виправте DNS, щоб клієнти не питали мультикаст про WPAD.

Задача 13 — Перевірити, чи WPAD розв’язується через DNS (уникнути драми з автопошуком проксі)

cr0x@server:~$ dig @10.20.0.10 wpad.corp.example A +noall +answer

Що це означає: Запису DNS немає. Якщо у клієнтів включено автопошук проксі, вони можуть спробувати LLMNR/NBT-NS для WPAD.

Рішення: Або правильно реалізуйте WPAD з суворим контролем, або явно відключіть автопошук проксі. Не лишайте в напівстані.

Задача 14 — Швидка перевірка доступності порту до контролера домену (коли невірні фаєрволи видаються за проблеми автентифікації)

cr0x@server:~$ nc -vz dc1.corp.example 88
Connection to dc1.corp.example 88 port [tcp/kerberos] succeeded!

Що це означає: TCP/88 для Kerberos доступний. (UDP також важливий, але це швидкий індикатор.)

Рішення: Якщо це не проходить з певних підмереж, у вас проблеми сегментації. Виправте маршрути/фаєрволи перед тим, як звинувачувати зміни NTLM.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія вирішила «просто відключити NTLMv1», бо сканер безпеки виявив це. Команда IAM застосувала GPO,
орієнтовану на «All Workstations», і надіслала привітальне повідомлення про досягнення.

У понеділок вранці операційники не могли дістатись до набору файлових шарів, що використовувалися виробничою лінією. Не всі — лише кіоски на цеховій підлозі.
Служба підтримки ставилась до цього як до простої аварії і почала перезавантажувати все, що має кнопку живлення. Це не була діагностика; це був ритуал.

Неправильне припущення: «Ці кіоски — Windows 10, отже вони мають використовувати NTLMv2 або Kerberos». Вони були Windows 10,
але реальна залежність була в десятирічному NAS, приєднаному до домену давно. Він підтримував NTLM, але його SMB-стек погоджувався на пониження у спосіб, який команда ніколи не тестувала. Кіоски не були проблемою. Сервер був.

Коли NAS ідентифікували, рішення було жорстко простим: перемістити шари на підтримуваний файловий сервер, а NAS ізолювати для архівного доступу. Справжній урок — не «не відключайте NTLMv1». А «не дозволяйте продакшен залежати від пристроїв, які не можна патчити й не можна контролювати».

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація хотіла зменшити обсяг логів і «шум» у SIEM. Вони відфільтрували набір подій автентифікації, бо «це все нормальні Windows-розмови». Це сталося прямо перед проєктом відключення LLMNR.

Після відключення LLMNR частина користувачів почала бачити періодичні запити логіну при доступі до внутрішніх веб-додатків.
Команда підозрювала нову політику, потім балансувальник навантаження, потім IdP. Вони витратили два дні, стрибаючи між командами,
бо логи, які б довели пониження протоколу автентифікації, тепер були відфільтровані.

Наслідок: оптимізувавши «шум» телеметрії автентифікації, вони ускладнили та затягнули root-cause аналіз і зробили його політичним.
Зрештою пакетний захоплення показав, що клієнти не розв’язують правильну адресу бекенду через DNS, потім пробують шляхі fallback.
NTLM виконувався через застаріле ім’я хосту, і відключення LLMNR просто прибрало випадкові успіхи.

Виправлення були нудними: коректні DNS-записи, примус FQDN в конфігах додатків і відновлення подій безпеки — цього разу зі смарт-парсингом і алертами, а не грубим придушенням. Операційний висновок: якщо ви змінюєте поведінку автентифікації, зберігайте логи автентифікації.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Велике підприємство зробило все неефектно, але правильно. Перед змінами GPO вони тижнями запускали аудит NTLM і маркували кожну подію джерелом клієнта, цільовим сервером і власником додатка. Створили простий робочий процес: «Якщо ви володієте ціллю — ви відповідаєте за виправлення».

Вони також мали тестовий OU, що відтворював політики продакшену. Кожна кандидатна зміна — відключення LLMNR, вимога NTLMv2, обмеження NTLM — застосовувалась там спочатку. Вони проганяли ключові бізнес-додатки в цьому OU на день кожен, з можливістю відкату. Це не було гламурно. Але працювало.

Коли вони нарешті відключили NTLMv1 широко, єдиними відмовами були попередньо ідентифіковані: кілька сканерів, старий Java-додаток і один пристрій вендора. У них були плани ремедіацій: оновлення прошивки, міграція на SFTP і ескалація до постачальника з жорстким дедлайном.

Практика, що їх врятувала: суворий change management з інструментами спостереження, а не лише паперовою роботою. Вони не «сподівалися», що ніхто не залежить від NTLMv1. Вони зібрали докази, а потім зробили зміну. Надійність інколи виглядає як наполегливість у вимірюванні.

Типові помилки (симптоми → корінь → виправлення)

1) «Користувачі не можуть отримати доступ до шарів» після відключення NTLMv1

Симптоми: повторні запити облікових даних; «access denied»; деякі клієнти працюють, інші — ні.

Корінь: пристрій зберігання або старий сервер погоджуються на NTLMv1 або мають поведінку епохи SMB1; Kerberos не використовується через проблеми SPN/DNS.

Виправлення: підтвердіть, що Kerberos працює для CIFS SPN-імені; виправте DNS/FQDN-використання; оновіть/мігруйте прилад; тимчасово вимагайте NTLMv2 як крок переходу.

2) «Відключення LLMNR зламало все» (ні; ваш DNS був проблемою)

Симптоми: короткі імена перестали розв’язуватись; мапінги дисків падають; скрипти не працюють в одній підмережі.

Корінь: відсутні DNS-записи, неправильні DNS-сервери в DHCP, відсутні пошукові суфікси або залежність від односегментних імен.

Виправлення: виправте A/PTR записи; упевніться, що DHCP штовхає правильні DNS і суфікси; оновіть скрипти на FQDN; прибирайте залежність від широковествальних резолюцій.

3) «Kerberos нестабільний, тож нам потрібен NTLM»

Симптоми: періодичні помилки автентифікації; працює після перезавантаження; працює для деяких користувачів.

Корінь: зсув часу; колізії SPN; клієнти розв’язують імена, що відрізняються від очікуваного в SPN; неправильні налаштування обмеженого делегування.

Виправлення: вимагайте NTP; аудит SPN; уніфікуйте імена хостів і сертифікати; ставтеся до DNS як до критичного продакшен-елемента, а не «роботи мережі».

4) «Ми заблокували NTLM і тепер додаток не працює»

Симптоми: внутрішній веб-додаток повертає 401; цикли аутентифікації; виклики сервісів між серверами падають.

Корінь: identity пул облікового запису/SPN не налаштований; додаток явно використовує NTLM замість Negotiate; проксі/балансувальник ламає Kerberos.

Виправлення: налаштуйте SPN для сервісного облікового запису; упевніться, що клієнти використовують правильний FQDN; перевірте вимоги делегування; за потреби тимчасово лиште NTLMv2, але обмежте його.

5) «Ми вимкнули LLMNR, але Responder все ще ловить щось у тесті»

Симптоми: мультикаст/броадкаст-трафік імен все ще присутній; запити облікових даних викликаються фальшивими іменами.

Корінь: NBT-NS ще увімкнений; WPAD/автопошук проксі активний; інші протоколи виявлення ще працюють.

Виправлення: відключіть NBT-NS де можливо; контролюйте WPAD; сегментуйте мережі; зменшіть можливості латерального доступу (SMB/RPC) між клієнтами.

Чеклісти / покроковий план

Фаза 0 — Зробіть середовище видимим (не міняйте те, чого не бачите)

1. Увімкніть і централізуйте телеметрію автентифікації (використання NTLM, відмови, fallback-и).
2. Почніть збирати зразки трафіку LLMNR/NBT-NS по VLAN, щоб зрозуміти, де це використовується.
3. Складіть інвентар: файлові сервери, NAS, принтери/сканери, сервери додатків, балансувальники, контролери домену.
4. Визначте «не-людські» шляхи доступу: сервісні облікові записи, заплановані завдання, облікові дані, збережені в пристроях.

Фаза 1 — Виправте DNS, щоб LLMNR став неактуальним

1. Переконайтеся, що кожен сервер має коректні A/AAAA та PTR записи.
2. Уніфікуйте розповсюдження пошукових суфіксів (DHCP/GPO) і перевірте, що клієнти їх отримують.
3. Оновіть мапінги дисків, скрипти і рукописи на використання FQDN.
4. Визначте політику щодо односегментних імен: відмовляти чи суворо забороняти в інструментах.

Фаза 2 — Вимкніть LLMNR (і бажано NBT-NS) у контрольованому обсязі

1. Застосуйте GPO/MDM спочатку до пілотного OU (IT, power users, репрезентативний бізнес-підрозділ).
2. Слідкуйте за інцидентами з вирішенням імен; коли вони виникають — виправляйте DNS, а не політику.
3. Розширюйте охоплення VLAN за VLAN або сайт за сайтом.

Фаза 3 — Видаліть NTLMv1 і посиліть NTLMv2

1. Налаштуйте клієнти й сервери відмовляти NTLMv1; вимагайте NTLMv2 там, де NTLM лишається.
2. Виправте блокатори Kerberos: синхронізація часу, SPN, гігієна сервісних облікових записів, коректність DNS.
3. Оновіть або замініть прилади, які не підтримують NTLMv2 або Kerberos.
4. Тримайте реєстр винятків з датами закінчення. Якщо в нього немає дати закінчення — це не виняток, а політика.

Фаза 4 — Обмежте або усуньте NTLM (опціонально, але бажаний фінал)

1. Блокуйте NTLM спочатку для високовартісних серверів (контролери домену, адміністративні точки, management planes).
2. Використовуйте білосписки для неминучих застарілих залежностей, а потім поступово їх зменшуйте.
3. Підтверджуйте, що всі нові додатки і постачальники підтримують Kerberos або сучасні моделі автентифікації.

FAQ

1) Якщо ми відключимо NTLMv1, чи отримаємо ми автоматично Kerberos у всіх місцях?

Ні. Ви отримаєте відмови там, де Kerberos не може використовуватися (проблеми SPN/DNS/час) і там, де клієнти/прилади знають лише NTLMv1.
Перевага — ви змушуєте ці проблеми стати видимими, щоб ви могли їх вирішити.

2) Чи достатньо відключити LLMNR, чи треба ще й NBT-NS?

Якщо ви хочете зменшити отруєння імен і атаки типу responder, зазвичай потрібно обидва. LLMNR і NBT-NS — родичі.
Відключення тільки одного часто лишає альтернативний шлях.

3) Чому раніше все «працювало», якщо DNS був хибним?

Бо мультикаст/броадкаст резолюція і кеші створювали випадковий успіх. Це як система, що «працює», бо повтори ховають баг.
Ви не маєте надійності; у вас є везіння.

4) Який порядок безпечніший: відключити LLMNR спочатку чи NTLMv1 спочатку?

Зазвичай: виправте DNS → відключіть LLMNR/NBT-NS → потім видаляйте NTLMv1. Зміни LLMNR здебільшого стосуються вирішення імен і звичок користувачів.
Зміни NTLMv1 можуть різкіше порушити пристрої й потоки автентифікації.

5) У нас є принтери/сканери, що не підтримують Kerberos. Який найменш поганий варіант?

Віддавайте перевагу пристроям, що підтримують сучасний SMB і принаймні NTLMv2, або змініть робочий процес: сканувати на email, SFTP, HTTPS-завантаження
або через брокер-сервіс. Якщо мусите тримати застарілий SMB — ізолюйте його в окремому VLAN і обмежте, до яких серверів він може підключатися.

6) Чи замінює SMB-підписування необхідність відключити NTLMv1?

Ні. SMB-підписування допомагає запобігти певним підтасовкам і деяким сценаріям реле, але не підніме слабку автентифікацію до сильного рівня.
NTLMv1 все одно варто видалити, а ідеально — використовувати Kerberos для доступу в домені.

7) Як уникнути потоку звернень до helpdesk при відключенні LLMNR?

Попередньо виправте DNS для найчастіше використовуваних сервісів (файлові сервери, принт-сервери, внутрішні сайти), поширте суфікси пошуку послідовно,
і оновіть GPO/скрипти мапінгів дисків на FQDN. Також: повідомте про нове правило «використовувати FQDN» в IT-документації.

8) Який явний знак, що Kerberos не використовується?

Повторні підказки логіну, події сервера, пов’язані з NTLM, і автентифікація, що вдається лише при використанні IP-адреси або короткого імені.
Kerberos чутливий до імен. Якщо ви заходите до сервісу за іменем, що не відповідає його SPN, Kerberos не спрацює.

9) Чи можемо ми просто відразу заблокувати весь NTLM?

Можете, якщо вам подобається незапланований простій і термінові «тимчасові» винятки. Поетапний підхід з аудитом і таргетованим блокуванням
доведе вас до тієї ж мети без підпалу операцій.

Наступні кроки, що не зіпсують вихідні

Якщо ви хочете практичний, бездрамний план, робіть це за порядком:

1. Виміряйте поточний стан: збирайте трафік LLMNR/NBT-NS; аудит використання NTLM; складіть список топ-говорців.
2. Виправте DNS: A/PTR записи, суфікси, і використання FQDN у конфігах і скриптах.
3. Пілово вимкніть LLMNR (і бажано NBT-NS): малий обсяг, швидкий фідбек, виправляйте корінні причини.
4. Вимкніть NTLMv1: вимагайте NTLMv2; мігруйте або ізолюйте пристрої, що не можуть відповідати.
5. Зробіть винятки дорогими: кожен виняток має власника, причину і дату закінчення.
6. Зберігайте логи автентифікації: не «оптимізуйте» телеметрію, що показує, чи покращується стан вашого середовища.

Кінцевий стан простий: кінцеві точки розв’язують імена через DNS, аутентифікуються через Kerberos і відкатуються на NTLMv2 тільки там, де ви явно дозволили.
Все інше — спадкова інерція. Позбувайтеся її акуратно.