Llmnr протокол что это

Отключение NetBIOS через TCP/IP и LLMNR в домене с помощью GPO

Использование устаревших протоколов без явной необходимости может являться потенциальной брешью в безопасности любой компьютерной сети. В этом плане показательна недавняя шумиха вокруг шифровальщика 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 сервера. Возможно они и нужны в рабочей группе, но в доменной сети оба этих протокола можно отключить.

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

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

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

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

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

1. Откройте свойства сетевого подключения
2. Выберите протокол TCP/IPv4 и откройте его свойства
3. Нажмите кнопку Advanced, затем перейдите на вкладку WINS и выберите опцию Disable NetBIOS over TCP (Отключить NetBIOS через TCP/IP)
4. Сохраните изменения

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

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

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

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

1. Для этого откройте консоль dhcpmgmt.msc и выберите настройки зоны Scope Option (или сервера – Server Options)
2. Перейдите на вкладку Advanced, в выпадающем списке Vendor class выберите MicrosoftWindows 2000Options
3. Включите опцию 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

LLMNR & NBT-NS Poisoning and Credential Access using Responder

Cynet protects its customers from this attack by actively searching for instances of Responder on the network, as well as utilizing passive mitigation methods – maintaining clients’ security and protecting credentials and data:

This is part of an extensive series of guides about Network Attacks.

Introduction

Name Resolution (from here on abbreviated NR) is a series of procedures conducted by a machine to retrieve a host’s IP address by its hostname. On Windows machines, the procedure will roughly be as follows:

1. The hostname fileshare‘s IP address is required
2. The local hostfile will be checked for suitable records
3. If no records were found, the machine will move on to the local DNS cache, which archives recently resolved names
4. No local DNS record found? A query will be sent to the configured DNS server
5. If all else fails – the machine will send a multicast query, asking other machines in the network for fileshare‘s IP address

As can be seen, the final fallback when resolving a hostname’s IP address is using multicast NR. This is managed by three main protocols: NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) and mDNS (multicast DNS).

The three protocol are used adjunctively for two main reasons: legacy support and compatibility. NBT-NS was created in the early 80’s and is somewhat unfitting with today’s standards. As the protocol was falling out of favor, Windows machines started implementing NBT-NS’s successor, LLMNR (still supporting NBT-NS for communication with older machines). On the other hand, most Linux-based machines implemented mDNS instead. Eventually with the release of Windows 10, Microsoft added support for mDNS as well to enhance overall compatibility.

Let’s see these protocols in action:

On a Windows 10 machine we mistyped a shared folder’s name (\\filesahre instead of \\fileshare), resulting in a series of mDNS, NBT-NS and LLMNR queries. Notice that all queries are sent to designated multicast addresses.

Figure 1: Network capture of a Windows 10 machine trying to resolve an unknown hostname using multicast name resolution protocols

Why It’s a Problem

NBT-NS, LLMNR and mDNS broadcast a query to the entire intranet, but no measures are taken to verify the integrity of the responses. Attackers can exploit this mechanism by listening to such queries and spoofing responses – tricking the victim into trusting malicious servers. Usually this trust will be used to steal credentials.

Moreover, a number of tools have been developed to automate this procedure, making the attack a no-brainer that can run in no-time. For this article we used Python-based Responder on a Kali Linux machine.

Common Abuse Cases

There are many occasions in which a machine will resort to multicast NR, some of which are:

• Mistyping – if a user mistypes the name of a legitimate host, usually no relevant host record will be found and the machine will resort to multicast NR. This is a rather weak use case because the attacker will have to wait for an error on the victim’s side.
• Misconfiguring – false configuration on either the DNS server or the client’s side can lead to problems in NR and force the client to rely on multicast name queries.
• WPAD Protocol – if a web browser is set to automatically detect proxy settings, it will use the WPAD protocol to discover the URL of a proxy configuration file. To discover this URL, WPAD will iterate through a series of potential URLs and hostnames – and with each false attempt expose itself to spoofing. Google Chrome and Firefox will not trigger this behavior by default, but Internet Explorer will.
• Google Chrome – when a single word string is typed in Chrome’s search bar, the application needs a way to discern whether the string is a URL or a search term. Chrome first treats the string as a search term and directs the user to its configured user engine, while simultaneously making sure the string is not a hostname by trying to resolve it [1] . Furthermore, to prevent exposure to DNS hijacking, Chrome will try to resolve several randomized hostnames on start-up to make sure they do not resolve – essentially guaranteeing some multicast NR action [2] !

