Как отключить llmnr windows 10

Обновлено: 01.07.2024

Служба LLMNR (Link-Local Multicast Name Resolution) позволяет организовать одноранговое разрешение имен в пределах одной подсети для IPv4, IPv6 или обоих видов адресов сразу без обращения к серверам, на что не способны ни DNS, ни WINS. WINS предоставляет как клиент-серверную, так и одноранговую службу разрешения имен, но не поддерживает адреса IPv6. DNS, с другой стороны, поддерживает оба тина адресов, но требует Наличия серверов.

Разрешение имен LLMNR, поддерживаемое как в Windows Vista, так и в Windows Server 2008, работает для адресов IPv6 и IPv4 в тех случаях, когда другие службы разрешения имен недоступны, например, в домашних сетях, в небольших предприятиях, во временных сетях или 15 корпоративных сетях, где по каким-то причинам недоступны DNS-службы.

LLMNR призвана дополнить DNS, обеспечивая разрешение имен в случаях, когда обычное DNS-разрешеиие невозможно. Если у вас нет необходимости в NetBIOS, LLMNR может полностью заменить WINS. Полностью заменить DNS не получится, поскольку LLMNR работает только в локальной подсети. Поскольку трафик LLMNR не проходит через маршрутизаторы, вы не рискуете случайно заполнить им сеть.

Как и WINS, LLMNR позволяет преобразовать имя хоста, например, COMPUTLR84, в IP-адрес. По умолчанию LLMNR включена на всех компьютерах под управлением Windows Vista и Windows Server 2008. Эти компьютеры прибегают к LLMNR, если попытки узнать имя хоста через DNS окончились неудачей. В результате, разрешение имен в Widows Vista и в Windows Server 2008 работает следующим образом:

Вы также можете использовать LLMNR для обратного разрешения. При этом компьютер посылает одноадресный запрос но конкретному ІР-адресу, запрашивая имя хоста. Компьютер с включенной LLMNR, получив запрос, посылает одноадресный ответ, содержащий имя хоста.

Компьютеры с включенной LLMNR должны проверять уникальность своих имен в подсети. В большинстве случаев это происходит при запуске, восстановлении из спящего режима или при смене параметров сетевого интерфейса. Если компьютер еще не проверил уникальность своего имени, он должен указывать это в ответе на запрос.

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

Автор: David Lodge

Суть метода заключалась в прослушивании широковещательных запросов, связанных с преобразованием имен, передаваемых по протоколу NetBIOS. В качестве ответа злоумышленник подменяет IP-адрес, заставляя жертву подключиться в нужное место. Техника может быть полезна в том случае, если вы хотите получить учетные записи пользователя и управляете сервером, на котором находится запрашиваемая веб-страница. Вы настраиваете сервер так, чтобы спровоцировать NT-аутентификацию, и пользователь, ни о чем не подозревая, отправляет вам свои учетные данные.

Недавно я выяснил, что подобную атаку можно осуществить и на протокол LLMNR, который используется в Windows 7 и более поздних версиях.

Что такое LLMNR

Звучит как заболевание, устойчивое к микробам, не так ли? На самом деле, эта аббревиатура расшифровывается как Local Loop Multicast Name Resolution. «Ок, зачем нужен этот протокол?», - спросите вы. Это легковесная служба имен, использующая группу абонентов (multicast group) для поиска и преобразования базовых имен внутри небольшой сети. Одно из главных преимуществ заключается в том, что этот протокол корректно работает и в сети IPv4 и в сети IPv6, что выглядит примерно так:

Рисунок 1: Схема работы протокола LLMNR

В Windows подобная схема именуется как Сетевое обнаружение (Network Discovery) и может быть включена в Центре управления сетями и общим доступом.

Рисунок 2: Настройка сетевого обнаружения

Проблемы в протоколе LLMNR

Наша задача заключается в прослушивании запросов к хосту и перенаправлении этих запросов к подконтрольному нам серверу. После соединения мы запрашиваем аутентификацию, и Windows с превеликим удовольствием отсылает нам учетные данные.

