Sicherheitsvorteile

Einführung: Sicherheitsbedrohungen und Abhilfemaßnahmen für DNS

Aufgrund des offenen, verteilten Designs des Domain Name Systems und seiner Verwendung des User Datagram Protocol (UDP) ist DNS anfällig für verschiedene Angriffe. Öffentliche oder „offene“ DNS-Resolver sind besonders gefährdet, da sie eingehende Pakete nicht auf eine Reihe zulässiger Quell-IP-Adressen beschränken. Es geht vor allem um zwei häufige Angriffe:

  • Spoofing-Angriffe, die zu DNS-Cache-Poisoning führen Es gibt zahlreiche Arten von DNS-Spoofing und Fälschungen, mit denen Nutzer von legitimen Websites zu schädlichen Websites weitergeleitet werden sollen. Dazu gehören auch sogenannte Kaminsky-Angriffe, bei denen Angreifer eine maßgebliche Kontrolle über eine gesamte DNS-Zone übernehmen.
  • DoS-Angriffe (Denial of Service) Angreifer können DDoS-Angriffe gegen die Resolver selbst starten oder Hacker lösen, um DoS-Angriffe auf anderen Systemen zu starten. Angriffe, bei denen DNS-Server verwendet werden, um DoS-Angriffe auf anderen Systemen zu starten, indem große DNS-Einträge bzw. -Antworten ausgenutzt werden, werden als Verstöße bezeichnet.

Jede Angriffsklasse wird weiter unten erläutert.

Cache-Poisoning-Angriffe

Es gibt verschiedene Varianten von DNS-Spoofing-Angriffen, die zu Cache-Vergiftungen führen können. Das allgemeine Szenario sieht jedoch so aus:

  1. Der Angreifer sendet einem DNS-Ziel-Resolver mehrere Abfragen für einen Domainnamen, von dem er weiß, dass der Server nicht autoritativ ist und der sich wahrscheinlich nicht im Cache des Servers befinden wird.
  2. Der Resolver sendet Anfragen an andere Nameserver, deren IP-Adressen der Angreifer ebenfalls vorhersagen kann.
  3. In der Zwischenzeit überflutet der Angreifer den Opferserver mit gefälschten Antworten, die scheinbar vom delegierten Nameserver stammen. Die Antworten enthalten Datensätze, die die angeforderte Domain letztlich in IP-Adressen auflösen, die vom Angreifer kontrolliert werden. Sie können Antwortdatensätze für den aufgelösten Namen enthalten oder – schlimmer noch – die Autorität an einen Nameserver delegieren, der dem Angreifer gehört, damit er die Kontrolle über die gesamte Zone hat.
  4. Wenn eine der gefälschten Antworten mit der Anfrage des Resolvers übereinstimmt (z. B. nach Abfragename, Typ, ID und Quellport des Resolvers) und vor einer Antwort vom echten Nameserver empfangen wird, akzeptiert der Resolver die gefälschte Antwort, speichert sie im Cache und verwirft die echte Antwort.
  5. Zukünftige Abfragen für die manipulierte Domain oder Zone werden mit den gefälschten DNS-Auflösungen aus dem Cache beantwortet. Wenn der Angreifer für die gefälschte Antwort eine sehr lange Gültigkeitsdauer angegeben hat, bleiben die gefälschten Datensätze so lange wie möglich im Cache, ohne dass sie aktualisiert werden.

Eine hervorragende Einführung in Kaminsky-Angriffe finden Sie im Illustrierten Leitfaden zu DNS-Sicherheitslücken in Kaminsky.

DoS- und Verstärkungsangriffe

DNS-Resolver unterliegen den üblichen DoS-Bedrohungen, mit denen Netzwerke verbunden sind. Allerdings sind Verstärkungsangriffe besonders besorgniserregend, weil DNS-Resolver attraktive Ziele für Angreifer sind, die ein hohes Verhältnis von Antwort zur Anfrage zur Steigerung der kostenlosen Bandbreite nutzen. Resolver, die EDNS0 (Extension Mechanisms for DNS) unterstützen, sind besonders anfällig aufgrund der wesentlich größeren Paketgröße, die sie zurückgeben können.

Bei einem Verstärkungsszenario geht der Angriff so vor:

  1. Der Angreifer sendet eine DNS-Serverabfrage des Opfers über eine gefälschte Quell-IP-Adresse. Die Abfragen können von einem einzelnen System oder einem System aus Systemen gesendet werden, die alle dieselbe gefälschte IP-Adresse verwenden. Die Abfragen beziehen sich auf Datensätze, von denen der Angreifer weiß, dass sie zu deutlich größeren Antworten führen können – bis zu ein paar Mal1 wie die ursprünglichen Abfragen (also der Name „amplification“-Angriff).
  2. Der Opferserver sendet die umfangreichen Antworten an die in den gefälschten Anfragen übergebene Quell-IP-Adresse. Dadurch wird das System überlastet und es kommt zu einer DoS-Situation.

Risikominderungen

Die standardmäßige systemweite Lösung für DNS-Sicherheitslücken ist DNSSEC. Allerdings müssen offene DNS-Resolver unabhängig voneinander einige Maßnahmen ergreifen, um bekannte Bedrohungen zu minimieren, bis sie universell implementiert sind. Es wurden viele Techniken vorgeschlagen. Eine Übersicht über die meisten dieser Methoden findest du unter IETF RFC 5452: Measurements to make DNS DNS about gefälscht answers. In Google Public DNS haben wir folgende Ansätze implementiert und empfohlen:

  • Schutz Ihres Codes vor Zwischenspeicherüberläufen, insbesondere dem Code für das Parsen und Serialisieren von DNS-Nachrichten
  • Überdimensionierung von Maschinenressourcen zum Schutz vor direkten DoS-Angriffen auf den Resolver selbst Da die Fälschung von IP-Adressen für Angreifer trivial ist, ist es nicht möglich, Abfragen auf der Grundlage von IP-Adressen oder Subnetzen zu blockieren. Die einzige effektive Methode zum Umgang mit solchen Angriffen besteht darin, die Last einfach zu absorbieren.
  • Implementierung einer grundlegenden Validierung der Antwortpakete und der Glaubwürdigkeit des Nameservers, um eine einfache Cache-Poisoning zu verhindern Dies sind Standardmechanismen und Plausibilitätsprüfungen, die jeder standardkonforme Caching-Resolver ausführen sollte.
  • Hinzufügen einer Entropie zum Anfordern von Nachrichten, um die Wahrscheinlichkeit komplexerer Spoofing-/Cache-Poisoning-Angriffe wie Kaminsky-Angriffe zu verringern Es gibt viele empfohlene Techniken zum Hinzufügen einer Entropie. Nachstehend finden Sie eine Übersicht über die Vorteile, Einschränkungen und Herausforderungen für jede dieser Techniken und darüber, wie sie in Google Public DNS implementiert wurden.
  • Doppelte Abfragen werden entfernt, um die Wahrscheinlichkeit von „Geburtstagsangriffen“ zu verringern.
  • Anfragen zur Ratenbegrenzung, um DoS und Angriffe zu verhindern
  • Monitoring des Dienstes für die Client-IP-Adressen mit der höchsten Bandbreite und dem höchsten Verhältnis von Antwort zur Anfragegröße.

DNSSEC

Der DNSSEC-Standard (Domain Name Security Extensions) ist in mehreren IETF-RFCs angegeben: 4033, 4034, 4035 und 5155.

Resolver, die DNSSEC-Counter-Cache-Poisoning-Angriffe implementieren, indem sie die Authentizität von Antworten verifizieren, die von Nameservern empfangen werden. In jeder DNS-Zone wird eine Reihe von privaten und öffentlichen Schlüsselpaaren angelegt. Für jeden DNS-Eintrag wird eine eindeutige digitale Signatur mit dem privaten Schlüssel generiert und verschlüsselt. Der entsprechende öffentliche Schlüssel wird dann über eine Kette von Schlüsseln authentifiziert, die zu übergeordneten Zonen gehören. DNSSEC-kompatible Resolver lehnen Antworten ab, die nicht die richtigen Signaturen enthalten. DNSSEC verhindert effektiv, dass Antworten manipuliert werden, da es in der Praxis praktisch unmöglich ist, Signaturen ohne Zugriff auf private Schlüssel zu fälschen.

Ab Januar 2013 wird DNSSEC von Google Public DNS vollständig unterstützt. Wir akzeptieren und leiten DNSSEC-formatierte Nachrichten weiter und validieren Antworten zur korrekten Authentifizierung. Wir empfehlen dringend anderen Resolvern, dasselbe zu tun.

Außerdem speichern wir NSEC-Antworten, wie in IETF RFC 8198: Aggressive Use of DNSSEC-Validated Cache angegeben. Dadurch können NXDOMAIN-Abfragen auf Nameserver reduziert werden, die DNSSEC implementieren und NSEC für negative Antworten verwenden.

Clientseitig verschlüsselte Transporte

Google Public DNS unterstützt verschlüsselte Transportprotokolle, DNS über HTTPS und DNS über TLS. Diese Protokolle schützen sich vor Manipulationen, Abhören und Spoofing und verbessern dadurch den Datenschutz und die Sicherheit zwischen einem Client und Google Public DNS. Sie ergänzen DNSSEC und ermöglichen eine durchgängige authentifizierte DNS-Suche.

Grundlegende Validierungsprüfungen einrichten

Einige DNS-Cache-Beschädigungen können durch unbeabsichtigte und nicht unbedingt böswillige Abweichungen zwischen Anfragen und Antworten verursacht werden, z.B. aufgrund eines falsch konfigurierten Nameservers, eines Fehlers in der DNS-Software usw. Zumindest sollten DNS-Resolver Prüfungen durchführen, um die Glaubwürdigkeit und Relevanz der Nameserver-Antworten zu prüfen. Wir empfehlen (und implementieren) alle folgenden Schutzmaßnahmen:

  • Legen Sie das rekursive Bit nicht in ausgehenden Anfragen fest und folgen Sie den Delegationsketten immer explizit. Wenn Sie das rekursive Bit deaktivieren, wird der Resolver im Modus „iterativ“ ausgeführt, sodass jeder Nameserver in der Delegationskette explizit abgefragt wird, anstatt dass ein anderer Nameserver diese Abfragen in Ihrem Namen ausführt.
  • Verdächtige Antwortnachrichten ablehnen. Unten finden Sie weitere Details dazu, was wir als „verdächtig“ erachten.
  • Geben Sie keine A-Einträge an Clients zurück, die auf Glue Records basieren, die aus vorherigen Anfragen im Cache gespeichert wurden. Wenn Sie beispielsweise eine Clientabfrage für ns1.beispiel.de erhalten, sollten Sie die Adresse auflösen, anstatt einen A-Eintrag mit im Cache gespeicherten Glue Records zu senden, der von einem .com-TLD-Nameserver zurückgegeben wird.

Antworten ablehnen, die die erforderlichen Kriterien nicht erfüllen

Folgendes wird vom Google Public DNS abgelehnt:

  • Nicht geparste oder fehlerhafte Antworten.
  • Antworten, bei denen Schlüsselfelder nicht mit den entsprechenden Feldern in der Anfrage übereinstimmen. Dazu gehören die Abfrage-ID, die Quell-IP-Adresse, der Quellport, die Ziel-IP-Adresse oder der Abfragename. Eine vollständige Beschreibung von DNS-Spoofing-Verhalten finden Sie in RFC 5452, Abschnitt 3.
  • Datensätze, die für die Anfrage nicht relevant sind.
  • Antworteinträge, für die wir die CNAME-Kette nicht rekonstruieren können.
  • Einträge in der Antwort, der Autorität oder zusätzlichen Abschnitten, für die der entsprechende Nameserver nicht glaubwürdig ist. Wir bestimmen die „Glaubwürdigkeit“ eines Nameservers anhand seines Platzes in der Delegationskette einer bestimmten Domain. Google Public DNS speichert Informationen zur Delegationskette im Cache und wir überprüfen jede eingehende Antwort anhand der im Cache gespeicherten Informationen, um die Glaubwürdigkeit des antwortenden Nameservers für die Beantwortung einer bestimmten Anfrage zu ermitteln.

Entropie zu Anfragen hinzufügen

Sobald ein Resolver grundlegende Sanity Checks erzwingt, muss ein Angreifer den Resolver mit Antworten überfluten. Dieser stimmt mit der Abfrage-ID, dem UDP-Port (der Anfrage), der IP-Adresse (der Antwort) und dem Abfragenamen der ursprünglichen Anfrage überein, bevor der legitime Nameserver dies tut.

Leider ist dies nicht schwierig zu erreichen, da das eindeutig identifizierbare Feld, die Abfrage-ID, nur 16 Bit lang ist (d. h. eine Wahrscheinlichkeit von 1/65.536 richtig ist). Die anderen Felder sind ebenfalls im Bereich begrenzt, sodass die Gesamtzahl der eindeutigen Kombinationen eine relativ niedrige Anzahl ist. Eine Berechnung der verwendeten Kombinatoren finden Sie unter RFC 5452, Abschnitt 7.

Die Herausforderung besteht daher darin, dem Anfragepaket so viel Entropie wie möglich im Standardformat der DNS-Nachricht hinzuzufügen, um es Angreifern zu erschweren, eine gültige Kombination von Feldern im Fenster der Opportunity zu finden. Wir empfehlen, alle in den folgenden Abschnitten beschriebenen Verfahren zu implementieren und zu implementieren.

Wir haben eine aktualisierte Überprüfung der hier vorgestellten Verfahren auf der DNS OARC 38-Konferenz im Juli 2022 vorgestellt. Die Präsentation enthält auch Empfehlungen für Nameserver-Operatoren.

Zufällige Quellports

Erlauben Sie grundsätzlich nicht, dass ausgehende Anfragepakete zur Verwendung des Standard-UDP-Ports 53 oder eines vorhersehbaren Algorithmus zur Zuweisung mehrerer Ports (z.B. einfache Inkrementierung) verwendet werden. Verwenden Sie einen möglichst großen Bereich von 1024 bis 65535 Ports in Ihrem System und verwenden Sie einen zuverlässigen Zufallsgenerator, um Ports zuzuweisen. Google Public DNS verwendet beispielsweise ~15 Bit, um etwa 32.000 verschiedene Portnummern zuzulassen.

Wenn Ihre Server hinter Firewalls, Load-Balancern oder anderen Geräten bereitgestellt werden, die Network Address Translation (NAT) verwenden, können diese Geräte zufällige Ports für ausgehende Pakete deaktivieren. Achten Sie darauf, NAT-Geräte so zu konfigurieren, dass die Port-Zufälligkeit deaktiviert wird.

Zufällige Auswahl von Nameservern

Einige Resolver, die Anfragen an das Stammverzeichnis, die TLD oder andere Nameserver senden, wählen die IP-Adresse des Nameservers anhand der kürzesten Entfernung (Latenz) aus. Wir empfehlen, die Ziel-IP-Adressen zufällig auszuwählen, um den ausgehenden Anfragen eine Entropie hinzuzufügen. In Google Public DNS wählen wir einfach zufällig einen Nameserver aus, der für die einzelnen Zonen konfiguriert ist. Dadurch sind einige schnelle und zuverlässige Nameserver bevorzugt.

Wenn Sie Bedenken bezüglich der Latenz haben, können Sie die Umlaufzeit (Round Trip Time, RTT) verwenden. Zu diesem Zweck werden zufällig ausgewählte Adressen in einem Adressbereich unterhalb eines bestimmten Latenzschwellenwerts (z. B. 30 ms, 300 ms usw.) randomisiert.

DNS-Cookies

RFC 7873 definiert eine EDNS0-Option zum Hinzufügen von 64-Bit-Cookies zu DNS-Nachrichten. Ein DNS-Cookie-unterstützter Client enthält ein zufälliges 64-Bit-Cookie und optional (sofern bekannt) ein Server-Cookie in einer Anfrage. Wenn ein unterstützender Server die Cookie-Option in einer Anfrage als gültig einstuft, wird das Client-Cookie und das richtige Server-Cookie in der Antwort widergespiegelt. Der unterstützende Client kann dann überprüfen, ob die Antwort vom erwarteten Server stammt, indem er das Client-Cookie in der Antwort verifiziert.

Wenn ein Nameserver keine DNS-Cookies unterstützt, können die folgenden beiden Optionen zum Hinzufügen einer Entropie verwendet werden.

Zufällige Groß-/Kleinschreibung in Abfragenamen

Die DNS-Standards verlangen, dass Nameserver Namen mit Groß- und Kleinschreibung verarbeiten. Die Namen example.com und EXAMPLE.COM sollten beispielsweise in dieselbe IP-Adresse aufgelöst werden2. Außerdem geben alle bis auf eine kleine Minderheit der Nameserver den Namen in der Antwort zurück, wie er in der Anfrage angezeigt wurde. Dabei bleibt der ursprüngliche Fall erhalten.

Eine weitere Möglichkeit, eine Entropie zu Anfragen hinzuzufügen, besteht daher darin, die Groß- und Kleinschreibung von Buchstaben in abgefragten Domainnamen nach dem Zufallsprinzip zu variieren. Diese Technik, die auch als &0t;0x20" bezeichnet wird, da das Bit 0x20 zur Festlegung der Groß-/Kleinschreibung von US-ASCII-Buchstaben verwendet wird, wurde ursprünglich im IETF-Internetentwurf Nutzung von Bit 0x20 in DNS-Labels zur Verbesserung der Transaktionsidentität vorgeschlagen. Bei dieser Technik muss die Nameserver-Antwort nicht nur mit dem Abfragenamen übereinstimmen, sondern auch mit jedem Buchstaben im Namensstring, z. B. wWw.eXaMpLe.CoM oder WwW.ExamPLe.COm. Dadurch kann eine Entropie zu Anfragen für die Top-Level- und Stammdomains hinzugefügt werden, für die meisten Hostnamen ist sie aber nicht effektiv.

Eine wichtige Herausforderung bei der Implementierung dieses Verfahrens besteht darin, dass einige Nameserver nicht dem erwarteten Antwortverhalten folgen:

  • Einige Nameserver antworten mit vollständiger Groß-/Kleinschreibung. Sie geben unabhängig von der Anfrage in der Anfrage dieselben Ergebnisse zurück, aber die Antwort stimmt nicht genau mit der Groß-/Kleinschreibung des Namens in der Anfrage überein.
  • Andere Nameserver antworten mit vollständiger Berücksichtigung der Groß- und Kleinschreibung (unter Verstoß gegen die DNS-Standards): Sie behandeln die entsprechenden Namen abhängig von der Groß- und Kleinschreibung in der Anfrage entweder überhaupt nicht oder geben falsche NXDOMAIN-Antworten zurück, die genau mit dem Namen der Anfrage übereinstimmen.
  • Mit Ausnahme von PTR-Abfragen in der Zone arpa funktionieren einige Nameserver ordnungsgemäß.

Bei beiden Arten von Nameservern führt die Änderung der Groß-/Kleinschreibung des Abfragenamens zu unerwünschten Ergebnissen: Für die erste Gruppe wäre die Antwort nicht von einer gefälschten Antwort zu unterscheiden. Für die zweite Gruppe könnte die Antwort (falls vorhanden) völlig falsch sein.

Unsere aktuelle Lösung für dieses Problem besteht darin, die Zufallsauswahl von Fällen nur für Nameserver zu verwenden, von denen wir wissen, dass sie die Standards korrekt anwenden. Außerdem auflisten wir basierend auf der Analyse unserer Logs die entsprechenden Ausnahme-Subdomains. Wenn eine Antwort, die von diesen Servern zu kommen scheint, nicht den richtigen Fall enthält, lehnen wir die Antwort ab. Die aktivierten Nameserver verarbeiten mehr als 70% unseres ausgehenden Traffics.

Ausstehende Labels zu Abfragenamen

Wenn ein Resolver einen Namen nicht direkt aus dem Cache auflösen oder einen autoritativen Nameserver nicht direkt abfragen kann, muss er Verweise von einem Root- oder TLD-Nameserver folgen. In den meisten Fällen führen Anfragen an die Root- oder TLD-Nameserver zu einem Verweis auf einen anderen Nameserver und nicht zum Versuch, den Namen in eine IP-Adresse aufzulösen. Daher sollten Sie für solche Anfragen auf jeden Fall ein zufälliges Label an einen Abfragenamen anhängen, um die Entropie der Anfrage zu erhöhen, und riskieren dabei gleichzeitig, dass ein nicht vorhandener Name nicht aufgelöst wird. Das heißt, wenn Sie eine Anfrage an einen verweisenden Nameserver nach einem Namen mit dem Präfix eines einmaligen Labels wie entriih-f10r3.www.google.com senden, sollte das gleiche Ergebnis wie eine Anfrage für www.google.com zurückgegeben werden.

Obwohl solche Anfragen in der Praxis weniger als 3% der ausgehenden Anfragen ausmachen, unter der Annahme, dass der normale Traffic direkt aus dem Cache oder durch eine einzelne Abfrage beantwortet werden kann, sind dies genau die Arten von Anfragen, die ein Angreifer zu lösen versucht. Daher kann diese Technik sehr effektiv dazu beitragen, Exploits im Stil von Kaminsky zu verhindern.

Zur Implementierung dieses Verfahrens müssen Nonce-Labels nur für Anfragen verwendet werden, die garantiert zu Verweisen führen, also Antworten, die im Abschnitt „Antworten“ keine Einträge enthalten. Beim Definieren solcher Anfragen gab es jedoch mehrere Herausforderungen:

  • Einige Länder-TLD-Nameserver (ccTLD) sind für andere TLDs der zweiten Ebene (Authority-Level-TLDs, 2LDs) tatsächlich maßgeblich. Obwohl sie über zwei Labels verfügen, verhalten sich 2LDs wie TLDs, weshalb sie häufig von ccTLD-Nameservern verarbeitet werden. Beispielsweise sind die .uk-Nameserver auch autoritativ für die Zonen mod.uk und nic.uk und damit auch für die Hostnamen in diesen Zonen, z. B. www.nic.uk, www.mod.uk usw. Anders ausgedrückt: Anfragen an ccTLD-Nameserver zur Auflösung solcher Hostnamen führen nicht zu Verweisen, sondern zu verlässlichen Antworten. Das Anfügen von Nonce-Labels an diese Hostnamen führt dazu, dass die Namen nicht aufgelöst werden können.
  • Manchmal geben generische TLD-Nameserver (gTLD) nicht verbindliche Antworten für Nameserver zurück. Das heißt, dass einige Nameserver-Hostnamen in einer gTLD-Zone und nicht in der Zone ihrer Domain existieren. Eine gTLD gibt eine nicht verbindliche Antwort für diese Hostnamen zurück und verwendet dazu den Glue Record, der sich in ihrer Datenbank befindet, anstatt einen Verweis zurückzugeben. Beispiel: Der Nameserver ns3.indexonlineserver.com befand sich bisher in der gTLD-Zone .COM und nicht in der Zone indexonlineserver.com. Als wir einen Antrag an n3.indexonlineserver.com an einen gTLD-Server gesendet haben, haben wir anstelle einer Weiterleitung eine IP-Adresse dafür erhalten. Wenn wir jedoch ein Nonce-Label vorangestellt haben, haben wir einen Verweis auf indexonlineserver.com erhalten, der den Hostnamen dann nicht auflösen konnte. Daher können wir keine Nonce-Labels für Nameserver anhängen, die eine Auflösung von einem gTLD-Server erfordern.
  • Die Berechtigungen für Zonen und Hostnamen ändern sich im Laufe der Zeit. Dies kann dazu führen, dass ein nicht vorbereiteter Hostname, der einmal auflösbar war, nicht mehr wieder geändert werden konnte, wenn sich die Delegationskette änderte.

Zur Bewältigung dieser Herausforderungen haben wir Ausnahmen für Hostnamen konfiguriert, an die wir keine Nonce-Labels anhängen können. Dies sind Hostnamen, für die TLD-Nameserver gemäß unseren Serverprotokollen Nichtverweis-Antworten zurückgeben. Die Liste der Ausnahmen wird regelmäßig überprüft, um sicherzustellen, dass sie im Laufe der Zeit gültig bleibt.

Doppelte Abfragen entfernen

DNS-Resolver sind anfällig für „Geburtstagsangriffe“, da diese ausgenutzt werden, weil sie das mathematische „Geburtstagsparadox“ ausnutzen, bei dem die Wahrscheinlichkeit einer Übereinstimmung keine große Anzahl von Eingaben erfordert. Angriffe auf den Geburtstag erfordern eine Überflutung des Opferservers nicht nur mit gefälschten Antworten, sondern auch mit ersten Abfragen. Dabei wird der Resolver verwendet, um mehrere Anfragen nach einer einzelnen Namensauflösung zu senden. Je größer die Anzahl der ausgehenden Anfragen ist, desto größer ist die Wahrscheinlichkeit, dass der Angreifer eine dieser Anfragen mit einer gefälschten Antwort abgleicht: Ein Angreifer benötigt nur eine Anfrage mit einer Größenordnung von 300 in Bearbeitung befindlichen Anfragen bei einer Erfolgsquote von 50% bei einer Übereinstimmung mit einer gefälschten Antwort und 700 Anfragen bei nahezu 100 % Erfolg.

Zum Schutz vor dieser Angriffsstrategie sollten Sie darauf achten, alle doppelten Abfragen aus der ausgehenden Warteschlange zu verwerfen. Beispielsweise erlaubt Google Public DNS nie mehr als eine ausstehende Anfrage für denselben Abfragenamen, Abfragetyp und dieselbe Ziel-IP-Adresse.

Anfragen zur Ratenbegrenzung

Die Verhinderung von Denial-of-Service-Angriffen ist mit einigen besonderen Herausforderungen für offene rekursive DNS-Resolver verbunden:

  • Offene rekursive Resolver sind attraktive Ziele für den Start von Verstärkungsangriffen. Sie sind Server mit hoher Kapazität und hoher Zuverlässigkeit und können größere Antworten liefern als ein typischer autoritativer Nameserver. Das gilt besonders, wenn ein Angreifer eine große Antwort in seinen Cache einschleusen kann. Jeder Entwickler eines offenen DNS-Dienstes ist dafür verantwortlich, dass seine Server nicht zum Starten von Angriffen auf andere Systeme verwendet werden.
  • Während sie auftreten, sind Verstärkungsangriffe manchmal schwer zu erkennen. Angreifer können über Tausende offene Resolver einen Angriff starten, sodass jeder Resolver nur einen Bruchteil des gesamten Abfragevolumens sieht und kein eindeutiges Signal extrahieren kann, dass er manipuliert wurde.
  • Schädlicher Traffic muss ohne Unterbrechung oder Manipulation des DNS-Dienstes an normale Nutzer blockiert werden. DNS ist ein wichtiger Netzwerkdienst. Daher ist das Ausschalten von Servern, um einen Angriff zu beenden, weder eine Option noch einen Dienst zu lange für eine bestimmte Client-IP. Resolver müssen Angriffe schnell blockieren können, sobald sie gestartet wurden, und den voll funktionsfähigen Dienst nach Ende des Angriffs wiederherstellen.

Der beste Ansatz zur Bekämpfung von DoS-Angriffen besteht darin, einen Ratenbegrenzungs- oder Drosselungsmechanismus anzuwenden. Google Public DNS implementiert zwei Arten der Preiskontrolle:

  • Ratenkontrolle ausgehender Anfragen an andere Nameserver. Zum Schutz anderer DNS-Nameserver vor DoS-Angriffen, die von unseren Resolver-Servern gestartet werden könnten, erzwingt Google Public DNS Limits für Abfragen pro Sekunde pro ausgehendem Cluster von jeder Nameserver-IP-Adresse.

  • Ratenkontrolle ausgehender Antworten an Clients. Zum Schutz anderer Systeme vor Verstärkung und traditionellen, verteilten DoS-Angriffen (Botnets) über unsere Resolver gibt es bei Google Public DNS zwei Arten von Ratenbegrenzungen für Clientabfragen:

    • Zum Schutz vor herkömmlichen volumenbasierten Angriffen gibt jeder Server pro Client-IP-Adresse Abfragen pro Sekunde und durchschnittliche Bandbreitenlimits vor.
    • Zum Schutz vor Verstärkungsangriffen, bei denen umfangreiche Antworten auf kleine Abfragen ausgenutzt werden, erzwingt jeder Server einen maximalen durchschnittlichen Verstärkungsfaktor pro Client-IP. Der durchschnittliche Verstärkungsfaktor ist ein konfigurierbares Verhältnis von Antwort-zu-Abfragegröße, das aus den bisherigen Traffic-Mustern in unseren Serverlogs bestimmt wird.

    Wenn DNS-Abfragen von einer Quell-IP-Adresse die maximale Anzahl von Abfragen pro Sekunde überschreiten, werden zusätzliche Abfragen gelöscht. Wenn DNS-Abfragen über UDP von einer Quell-IP-Adresse das durchschnittliche Bandbreiten- oder Verstärkungslimit konsistent überschreiten (die gelegentliche große Antwort wird ignoriert), kann es vorkommen, dass Abfragen gelöscht werden oder nur eine kleine Antwort gesendet wird. Kleine Antworten können eine Fehlerantwort oder eine leere Antwort mit festgelegtem Kürzungsbit sein, sodass die meisten legitimen Abfragen über TCP wiederholt werden und erfolgreich sind. Nicht alle Systeme oder Programme versuchen es noch einmal über TCP. DNS über TCP wird möglicherweise durch Firewalls auf der Clientseite blockiert, sodass einige Anwendungen möglicherweise nicht richtig funktionieren, wenn Antworten abgeschnitten werden. Durch die Kürzung können RFC-konforme Clients jedoch in den meisten Fällen ordnungsgemäß funktionieren.

  1. Im Artikel DNS Amplification Attacks finden Sie Beispiele und eine allgemeine Beschreibung des Problems. ↩

  2. RFC 1034, Abschnitt 3.5 besagt: ↩

    Beachten Sie, dass Groß- und Kleinbuchstaben zwar in Domainnamen zulässig sind, der Fall jedoch keine Bedeutung hat. Das heißt, zwei Namen mit identischer Schreibweise, aber unterschiedlicher Groß-/Kleinschreibung müssen als identisch behandelt werden.