Link-Local Multicast Name Resolution (LLMNR) – protokół, który pozwala komputerom w tej samej sieci lokalnej ustalać nawzajem swoje adresy IP na podstawie nazw, bez udziału serwera DNS. Zamiast odpytywać serwer, komputer rozgłasza pytanie „kto nazywa się X?” do wszystkich maszyn w swoim segmencie sieci i czeka, aż odezwie się ta, która tę nazwę nosi. Opisuje go dokument RFC 4795 ze stycznia 2007 roku, przygotowany przez Bernarda Abobę, Dave’a Thalera i Levona Esibova z Microsoftu. Ma on status informacyjny i nie jest standardem internetowym – pierwotnie kierowano go do zatwierdzenia jako Proposed Standard, jednak IETF nie osiągnęło konsensusu co do przyjętego rozwiązania[1].
LLMNR ma pomagać w sieciach, w których serwera DNS nie ma albo jego uruchamianie nie ma sensu – typowym przykładem jest doraźna sieć bezprzewodowa utworzona przez grupę komputerów. Dzięki protokołowi maszyny w takiej sieci rozpoznają swoje nazwy bez wyznaczania jednej z nich na serwer DNS i konfigurowania pozostałych jego adresem. Podobną rolę pełnił wcześniej NetBIOS rozgłaszający zapytania po IPv4, ale działa on wyłącznie w IPv4 i bywa wyłączany tam, gdzie nazwy rozwiązuje się wyłącznie przez DNS. LLMNR obsługuje zarówno IPv4, jak i IPv6[2]. Protokół nie jest zamiennikiem DNS: obejmuje wyłącznie łącze lokalne, a specyfikacja zaleca używać go dopiero wtedy, gdy rozwiązanie nazwy przez DNS się nie powiedzie, i tylko dla nazw jednoetykietowych, czyli takich bez kropek. Stosowanie LLMNR jako podstawowego mechanizmu rozwiązywania nazw jest w RFC wprost odradzane[1].
Pytający komputer wysyła zapytanie multicastem: na adres grupowy 224.0.0.252 w sieci IPv4 albo FF02::1:3 w sieci IPv6, w obu przypadkach na port 5355 UDP. Wszystkie hosty z włączonym LLMNR nasłuchują pod tymi adresami, więc pytanie trafia jednocześnie do każdego z nich. Oba adresy mają zasięg ograniczony do łącza, dzięki czemu router nie przekaże zapytania poza segment, w którym je nadano – i właśnie dlatego protokół działa tylko w obrębie jednej sieci lokalnej[1][2].
Odpowiada wyłącznie ten komputer, który jest autorytatywny dla pytanej nazwy, czyli po prostu ten, który tę nazwę nosi. Odpowiedź wysyła już bezpośrednio do pytającego, a nie do całej grupy. Pozostałe maszyny milczą – nie odsyłają informacji, że nazwy nie znają, a pytający traktuje brak odpowiedzi tak samo jak odpowiedź serwera DNS o nieistnieniu nazwy[1].
Same komunikaty mają format pakietów DNS zdefiniowany w RFC 1035, uzupełniony o dwa bity: C, sygnalizujący konflikt nazw w sieci, oraz T, oznaczający nazwę, której unikatowości nadawca jeszcze nie sprawdził. LLMNR korzysta jednak z innego portu niż DNS i z osobnej pamięci podręcznej, tak aby odpowiedzi uzyskane z sieci lokalnej nie mieszały się z danymi z DNS. W odróżnieniu od serwera DNS host odpowiada wyłącznie za własne nazwy, a nie za całą gałąź poniżej – komputer foo.example.com nie odpowiada na pytania o child.foo.example.com[1][2].
Microsoft zaimplementował LLMNR w systemach Windows Vista i Windows Server 2008. Rozwiązując nazwę jednoetykietową, Vista odpytuje najpierw DNS, następnie wysyła najwyżej dwie serie zapytań LLMNR po IPv6 i IPv4, a na końcu – jeżeli NetBT jest włączony – rozgłasza zapytania NetBIOS. LLMNR jest przy tym używany niezależnie od tego, czy skonfigurowano serwer DNS[2].
W systemach Linux protokół realizuje usługa systemd-resolved, która potrafi zarówno zadawać pytania, jak i na nie odpowiadać. Steruje tym opcja LLMNR= w pliku resolved.conf, przyjmująca wartość logiczną albo resolve – ta ostatnia włącza samo zadawanie pytań, bez odpowiadania na cudze[3].
Słabość protokołu wynika wprost z jego konstrukcji i opisano ją już w samej specyfikacji: skoro pytanie rozgłaszane jest do wszystkich maszyn w segmencie, każda z nich – w tym maszyna napastnika – widzi je i może odpowiedzieć pierwsza, nie musząc niczego zgadywać ani podsłuchiwać[1]. W kwietniu 2011 roku Microsoft opublikował biuletyn MS11-030 dotyczący podatności CVE-2011-0657: błąd w obsłudze spreparowanych zapytań LLMNR przez usługę klienta DNS umożliwiał zdalne wykonanie kodu w kontekście konta NetworkService[4].
Typowym nadużyciem protokołu jest zatruwanie LLMNR, sklasyfikowane w MITRE ATT&CK razem z zatruwaniem usługi nazw NetBIOS (NBT-NS) jako podtechnika T1557.001. Napastnik odpowiada na cudze zapytania, podając się za poszukiwany komputer. Jeżeli ofiara sięgała po zasób wymagający uwierzytelnienia, przesyła mu nazwę użytkownika i skrót Net-NTLMv2 (zwany też NTLMv2), który można potem łamać offline albo przekazać dalej w ataku typu relay[5]. Przedrostka Net- używa się, aby odróżnić ten skrót, powstający przy uwierzytelnianiu w sieci, od przechowywanego lokalnie skrótu NTLM, z którym bywa mylony[5]. Jako przeciwdziałanie wskazuje się wyłączenie protokołu oraz podpisywanie pakietów SMB, które zatrzymuje ataki typu relay[6].
Amerykańska CISA opisuje wyłączenie LLMNR jako osobne przeciwdziałanie o identyfikatorze CM0053. W systemach Windows służy do tego zasada grupy „Turn off multicast name resolution” albo ustawienie wartości EnableMulticast na zero w kluczu rejestru HKLM\Software\Policies\Microsoft\Windows NT\DNSClient, w systemach Linux – zmiana LLMNR=yes na LLMNR=no w pliku /etc/systemd/resolved.conf. Zalecane jest też filtrowanie na urządzeniach sieciowych ruchu kierowanego na adres 224.0.0.252[7].
