DNS Dos und Windows

Schon im März  2006 haben Randal Vaughn and Gadi Evron (http://www.isotf.org/news/DNS-Amplification-Attacks.pdf) beschrieben, wie verteilte Angriffe über "freundliche" DNS Server möglich sind. Und in der iX Heft 9/12 hat Heise das auch noch einmal aufgefrischt. Und am 24.8 wurden die DNS-Server von Heise dann auch angegriffen. Die ganzen Artikel beschreiben aber in der Regel, wie man einen BIND-Server entsprechend konfiguriert, dass er nicht mehr für diesen Angriff missbraucht werden kann. Allerdings sind auch Windows DNS-Server für diesen Missbrauch durchaus verwendbar.

Wenn Sie einen Windows DNS Server aus dem Internet erreichbar machen, dann sollten Sie die folgenden Hinweise durchlesen.

DNS und Reverse Lookup

DNS Server haben in der Regel zwei Funktionen:

  1. Sie betreiben DNS-Zonen, für die sie autoritativ Auskünfte erteilen
    Wer ein Active Directory mit Windows DNS-Servern betreibt bekommt automatisch auch eine DNS-Zone für die eigenen Active Directory Domäne angelegt. Das ist auch wichtig, damit interne Server sich authentifiziert in diese Domäne eintragen können. Ansonsten würden viele Dienste gar nicht laufen. Diese DNS-Server sind in der Regel aber nur von intern erreichbar. Beim NSLOOKuP liefert ein Client etwas in der Art zurück

    Sie sehen hier die IP-Adressen des Server.
  2. Rekursive Anfragen
    Will ein Client aber einen Namen erfragen, der nicht durch den DNS-Server selbst bedient werden kann, dann kann der DNS-Server den Client entweder an einen anderen DNS-Server verweisen (REFER) oder für den Client die Antwort besorgen und an den Client zurück geben. Meist sind die internen DNS-Server so eingestellt, dass Sie interne Anfragen über einen "Forwarder" an einen DNS-Server Richtung Internet geben und die erhaltene Antwort dann dem Client liefern. Das erkennen Sie z.B. am "unauthorized" bei NSLOOKuP

    Die zweite Option ist eine häufig anzutreffende Konstellation, wenn interne Clients per DNS z.B. externe Adressen auflösen sollen, aber der Client keinen offiziellen DNS-Server fragen darf

Diese beiden Aktionen sind bei korrekter Konfiguration unkritisch und sogar notwendig.

Externe DNS mit Rekursion

Kritisch wird es nun aber, wenn ein DNS-Server aus dem Internet erreichbar ist. Die Erreichbarkeit selbst ist nicht schlimm, schließlich sind DNS-Server dazu da, aus Namen eine IP-Adresse zu machen. Viele Provider betreiben sogar DNS-Server für ihre Kunden, die sie befragen können und für den Kunden die Adresse aus dem Internet "beiholen". Ist ist gute Praxis um die "Root-Server" zu entlasten und durch Caching sogar die Anfragen zu beschleunigen. Nun stellen Sie sich aber mal vor, die betreiben einen eigenen DNS-Server, der unter einer öffentlichen IP erreichbar ist. Wenn dieser Server dann auch Rekusion auf der externen IP-Adresse zulässt, dann können Sie als "Störer" missbraucht werden.

Wenn Sie nun glauben, dass ihren DNS-Server eh niemand benutzt, dann sei ihnen gesagt, dass ein Portscan auf 53/UDP heute sehr einfach ist. Ich brauche dann nur noch z.B. nach "www.google.de" zu suchen und wenn ihr DNS-Server mit antwortet, habe ich einen willigen Helfer gefunden. Hier das Übersichtsbild

Der Missbrauch funktioniert wie folgt (Schritt 2 und 3 werden einmal am Anfang durchlaufen)

  1. Der Angreifer sendet eine DNS-Anfrage an ihren Server und bittet ihn z.B. einen Eintrag zu beschaffen, der möglichst groß ist.
    Für den Angreifer ist das aber nur ein sehr kleines Paket
  2. DNS stellt die Rekursive anfrage (oder Cache)
    Ihr Server holt die Daten entsprechend seiner Konfiguration von extern. Bei der zweiten Anfrage wird er die Daten aus dem lokalen Cache bedienen
  3. Der angefragte Server liefert die "Große" Antwort
  4. Ihr DNS Server sendet die Antwort an ... die angebliche IP-Adresse des Clients
    Da der Angreifer aber eine "falsche" IP-Adresse geliefert hat, sendet ihr DNS-Server nun ein sehr großes Paket an das Opfer

Für den Angreifer ist es also ein kleines Paket von weniger als 100 Byte um einen anderen Server mit einem sehr großen Paket zuzuschütten. Das Ganze funktioniert nur mit UDP da bei TCP-Verbindungen der "kleine" Handshake nicht zustande kommt.

Selbst bei korrekter Konfiguration können Sie einen Missbrauch nicht verhindern, denn auf eine DNS-Anfrage muss der DNS-Server auch antworten. Wenn die Anfrage mit einer falschen Absender-Adresse ankommt, wird ihr Server auch an diese Absenderadresse antworten.
Die kritische Komponente bei einer Falschkonfiguration ist die sehr große Antwort in folge auf eine kleine Anfrage.

Einblicke mit NETMON

Der Microsoft Netzwerkmonitor (NetMon 3) ist ein sehr effektives Mittel um ein Fehlverhalten zu sehen. Einfach einen CAPTuRE-Filter auf UDP-Port 53 einstellen:

Und dann den NETMON starten. Wenn Sie jemand versucht zu missbrauche, dann finden Sie sehr viele DNS-Anfragen und Antworten. Hier ein kleiner Auszug einer solchen Konversation. Die Ü

Schaut man sich die beiden Pakete an, dann ist zum einen die kleine DNS-Anfrage zu erkennen, die vom Server mit einer "großen" Anfrage beantwortet wird.

Damit gelingt es dem Angreifer sich sowohl zu verbergen als auch mit wenig Bandbreite eine große Last zu generieren.

Hilfe durch die Provider ?

Nun wissen wir alle, dass jeden Tage neue (unerfahrene) Personen ihren Server am Internet anschließen und nicht wirklich perfekt sichern. Da nehme ich mich nicht mal davon aus. Ich bin auch nicht allwissend und oft fällt mit ein Fehler auf, den ich schon lange kenne aber einfach wieder übersehen habe. Das oben beschriebene Angriffs-Szenario kann aber nur greifen, wenn Provider ihrem Kunden ein "ungefiltertes" Internet anbietet. Und es wäre durchaus für Provider möglich, solch einen Missbrauch eines nicht sicher konfigurierten Kundensystem zu erkennen. Schon allein das Datenvolumen über den Port 53/UDP wäre ein einfach zu erkennendes Kriterium. Ebenso könnte ein Provider, der einen DNS-Forwarder für seine Kunden anbietet, einfach im DNS-Cache sehen, welche "große Antworten" von wem angefragt wurden oder sogar die angefragten "bösen" Namen blockieren.

Aber es gibt einen ganz anderen Punkte, den die Provider zum Schutz ihrer Kunden (und anderer Server) umsetzen könnten:

  • Stoppen von IP-Spoofing
    Das ganze Angriffsmuster funktioniert nur, weil DNS das Protokoll UDP verwendet und die Source-IP von Providern nicht verifiziert wird. Die angebliche Quell-IP ist ja eine "offizielle" Adresse, nämlich die des anzugreifenden Servern. Der Angreifer aber gibt diese bei der gestellten Anfrage nur "vor". Es wäre für die Zugangsprovider ein einfaches auf Firewall dafür zu sorgen, dass ihre Clients nur IP-Adressen verwenden, die vom Provider auch zugewiesen wurden. Die Transportprovider könnten das anhand der IP-Routingtabellen vielleicht auch, aber das dürfte ein Ressourcenproblem sein. Die Router haben schon genug damit zu tun anhand der Zieladresse den nächten Hop zu finden und kümmern sich nicht um die Quelladresse.

Durch die Möglichkeit des Spoofings ist es auch nicht möglich, den Angreifer dingfest zu machen. Nicht mal der Provider kann ermittelt werden. Nicht mal die Anzahl der bislang durchlaufenen Hops anhand des verbleibenden TTL ist möglich, da ein Angreifer auch den Startwert von 127 ja tiefer ansetzen kann. Spoofing ist also die perfekte Tarnkappe für Angreifer und genau genommen auch für den Zugangsprovider

  • Aktives Monitoring und Reaktion
    Zwischen Provider und Kunde besteht ein Vertragsverhältnis. Meine Autowerkstatt macht mich "natürlich" darauf aufmerksam, wenn bei der Inspektion etwas "festgestellt" wird. Selbst meine Telekom "informiert" mich, wenn mein iPhone mal wieder das Freikontingent erreicht hat und nun gedrosselt arbeitet. Es wäre für den Zugangsprovider ein einfaches den Datenverkehr der Kunden zu müssen. Ich gehe sogar davon aus, dass sie das machen. Sehr hohe DNS-Anteile sollten auf jeden Fall "auffallen" und als Provider habe ich auch einen Ansprechpartner bei meinem Kunden, den ich über die IP-Adresse auch identifizieren kann.

Ist Bandbreite denn wirklich so unwichtig, dass Provider hier gar keine Aktivitäten entfalten. In dem unten analysierten Fall waren das 2,4GByte/Tag (72 GB/Monat) für einen einzigen DNS-Server. Ich habe ja schon lange die Hoffnung aufgegeben, dass die Provider eine Art "Fürsorgepflicht" haben. Oder warten alle wieder mal ab, bis unser Staat Regelungen vorschreibt ?. Sie machen sich ja auch zum "Helfer" einer möglichen Straftat.

Abhilfe mit Bordmitteln ?

Leider ist es mit dem Windows DNS-Server nicht möglich diese Rekursion für bestimmte Subnetze ein oder abzuschalten. Man kann die Rekursion nur komplett deaktivieren. Wenn Sie also nicht auf einer vorgelagerten Firewall den Zugriff auf Port 53/UDP ihres Servers verhindern können, dann bleibt ihnen nur die Option die Rekursion komplett abzuschalten, die per Default eingeschaltet ist.

By default, recursion is not disabled für the DNS Server service. This makes it possible für the DNS server to perform recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. Recursion may be used by attackers to deny the DNS Server service. Therefore, if a DNS server in your network is not intended to receive recursive queries, it should be disabled
Quelle: Securing the DNS Server Service: http://technet.microsoft.com/en-us/library/cc731367.aspx

Wenn Sie Rekursion abschalten, dann verhindert dies nicht nur die Nutzung der direkten Forwarder sondern auch den Zugriff auf die "Root"-Server. Ein so gesicherter DNS-Server kann also NuR noch Anfragen nach Daten seiner eigenen lokalen Zonen beantworten. Allerdings sendet er an die angebliche Absenderadresse immer noch eine Antwort. Nämlich den Hinweis, welche Rootserver es gibt.

Dieses Paket ist aber schon um einiges kleiner und das Schadpotential ist geringer. Wer sich dann aber auf diesem DNS-Server noch die Mühe macht, die Liste der "Root-Server" zu leeren, kann die Antwort noch einmal weiter reduzieren.

Spätestens hier sollte der Angreifer dann verstanden haben, dass er mit diesem DNS-Server nichts mehr viel anstellen kann. Aber leider wird es noch viele andere Server geben, die er für sein böses Spiel verwenden kann.

Tipp für kleine Firmen
Auch wenn es unschön erscheint, so können Sie natürlich ihren internen DNS-Servern die Forwarder definieren und an der Firewall dann per NAT den Weg zu den DNS-Servern des Providers oder der Root-Server öffnen. Dann können sie den eigenen Forwarder auf ihrem TMG/ISA-Server einsparen oder entsprechend dicht machen.
Das gleiche gilt, wenn sie ihre offiziellen Domänen einfach nicht mehr auf dem eigenen DNS-Server betreiben sondern "outsourcen".

Volumen und Traffic: Kleinvieh macht auch Mist

Aufgrund der Standardeinstellung dürfte ein Großteil der Windows DNS, die aus dem Internet erreichbar sind, für solchen Missbrauch erreichbar sein. Und der Server wird sicher auch "gefunden" und dann auch "genutzt". Die kostenfreie Version von PRTG ist ein effektives Hilfsmittel, um diese Lasten zu sehen. Über den "Packetsniffer"-Sensor schneidet PRTG z.B.: Pakete mit und wertet diese nach den Ports entsprechend aus. DNS wird per Default leider nicht getrennt aufgeführt aber ein sehr hoher Anteil an "Infrastruktur"-Paketen sollte sie nervös machen.

Schaut man sich dann die TOP-Connections an, dann ist schnell zu erkennen, dass UDP53 hier sogar alle ersten Plätze belegt und die Datenmenge gar nicht klein ist.

Bei der Anzeige der Verteilung über die Zeit lassen sich die anderen Datenklassen Ausblenden, so dass "Infrastruktur" einen großen Anteil am "Gesamtverkehr" hat. Aber es ist auch zu sehen, dass eine recht gleichmäßig und scheinbar gedrosselte Last anliegt.

 

Das rechte Bild zeigt dann den Rückgang der eingehenden Pakete nach einiger Zeit. Ein Teil der Angreifer hat wohl bemerkt, dass dieser Bot nicht mehr funktioniert.

Interessante Zusatzinformation:
Das System, auf dem dieses Bild entstanden ist, könnte mit 6 Megabit bidirektional kommunizieren, aber abgesehen von einem Ausschlag am Anfang pendelt die "Infrastruktur"-Last fast kontinuierlich um die 200kBit herum. Umgerechnet auf den Tag ergibt ist aber auch 2,4 GByte Transfervolumen pro Tag oder 72GB/Monat, welches sowohl auf diesem Anschluss die Performance beschränkt aber vor allem beim Zielsystem des Angriffs sich durch mehrere missbrauchte Server aufsummiert. Das System ist damit unfreiwillig ein Werkzeug einer DDoS-Attacke geworden.

Auch die einfache SNMP-Anfrage des WAN-Routers, der natürlich keine Informationen über die einzelnen Dienste hat, liefert Zusatzinformationen:

Die Aufnahmen sind zu einer Zeit entstanden, an der kaum "Fremdverkehr" über die Leitung gegangen ist, d.h. die angezeigten Datenvolumen zeigen fast nur DNS und nach dem ersten Drittel ist der Drop der gelben Leitung (Ausgehender Traffic) zu sehen. Ab hier ist die umkonfiguration des DNS-Servers erfolgt. Es hat dann aber noch einige Stunden gedauert, bis auch ein Teil der Angreifer sein UDP-Versand an den vormals offenen Server einstellt. Sie sollten also hellhörig werden, wenn während normaler "Ruhezeiten" (Feiertage o.ä.) eine fast kontinuierliche Grundlast anliegt.

Weitere Links