Werden autoritative DNS-Server über reflektierende DNS-Angriffe missbraucht, zum Beispiel um in einem Distributed Denial of Service (DDoS) Angriff ein Zielsystem zu überlasten, so ist eine der vorgeschlagenen Massnahmen DNS Response Rate Limiting (DNS RRL) zu aktivieren.
SWITCH hat auf diesem Blog bereits in früheren Posts über DNS Angriffe und Massnahmen berichtet. In diesem Artikel möchten wir unsere neusten Beobachtungen im Betrieb von DNS RRL teilen und zeigen, dass es Anzeichen gibt, dass die Angreifer die Schwächen von DNS RRL ausnutzen um weiterhin ihre Angriffe durchführen zu können.
Stärken und Schwächen von DNS RRL
Für viele autoritative DNS Serverbetreiber war DNS RRL eine ersehnte Lösung um die Serverlast und vor allem die ausgehende Serverbandbreite aufgrund von reflektierenden DNS-Angriffen einzuschränken. DNS RRL lässt für einen IP-Adressbereich nur eine bestimmte Anzahl identische DNS Antworten zu. Wird der konfigurierte Schwellwert überschritten, verwirft DNS RRL zum einen die DNS-Antwort. Für einen anderen Teil der Antworten wird das “Truncated”-Bit (TC) in der Antwort gesetzt, damit wird der DNS Resolver aufgefordert, die Anfrage noch einmal über TCP zu stellen. Da bei reflektierenden DNS-Angriffen die Quelladresse gefälscht wird, kommt nie eine Verbindung über TCP zu Stande. Im Gegensatz zu Firewall-Regeln hat der DNS RRL Ansatz den Vorteil, dass bei einem leicht geänderten Angriffs-Pattern (z.B. Query-Name ändert) die implementierten Firewall-Regeln nicht angepasst werden müssen. Kurz, DNS RRL ist sehr effektiv gegenüber Angriffen, bei denen DNS-Anfragen gesendet werden, welche in identischen Antworten resultierten.
Wie aber auch von anderen festgestellt (NlNetLabs (PDF)), hat DNS RRL auch seine Schwächen. Insbesondere, ist DNS RRL ineffizient, wenn der Angreifer verschiedene Anfragen stellt, welche in unterschiedlichen Antworten resultieren, oder wenn der Angreifer von vielen unterschiedlichen IP Adressen die DNS-Anfragen schickt. Für den ersten Fall, setzt dies voraus, dass der Angreifer Teil des Zonen-Inhalts oder der autoritativen Zonen kennt. Im zweiten Fall führt der Angreifer gleichzeitig einen DDoS-Angriff auf mehrere Angriffsziele durch.
Angreifer passen sich an
Auf einem unseren DNS-Servern, welcher autoritativ für einige hundert Domains ist, konnten wir in letzter Zeit beobachten, dass die Angreifer auch Kenntnis der DNS RRL Schwächen haben.

Die DSC Grafik zeigt, dass rund 200 DNS ANY Anfragen an den Server geschickt werden. Keine dieser DNS-Anfragen wird von DNS RRL “gefiltert”. Der Grund ist:
- der Angreifer sendet pro Query-Name maximal nur so viele DNS-Anfragen, wie unser DNS RRL Schwellwert zulässt.
- der Angreifer sendet die DNS-Anfragen mit mehreren unterschiedlichen gefälschten IP-Adressen.
In diesem Angriffsbeispiel werden nur sehr wenige DNS-Anfragen geschickt. Uns geht es in diesem Beispiel nicht um die Anzahl von Anfragen, sondern darum, dass bestehende Massnahmen (in diesem Fall DNS RRL) umgangen werden.
Wir haben uns die Frage gestellt, ob der Angreifer immer die selben Query-Namen sendet oder ob diese stark variieren. Folgende Grafik zeigt über eine Woche die vom Angreifer benutzten Query-Namen.
Es ist ersichtlich, dass der Angreifer mehrheitlich mit einem konstanten Satz von Query-Namen arbeitete und diese über einen Zeitraum auch gleich häufig benutzte.
Wir wollten auch prüfen, ob der Angreifer die Quelladressen über einen Zeitraum konstant hielt. Die Folgende Grafik zeigt die Anzahl DNS-Anfragen pro Quelladresse über knapp fünf Tage verteilt.

