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

Gegen die Kaminsky-Attacke sind die meisten DNS-Server mittlerweile gut gerüstet. Neuere Versionen nahezu aller DNS-Server stellen ihre Anfragen von einem zufällig ausgewählten UDP-Port. Wird die Antwort nicht an denselben Port geschickt, so lehnen sie die Server ab.

Dadurch erreicht man zusammen mit der Query-ID eine 32-Bit-Zufallskomponente. Die Chance, dass ein Angreifer die richtige Kombination aus Query-ID und Source-Port trifft, ist geringer als eins zu vier Milliarden.

Darüber hinaus lassen sich Heuristiken verwenden, die einen DNS-Cache-Angriff erkennen. Wird ein Manipulationsversuch vermutet, kann ein Provider von mehreren seiner DNS-Server dieselbe Query stellen und vergleichen, ob die Antworten identisch sind. Ist das nicht der Fall, kann man von einem Angriff ausgehen.

Hat ein Angreifer die Möglichkeit, an einem großen Internetknotenpunkt, beispielsweise dem DE-CIX, den IP-Traffic zu modifizieren, dann helfen die Abwehrmaßnahmen gegen eine Kaminsky-Attacke allerdings nichts mehr. Der Angreifer kann in diesem Fall dauerhaft falsche Antworten geben – und das mit der richtigen Query-ID sowie an den korrekten Source-Port.

Um sich vor derartigen Manipulationen zu schützen, muss man eine Möglichkeit schaffen, die von einem DNS-Server stammenden Antworten zu überprüfen. DNSSEC erlaubt das mit recht einfachen Mitteln.

Etwas vereinfacht ausgedrückt generiert der Domaininhaber ein Schlüsselpaar für einen asymmetrischen Hash-Algorithmus. Mit dem privaten Schlüssel, den er geheim halten muss, kann er zu jeder DNS-Antwort eine Signatur generieren. Diese Signatur kann ein Empfänger mit dem öffentlichen Schlüssel überprüfen.

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 *