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[1], 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[2], oder vor gefälschten Antworten der Provider[3], um Kunden Werbung unterzuschieben. DNSSEC schützt ausschließlich vor Angriffen, die nicht vom Betreiber kommen.
Ein solcher Angriff ist beispielsweise die Kaminsky-Attacke[4]. 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.
Bildergalerie
DNSSEC-Einführung kann die Fritzbox lahmlegen[5]
» zur Bildergalerie ...[5]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.
Das Prinzip von DNSSEC hört sich einfach an, ist aber durchaus mit Problemen verbunden. Für Endanwender geht es damit los, dass gängige NAT-Router, etwa eine Fritzbox, in bestimmten Situationen nicht mehr richtig arbeiten - und zwar unabhängig davon, ob man DNSSEC nutzen möchte oder nicht.
<Update 30.09.2010 11:20:> AVM hat im September 2010 für die Fritzbox-Modelle 7390, 7320, 7270 und 7240 ein Update herausgebracht[6], das DNSSEC unterstützt. Die Implementierung unterstützt DNS über TCP und "lange" UDP-Pakete mit mehr als 512 Bytes. Sie wurde vom BSI als DNSSEC-kompatibel bestätigt. Für die Modelle 3270, 7170 und 7112 sind Aktualisierungen in Vorbereitung.</Update>
Damit DNSSEC funktioniert, muss ein Server zu jeder DNS-Antwort eine gültige Signatur liefern können. Das geschieht in Form eines RRSIG-Records[7]. Diese RRSIG-Records haben eine gewisse Länge, meist 128 Byte, und etwas Protokoll-Overhead. Das Problem dabei ist, dass die meisten Consumer-Router nicht in der Lage sind, DNS über TCP abzuwickeln, was immer dann notwendig ist, wenn die Antwort 512 Byte überschreitet.
Normalerweise werden DNS-Antworten in einem UDP-Paket abgewickelt. Da die Queries und Antworten in der Regel recht kurz sind, wäre es ein großer Aufwand, dafür eine TCP-Verbindung auf- und wieder abzubauen. Der notwendige Datenverkehr für den Auf- und Abbau einer TCP-Verbindung würde die DNS-Nutzdaten meist überschreiten.
Grundsätzlich können IP-Pakete so lang sein, dass sie in ein Paket des darunterliegenden Transportprotokolls passen. Bei Ethernet sind das 1500 Byte. Diesen Wert bezeichnet man als Maximum Transmission Unit[8] (MTU). Die MTU sinkt, wenn weitere Protokollebenen verwendet werden. Die deutschen DSL-Anbieter verwenden zur Authentifizierung PPPoE[9]. Das bedeutet einen Protokolloverhead von 8 Byte. Die MTU sinkt somit auf 1492 Byte.
Jede Tunnelung, beispielsweise VPN-Verbindungen oder IPsec[10], sorgen für eine weitere Reduktion der MTU. Da verschiedene Tunnelmechanismen miteinander kombiniert werden können, kann die MTU weit unter 1500 Byte sinken. Um auf "Nummer sicher" zu gehen, versenden DNS-Server maximal 512 Byte in einem UDP-Paket. So ist sichergestellt, dass das UDP-Paket auf jeden Fall durchkommt. Ab 513 Byte muss TCP verwendet werden.
Eine DNS-Antwort, die größer als 512 Byte ist, kommt durch einen üblichen Consumer-Router nicht durch. Die meisten Antworten sind trotz Signatur kleiner als 512 Byte, jedenfalls, wenn man eine spezifische Frage stellt.
Fragt man beispielsweise ab, an welche Server E-Mails an die Domain nlnetlabs.nl abgeliefert werden können, dann erhält man die Antwort, dass dies bei den Servern omvak.tednet.nl, xs4all.dacht.net und open.nlnetlabs.nl möglich ist. Diese Antwort passt in 174 Byte, siehe Bild 1[11].
Obwohl die Zone nlnetlabs.nl signiert ist, schickt der DNS-Server keine RRSIG-Records mit, weil er nicht danach gefragt wurde. Anders sieht es aus, wenn man eine ANY-Abfrage durchführt, siehe Bild 2[12]. Das Ergebnis ist 2807 Byte lang. Man erkennt, dass der Client es zunächst über UDP versucht hat. Da die Antwort "abgeschnitten" war, hat es der Client noch einmal über TCP versucht. Erst der zweite Versuch brachte das richtige Ergebnis.
Ferner sieht man an Bild 2, dass die Abfrage an den öffentlichen DNS-Server ns2.free-germany.com gestellt wurde. Das hat durchaus seinen Grund. Ein typischer Consumer-Level-NAT-Router hätte die Anfrage nicht beantworten können, da er DNS über TCP nicht beherrscht und die Antwort für DNS über UDP zu lang ist.
Im Beispiel von Bild 3[13] wurde ein Thomson-Speedport-Router mit der Adresse 192.168.0.1 getestet. Man erhält schlicht und einfach keine Antwort, weil der DSL-Router auf TCP-Port 53 gar nicht reagiert. Dieses Verhalten zeigen nahezu alle NAT-Router. Auch viele auf den Unternehmensmarkt zielende NAT-Router beherrschen kein DNS über TCP, etwa die Komponenten von Lancom.
Wer seine Rechner im Heimnetz auf "automatische Netzwerkkonfiguration" eingestellt hat, kann möglicherweise eine böse Überraschung erleben, wenn einige DNS-Zonen damit beginnen, DNSSEC zu verwenden. Solange die Routerhersteller kein Firmware-Update liefern, muss man sich dieser Problematik bewusst sein und nach Alternativen suchen, insbesondere vor dem Hintergrund, dass die Denic ab dem 2. März Domaininhabern erlaubt, Schlüsselmaterial zu hinterlegen.
Wenn einzelne Domains damit beginnen, ihre Zonen zu signieren, kann es auch bei .de-Domains zu Problemen mit Consumer-NAT-Routern kommen. Dabei hilft auch die "Testbed-Umgebung" der Denic nicht, da diese auf dieselben Nameserver delegiert wie die Produktivserver der Denic.
Abhilfe ist im Prinzip nicht schwer. Anstelle den NAT-Router als DNS-Server zu verwenden, wie es meist der Fall ist, wenn man seine Rechner vom Router per DHCP konfigurieren lässt, trägt man die DNS-Server des Providers, freie DNS-Server[14] oder die DNS-Server von Google[15] ein, siehe Bild 4[16].
Endanwender, die von der neuen Sicherheit bei DNS profitieren möchten, müssen zunächst enttäuscht werden. Um den eigenen Rechner sicher zu machen, muss man einen Resolver-Mechanismus auf seinem Rechner installieren, der DNSSEC unterstützt. Das ist nicht grundsätzlich unmöglich, jedoch mit Schwierigkeiten verbunden.
Windows hat einen DNS-Client, der die Namensauflösung vornimmt und in der Lage ist, DNS-Antworten zu cachen. Er unterstützt kein DNSSEC. Unix-Betriebssysteme wie Linux und Mac OS können von Haus aus noch weniger. Sie befragen grundsätzlich bei jeder Namensauflösung einfach die konfigurierten DNS-Server in der Datei /etc/resolv.conf. Wer lokales Caching haben möchte, muss ein Programm wie nscd[17] installieren, das bei vielen Linux-Distributionen mitgeliefert wird.
Um DNSSEC auf dem eigenen Rechner zu installieren, kommt man bei allen Betriebssystem nicht umhin, einen DNSSEC-fähigen DNS-Server aufzusetzen, der zunächst als Caching-Only-Server konfiguriert wird. Eine Anleitung gibt der ZDNet-Artikel Sperre von freien DNS-Servern: So umgeht man die Blockade[18].
Bevor man sich diese Mühe macht, sollte man jedoch wissen, dass eine lokale Installation von DNSSEC erst sinnvoll ist, wenn DNSSEC durchgängig in allen Domainhierarchien verfügbar ist. Generell wird für jede DNS-Zone ein öffentlicher Schlüssel benötigt. Diesen darf man sich jedoch nicht per DNS holen, weil eine gefälschte DNS-Antwort auch einen gefälschten Schlüssel beinhalten kann. Der Schlüssel muss daher auf einem anderen Übertragungsweg kommen, etwa über eine HTTPS-Verbindung.
Das bedeutet, dass man sich für jede Domain einen Schlüssel beschaffen und in seine DNS-Serverkonfiguration eintragen muss. Das ist praktisch nicht durchführbar. Daher lassen sich die sogenannten Zone Signing Keys (ZSKs) mittels Key Signing Keys (KSK) verketten. Im Idealfall reicht es aus, als "Trust Anchor" nur den KSK der Root-Zone zu konfigurieren.
Derzeit gibt es jedoch nur "DNSSEC-Inseln". Das bedeutet, dass man die KSKs jeder Inselhierarchie in seiner DNS-Konfiguration pflegen muss. Dazu ist es auch erforderlich, gelegentliche Schlüsselwechsel zu berücksichtigen und seine Konfiguration upzudaten.
Endanwender können von DNSSEC derzeit nur profitieren, wenn die DNS-Server des Providers DNSSEC unterstützen. Wer nicht die Server seines Providers einsetzt, ist DNS-Cache-Angriffen genauso ausgesetzt wie DNS-Server-Betreiber. Die Provider können in ihrem eigenen Netz sicherstellen, dass IP-Adressen aus dem eigenen Adressraum nicht von außen akzeptiert werden. Kommt ein gespooftes Paket, jedoch von einem fremden DNS-Server, etwa 8.8.8.8, hat der Provider keine Möglichkeit festzustellen, ob das Paket wirklich vom Google-DNS-Server kommt.
Wenn immer mehr Domains damit beginnen, DNSSEC einzuführen, kann das durchaus Probleme für Anwender geben, die einen Consumer-NAT-Router wie eine Fritzbox einsetzen. Durch DNSSEC werden die DNS-Antworten länger und überschreiten möglicherweise 512 Byte. Da in diesem Fall DNS über TCP verwendet werden muss, und die NAT-Router das derzeit nicht beherrschen, bekommen Clients keine Antwort mehr.
Um das Problem zu lösen, sind mehrere Beteiligte gefordert: Wer seine Domain mit DNSSEC absichert, sollte darauf achten, dass Antworten auf gezielte Fragen auch signiert in 512 Byte passen. Problematisch sind dabei vor allem lange TXT- und SPF-Records. Damit lässt sich das Problem auf ANY-Abfragen begrenzen, die von Clientsoftware nur äußerst selten verwendet werden.
Die Hersteller sollten ihre NAT-Router um DNS über TCP erweitern. Alternativ könnten NAT-Router auch ganz darauf verzichten, selbst DNS-Forwarder zu spielen. Das ist nämlich gar nicht notwendig. Stattdessen könnten sie die vom Provider vorgegebenen oder vom Benutzer konfigurierten DNS-Server per DHCP an ihre Clients weitergeben. Selbst, wenn sich an einem DSL-Anschluss die IP-Adresse ändert, und die DHCP-Leasezeit noch nicht abgelaufen ist, bleiben die DNS-Server-Adressen konstant.
Als Endanwender lassen sich die Probleme umgehen, die durch die DNSSEC-Einführung entstehen, indem man grundsätzlich den NAT-Router nicht als DNS-Server einsetzt. Als Alternative bieten sich die DNS-Server des Providers, freie DNS-Server[14] oder die DNS-Server von Google[15] an. Einige NAT-Router erlauben das in ihrer Konfiguration. Wenn das nicht der Fall ist, muss man die DNS-Einstellungen am Client ändern.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/
[15] = http:/
[16] = http:/
[17] = http:/
[18] = http:/