9
DNSSEC - Umgang mit DNS-Anfragen
Guten Abend liebe Kolleginnen und Kollegen,
wir beschäftigen uns aktuell wieder mit dem Thema DNSSEC unter Windows Server. Ist ein heißes Thema was zu einem heißen Tag passt.
Nachstehend die Grundlagen für Windows (Server):
DNSSEC in Windows
DNSSEC – What Is It and Why Is It Important?
Windows client and server operating system compatibility with DNSSEC enabled root servers ,
Genauer gesagt geht es um die Windows Server welche als DNS-Server in den Domänen agieren. In der Regel sind unsere DNS-Server gleichzeitig auch Domain Controllers. Im ersten Schritt geht es um die Validierung von DNS-Anfragen welche nicht duch den DNS-Server selbst beantwortet werden können, sondern durch die konfigurierten Forwarder.
Die Konfiguration der DNSSEC Validierung ist an jedem DNS-Server innerhalb von 5 Minuten erledigt.
Kollege @lcer00 hat dazu den Tipp DNSSEC Validation für Windows Server aktivieren geschrieben.
Der erste Knackpunkt ist die Installation des Root Trust Point. Hierzu gibt es von Microsoft natürlich auch Lesestoff: Deploy a Root Trust Point. Damit verbunden auch die erste Firewall Regel für alle DNS-Server. Soweit überschaubar, da die Datei von IANA nicht über ein CDN o.ä. bereitgestellt wird, sondern eine dedizierte Adresse bzw. IP-Adresse. Es ist mit dem Worten der Kollegen "ein Traum für Firewall Admins".
Der zweite Knackpunkt ist, dass durch die Aktivierung der Validierung ab sofort jeder DNS-Server in Netzwerk einen Haufen an DNS-Anfragen (Port 53/tcp) stellt. Und zwar an die autoritativen Nameserver der jeweiligen TLD. Nachstehend eine Schaubild von RIPE zur Verdeutlichung:
Damit verbunden müssten an der Firewall für alle betroffenen Servern im Netzwerk der Port 53/tcp ins Internet freigeben werden. Der Request wird so natürlich niemals in allen betroffenen Teams freigeben werden. Weil dadurch eine kritische Komponente, nämlich das Active Directory/DNS in die Nähe des Internet kommt. Zudem steigt damit auch das Sicherheitsrisiko nicht nur für die Server sondern für die ganze Landschaft. Es ist somit theroetisch möglich, dass Angreifer jeden beliebigen DNS-Server abfragen können ohne dass es direkt auffallen wird/kann.
Wer von euch hat mir für den zweiten Knackpunkt eine Idee, wie ich das Sicherheitsrisiko deutlich minimieren kann?
Evtl. hat sich jemand damit noch intensiver beschäftigt und kann sogar parktische Ansätze skizzieren.
Gruß,
Dani
wir beschäftigen uns aktuell wieder mit dem Thema DNSSEC unter Windows Server. Ist ein heißes Thema was zu einem heißen Tag passt.
Nachstehend die Grundlagen für Windows (Server):
DNSSEC in Windows
DNSSEC – What Is It and Why Is It Important?
Windows client and server operating system compatibility with DNSSEC enabled root servers ,
Genauer gesagt geht es um die Windows Server welche als DNS-Server in den Domänen agieren. In der Regel sind unsere DNS-Server gleichzeitig auch Domain Controllers. Im ersten Schritt geht es um die Validierung von DNS-Anfragen welche nicht duch den DNS-Server selbst beantwortet werden können, sondern durch die konfigurierten Forwarder.
Die Konfiguration der DNSSEC Validierung ist an jedem DNS-Server innerhalb von 5 Minuten erledigt.
Kollege @lcer00 hat dazu den Tipp DNSSEC Validation für Windows Server aktivieren geschrieben.
Der erste Knackpunkt ist die Installation des Root Trust Point. Hierzu gibt es von Microsoft natürlich auch Lesestoff: Deploy a Root Trust Point. Damit verbunden auch die erste Firewall Regel für alle DNS-Server. Soweit überschaubar, da die Datei von IANA nicht über ein CDN o.ä. bereitgestellt wird, sondern eine dedizierte Adresse bzw. IP-Adresse. Es ist mit dem Worten der Kollegen "ein Traum für Firewall Admins".
Der zweite Knackpunkt ist, dass durch die Aktivierung der Validierung ab sofort jeder DNS-Server in Netzwerk einen Haufen an DNS-Anfragen (Port 53/tcp) stellt. Und zwar an die autoritativen Nameserver der jeweiligen TLD. Nachstehend eine Schaubild von RIPE zur Verdeutlichung:
Damit verbunden müssten an der Firewall für alle betroffenen Servern im Netzwerk der Port 53/tcp ins Internet freigeben werden. Der Request wird so natürlich niemals in allen betroffenen Teams freigeben werden. Weil dadurch eine kritische Komponente, nämlich das Active Directory/DNS in die Nähe des Internet kommt. Zudem steigt damit auch das Sicherheitsrisiko nicht nur für die Server sondern für die ganze Landschaft. Es ist somit theroetisch möglich, dass Angreifer jeden beliebigen DNS-Server abfragen können ohne dass es direkt auffallen wird/kann.
Wer von euch hat mir für den zweiten Knackpunkt eine Idee, wie ich das Sicherheitsrisiko deutlich minimieren kann?
Evtl. hat sich jemand damit noch intensiver beschäftigt und kann sogar parktische Ansätze skizzieren.
Gruß,
Dani
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3119243054
Url: https://administrator.de/contentid/3119243054
Ausgedruckt am: 23.11.2024 um 07:11 Uhr
9 Kommentare
Neuester Kommentar
Dein Problem ist jetzt, dass deine DNS Server, die auf dem Domaincontroller laufen, ein Sicherheitsproblem werden, wenn sie DNS Server im öffentlichen Internet anfragen?
Hallo Dani,
Ich kann leider dazu nichts beitragen, würde aber gern das Problem verstehen:
Viele Grüße, commodity
Ich kann leider dazu nichts beitragen, würde aber gern das Problem verstehen:
... durch die Aktivierung der Validierung ab sofort jeder DNS-Server in Netzwerk einen Haufen an DNS-Anfragen (Port 53/tcp) stellt. Und zwar an die autoritativen Nameserver der jeweiligen TLD.
DNS braucht nach meinem Verständnis doch immer ausgehend einen Port (idR 53) zum Upstream-DNS. Woher bekommt Dein AD denn aktuell seine DNS-Informationen? Wo ist der Unterschied?Viele Grüße, commodity
Moin,
Gruß,
Dani
Dein Problem ist jetzt, dass deine DNS Server, die auf dem Domaincontroller laufen, ein Sicherheitsproblem werden, wenn sie DNS Server im öffentlichen Internet anfragen?
Problem ist im jetztigen Stadium des Themas vermutlich das falsche Wort - meine Befürchtung. Die Antwort auf die Frage ist: Ja.DNS braucht nach meinem Verständnis doch immer ausgehend einen Port (idR 53) zum Upstream-DNS. Woher bekommt Dein AD denn aktuell seine DNS-Informationen? Wo ist der Unterschied?
Wir haben mehrere Child Domains im Einsatz. Dieser Fragen bei der übergeordenten Root Domain nach. Diese wiederrum reicht die Anfragen an einen dedzierten DNS Server in der jeweiligen DMZ weiter. Wenn dort die Anfrage nicht beanwortet werden kann, werden die Root DNS Server kontaktiert (da bin ich mir gerade nicht zu 100% sicher). Sprich eine klar definierte Kette mit verschiedenen Maßnahmen und Rahmenbedingungen.Gruß,
Dani
Hallo,
ist es nicht so, dass nur ein recursiv anfragender Resolver die DNSSEC records wie Du es beschreibst abfragt? Der fragt ja aber auch die anderen Records ( A, PTR, etc) vom jeweiligen zuständigen DNS Server ab.
Wenn ihr auf den untergeordneten DNS-Servern klassische Weiterleitungen konfiguriert habt und recursive Abfragen deaktiviert habt, sollten die keine solchen wilden queries entstehen.
(Ich habe das aber nicht getestet und auch keine explizite Quelle für meine Einschätzung.)
Grüße
lcer
ist es nicht so, dass nur ein recursiv anfragender Resolver die DNSSEC records wie Du es beschreibst abfragt? Der fragt ja aber auch die anderen Records ( A, PTR, etc) vom jeweiligen zuständigen DNS Server ab.
Wenn ihr auf den untergeordneten DNS-Servern klassische Weiterleitungen konfiguriert habt und recursive Abfragen deaktiviert habt, sollten die keine solchen wilden queries entstehen.
(Ich habe das aber nicht getestet und auch keine explizite Quelle für meine Einschätzung.)
Grüße
lcer
Moin @lcer00
Gruß,
Dani
Wenn ihr auf den untergeordneten DNS-Servern klassische Weiterleitungen konfiguriert habt und recursive Abfragen deaktiviert habt, sollten die keine solchen wilden queries entstehen.
Ich habe deinen Kommentar nun jeden Tag gelesen. Wirft aber jedes Mal die selbe Frage auf: Redest du von Weiterleitungen oder von rekusiven Abfragen? Weil das sind zwei grundverschiedene Dinge in der Windows Welt.Gruß,
Dani
Hallo,
Beispiel: DNS-Server-A führt rekursive Abfragen aus und darf alle DNS-Server im Internet abfragen. Die DNS-Server-(1-99) haben eine Weiterleitung (bind9: forwarders) auf DNS-Server-A eingerichtet und auf denen sind rekursive Abfragen verboten.
Also:
DNS-Server-A:
Set-DnsServerRecursion -Enable true
DNS-Server-(1-99)
Set-DnsServerRecursion -Enable false
Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
Dann sollten die DNS-Server-(1-99) immer nur den DNS-Server-A fragen (forwarder) und nie über die root-hints anfangen recursiv aufzulösen.
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/revi ...
Grüße
lcer
Zitat von @Dani:
Moin @lcer00
bei bind9 auch.Moin @lcer00
Wenn ihr auf den untergeordneten DNS-Servern klassische Weiterleitungen konfiguriert habt und recursive Abfragen deaktiviert habt, sollten die keine solchen wilden queries entstehen.
Ich habe deinen Kommentar nun jeden Tag gelesen. Wirft aber jedes Mal die selbe Frage auf: Redest du von Weiterleitungen oder von rekusiven Abfragen? Weil das sind zwei grundverschiedene Dinge in der Windows Welt.Beispiel: DNS-Server-A führt rekursive Abfragen aus und darf alle DNS-Server im Internet abfragen. Die DNS-Server-(1-99) haben eine Weiterleitung (bind9: forwarders) auf DNS-Server-A eingerichtet und auf denen sind rekursive Abfragen verboten.
Also:
DNS-Server-A:
Set-DnsServerRecursion -Enable true
DNS-Server-(1-99)
Set-DnsServerRecursion -Enable false
Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
Dann sollten die DNS-Server-(1-99) immer nur den DNS-Server-A fragen (forwarder) und nie über die root-hints anfangen recursiv aufzulösen.
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/revi ...
Grüße
lcer
Moin,
Gruß,
Dani
Set-DnsServerRecursion -Enable false
Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
Danke für den Hinweis. Ich habe mir die Beschreibung des cmdlet durchgelesen. Soweit ich das verstehe funktioniert Forwarding dann aber auch nicht mehr:Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
The Set-DnsServerRecursion cmdlet modifies recursion settings for a Domain Name System (DNS) server. Recursion occurs when a DNS server queries other DNS servers on behalf of a requesting client, and then sends the answer back to the client.Gruß,
Dani
Hallo,
OK. Habe nochmal die cmdlets durchgesehen: unter https://docs.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserv ... findet man:
das müsste dann aber passen.
Grüße
lcer
Zitat von @Dani:
Moin,
Moin,
Set-DnsServerRecursion -Enable false
Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
Danke für den Hinweis. Ich habe mir die Beschreibung des cmdlet durchgelesen. Soweit ich das verstehe funktioniert Forwarding dann aber auch nicht mehr:Add-DnsServerForwarder -IPAddress {IP von DNS-Server-A}
The Set-DnsServerRecursion cmdlet modifies recursion settings for a Domain Name System (DNS) server. Recursion occurs when a DNS server queries other DNS servers on behalf of a requesting client, and then sends the answer back to the client.OK. Habe nochmal die cmdlets durchgesehen: unter https://docs.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserv ... findet man:
-UseRootHint
Specifies whether to prevent the DNS server from performing iterative queries. If you set UseRootHint to $false, the DNS server forwards unresolved queries only to the DNS servers in the forwarders list and does not try iterative queries if the forwarders do not resolve the queriesGrüße
lcer
Moin,
Wie gesagt, DNSSEC => Off, keine Anfragen an fremde DNS-Server sichtbar. DNSSEC => On, füllt sich das Log in Sekunden.
Gruß,
Dani
das müsste dann aber passen.
die Verwendung von den DNS Root Servern ist standardmäßig deaktiviert. Zudem würde das Verhalten, dem von dir geposteten Link anderenfalls vollumfänglich wiedersprechen.Wie gesagt, DNSSEC => Off, keine Anfragen an fremde DNS-Server sichtbar. DNSSEC => On, füllt sich das Log in Sekunden.
Gruß,
Dani
