Wer im kleinen Umfang einen privaten DNS-Server, möglicherweise für sich und ein paar Freunde betreibt, hat vielleicht schon mal in die Querylogs geschaut und sich über (regelmäßig und gruppenweise auftretende) DNS-Anfragen aus obskuren Netzen gewundert. Mit obskur meine ich vor allem die Fragestellung, wieso jemand aus Ostsibirien gerade diesen Server befragt oder wie um alles in der Welt er überhaupt von dessen Existenz weiß.

Natürlich kommt man schnell zu der Vermutung, dass hier Schabernack getrieben wird. So geschehen bei mir, was sich nach kurzer Inspektion als DNS-Amplification-Angriff auf ein großes soziales Netzwerk heraus stellte. Hierbei handelt es sich um eine spezielle, relativ leicht und sehr günstig durchzuführende Denial-of-Service-Attacke, deren Grundprinzip schon im hohen Zeitalter der E-Mail als Backscatter bekannt war.

Im Großen und Ganzen geht es immer darum, dass man eine (legitime) Anfrage mit gefälschter Absenderkennung an einen Dienst richtet und dessen (legitime) Antwort darauf hin nicht die reale Ursprungsadresse, sondern die vom Urheber gewünschte Adresse erreicht. Anders ausgedrückt; das Opfer bekommt aus heiterem Himmel die Antwort auf eine Frage, die es gar nicht gestellt hat.

Gegenüber Botnetzen ist der klare Vorteil, dass keine Trojaner oder ähnliches auf den Systemen selbst eingeschleust werden müssen, was auch wieder einen beträchtlichen Aufwand mit sich brächte. Serverdienste sind nunmal per Definition mehr oder weniger erreichbar. Ansonsten wären es keine Serverdienste oder welche mit sehr fragwürdigem Nutzen.

Dass sich gerade DNS-Server außerordentlich gut für einen solchen Angriff eignen, hat drei Gründe:

1. Geeignete DNS-Server sind sehr leicht und in großer Zahl aufspürbar

Man muss nichts weiter tun, als beliebige Netzbereiche nach offenen Servern zu scannen. Findet man einen solchen, testet man, ob dort auch wirklich Anfragen in geeigneter Weise beantwortet werden. Wenn ja, merkt man sich die Adresse und über Nacht wächst eine hübsche Liste heran. In den meisten Fällen hat man es wahrscheinlich auch noch mit einem Administrator zu tun, der das entweder gar nicht weiß oder sich nicht darum kümmert.

[In meinem konkreten Fall habe ich etwa zwei Wochen bevor der eigentliche Angriff losging eine russische IP-Adresse in meinen Logs bemerkt, die einmal täglich „google.com“ aufgelöst hat. Da mein Server brav geantwortet hat, wanderte ich damit wohl auf so eine Liste.]

2. DNS benutzt hauptsächlich UDP

Durch diesen Umstand bekommt man eine effiziente Verschleierung des Angriffsursprungs frei Haus. UDP-Pakete (korrekterweise UDP/IP-Pakete) verhalten sich weitgehend wie Postkarten. Sie enthalten Informationen wie Absender, Ziel und was eigentlich los ist. Nicht mehr und nicht weniger. Niemand, erst recht nicht der Empfänger, kann ohne horrenden Aufwand den Wahrheitsgehalt dieser Informationen prüfen. (Das würde die Vorteile des verbindungs- und zustandslosen UDP auch sofort ad absurdum führen.) Ein Dienst, der auf eine per UDP empfangene Anfrage antwortet, wird seine Antwort in bestem Wissen an die als „Absender“ eingetragene Adresse schicken. Das ist weder Bug noch Sicherheitslücke, sondern bewusst so designed worden. (Das Fälschen solcher Informationen, gerade in Bezug auf Adressen nennt man übrigens Spoofing.)

3. Der Knackpunkt: Wenig Frage, viel Antwort