Poisoning with Responder

Responder is an open-source python-based LLMNR/NBT-NS/mDNS poisoner acting in two stages as described above:

1. First, it will listen to multicast NR queries (LLMNR – UDP/5355, NBT-NS – UDP/137) and, under the right conditions, spoof a response – directing the victim to the machine on which it is running.
2. Once a victim will try and connect to our machine, Responder will exploit the connection to steal credentials and other data.

In this demonstration we will use Responder to access credentials through SMB and WPAD authentication. We used a Kali Linux machine, which has this tool pre-installed and can be accessed under /usr/share/responder.

Step 1: Setting-Up

This is our network setup:

Figure 2: Demonstration network diagram, depicting the victim PC, attacker PC and a file server named fileshare.

Now let’s see Responder’s arguments on our attacking machine (192.168.68.111):

Figure 3: Responder’s arguments (running on Kali Linux machine)

We can see that WPAD capabilities are turned off by default, and to activate them we will add the flags -w and -F (to force the client to authenticate to us as part of the WPAD protocol). Coupled with the -I flag (to specify the interface to run on) and the -v flag (to have a better view of what’s happening), we will execute the following command:

Figure 4: Responder’s enabled and disabled services and options, as displayed after execution

Now everything is set up and Responder will wait for multicast NR queries.

Step 2: Attacking the Target

SMB Credential Access

Remember our aforementioned mistyped “\\filesahre“? This is how the same event looks on our attacking machine:

Figure 5: NR spoofing leading to SMB credential access, as seen on Responder’s log

As seen in the introduction, several NBT-NS, LLMNR and mDNS queries were broadcast by our victim Windows 10 machine, indicating that the required host is supposed to be a file server. Responder will reply to file server queries (SMB and FTP) by default. The victim then established a connection with our malicious SMB server and handed us its credentials.

Let’s see this process on Wireshark:

Figure 6: NR spoofing leading to credential access, as seen on Wireshark

First our victim (192.168.68.101) sent multiple multicast NR queries using mDNS, NBT-NS (NBNS) and LLMNR. As seen in the second packet, Responder replied to the NBT-NS query claiming our machine (192.168.68.111) is filesahre:

Figure 7: Poisoned NBT-NS answer for fileshare (mistyped filesahre)

The victim then initiated an SMB connection and authenticated to our server, as seen in the last two packets. His username and password hash code were transferred and are now visible to us as plaintext (“User: WINDEV2004EVAL\User”). The full hash code is dispersed among several fields in both packets and can be gathered manually, but responder automatically puts them together – outputting the complete hash code seen in the log.

WPAD Credential Access

On our second run, a query for WPAD hosts was broadcast through Google Chrome. After spoofing a response and establishing a connection, the victim requested the wpad.dat Proxy Auto-Config (PAC) file. Responder requested the victim to authenticate first – retrieving its credentials. It’s that simple!

Figure 8: Responder log demonstrating a WPAD-based credential access. Responder identified several NBT-NS, LLMNR and mDNS queries for wpad and wpad.local and responded with poisoned answers, tricking the victim to initiate an HTTP connection (1). Next our victim, 192.168.68.101, sent a GET request for wpad.dat to our machine, and was requested to authenticate in response (notice that responder displays the User-Agent as retrieved from the HTTP GET request). The victim then handed over its credentials and they were added to Responder’s log (2). Later, we can see Chrome’s 3 random hostname resolution attempts: lvgeeyxplexhzl, ndxyphcamokhchl and awlzijvh (3).

And again on Wireshark:

Figure 9: NR spoofing leading to WPAD credential access, as seen on Wireshark

First our victim machine (192.168.68.101) queried for wpad and wpad.local. Responder then sent a response, directing the victim to itself (192.168.68.111). Notice that this time the response was sent over LLMNR:

Figure 10: Poisoned LLMNR answer for fileshare (mistyped filesahre)

