DDoS-Attacke durch recursive DNS-Queries
Zahlreiche Admins erhalten die letzten Tage verzweifelte E-Mails ihrer durch eine DDoS-Attacke angegriffenen Kollegen. Für den Angriff werden ihre falsch konfigurierte DNS-Server mißbraucht, um eine Traffic-DDoS-Attacke auszulösen. Das Opfer klagt, über 50.000 DNS-Server wären weltweit in den Angriff involviert. Einzige Abhilfe: Eine wichtige (und richtige) Konfigurationsänderung. Unser Schaubild zeigt den Ablauf des Angriffs: Durch das in DNS-Abfragen übliche UDP-Protokoll kann der Angreifer sehr leicht DNS-Queries an beliebige Nameserver stellen, die als Quell-IP die IP-Adresse des angegriffenen Opfers tragen (1). Der angefragte DNS-Server wird seine spätere Antwort darum an den Opfer-Server zurücksenden (3). 
Das alleine wäre noch kein DDoS-Angriff. Der Angreifer muß es also nun darauf anlegen, möglichst viel Traffic zum Opfer senden zu lassen. Also fragt er nach speziell präparierten TXT-Records seiner eigenen Domain (2). Der Vorteil am TXT-Feld im DNS ist, daß sich hier viel Text und damit echtes Datenvolumen unterbringen läßt. Da die mißbrauchten DNS-Server die DNS-Abfrage lokal cachen, kann der Angreifer nun fortlaufend Tausende von gefälschten DNS-Queries per UDP lossenden, ohne daß seine eigene DNS-Infrastruktur durch den Traffic ernsthaft belastet wird (4). Die mißbrauchten DNS-Server arbeiten jedoch nun für den Angreifer und erzeugen fortlaufend große Datenpakete zum Opfer -- ein klassischer Distributed Denial of Service (DDoS).
So muß der Nameserver konfiguriert werden
Das Problem ist, daß die mißbrauchten DNS-Server "open recursive" sind. Das heißt: DNS-Abfragen für ihre eigenen von ihren authoritativ gehosten Domains ("primary/secondary DNS") müssen sie natürlich aus dem ganzen Internet annehmen und beantworten. DNS-Abfragen nach fremden Domains ("recursive Queries"), für die sie also keine lokalen Zonefiles besitzen, dürfen sie genaugenommen nur für eigene Server, Netze oder Einwahlbereiche vornehmen. Oft ist das jedoch für alle IP-Adressen der Welt offen -- es stört in der Regel ja nicht, weil ja niemand sonst diese DNS-Abfragen stellt. Wichtig ist in diesem DDoS-Angriff also, daß die mißbrauchten DNS-Server keine Queries mehr von überall her ("any") zulassen -- dann würde der gefälschte DNS-Query des Angreifers kurzerhand abgelehnt und nicht beantwortet werden. In der Konfigurationsdatei des populären DNS-Servers bind ist das schnell eingetragen. An passender Stelle (named.conf, named.conf.local bzw. bei Debian named.conf.options) ist in den options-Block einzutragen:
options {
[...]
allow-recursion { x.x.x.x/x, 10.0.0.0/8; 192.168.0.0/16;
127.0.0.0/8; ::1; };
[...]
}
wobei x.x.x.x/x natürlich durch die jeweiligen eigenen IP-Netzbereiche zu ersetzen ist. Anschließend muß named neu gestartet werden.
Und so wird getestet
Der Erfolg ist schnell zu sehen. Während zuerst eine rekursive Abfrage nach einer fremden Domain noch beantwortet wurde:
peer@booster:~> dig heinlein-support.de @ns.example.com ; <<>> DiG 9.7.4-P1 <<>> heinlein-support.de @ns.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6997 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;heinlein-support.de. IN A ;; ANSWER SECTION: heinlein-support.de. 34 IN A 91.198.250.115 ;; AUTHORITY SECTION: heinlein-support.de. 3334 IN NS ns.jpberlin.de. heinlein-support.de. 3334 IN NS ns2.jpberlin.de. ;; ADDITIONAL SECTION: ns.jpberlin.de. 1534 IN A 213.203.238.4 ns2.jpberlin.de. 1534 IN A 194.150.191.56 ;; Query time: 29 msec ;; SERVER: xxx ;; WHEN: Mon Jul 23 15:55:30 2012 ;; MSG SIZE rcvd: 129
Wird anschließend die Beantwortung abgelehnt. Der Angreifer kann keinen nennenswerten Traffic mehr zum Opfer erzeugen:
peer@booster:~> dig heinlein-support.de @ns.example.com ; <<>> DiG 9.7.4-P1 <<>> heinlein-support.de @ns.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18795 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;heinlein-support.de. IN A ;; Query time: 27 msec ;; SERVER: xxx ;; WHEN: Mon Jul 23 15:55:44 2012 ;; MSG SIZE rcvd: 37
Wer diese Konfigurationsanpassung nicht vornimmt muß ein schlechtes Gewissen haben. Er ist dann Teil des Angriffs und hilft dem Angreifer bei seiner Attacke (und bezahlt den Traffic...).
Kommentare
12 Antworten zu DDoS-Attacke durch recursive DNS-Queries
Bei mir funktioniert es nicht Bind antwortet weiter rekursive Anfragen!
Tja... Wenn Du die Config schickst, dann kann ich gerne mal reinschauen und den Fehler suchen. Schick mir Config und die IP des Nameservers per Mail, dann schau ich rauf.
Danke für die interessante Darstellung; ich habe unseren DNS entsprechend konfiguriert, weiß aber jetzt nicht, wie ich das testen kann (unser eigenes Netzt darf entsprechend auflösen).
Vielen Dank und beste Grüße aus Österreich
Georg
Hallo Georg. Testen kannst Du es eben, indem Du mal von einer externen IP aus kommst. DSL-Dialup, UMTS, sonstwas. Oder indem Du mal Abends Dein eigenes Netz aus der DNS-ACL rausnimmst und dann schaust, ob nichts mehr geht :-)
Hallo,
vielen Dank für die Anleitung. Ich lasse bei mir recursive Queries nur von localhost zu
<code>
options {
[...]
allow-recursion { 127.0.0.1/32; };
};
</code>
Danach erhalte ich statt eines Eintrags bei ANSWER 13 unter AUTHORITY. Damit ist das Problem nicht wirklich behoben, oder?
<code>
; <> DiG 9.7.3 <> heinlein-support.de @myserver
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45475
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;heinlein-support.de. IN A
;; AUTHORITY SECTION:
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
;; Query time: 15 msec
;; SERVER: xxx
;; WHEN: Mon Mar 18 16:08:56 2013
;; MSG SIZE rcvd: 248
</code>
Doch, sieht doch alles gut aus. Du kriegst keine Antwort und es gibt ja sogar explizit den Hinweis,daß recursion nicht erlaubt ist.
Danke für die ausführliche Beschreibung, aber was mache ich auf einem Windows Server SBS 2011 mit Exchange, der scheint das rekursive DNS zu benötigen, ich finde aber keine Möglichkeit die allow-recursion zu verändern?
Danke
Christian
Hmm, tja. Windows-Admins vor. Ich habe leider ECHT keine Ahnung von Windows-Servern...
Hallo Peer, (hoffe du liest das noch mit)
als jüngstes Opfer einer DDoS Attacke und Herzklopfen nach einer abuse-email habe ich nach langen Recherchen im Internet genau deine Anleitung gefunden und auch so umgesetzt. Jedoch haben mich die weiterhin eintreffenden DDoS Anfragen sehr beunruhigt obwohl sie nun "Refused" werden.
Ist das nun noch gefährlich oder kann ich nun beruhigt sein?
Am liebsten würde ich eine Firewall-Regel einbinden, die solche Anfragen nicht zu lässt oder die Beantwortung unterdrückt.
Oder sind solche Antworten mit 39 Bytes nur als Internet Müll zu betrachten?
Dank
Bernhard
Das eigentliche Ziel dieser DDoS-Attacken ist ja nicht der Recursive Nameserver -- der wird ja nur als Mittel zum Zweck genutzt um das eigentliche Opfer zu fluten.
Die 39 Byte Anfragen sollten Dich und Deinen Server kalt lassen. Müll, Grundrauschen, total egal. Du lehnst das ab und damit ist gut. Und eine ernsthafte Belastung für den Server sollte das ja nicht sein.
Höchstens WENN es eine spürbare Belastung ist würde ich mich da drum kümmern.
Hallo Peer,
ok, muss mir also kein Sorgen (Herzklopfen) mehr machen :-)
Danke.
Hallo Peter,
gibt es hier noch andere methoden um einen DNS-server gegen diese methoden zu schützen?
ich würde gern meinen DNS-Server weiterhin für ein projekt offen betreiben und kann daher keine ip-ranges explizit zuweisen/verbieten...
wäre hier sehr dankbar für weitere hilfe damit diese DDoS kram aufhört.
Gruß
Thhunder
P.S.: mail wäre bevorzugt zur kontaktaufnahme :-)