Bis jetzt kann man sich gerne fragen, wieso dieser seltsame Angreifer sein Paket nicht einfach direkt an sein Opfer schickt. Wenn es doch so einfach ist, die Absenderadresse eines UDP/IP-Pakets zu fälschen, wieso dann nicht „von zuhause aus“ und noch den Umweg über einen anderen Server und zusätzlich noch über das DNS gehen? Ganz einfach: Setzt man ein spezielles DNS-Query ab, erhält man eine Antwort, die im „besten“ Fall über 50x so groß ist wie das Fragepaket. Genauer gesagt ca. 60 Byte gegenüber 3000+ Byte. Das begründet, wieso man diese Geschichte „amplification“ (=Verstärkung) nennt.

Um sich den Faktor 50 mal schnell zu verdeutlichen:

z.B. 10000 offene DNS-Server (halte ich für leicht zu sammeln)
10000 * 60 Byte, die der Angreifer aussenden muss = 0,6 Megabyte
10000 * 3000 Byte Antworten der DNS-Server = 30 Megabyte an das Ziel

(Bandbreiten, Übertragungsraten usw. mal außen vor gelassen)

Wie gesagt: Offene DNS-Server stehen auf der ganzen Welt und warten auf Arbeit – oft ohne das Wissen ihrer Administratoren. Wieviele Nullen man also noch in die Rechnung einfügen kann, probiere ich mal nicht aus. Ich habe auch keine Daten, wieviel UDP-Traffic man genau braucht, um Störungen in der gewünschten Dimension zu verursachen. Aber ich denke, dass die Theorie hinter dieser Methode so faszinierend simpel ist, dass sie schon irgendwer hoch genug skalieren oder verfeinern wird, um damit genügend Schaden anzurichten.

Das ist ziemlich schlimm, oder?

Kommt drauf an, aus welcher Perspektive man das sehen will. Solche Attacken laufen aufgrund ihrer Einfachheit den ganzen Tag, rund um die Uhr, überall im Netz. Und trotzdem läuft das Internet noch. Da die Möglichkeit zum einfachen Fälschen bei UDP/IP inhärent ist, wird ein „großer Admin“ auch allenfalls mit den Schultern zucken und sowas als Spielerei im allgemeinen Netzrauschen belächeln. Selbst wenn das Ausmaß eines solchen Angriffs bedenklich werden sollte, bleiben die dafür missbrauchten Server jeweils die selben, weshalb man deren Adressen schnell aussperren kann.

Ein deutliches Problem ist allerdings, dass das Internet nicht nur aus den „großen Playern“ besteht, und natürlich auch kleinere Systeme damit belastet werden können. Kleine Systeme und Netze in dem Sinne, dass dort keine automatischen, adaptiven Türstehersysteme sofort für Ruhe sorgen, wenn der Radau losgeht. Für solche und schon allein fürs gute Admingewissen sollte man also doch etwas tun…

Was tun?

Ganz generell sollte man einfach keinen DNS-Server betreiben, der unnötig offen reagiert.

Ich selbst habe nur eine Holzhammer-Methode umgesetzt. Ich will hier auch nicht lange auf die verschiedenen Betriebsmodi und Ausprägungen von Nameservern an sich eingehen oder detaillierte HowTos geben. (Ich bin mir nichtmal sicher, ob es HowTos gegen dieses Szenario gibt. Das alles ist ja schon ziemlich „exploitable-by-design“.) Also erzähle ich nur schnell, was ich gemacht habe und überlasse das Weiterdenken und Verfeinern dem geneigten Leser.

Weiße Listen, schwarze Löcher und der unausweichliche Holzhammer

Ich betreibe meinen Nameserver primär für mich allein. Also habe ich definiert, dass nur Anfragen aus den Netzen akzeptiert werden, in denen ich auch unterwegs bin. Sprich, zwei große Provider und eine Universität. In welchen IP-Adressen sich das konkret äußert, lässt sich mit etwas Beobachtung, dem Linux-Tool ipcalc und letzendlich der IPv4-Allocation List des RIPE herausbekommen.

