Suchen

Mehr Schutz vor Denial-of-Service-Attacken DNS mit Richtlinien und RRL in Active Directory absichern

| Autor / Redakteur: Thomas Joos / Peter Schmitz

DNS ist einer der wichtigsten Dienste in Netzwerken, da nahezu alle internen Serverdienste auf die Namensauflösung per DNS setzen. Bezüglich der Sicherheit sollten Administratoren aber nacharbeiten. Wir zeigen, welche Möglichkeiten es gibt.

Um ihr Active Directory (AD) und die DNS-Server besser schützen zu können, sollten sich Admins auch mit den Richtlinien im DNS auseinandersetzen.
Um ihr Active Directory (AD) und die DNS-Server besser schützen zu können, sollten sich Admins auch mit den Richtlinien im DNS auseinandersetzen.
(© areebarbar - stock.adobe.com)

Neben den Sicherheitseinstellungen für DNS-Server, die wir im Artikel „DNS in Windows-Netzwerken absichern“, inklusive Video, behandelt haben, sollten sich Administratoren auch mit den Richtlinien in DNS auseinandersetzen. Diese können Active Directory und die DNS-Server zusätzlich schützen.

Um Active Directory und DNS sicher zu betreiben, können diese Richtlinien einen echten Mehrwert bieten, da besser festgelegt werden kann, wer das Recht hat Anfragen an DNS-Server zu stellen. Richtlinien sind mit Windows Server 2016 und Windows Server 2019 umsetzbar. Auf den Seiten „Neues in DNS-Server unter Windows Server“ und „DNS-Richtlinien (Übersicht)“ werden die Richtlinien und deren Möglichkeiten beschrieben.

Neben Richtlinien, bieten Windows Server 2016 und Windows Server 2019 auch Schutz vor Denial of Service-Attacken. Dazu wird Response Rate Limiting (RRL) eingesetzt. Wir gehen auch auf diese Sicherheits-Funktion und die Einstellungen dazu in diesem Beitrag ein.

Mit DNS-Richtlinien Abfragen filtern

Ohne Richtlinien beantworten DNS-Server generell alle Anfragen, die durch die Firewall an den DNS-Server durchgelassen werden. Mit Windows Server 2016 und Windows Server 2019 können die DNS-Anfragen durch DNS-Server gefiltert werden. Hier lassen sich verschiedene Filter definieren, zum Beispiel auf Basis des Subnetzes der Clients, IPv4- und IPv6-Anfragen, Netzwerkadapter des Servers, Uhrzeit, Anfragetypen und andere. Die Zonen auf dem DNS-Server lassen sich in den Richtlinien aufteilen, sodass nicht alle Daten einer Zone abgefragt werden können und zusätzlich kann ein DNS-Server zwischen internen und externen Clients unterscheiden.

Richtlinien werden in der PowerShell über das CMDlet „Add-DnsServerQueryResolutionPolicy“ erstellt. Ein Beispiel sieht folgendermaßen aus:

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"

Der Befehl ermöglicht das Blockieren von Anfragen auf Basis eines Filters, oder das Erstellen von Whitelists. Eine Blockierung wird mit „-Action IGNORE“ erreicht. Richtlinien zum Erlauben von Anfragen werden mit der Option „-Action ALLOW“ definiert. Neben dem CMDlet zum Erstellen einer Richtlinie, gibt es weitere CMDlets, mit denen Richtlinien verwaltet werden:

  • Get-DnsServerQueryResolutionPolicy
  • Remove-DnsServerQueryResolutionPolicy
  • Set-DnsServerQueryResolutionPolicy
  • Add-DnsServerClientSubnet
  • Get-DnsServerClientSubnet
  • Add-DnsServerZoneScope
  • Add-DnsServerResourceRecord
  • Set-DnsServerRecursionScope
  • Add-DnsServerZoneTransferPolicy

Mit „Get-DnsServerQueryResolutionPolicy“ werden vorhandene Richtlinien angezeigt, „Remove-DnsServerQueryResolutionPolicy“ löscht Richtlinien. Um Richtlinien anzupassen wird „Set-DnsServerQueryResolutionPolicy“ verwendet.

Bildergalerie
Bildergalerie mit 7 Bildern

Um Client-Subnetze als Filter zu nutzen, müssen diese zuerst angelegt werden. Dazu wird „Add-DnsServerClientSubnet“ genutzt. Um zum Beispiel ein Objekt zur Client-Filterung anzulegen, wird der folgende Befehl verwendet:

Add-DnsServerClientSubnet -Name InternSubnet -IPv4Subnet 192.168.178.0/24

Mit „Get-DnsServerClientSubnet“ lassen sich wiederum die erstellten Subnetze anzeigen. Es lassen sich auch mehrere Subnetze in einem Filterobjekt speichern. Dazu werden die Subnetze durch Komma getrennt. Das macht die Befehle etwas einfacher.

Werden Richtlinien in kleinen Netzwerken betrieben, ist die Leistung eines Servers kaum beeinträchtigt, da hier auch eher weniger Anfragen zu erwarten sind. In großen Netzwerken kann es bei zahlreichen Anfragen aber durchaus passieren, dass ein Server durch die Verwaltung und Anwendung der Richtlinien mehr Leistung benötigt als ohne Richtlinien.

Response Rate Limiting - Schutz vor Denial of Service

Um sich vor einem zu starken Leistungseinbruch zu schützen und auch Denial of Service (DoS)-Attacken abzuwehren, unterstützen Windows Server 2016 und Windows Server 2019 die Funktion Response Rate Limiting (RRL). Damit lassen sich die maximalen Anfragen festlegen, die ein Server pro Sekunde beantwortet. Alternativ kann mit RRL auch festgelegt werden, wieviele Fehler pro Sekunde erlaubt sind, und wieviel Zeit zwischen Abfragen ablaufen muss, bis die nächste Abfrage vom Client gestellt werden kann. Auch Limits pro Clients können auf dieser Basis gesteuert werden. Natürlich lassen sich Clients, Subnetze und auch Netzwerkadapter des DNS-Servers von RRL-Filtern ausnehmen.

Aktuelle RRL-Einstellungen lassen sich mit „Get-DnsServerRRL“ anzeigen. Einstellungen werden wiederum mit „Set-DnsServerRRL“ angepasst. Bei „Mode“ ist zu sehen, ob der Dienst aktuell bereits schon gestartet ist (Enable) oder ob er noch inaktiv ist (Disable). Standardmäßig ist RRL in Windows Server 2016 und Windows Server 2019 inaktiv. Die dritte Option von RRL ist aktiviertes Logging. Bei dieser Einstellung werden die Einstellungen von RRL angewendet, der Server blockiert aber keine Anfragen, sondern protokolliert diese nur. Der Protokollmodus wird mit folgendem Befehl aktiviert:

“Set-DNSServerRRL -Mode LogOnly”

Um RRL zu aktivieren, wird der folgende Befehl verwendet:

„Set-DNSServerRRL -Mode Enable“

Als Limit verwenden die beiden Befehle die Grenzwerte, die mit Get-DnsServerRRL“ angezeigt werden.

(ID:46494569)

Über den Autor

 Thomas Joos

Thomas Joos

Freiberuflicher Autor und Journalist