Для решения этой задачи мы можем использовать автоматический прокси-сервер, предусмотренный в Internet Explorer. Когда вы запускаете Internet Explorer с настройкой автоматического прокси-сервера, на хост отсылается запрос «wpad», а после соединения с хостом скачивается файл wpad.dat. Более подробно об этой технологии рассказывает русскоязычная и англоязычная Википедия.

Windows 7+ делает запрос wpad через следующие протоколы:

DNS (одноадресный запрос wpad)
NetBIOS (широковещательный запрос WPAD)
LLMNR (многоадресный запрос wpad)

Поскольку по протоколу DNS идет одиночный запрос, мы должны осуществить атаку типа «Человек посередине». О NetBIOS уже говорилось в других статьях. Я же хочу коснуться протокола LLMNR.

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

Рассмотрим суть происходящего через Wireshark:

Рисунок 3: Запросы, отправляемые по протоколу LLMNR

На рисунке выше показаны запросы, отправляемые по протоколу LLMNR для сети IPv4 (записи типа A) и для сети IPv6 (записи типа AAAA). Кроме того, показаны запросы к файлу wpad.dat и попытка аутентификации.

Настраиваем Metasploit

Как и в случае с NetBIOS мы будем использовать Metasploit. Наш пример чуть более сложен по сравнению со стандартными эксплоитами, поскольку нужно запустить два вспомогательных модуля.

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

Мы можем обратиться к новому веб-серверу через обычный браузер, и тут нет ничего выдающегося, поскольку нашу поддельную страницу пользователь не увидит.

Рисунок 4: Поддельная страница, на которую будет перенаправляться пользователь

Теперь нам нужно нечто, что позволит наладить взаимодействие с веб-сервером. Используем модуль auxiliary/spoof/llmnr/llmnr_response module:

[*] LLMNR Spoofer started. Listening for LLMNR requests with REGEX "(?-mix:wpad)" .

Мы установили мультикастовый listener, который будет слушать запросы «wpad» по протоколу LLMNR и в ответ на эти запросы отсылать IP-адрес созданного ранее веб-сервера.

Получение паролей

На какое-то время оставьте запущенную связку модулей до тех пор, пока люди не откроют Internet Explorer и не начнут запрашивать файл wpad. Наиболее подходящее время – середина утра или обеденное время. В итоге вы получите файл, заполненный запросами на NT-аутентификацию.

Следующий шаг – расшифровка полученных хешей при помощи John the Ripper (jumbo patch) или, если у вас есть быстрая графическая карта, hashcat.

Вначале отфильтруем машинные аккаунты. Машинный аккаунт представляет собой NT-аккаунт, используемый компьютером для аутентификации при помощи учетной записи домена. Подобные учетные записи оканчивается символом ‘$’ (например, ASPHODEL$). В качестве фильтра используем следующую команду:

grep –v ‘\$:’ out.txt >filtered.txt

Затем указываем тип хеша 5600 (NetNTLMv2) и подбираем пароли при помощи hashcat:

c:\tools\passwords\hashcat>cudahashcat64 -m 5600 out.txt --remove --session llmnr ..\dictionaries

Как защититься от этой угрозы

Самый простой способ защиты – отключить протокол LLMNR, что необходимо сделать для каждого сетевого профиля. В панели управления зайдите в раздел Network and Sharing Center > Change Advanced Sharing Settings > profile > Network discovery и установить флажок «Turn off network discovery».

То же самое можно сделать через групповую политику: Administrative Templates > Network > Link-Layer Topology Discovery.

Помимо упомянутых настроек можно отключить автоматический прокси-сервер и указать принудительное использование конкретного адреса в качестве прокси.

