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.
Neueste Kommentare
2 Kommentare zu Denic führt DNSSEC ein: neue Technik mit kleinen Tücken
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
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.“
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.