Then the victim requested the wpad.dat PAC file, Responder negotiated an authentication and the user’s credentials were handed over in the second to last packet:

Figure 11: User credentials retrieved from WPAD

WPAD poisoning is more reliable than waiting for a victim to mistype network locations, but it’s not perfect. Some machines we tested didn’t query for WPAD hosts at all, and some queried for WPAD but refused to authenticate. Certain browsers will also prompt the user to manually enter his credentials.

Finally, here is a video of the entire process:

Step 3: What Next?

Hash Cracking

Responder can spoof some services that use plaintext authentication (FTP, POP3), but in this demonstration we opted for services that use hash codes. There are many tools to crack hash codes and we used John the Ripper, which utilizes password dictionaries, wordlists and brute force methods. This tool can be very effective when passwords are not overly complex.

MultiRelay and Pass the Hash

What if our hash codes deem uncrackable? Well then, this is when Responder’s bundled sidekick MultiRelay comes into play. This tool can be used to relay the victim’s authentication packets to a different machine and get privileged access to it. in a manner similar to Man-in-the-Middle attacks. If the spoofed victim has administrative access to the targeted machine, it will be severely compromised.

Machines can utilize SMB Signing to prevent MITM attacks in SMB connections by digitally signing the data transferred and confirming its authenticity. However, enabling SMB signing for all hosts on a network can impact performance by up to 15% [3] .

Another option is to use Pass the Hash methods to authenticate using the compromised hash code, rather than cracking it and using the password itself.

Mitigation

Since multicast NR is a peer-to-peer behavior, most mitigation methods will focus on endpoint security, rather than relying on network security alone:

Windows Server

Существует четыре типа узлов.
■ Широковещательный (b- узел )
Этот тип узла использует широковещательные запросы имен NetBIOS для регистрации и разрешения имен. В-узел имеет два недостатка: широковещание затрагивает все узлы в сети, а маршрутизаторы, как правило, блокируют широковещание, так что разрешаться будут лишь имена NetBIOS в локальной сети. Принцип работы этого типа узлов больше других похож на LLMNR.
■ Узел точка — точка ( р — узел )
Этот тип узла использует коммуникации точка- и WINS-сервер для разрешения имен. Р-узел не применяет широковещание, а напрямую запрашивает сервер имен.
■ Комбинированный (m- узел )
Данный тип узла вначале использует широковещание (b-узел), а затем, если имя не было разрешено с помощью широковещания, применяет запросы WINS-сервера (р-узел).
■ Смешанный (h- узел )
Этот тип узла вначале использует запросы WINS (р-узел), а затем — широковещание (b-узел), если сервер имен недоступен или имя не зарегистрировано в базе данных WINS. Однако до внедрения широковещания b-узла эти компьютеры также используют файл Lmhosts для поиска сопоставлений имени в IP-адрес. По умолчанию клиенты Windows конфигурируются с комбинированным, или h-узлом. Текущее состояние узла, назначенного компьютеру Windows, можно определить в результатах команды Ipconfig /all, как показано в примере. Отметим, что на этом компьютере назначен смешанный тип узла.

Преимущества и недостатки NetBIOS

Главное ограничение NetBIOS состоит в том, что, хотя этот протокол обеспечивает резервный метод разрешения имен компьютеров в пределах диапазона широковещания и небольших сетях, он неэффективен в больших сетях. В NetBIOS каждому компьютеру назначается только одно имя или метка. Если вы используете WINS для разрешения имен NetBIOS в подсетях, имя каждого компьютера должно быть уникальным для всей сети. Еще один недостаток NetBIOS состоит в том, что этот протокол не рекомендуется использовать в тех случаях, когда требуется высокий уровень безопасности. Система NetBIOS разглашает информацию о сетевых службах, которая может быть использована для взлома сети. И, наконец, протокол NetBIOS несовместим с IPv 6-сетями.
ПРИМЕЧАНИЕ:
Если вы используете множество WINS-серверов в большой организации, па них нужно отконфигурировать репликацию, чтобы базы данных WINS все время обновлялись. В большинстве случаев на всех WINS-серверах настраивается репликация приема/передачи (push/pull) (особенно при звездообразной конфигурации), чтобы серверы могли эффективно обновлять друг друга.

Разрешение имен DNS

Система именования DNS основана на иерархической и логической древовидной структуре, которая называется пространством имен DNS. Это пространство имеет уникальный корень с любым количеством субдоменов. Каждый субдомен может располагать доменами нижнего уровня. Например, корень «» (пустая строка) в пространстве имен Интернета располагает множеством доменных имен верхнего уровня, одним из которых является org . Домен org может, например, содержать субдомен wikipedia . org компании Wikipedia , который, в свою очередь, может располагать производственным субдоменом ru . wikipedia . org . Организации также могут создавать частные сети и использовать собственное пространство имен DNS, скрытое для Интернета.

Доменные имена

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

Распознаватель DNS представляет службу, использующую протокол DNS для запроса информации DNS-серверов. Распознаватели DNS осуществляют коммуникации с удаленными DNS-серверами или программой DNS-сервера на локальном компьютере. В Windows Server 2008 роль распознавателя DNS выполняет служба DNS-клиент (DNS Client). Помимо функций распознавателя DNS служба DNS-клиент обеспечивает дополнительные возможности кэширования сопоставлений DNS.

Записи ресурсов

Когда DNS-клиенту требуется выполнить поиск имени, используемого приложением, он опрашивает DNS-серверы для разрешения этого имени. Каждое сообщение запроса, отправляемое клиентом, содержит следующие сведения.
■ Имя домена DNS, указанное в формате FQDN. ( Служба DNS- клиент добавляет необходимые суффиксы для генерирования имени FQDN, если оно не было указано исходной клиентской программой.)
■ Указанный тип запроса , например запрос записи ресурса по типу или специализированный тип операции запроса.
■ Указанный класс доменн ого имени DNS. (Для службы DNS-клиент всегда указывается класс Internet [IN].
Так, в запросе можно указать имя FQDN конкретного компьютера (например, host- a .example.microsoft.com.), а в качестве типа запроса указать поиск записи А по этому имени. Запрос DNS как клиент задает серверу, скажем, такой вопрос: «Имеются ли записи А для компьютера hostname.example.microsoft.com?». Получив ответ от сервера, клиент читает полученную запись А и определяет IP-адрес имени компьютера, которое запрашивалось.

Методы разрешения имен DNS

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

Этапы выполнения запроса DNS

Запрос DNS выполняется в два этапа.
■ С клиентского ко мпьютера запускается запрос имени и передается службе
DNS-клиент (DNS Client) для разрешения.
■ Если запрос нельзя разрешить локально , служба DNS- клиент передает запрос DNS-серверу.
Далее подробно описаны оба этапа выполнения.

Этап 1 . Локальный распознаватель
По умолчанию DNS-запрос клиента отконфигурирован для выполнения рекурсивных запросов сервера. Если в этом сценарии служба DNS-клиент не может разрешить запрос с помощью локально кэшированной информации (сопоставления имен с адресами, предварительно загружаемые из файла Hosts), клиент отправляет лишь один запрос на DNS-сервер, который затем выполняет его от лица клиента.
Процесс выполнения запроса начинается с использования доменного имени DNS в программе на локальном компьютере. Например, браузер запрашивает имя FQDN для www.microsoft.com. Затем запрос пересылается службе DNS-клиент (кэш распознавателя DNS) для разрешения этого имени с помощью локально кэшированной информации. Если такое имя можно разрешить, отправляется ответ на запрос, и процесс завершается.
Кэш локального распознавателя может включать информацию об имени, полученную из двух возможных источников.
■ При наличии локально отконфигурированного файла Hosts все сопоставления имен узлов в адреса загружаются из файла в кэш при запуске службы DNS- клиент и при каждом обновлении файла Hosts. В Windows Server 2008 записи динамически добавляются в кэш распознавателя, создавая файл Hosts.
■ Записи ресурсов , полученные в ответах на предыдущие запросы DNS, добавляются в кэш и хранятся там некоторое время.
Если запрос не соответствует ни одной записи в кэше, клиент запрашивает DNS-сервер для разрешения имени.

Этап 2. Запрос DNS-сервера
Служба DNS-клиент (DNS Client) использует список поиска серверов, упорядоченный согласно предпочтениям. В этот список включены все предпочтительные и альтернативные DNS-серверы, отконфигурированные для каждого активного сетевого подключения в системе. Клиент вначале запрашивает DNS-сервер, указанный как предпочтительный в диалоговом окне Свойства: Протокол Интернета (TCP/IP) (Internet Protocol (TCP/ IP) Properties). Если предпочтительные DNS-серверы недоступны, используются альтернативные DNS-серверы.
После получения запроса DNS-сервер проверяет возможность приоритетного ответа на запрос на основе информации, содержащейся в локально сконфигурированной зоне на сервере. Если запрашиваемое имя соответствует записи ресурса в данных локальной зоны, сервер отвечает на запрос в приоритетном порядке, используя эту информацию для разрешения запрашиваемого имени.
Если для запрашиваемого имени не нашлось соответствующей записи в информации зоны, сервер проверяет возможность разрешения имени с помощью локально кэшированной информации предыдущих запросов. Если найдена соответствующая запись, сервер отвечает на запрос. Если предпочтительный сервер находит ответ для запрашивающего клиента в своем кэше, выполнение запроса завершается.

В следующем примере продемонстрирован запрос DNS. Клиент запрашивает предпочтительный DNS-сервер, который затем выполняет рекурсию, запрашивая DNS-серверы, расположенные выше в иерархии. Предполагается, что кэши DNS-клиента и всех DNS-серверов пусты.
Ниже описан процесс обработки запроса службой DNS-клиент на клиентском компьютере.
1. Клиент связывается с сервером NameServer1 и запрашивает example. wikipedia . org .
2. Сервер NameServer1 проверяет свой кэш и зоны. Если ответ не получен, он обращается к главному серверу Интернета (т. е. корневому серверу) и запрашивает example. wikipedia . org .
3. Корневой сервер Интернета не знает ответ и запрашивает направление на главный сервер домена . org .
4. Сервер NameServer1 обращается к главному серверу домена . org и запрашивает имя example . wikipedia . org .
5. Главный сервер домена . org не знает точный ответ и направляет запрос на главный сервер домена wikipedia . org .
6. Сервер NameServer1 обращается к главному серверу домена wikipedia . org и запрашивает имя example. wikipedia . org .
7. Главный сервер домена wikipedia . org знает ответ и отправляет запрашиваемый IP-адрес.
8. Сервер NameServer1 отправляет в ответе на запрос клиента IP-адрес узла
example. wikipedia . org ..

Кэширование

Кэш DNS-клиента

Кэш DNS-клиента еще называют кэшем распознавателя DNS. При каждом запуске службы DNS-клиент все сопоставления имен в IP-адреса, содержащиеся в статическом файле Hosts, предварительно загружаются в кэш распознавателя DNS . Файл Hosts находится в папке WINDOWS\System32\Drivers\Etc.
ПРИМЕЧАНИЕ: Использование файла Hosts
Каждая запись, добавляемая в файл Hosts, немедленно загружается в кэш распознавателя DNS.
Помимо записей в файле Hosts кэш распознавателя DNS также включает записи, получаемые клиентом в ответ на запросы DNS-серверов. Каждый раз при остановке службы DNS-клиент (DNS Client) выполняется очистка кэша распознавателя DNS.

Кэш DNS-сервера

Поскольку DNS-серверы выполняют рекурсивные запросы от лица клиентов, они временно кэшируют записи ресурсов. Эти кэшированные записи содержат информацию, получаемую в ответах на запросы от лица клиента. Позже, при получении новых запросов информации, соответствующей кэшированным записям ресурсов, DNS-сервер может использовать кэшированную информацию для ответа на эти запросы.
Очистка кэша DNS-сервера выполняется каждый раз при остановке службы DNS-сервера. Очистку кэша DNS-сервера можно выполнить и вручную в консоли DNS (инструмент, используемый для администрирования DNS), щелкнув правой кнопкой мыши значок сервера в дереве консоли и применив команду Очистить кэш (Clear Cache). Наконец, кэш сервера можно очистить, запустив в командной строке команду Dnscmd/clearcache.
Значения Time To Live (TTL)
Время жизни датаграммы в секундах применяется ко всем кэшированным записям ресурсов в кэше распознавателя DNS и кэше DNS-сервера. Во время жизни TTL кэшированного ресурса распознаватель или сервер DNS может использовать эту запись для ответа на запросы. По умолчанию назначается значение TTL 3600 с (1 ч), однако этот параметр можно изменять на уровнях зоны и записи.

Отключение протоколов NetBIOS и LLMNR в Windows с помощью GPO

Широковещательные протоколы NetBIOS over TCP/IP и LLMNR являются устаревшими и в большинстве современных сетей они используются только для совместимости с legacy версиями Windows. Оба протокола подвержены спуфингу и атакам MITM. В том же Metasploit есть готовые модули, позволяющие легко использовать уязвимости в широковещательных протоколах NetBIOS и LLMNR для перехвата учетных данных пользователей в локальной подсети (в т.ч. можно получить хэши NTLMv2 ). Для повышения безопасности необходимо отключать эти старые протоколы в доменной сети. Разберемся, как отключить протоколы LLMNR и NetBIOS в Windows 10/Windows 2016 вручную или через групповые политики.

• Протокол LLMNR
• Протокол NetBIOS over TCP/IP
• Отключение протокола LLMNR с помощью GPO
• Отключение протокола NetBIOS over TCP/IP в Windows 10
• Как отключить NetBIOS через групповые политики?

Протокол LLMNR

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

Протокол NetBIOS over TCP/IP

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

В Windows вы можете вывести статистику протокола NetBIOS и текущий подключений TCP/IP по NBT с помощью команды nbtstat. Чтобы по IP адресу получить имя компьютера, выполните:

nbtstat -A 192.168.31.90

Как вы видите, утилита с помощью NetBIOS обнаружила в локальной сети компьютер и вернула его имя.

Можете вывести все записи о соседних компьютерах в локальных сети в кэше NetBIOS:

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

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

Отключение протокола LLMNR с помощью GPO

Можно отключить LLMNR на компьютере Windows локально через реестр с помощью следующей команды PowerShell:

New-Item «HKLM:\SOFTWARE\Policies\Microsoft\Windows NT» -Name DNSClient -Force
New-ItemProperty «HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient» -Name EnableMultiCast -Value 0 -PropertyType DWORD -For ce

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

1. В консоли GPMC.msc создайте новую или отредактируйте имеющуюся политику, применяемую ко всем рабочим станциям и серверам;
2. Перейдите в раздел Computer Configuration -> Administrative Templates -> Network -> DNS Client;
3. Включите политику Turn off smart multi-homed name resolution, изменив ее значение на Enabled;
4. Дождитесь обновления параметров GPO на клиентах или обновите их вручную командой gpupdate /force .

Либо вы можете через GPP распространить на компьютеры домена параметр реестра EnableMulticast = 0 (HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient).

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

Вы можете отключить NetBIOS в Windows вручную:

1. Откройте свойства сетевого подключения;
2. Выберите протокол TCP/IPv4 и откройте его свойства;
3. Нажмите кнопку Advanced, затем перейдите на вкладку WINS и выберите опцию Disable NetBIOS over TCP (Отключить NetBIOS через TCP/IP);
4. Сохраните изменения.

Если у вас на компьютере несколько сетевых интерфейсов (или отдельных VLAN), нужно будет отключить NetBIOS в свойствах каждого их них.

Вы можете проверить статус NetBIOS over TCP/IP для сетевых адаптеров из командной строки Windows:

ipconfig /all |find «NetBIOS»

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

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

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

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

Как отключить NetBIOS через групповые политики?

В редакторе групповых политик или последней версии административных шаблонов для Windows 10/Windows Server 2019 нет отдельного параметра, позволяющего отключить протокол NETBIOS over TCP/IP для всех сетевых адаптеров компьютера. Чтобы отключить NETBIOS для всех адаптеров компьютера воспользуйтесь таким логон скриптом PowerShell.

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

Сохраните этот код в файл disableNetbios.ps1, скопируйте его в каталог вашей GPO и запускайте на клиентах через Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup- > PowerShell Scripts.

Если на клиентах настройки политики выполнения PowerShell блокируют запуск этого скрипта, нужно подписать PS1 скрипт или запускать его в режиме –bypass.

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

Затем откройте командную строку и проверьте, что NetBIOS отключен для ваших сетевых адаптеров (кроме туннельных интерфейсов):