Использование устаревших протоколов без явной необходимости может являться потенциальной брешью в безопасности любой компьютерной сети. В этом плане показательна недавняя шумиха вокруг шифровальщика WCry, простейшая защита от которого заключалась в отказе от использования устаревшего протокола SMBv1 путем его полного отключения. Широковещательные протоколы NetBIOS через TCP/IP и LLMNR также являются устаревшими протоколами, и в большинстве современных сетей они используются только с целями совместимости. Одновременно с этим в инструментарии хакеров есть различные инструменты, позволяющие использовать уязвимости в протоколах NetBIOS и LLMNR для перехвата учетных данных пользователей в локальной подсети (в т.ч. хэши NTLMv2). Поэтому в целях безопасности в доменной сети эти протоколы следует отключать. Разберемся как отключить LLMNR и NetBIOS с помощью групповых политик.

Прежде всего следует напомнить, что это за протоколы.

Протокол LLMNR

LLMNR (UDP/5355, Link-Local Multicast Name Resolution — механизм широковещательного разрешения имен) – протокол присутствует во всех версиях Windows, начиная с Vista и позволяет IPv6 и IPv4 клиентам за счет широковещательных запросов в локальном сегменте сети L2 разрешать имена соседних компьютеров без использования DNS сервера. Этот протокол также автоматически используется при недоступности DNS. Соответственно, при работающих DNS-серверах в домене, этот протокол абсолютно не нужен.

Протокол NetBIOS поверх TCP/IP

Протокол NetBIOS over TCP/IP или NBT-NS (UDP/137,138;TCP/139) – является широковещательным протоколом-предшественником LLMNR и используется в локальной сети для публикации и поиска ресурсов. Поддержка NetBIOS over TCP/IP по умолчанию включена для всех интерфейсов во всех ОС Windows.

Таким образом эти протоколы позволяют компьютерам в локальной сети найти друг друга при недоступности DNS сервера. Возможно они и нужны в рабочей группе, но в доменной сети оба этих протокола можно отключить.

Совет. Перед массовым внедрением данных политики в домене, настоятельно рекомендуем протестировать работу компьютеров с отключенными NetBIOS и LLMNR на тестовых группах компьютеров и серверах. И если проблем с отключением LLMNR нет, отключение NetBIOS может парализовать работу устаревших систем

Отключение протокола LLMNR с помощью групповой политики

В доменной среде широковещательные запросы LLMNR на компьютерах домена можно отключить с помощью групповой политики. Для этого:

В консоли GPMC.msc создайте новую или отредактируйте имеющуюся политику, применяемую ко всем рабочим станциям и серверам.
Перейдите в раздел Computer Configuration -> Administrative Templates -> Network -> DNS Client
Включите политику Turn Off Multicast Name Resolution, изменив ее значение на Enabled

Отключение протокола NetBIOS over TCP/IP

Примечание. Протокол NetBIOS может используется старыми версиями Windows и некоторыми не-Windows-системами, поэтому его процесс его отключения в конкретной среде стоит тестировать.

На конкретном клиенте отключить NetBIOS можно вручную.

Отключить поддержку NetBIOS для конкретного сетевого адаптера можно и из реестра. Для каждого сетевого адаптера компьютера есть отдельная ветка с его TCPIP_GUID внутри HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.

Чтобы отключить NetBIOS для конкретного адаптера, нужно открыть его ветку и изменить значение параметра NetbiosOptions на 2 (по умолчанию значение – 0).

Для полного отключение протокола NetBIOS, рассмотренные выше операции нужно выполнить для всех сетевых адаптеров компьютера.

На клиентах домена, получающих IP адреса с DHCP сервера, отключить NetBIOS можно через настройку опций DHCP сервера.

Для этого откройте консоль dhcpmgmt.msc и выберите настройки зоны Scope Option (или сервера – Server Options)
Перейдите на вкладку Advanced, в выпадающем списке Vendor class выберите MicrosoftWindows 2000Options
Включите опцию 001MicrosoftDisableNetbiosOption и измените ее значение на 0x2

Отдельной опции, позволяющей отключить NETBIOS over TCP/IP для всех сетевых адаптеров компьютера через групповые политики нет. Чтобы отключить NETBIOS для всех адаптеров компьютера воспользуйтесь следующим PowerShell скриптом, который нужно поместить в политику Computer Configuration -> Policies -> Windows Settings ->Scripts ->Startup->PowerShell Scripts

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach

Читайте также: