DNS-Amplification-Angriffe: Missbrauch offener Resolver

Ein direkter Flood-Angriff setzt voraus, dass der Angreifer die Bandbreite, die er ausliefert, selbst besitzt. Ein Reflection-Angriff nicht. Der Angreifer sendet einen mäßigen Strom kleiner Anfragen an viele fremde Server, und diese Server schicken die großen Antworten an das Opfer. DNS ist dafür seit Jahren ein Favorit, weil DNS-Server jedem antworten und Antworten sehr viel größer sein können als Fragen. Dieser Artikel erklärt den Mechanismus, zeigt, wie viel Verstärkung Forscher gemessen haben, und behandelt die Abwehrmaßnahmen, die die IETF dokumentiert.

Der Mechanismus in drei Schritten

1. 1

   Die Quelladresse fälschen

   Der Angreifer sendet eine kleine DNS-Abfrage über UDP und trägt die Adresse des Opfers als Absender ein. UDP hat keinen Handshake, daher überprüft auf dem Weg nichts diese Angabe.

2. 2

   Etwas Großes anfordern

   Eine Abfrage vom Typ ANY mit EDNS(0) kann jeden Record zurückgeben, den ein Name hält, bis zu 4.096 Bytes über UDP. Rossow (2014) merkt an, dass ein Angreifer sogar eine Domain, die er kontrolliert, so konfigurieren kann, dass ihr autoritativer Server genau 4.096 Byte große Antworten liefert. Resolver cachen diese für die Dauer der TTL, sodass der eigene Server des Angreifers die Last kaum bemerkt.

3. 3

   Den Resolver senden lassen

   Jeder Resolver antwortet an die gefälschte Adresse. Tausende Resolver zusammen überfluten das Opfer mit echt aussehenden DNS-Antworten legitimer Server, und der eigentliche Angreifer bleibt verborgen.

Wie groß ist die Verstärkung?

Rossow definiert den Bandbreiten-Verstärkungsfaktor (bandwidth amplification factor, BAF) als die UDP-Nutzdaten-Bytes, die ein Verstärker an das Opfer sendet, geteilt durch die UDP-Nutzdaten-Bytes, die der Angreifer an ihn gesendet hat, wobei Ethernet-, IP- und UDP-Header unberücksichtigt bleiben. Gewöhnliche Lookups nach A- oder MX-Records verstärken kaum. Die folgenden Zahlen gelten für den ANY-basierten Missbrauch von DNS, neben drei weiteren Protokollen, die in derselben Studie von 2014 gemessen wurden. „Top 10 %“ ist der Durchschnitt über das Zehntel der Verstärker, die mit den größten Antworten reagieren.

DNS ist weder der größte noch der einzige Verstärker, aber der bekannteste. Rossow schätzte etwa 7,8 Millionen offene Resolver, indem er aus einem Scan einer Zufallsstichprobe von einer Million IPv4-Adressen hochrechnete, und er identifizierte mindestens 255.819 autoritative Server, eine Untergrenze, sodass der Pool potenzieller Reflektoren enorm war. Der Wert für autoritative Server in der Tabelle wurde an den 1.404 dieser Server gemessen, die für mindestens eine Domain DNSSEC einsetzen, und den Wert für offene Resolver hat er mit einer Domain gemessen, die er selbst kontrollierte. Seine eigene Analyse umfasste mehr als 130 reale Angriffe, und er nennt drei große Vorfälle: 167 Gb/s im Mai 2012, 300 Gb/s gegen Spamhaus im März 2013 und 100 Gb/s im August 2013. In allen drei Fällen missbrauchten Angreifer offene DNS-Resolver mit ANY-Anfragen. Das sind Messungen aus den Jahren 2013 und 2014; die Zahlen verschieben sich, der Mechanismus nicht.

Die Rechnung mit dem Hebel

Da der Faktor das, was das Opfer empfängt, durch das teilt, was der Angreifer sendet, ergibt sich die Bandbreite, die ein Angreifer braucht, aus dem Zielwert geteilt durch den Faktor. Beim Durchschnitt von 28,7 für offene Resolver braucht ein Flood von 1 Gb/s grob 35 Mb/s an gefälschten Abfragen. Beim Wert 98,3 für das obere Zehntel der autoritativen Server sind es etwa 10 Mb/s. Für den Spitzenwert von 4.670 bei NTP beziffert Rossows Abstract es auf 0,02 Prozent der Bandbreite, die der Angreifer beim Opfer ankommen lassen will. Der Faktor ignoriert Paket-Header, sodass der reale Verkehr etwas abweicht, aber der Hebel ist der entscheidende Punkt: Aus einem bescheidenen Uplink wird eine Flut.

Warum die Ursache im Spoofing liegt

Ein Reflection-Angriff funktioniert nur, wenn gefälschte Pakete das Netzwerk des Angreifers verlassen können. Kührer und Kollegen (2014) haben das direkt untersucht. Ihr Remote-Test deckte bis zu 2.692 autonome Systeme auf, die kein Egress Filtering einsetzen, und Rossow zitiert den Befund des Spoofer Project, dass im Juli 2013 25 Prozent der autonomen Systeme Adressfälschung zuließen. Dieselbe Studie berichtet, dass während einer mit der Security-Community durchgeführten Benachrichtigungskampagne die Zahl der für monlist-Amplification anfälligen NTP-Server um mehr als 92 Prozent sank, auch wenn die Autoren sagen, sie könnten nicht beweisen, dass die Kampagne die Ursache war.

Drei Abwehrebenen

• Verhindern, dass gefälschte Pakete das Netzwerk verlassen. BCP 38 (RFC 2827) beschreibt Ingress Filtering, um Denial-of-Service-Angriffe mit gefälschten Quelladressen abzuwehren, und BCP 84 (RFC 3704) erweitert es auf Multihoming-Netzwerke. Das ist die Lösung, die die Ursache beseitigt.
• Keinen offenen Resolver betreiben. BCP 140 (RFC 5358) empfiehlt, Rekursion nur für die vorgesehenen Clients anzubieten, per Zugriffsliste nach Quelladresse, nach eingehender Schnittstelle oder über signierte Abfragen (TSIG oder SIG(0)). RFC 5358 merkt an, dass die Auswahl der Clients nach eingehender Schnittstelle zu Routern für kleine Büros und Privathaushalte mit eingebetteten rekursiven Resolvern passt, die nicht dem gesamten Internet antworten sollten.
• Die Antworten weniger nützlich machen. RFC 8482 gibt Hinweise, ANY-Abfragen mit minimalen Antworten statt mit allem zu beantworten, was der Server hält. DNS Cookies (RFC 7873) geben Servern eine leichtgewichtige Möglichkeit, Clients zu verifizieren und Missbrauch durch Off-Path-Angreifer zu begrenzen. RFC 7766 merkt an, dass der TCP-Handshake Adressfälschung im Allgemeinen verhindert, was TCP gegen Reflection und Amplification nützlich macht, und dass TCP heute beim Response Rate Limiting breit eingesetzt wird. Rossow warnt, dass sorgfältig gestaltete Angriffe schlecht konzipiertes Rate Limiting umgehen können; es ergänzt daher das Filtern gefälschten Verkehrs und ersetzt es nicht.

Prüfen, ob Ihr Resolver offen ist

Testen Sie aus einem Netzwerk, das nicht das des Resolvers selbst ist, und bitten Sie ihn, einen Namen aufzulösen, für den er nicht zuständig ist. Erhalten Sie eine Antwort, bedient er Außenstehende. Ein rein autoritativer Server lehnt rekursive Abfragen zu fremden Zonen typischerweise mit REFUSED ab (die Antwortcodes stehen in Aufbau einer DNS-Nachricht).

dig @192.0.2.53 www.example.com A

Quellen und weiterführende Literatur

• Christian Rossow, Amplification Hell: Revisiting Network Protocols for DDoS Abuse, NDSS Symposium, 2014
• Marc Kührer, Thomas Hupperich, Christian Rossow and Thorsten Holz, Exit from Hell? Reducing the Impact of Amplification DDoS Attacks, 23rd USENIX Security Symposium, 2014, pp. 111-125
• RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (Ferguson and Senie, 2000)
• RFC 3704: Ingress Filtering for Multihomed Networks (Baker and Savola, 2004)
• RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks (Damas and Neves, 2008)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• RFC 7873: Domain Name System (DNS) Cookies (Eastlake and Andrews, 2016)
• RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Abley et al., 2019)