Ausgangslage: Broadcast-Namensauflösung ist in Enterprise-Netzen eine Altlast

In vielen AD-Umgebungen ist die Namensauflösung faktisch „DNS-first“ – aber nicht „DNS-only“. Sobald ein Client einen Namen nicht sauber auflösen kann (falscher Suffix, falsch geschriebener Hostname, temporäres DNS-Problem), greifen Windows-Systeme häufig auf LLMNR (Link-Local Multicast Name Resolution) oder NBT-NS (NetBIOS Name Service) zurück.

Das hat zwei unangenehme Effekte:

  • Sicherheitsrisiko: Broadcast/Multicast erlaubt grundsätzlich, dass andere Systeme im gleichen Segment „Antworten anbieten“. Das ist keine Autorität, sondern ein Rennen um die schnellste Antwort.
  • Betriebliches Rauschen: Du siehst plötzlich Auth-Versuche zu „irgendwelchen“ Namen, Troubleshooting wird schwer, und Altlasten bleiben unbemerkt im Netz.

Wenn du AD-Hardening als Projekt betreibst, ist das ein sauber abgrenzbarer Baustein: DNS stabilisieren, Fallbacks abschalten, Nebenwirkungen gezielt abfangen.

Zielbild: DNS ist die einzige Namensautorität im internen Netz

Ein robustes Zielbild sieht so aus:

  1. LLMNR ist per GPO deaktiviert (domainweit, inkl. Server/Clients).
  2. NetBIOS over TCP/IP ist deaktiviert (und WINS ist nicht mehr im Client-Footprint).
  3. Clients nutzen definierte DNS-Suffixe, statt „Shortnames raten“.
  4. Ausnahmen sind bewusst (Altgeräte, OT, Übergangsphasen) und technisch/organisatorisch kontrolliert.

Wichtig: Das Ziel ist nicht „Broadcast um jeden Preis blocken“, sondern Namensauflösung deterministisch zu machen: DNS-Einträge, Suffix-Listen, saubere FQDN-Nutzung.

Umsetzung: LLMNR per GPO abschalten (schnell, stabil, gut rückrollbar)

LLMNR lässt sich in der Regel ohne Drama domainweit deaktivieren:

  • GPO: Computer Configuration → Policies → Administrative Templates → Network → DNS Client → Turn off multicast name resolution → Enabled

Damit wird LLMNR ausgeschaltet und du zwingst Clients, DNS-Probleme nicht mehr „wegzubroadcasten“.

Validierung (LLMNR)

Auf einem Zielsystem:

gpresult /scope computer /r

Und technisch (Policy-Registry):

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue

Erwartung: EnableMulticast ist gesetzt und 0.

Umsetzung: NBT-NS / NetBIOS sauber zurückbauen (erst verstehen, dann schalten)

NBT-NS ist zäher als LLMNR, weil in manchen Umgebungen noch implizite Abhängigkeiten existieren (alte Clients, Appliances, Druck/Scan-Workflows, Alt-Anwendungen).

1) Ist-Stand erheben: Wo steckt NetBIOS/WINS noch drin?

Pragmatische Checks:

  • Gibt es WINS-Server oder DHCP-Optionen, die WINS verteilen?
  • Nutzen Systeme noch UNC-Pfade/Hostnamen ohne DNS-Suffix (\\APP1\share statt \\app1.corp.example\share)?
  • Tauchen in Logs/Netzwerkdaten häufig UDP/137 oder UDP/138 auf?

Wenn du bereits eine „Tiering“-Struktur hast, starte bei Clients und Member-Servern – Domain Controller sind selten der Grund für NetBIOS-Abhängigkeiten.

2) Technische Maßnahme: NetBIOS over TCP/IP deaktivieren (GPO-Startup-Script)

Der verlässlichste Weg ist ein GPO-Computer-Startup-Skript, das die NetBT-Interface-Parameter setzt. Das ist:

  • idempotent (mehrfach ausführbar)
  • Interface-agnostisch (funktioniert auch bei mehreren NICs)
  • rückrollbar (NetbiosOptions wieder auf Standard setzen)

Beispiel (Startup-Skript, PowerShell):

$base = 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces'
Get-ChildItem -Path $base -ErrorAction SilentlyContinue | ForEach-Object {
  $path = $_.PSPath
  $current = (Get-ItemProperty -Path $path -Name NetbiosOptions -ErrorAction SilentlyContinue).NetbiosOptions
  if ($current -ne 2) {
    New-ItemProperty -Path $path -Name NetbiosOptions -PropertyType DWord -Value 2 -Force | Out-Null
  }
}

Hinweis: Plane eine Pilot-OU (z.B. „Workstations – Hardening Pilot“) und roll dann stufenweise aus. NetBIOS-Änderungen sind selten kritisch, aber wenn es knallt, willst du es in einem kleinen Scope sehen.

3) DNS-Suffix-Suche explizit machen (damit Shortnames nicht brechen)

Wenn in der Umgebung viel mit Shortnames gearbeitet wird, ist das eigentliche Problem meist nicht „NetBIOS fehlt“, sondern „DNS-Suffix ist nicht sauber“.

Typischer Fix: Definiere die DNS Suffix Search List per GPO, damit APP1 zuverlässig als APP1.<corp-domain> aufgelöst wird.

Vorteile (explizit)

  • Weniger Angriffsfläche im lokalen Segment: Namensauflösung basiert auf DNS-Autorität statt Broadcast-Rennen.
  • Weniger unklare Auth-Versuche: Du reduzierst „mysteriöse“ Verbindungen zu nicht autoritativen Namen.
  • Bessere Fehlersichtbarkeit: DNS-Probleme werden sichtbar und werden behoben, statt durch Fallbacks kaschiert.
  • Netz-Hygiene: Weniger Broadcast/Multicast-Rauschen.

Nachteile und Grenzen (explizit)

  • Legacy-Abhängigkeiten: Einzelne Alt-Anwendungen/Appliances können NetBIOS voraussetzen (meist indirekt über Shortnames).
  • Kurzfristiger Troubleshooting-Aufwand: Du wirst Namen finden, die „irgendwie immer gingen“, aber technisch nie sauber waren.
  • Kein Ersatz für Segmentierung: Das Abschalten reduziert die Oberfläche, ersetzt aber keine Netzwerk-Segmentierung oder Admin-Tiering-Disziplin.

Typische Stolperfallen aus Projekten

  • DNS-Suffix nicht definiert: Nach Abschalten fällt auf, dass Shortnames ohne Suffix nicht zuverlässig auflösbar waren.
  • WINS/DHCP Altlasten: DHCP verteilt noch WINS-Server oder Node-Type-Optionen, die NetBIOS-Verhalten beeinflussen.
  • „Sondernetze“ ohne AD-DNS: OT/Legacy-Segmente hängen an anderen DNS-Setups – dort braucht es ein separates Zielbild.
  • Uneinheitliche Clients: VPN-Profile, WLAN, virtuelle NICs – das Startup-Skript muss alle Interfaces treffen.

Projekt-Checkliste (kurz, umsetzbar)

  1. Pilot-Scope definieren (OU + Rollback-Plan).
  2. LLMNR per GPO deaktivieren (domainweit, schnell).
  3. DNS-Suffix-Suchliste definieren und testen.
  4. NBT-NS/NetBIOS per Startup-Skript deaktivieren (stufenweise).
  5. Betriebsprüfung: Compliance-Check (Registry/GPO) + Monitoring auf Namensauflösungsfehler.
  6. Ausnahmen dokumentieren (Owner, Ablaufdatum, technische Abgrenzung).