Für die Grafik wurden nur die zwölf häufigsten verwendeten Quelladressen benutzt. Insgesamt, tauchten über 16’407 verschiedene Quelladressen auf. 75% der DNS-Anfragen wurden jedoch mit den erwähnten zwölf Quelladressen gesendet. Die Zahl der Quelladressen, welche am stärksten benutzt wurden lässt sich also auf ein paar wenige reduzieren. Wie in der Grafik ersichtlich, kommen von gewissen IP-Adressen mehr DNS-Anfragen, als ein Schwellwert von zum Beispiel 10 zulassen würde. Die Grafik zeigt nicht, dass in diesem Fall mehrere Query-Namen benutzt wurden und so der Angreifer trotzdem unter dem Schwellwert blieb.
Interessanterweise hatten alle analysierten DNS-Anfragen dieselbe IP TTL (Hop-Count). Das lässt darauf schliessen, dass diese wenigen DNS-Anfragen von einem einzelnen Host hätten gesendet werden können. Es ist uns natürlich klar, dass der Angreifer den DNS-Server massiv stärker hätte missbrauchen können. Einen Schwellwert von zum Beispiel 10 identischen DNS-Antworten pro IP-Adressbereich, lässt sich wie folgt ausnutzen:
- Anstatt nur einen Query-Namen können zum Beispiel 1000 unterschiedliche Query-Namen verwendet werden, welche in unterschiedlichen DNS-Antworten resultieren.
- Pro Query-Name können immer noch maximal 10 Anfragen pro Sekunde (qps) gesendet werden.
- Die Zahl der gefälschten Quelladressen kann von einer IP-Adresse auf zum Beispiel 5 erhöht werden.
1000 x 10 x 5 = 50’000 qps
Mit dem obigen Rechenbeispiel könnte der Angreifer also 50’000 qps schicken, ohne dass seine Anfragen „gefiltert“ würden. Wir müssen also zur Kenntnis nehmen, dass die Angreifer bereits jetzt unsere DNS RRL Filter umgehen. Momentan scheinen die Angreifer mit den Open-Resolvers noch eine einfachere Methode gefunden zu haben und lassen die autoritativen DNS Server-Betreiber eher wieder in Ruhe.
Empfehlung
Eine konkrete Empfehlung um die autoritativen DNS-Server von diesen Angriffen zu schützen gibt es momentan nicht. Eine aggressivere Lösung wie DNS-Dampening wäre zwar effizienter, jedoch wollen wir DNS-Dampening nicht einsetzen, weil mittels IP-Spoofing legitime DNS-Resolver relativ einfach komplett gesperrt werden könnten. Wir haben deshalb das Sperren von einzelnen Quelladressen über unsere Firewall Regeln optimiert. Diese Prozedur wird grössten Teils manuell sein, da wir keine legitimen DNS-Resolver sperren wollen.
DNS Dampening gestattet durchaus das Whitelisting und eine angepaßte Parametrisierung. Der von NLlabs getestete Code war ein Frühstadium ohne jede Konfigurationsmöglichkeit. Es hatte sich also schon zeitig etwas getan.
Hallo Lutz. Danke für dein Feedback. Ich nehme dein Input zum Anlass, dass wir DNS Dampening selber im der Praxis testen. Dann kann ich hoffentlich in Zukunft auch eine faire Empfehlung abgeben.
Haut mich bitte, wenn’s nicht tut, wie ihr wollt. Es ist *mein* Code für *meinen* Zweck.