Hat man seine möglichen IP-Adressen dann zusammengetragen, kann man eine Whitelist einrichten, damit nur auf Anfragen aus diesen Netzen reagiert wird. Hier muss man allerdings einen Haken beachten: Eine unbefugte Anfrage wird gegebenenfalls nicht ignoriert, sondern immernoch aktiv mit „nicht erlaubt“ beantwortet. Und das ist schonwieder eine Antwort, die zu einem potentiellen Opfer dirigiert werden könnte. Zwar ist diese Antwort „nur noch“ genauso groß wie die Anfrage selbst, aber als Quelladresse des bösen Pakets klebt trotzdem noch unser DNS-Server statt dem eigentlichen Angreifer drauf. Reicht also nicht aus.

Es ist bei mancher Nameserver-Software weiterhin möglich, Listen zu definieren, für die gar keine Antwort erzeugt wird. BIND z.B. bietet hierfür sogenannte blackhole-Direktiven an. Aufgeführte Netze werden völlig ignoriert, es gibt also gar keine Antwort. Das klingt schon eher nach unserer gesuchten Lösung, aber man schießt sich damit fürchterlich ins eigene Knie.

Wieso? Stellen wir uns vor, über unseren DNS-Server wird eine Amplification-Attacke auf „example.com“ gefahren. Folglich tragen die Requests, die wir sehen, „example.com“ als Absender. Jetzt können wir diesen Absender blackhole’n und haben Ruhe. Aber was ist, wenn wir selbst, als Nutzer unseres Nameservers ganz normal auf example.com surfen möchten? Dann fragt unser Browser unseren Nameserver nach der Adresse von „example.com“. Sollte dieser sie nicht in seinem Cache haben und sie auch sonst nirgends herbekommen, landet unser Request irgendwann, im schlechtesten Fall, bei den hauseigenen Nameservern von „example.com“. Diese packen bereitwillig eine Auskunft zusammen und … schießen sie genau in unser vorhin definiertes blackhole. Feierabend.

Es scheint, als hätte man innerhalb der DNS-Software nicht wirklich die Chance, das zufriedenstellend zu regeln. Und deshalb nun die eingangs erwähnte Holzhammermethode:

Auftritt iptables:

iptables -A INPUT -s XXXXXX -p udp --dport 53 -j DROP

Die einfachste denkbare Regel. Sie verwirft alle UDP-Pakete, die von „XXXXXX“ aus an unseren DNS-Port (53) klopfen. Diese Regel blockiert also DNS-Anfragen aus dem betreffenden Netz, steht unseren eigenen Anfragen an dieses Netz aber nicht wie ein blackhole im Weg!

Man kann das nach Belieben erweitern. Zum Beispiel kann man hier alle „freundlichen“ Netze explizit erlauben (localhost nicht vergessen!), und alle anderen auf einen Schlag aussperren. Zusätzlich können wir TCP-Verbindungen an unseren Port 53 verbieten, da mir kein legitimer Grund für solche auf meinem privaten DNS-Server einfällt.

iptables -A INPUT -s 127.0.0.1 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -s UniNetzAB -p udp --dport 53 -j ACCEPT
iptables -A INPUT -s UniNetzXY -p udp --dport 53 -j ACCEPT
iptables -A INPUT -s ProviderZ -p udp --dport 53 -j ACCEPT

iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Soweit schon ziemlich gut. Nur leider, leider immernoch nicht perfekt. Egal ob Whitelist, Blackhole oder harte Sperre im Routing: Wenn der Angreifer nicht in einem „obskuren Netz“ sitzt, sondern innerhalb eines erlaubten Netzes, hilft das alles nicht. Deshalb kommt man mit keinem der hier angerissenen Ansätze drum herum, seine Logs kontinuierlich auf verdächtige Aktivität zu überwachen (oder das einem schlauen Skript zu übertragen?) und die betreffenden Netze in jedem Einzelfall zu blockieren.

 

Ergänzende Informationen bietet der Wikipedia-Artikel zum Thema.