Denic führt DNSSEC ein: neue Technik mit kleinen Tücken

Die zusätzlichen DNS-Antworten bleiben für Nutzer nicht folgenlos: Die meisten NAT-Router kommen damit nicht zurecht. ZDNet erläutert die neue Technologie und zeigt, welche Einstellungen man ändern muss, um alle Domains zu erreichen.

Seit dem 5. Januar hat die Denic damit begonnen, die Sicherheitstechnologie DNSSEC in einem „Testbed“ einzuführen. Das „Testbed“ besteht aus den beiden Servern 81.91.161.228 und 87.233.175.25. Dabei handelt es sich um Kopien der TLD-Nameserver der .de-Domainhierarchie (Zone).

Eine Technologie wie DNSSEC ist notwendig, um sicherzustellen, dass die Antworten, die man von einem DNS-Server erhält, nicht von einem Angreifer auf dem Übertragungsweg modifiziert wurden. DNSSEC schützt jedoch nicht, wenn der Betreiber eines DNS-Servers absichtlich falsche Antworten liefert, etwa durch die Umsetzung des Internetzensurgesetzes, oder vor gefälschten Antworten der Provider, um Kunden Werbung unterzuschieben. DNSSEC schützt ausschließlich vor Angriffen, die nicht vom Betreiber kommen.

Ein solcher Angriff ist beispielsweise die Kaminsky-Attacke. Dan Kaminsky konnte im Jahre 2008 praktisch vorführen, dass es möglich ist, einem DNS-Server mittels gespooften IP-Adressen falsche Antworten unterzuschieben. Dazu brauchte Kaminsky nicht einmal fünf Minuten.

Wenn ein DNS-Server im Auftrag seines Clients eine DNS-Anfrage beantwortet, wendet er sich an weitere Server der verteilten Datenbank DNS. Dabei gibt er jeder Anfrage eine sogenannte Query-ID. Das ist eine 16-Bit-Zahl. Ein Angreifer kann also mit einer Wahrscheinlichkeit von eins zu 65.536 die Query-ID treffen und dem Server im richtigen Moment mit einer gespooften IP-Adresse eine Antwort unterschieben.

Dabei kann die Additional-Section dazu verwendet werden, dem DNS-Server eine Antwort auf eine Frage zu geben, die er gar nicht gestellt hat. So lässt sich etwa die Antwort www.google.de 86400 IN A 1.2.3.4 einschmuggeln. Wenn der Server die Antwort akzeptiert, wird er für 86400 Sekunden (24 Stunden) seinen Clients die Antwort geben, dass der Hostname www.google.de die IP-Adresse 1.2.3.4 besäße.

Insbesondere interessant ist das für Phisher, die auf diese Weise versuchen, Websites von Banken zu kapern. Bei einer klassischen Phishing-Attacke kann der Nutzer an der Adressleiste in seinem Browser erkennen, dass er gar nicht bei www.deutsche-bank.de, sondern bei einer Domain wie www.deutsche-bank.de.vu.cc gelandet ist. Zudem ist es bei einer solchen Attacke notwendig, dass der Phisher den Anwender auf seine Website lockt, beispielsweise mit einer Spam-Mail.

Wenn es einem Angreifer gelingt, den DNS-Servern eines großen Providers eine gefälschte Antwort unterzuschieben, werden alle Kunden dieses Providers trotz Eingabe einer korrekten URL auf die falsche Website geleitet, da der DNS-Server dem Nutzer „gutgläubig“ eine falsche IP-Adresse mitteilt.

Themenseiten: Hacker, Kommunikation, Security-Analysen

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

2 Kommentare zu Denic führt DNSSEC ein: neue Technik mit kleinen Tücken

Kommentar hinzufügen
  • Am 31. Januar 2010 um 18:34 von Martin

    Denic und DNSSEC
    Vielen Dank für Ihren lesenwerten und gut recherchierten Artikel!

    Was Denic in dieser Sache jedoch veranstaltet, ist unterirdisch! So wird auf http://www.denic.de/denic-im-dialog/pressemitteilungen/pressemitteilungen/2464.html im dritten Absatz vom „DNSSEC-Testbed für Deutschland“ gesprochen, und Denic als die deutsche Registry sollte für alle Deutschen und Computer zuständig sein, aber in der Resolver-Konfigurationsseite http://www.denic.de/domains/dnssec/status/resolver-konfiguration.html wird Windows – und damit ca. 90 % der Computerbenutzer – ausgeschlossen!
    Einem kompetenten Umternehmen in Frankfurt’s Kaiserstraße sollte bekannt sein, dass Windows seit Vista und Server 2008 natürlich auch DNSEC unterstützen.

  • Am 23. Mai 2011 um 18:41 von Sydney

    DNSSEC & LANCON
    „Für DNSSEC ist DNS über TCP nicht zwingend erforderlich, solange alle Beteiligten
    mit UDP-Paketen umgehen können, die größer als 512 Bytes sind… Dafür gibt es 
    EDNS (RFC 2671) über das dem Empfänger mitgeteilt wird, wie groß Die DNS-
    Anfrage wirklich ist und wie viel Puffer er zur Verfügung stellen muß.

    DNSSEC-fähige Server und Resolver *müssen* EDNS unterstützen – siehe auch
    http://en.wikipedia.org/wiki/DNSSEC

    Daher ist es nicht nötig eine Auflösung über TCP zu unterstützen – und schon gar 
    nicht als Forwarder, der einfach nur Anfragen an den DNS-Server des Providers
    weiterleitet… Nun gibt es da das Problem, daß viele Forwarder in Routern nicht 
    mit Anfragen umgehen können, die länger als 512 Bytes sind. Ich kann dazu nur
    sagen, daß das LANCOM davon nicht betroffen ist – es forwarded Anfragen bis 
    zur Maximalgöße von 64K.“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *