BSI-Studie DNSSEC-Unterstützung durch Heimrouter Version 0.9.9 vom 15.04.2010
DNSSEC-Unterstützung durch Heimrouter BSI-Studie Vervielfältigung und Verbreitung Bitte beachten Sie, dass das Werk einschließlich aller Teile urheberrechtlich geschützt ist. Erlaubt sind die Vervielfältigung und Verbreitung zu nicht-kommerziellen Zwecken, insbesondere zu Zwecken der Ausbildung, Schulung, Information oder hausinternen Bekanntmachung, sofern sie unter Hinweis auf die Studie des BSI als Quelle erfolgen. https://www.bsi.bund.de Bundesamt für Sicherheit in der Informationstechnik Referat Internetsicherheit Postfach 20 03 63 53133 Bonn Tel. +49 (0) 228 99 9582-0 E-Mail: dnssec@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit in der Informationstechnik 2010 2 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter Inhaltsverzeichnis 1 Management-Summary...5 2 Einleitung...6 3 Begriffsdefinitionen...7 3.1 Domain Name System (DNS)...7 3.2 DNSSEC...7 3.3 Heimrouter...9 4 Ziele der Studie...10 4.1 Vorausgehende Untersuchungen / Motivation...10 5 Geräte...11 6 Methodik...12 7 Tests der in die Router implementierten DNS-Proxies...13 7.1 RFC1035-Konformität...13 7.1.1 Durchgeführte Tests...13 7.1.2 Testergebnisse...13 7.1.3 Empfehlung...14 7.2 EDNS0...14 7.2.1 Durchgeführte Tests...14 7.2.1.1 EDNS0-Abfrage < 512 Byte...14 7.2.1.2 512 Byte < EDNS0-Abfrage < 1024 Byte...14 7.2.1.3 1600 Byte < EDNS0-Abfrage...15 7.2.2 Testergebnisse...15 7.2.3 Empfehlung...16 7.3 TCP-Unterstützung...16 7.3.1 Durchgeführter Test...16 7.3.2 Testergebnisse...17 7.3.3 Empfehlung...17 7.4 Zusammengefasste Betrachtung von EDNS0 und TCP...17 7.5 Umgang mit DNSSEC-Protokollbits...18 7.5.1 Durchgeführte Tests...18 7.5.2 Testergebnisse...18 7.5.3 Empfehlung...19 7.6 DNSSEC-Kompatibilität der DNS-Proxies...19 7.7 Caching-Funktionalität...20 7.7.1 Durchgeführte Tests...20 7.7.2 Testergebnisse...20 7.7.3 Empfehlung...21 7.8 Umgang mit RFC1918-Abfragen...21 7.8.1 Durchgeführter Test...21 7.8.2 Testergebnisse...21 7.8.3 Empfehlung...22 7.9 Secret Key Transaction Authentication for DNS (TSIG)...22 7.9.1 Durchgeführter Test...22 7.9.2 Testergebnisse...22 Bundesamt für Sicherheit in der Informationstechnik 3
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 7.9.3 Empfehlung...23 7.10 0x20 Bit-Unterstützung...23 7.10.1 Durchgeführter Test...23 7.10.2 Testergebnisse...23 7.10.3 Empfehlung...24 8 Untersuchung weiterer (Sicherheits-)eigenschaften...25 8.1 WLAN-Sicherheit...25 8.1.1 Durchgeführter Test...25 8.1.2 Testergebnisse...25 8.1.3 Empfehlung...26 8.2 Widerstandsfähigkeit gegen Angriffe...27 8.2.1 Durchgeführte Tests...27 8.2.2 Testergebnisse...27 8.2.3 Empfehlung...28 8.3 DHCP...29 8.3.1 Durchgeführte Tests...29 8.3.2 Testergebnisse...29 8.3.3 Empfehlung...31 8.4 IPv6...31 8.5 DNS(SEC)-Abfragen unter Umgehung des implementierten DNS-Proxies...31 9 DNSSEC-Kompatibilität der Heimrouter...33 9.1 DNSSEC-Validierung erfolgt ausschließlich durch Caching-Resolver des ISPs...33 9.2 DNSSEC-Validierung erfolgt auch auf Anwenderseite...34 10 Fazit...38 4 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 1 Management-Summary Das Domain Name System (DNS) ist im Internet für die Auflösung von Domainnamen auf IP- Adressen verantwortlich. Es enthält jedoch konzeptionelle Schwachstellen, deren Ausnutzung einem Angreifer die Kontrolle über die Namensauflösung für Domains ermöglicht. So kann ein Angreifer beispielsweise die Umlenkung des Aufrufs einer Webseite auf eine betrügerische Seite umleiten. Zur Verbesserung der Sicherheit vor solchen Phishing-Angriffen wurde die DNS-Protokollerweiterung DNSSEC (Domain Name Security Extensions) entwickelt, die solche Manipulationen deutlich erschwert. Zur Zeit finden weltweit Aktivitäten statt, die im Zusammenhang mit der Einführung von DNSSEC stehen. Auch die DENIC eg, der eco Verband der deutschen Internetwirtschaft e. V. und das Bundesamt für Sicherheit in der Informationstechnik (BSI) haben dazu eine gemeinsame Initiative gestartet. Innerhalb eines von der DENIC bereitgestellten Testbeds werden zur Zeit operative und technische Erfahrungen gesammelt um beurteilen zu können, welche Auswirkungen DNSSEC auf die Sicherheit und Zuverlässigkeit im Internet hat. Bei der Einführung von DNSSEC in Schweden wurden Probleme im Zusammenhang mit den dort an privaten Internetanschlüssen eingesetzten Internetzugangsroutern beobachtet, die in der Folge im Rahmen von Studien sowohl in Schweden als auch Großbritannien im Jahr 2008 näher untersucht wurden. Ergebnis dieser Studien war, dass die in diesen Ländern üblichen Router DNSSEC häufig noch nicht ausreichend unterstützt haben. Diese Erfahrungen wurden zum Anlass genommen, die Situation in Deutschland zu untersuchen. Darüber hinaus möchte das BSI mit der vorliegenden Studie einen Beitrag zur Sensibilisierung von Herstellern und Internetprovidern leisten, die entsprechende Produkte produzieren bzw. vertreiben und identifizierte Schwachstellen aufzeigen. Zusätzlich zur Prüfung der Kompatibilität mit DNSSEC wurden auch weitere Sicherheitseigenschaften überprüft. Nicht im Fokus der Studie stand dagegen eine möglichst vollständige Erfassung des deutschen Marktes bzw. die Erstellung von Einzelbewertungen oder Produktempfehlungen. Die Studie wurde in Zusammenarbeit mit interessierten Herstellern und Internetprovidern erstellt. Ein Ergebnis der Studie ist, dass insbesondere im Auslieferungszustand der getesteten Geräte eine Kompatibilität mit DNSSEC in vielen Fällen nur eingeschränkt besteht. Aufgrund der Rückwärtskompatibilität von DNSSEC ist jedoch eine weitere Nutzung der getesteten Geräte auch nach Einführung von DNSSEC in allen Fällen möglich. Unter Umständen kann der Endanwender jedoch nicht vollumfänglich von der durch DNSSEC gebotenen verbesserten Sicherheit profitieren. Erschreckend ist, dass mehr als die Hälfte der getesteten Geräte mit einem aktivierten WLAN ausgeliefert wurden, bei dem keine Verschlüsselung vorkonfiguriert war. Ein so betriebener Router stellt eine Gefahr für den Betreiber dar und ermöglicht die missbräuchliche Verwendung des Internetzugangs durch Dritte. Eine Unterstützung des zukünftigen Internetprotokolls IPv6 war überwiegend nicht vorhanden. Bundesamt für Sicherheit in der Informationstechnik 5
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 2 Einleitung Das im Internet für die Auflösung von Domainnamen (z.b. www.bsi.de) auf IP-Adressen verwendete Domain Name System (DNS) bildet einen grundlegenden Dienst für nahezu jede Internetkommunikation. Angriffe auf das DNS, die zu einer Verfälschung der Daten führen, sind als besonders kritisch einzustufen, da sie in vielen Fällen nicht vom Anwender erkannt oder geprüft werden können. In den vergangenen Jahren wurden mehrfach Schwachstellen in der Spezifikation des DNS-Protokolls bekannt, die für einen Angriff ausgenutzt werden können. Zur Steigerung der Sicherheit des DNS steht seit einiger Zeit die Protokollerweiterung DNSSEC als Verfahren zur Verfügung. Die DENIC eg, der eco Verband der deutschen Internetwirtschaft e.v. und das Bundesamt für Sicherheit in der Informationstechnik (BSI) haben im Juli 2009 eine gemeinsame Initiative gestartet, mit dem Ziel, die Einführung von DNSSEC zunächst im Rahmen einer von DENIC bereitgestellten Testumgebung unter technischen und operativen Gesichtspunkten zu erproben. Das BSI hat in diesem Zusammenhang die nachfolgend vorgestellte Studie durchgeführt, in der verschiedene Sicherheitseigenschaften, darunter die DNSSEC-Kompatibilität der auf Endkundenseite eingesetzten Internetrouter, nachfolgend Heimrouter genannt, untersucht wurden. Anlass für die Studie waren bereits erfolgte ähnliche Untersuchungen in Schweden (http://www.iis.se/docs/routertester_en.pdf) und Großbritannien (http://download.nominet.org.uk/dnssec-cpe/dnssec-cpe-report.pdf), die gezeigt haben, dass in diesen Ländern übliche Heimrouter DNSSEC häufig noch nicht ausreichend 1 unterstützen und dass die in den untersuchten Heimroutern implementierten DNS-Proxies teilweise inkompatibel mit bestehenden DNS-Standards sind. Im Rahmen der Studie wurden insgesamt 36 in Deutschland übliche Heimrouter untersucht, die hierzu dem BSI freundlicherweise überwiegend von Herstellern und Internetprovidern zur Verfügung gestellt wurden. 1 Implementierungsempfehlungen für DNS-Proxies in Heimroutern werden auch im Dokument DNS Proxy Implementation Guidelines (http://www.ietf.org/id/draft-ietf-dnsext-dnsproxy-06.txt ) gegeben. 6 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 3 Begriffsdefinitionen In diesem Kapitel werden die Funktionsweise des Domain Name Systems (DNS) sowie der Sicherheitserweiterungen DNSSEC erläutert. Weiterhin erfolgt eine Definition des Begriffs Heimrouter. 3.1 Domain Name System (DNS) Das DNS (Domain Name System) ist ein verteiltes System zur Speicherung und Abfrage von Informationen im Internet. Die historisch bekannteste Anwendung dient der Umwandlung von Domainnamen in IP-Adressen. Neben dieser Grundfunktion wird das DNS noch zu einer großen Zahl anderer Abfragen genutzt, dazu zählen das Auffinden von Servern für verschiedene Dienste wie E- Mailservern und Anmeldeservern, die flexible Abfrage von Rufnummern und vieles andere mehr. Die Verfügbarkeit und die Korrektheit der Ergebnisse von DNS werden heute im Internet als gegeben betrachtet. Prinzipiell funktioniert das Internet auch ohne DNS, allerdings ist ein Verzicht auf Domainnamen und stattdessen die direkte Verwendung von IP-Nummern kaum vorstellbar. Ohne DNS müsste jeder Benutzer ständig IP-Adressen in seinem Browser oder in seiner E-Mail verwenden, was umständlich und fehleranfällig ist. IP-Adressen sind außerdem teilweise an den Provider gebunden und somit bei Serverwechsel/-umzug zwangsläufig Änderungen unterworfen. Das DNS basiert auf einer hierarchischen Server-Struktur, von der aus die Abfragen beantwortet werden. Diese sogenannten Nameserver stehen im Netz des Kunden oder beim Provider (für die lokale Zwischenspeicherung und die lokalen Netze), beim jeweiligen Anbieter von Diensten (für die Zielnetze), bei den nationalen Network Information Centers (NICs für Bereiche wie.de oder.fr), bei den NICs für generische TLDs (Top Level Domains wie.com,.net oder.org) und auf oberster Ebene bei den Betreibern der sogenannten root-zone. Nameserver, die keine eigenen Informationen vorhalten und ausschließlich für die Auflösung und Zwischenspeicherung von DNS- Abfragen zuständig sind, werden als DNS-Resolver bezeichnet. DNS-Resolver in Client-Betriebssystemen heißen auch Stub-Resolver. Im Gegensatz dazu heißen Nameserver, die eigene Informationen bereitstellen, autoritative Nameserver. Die einzelnen Einträge im DNS werden als Resource-Records bezeichnet. 3.2 DNSSEC Das in Verbindung mit DNS eingesetzte Protokoll wurde in den Anfangszeiten des Internets entwickelt. Es enthält selbst noch keine Maßnahmen zum Schutz der Daten, insbesondere enthält das DNS-Protokoll keine Sicherung der Daten gegen Veränderungen auf dem Transportweg oder in den durchlaufenden Servern und Caches. Verfälschungen können weder erkannt noch verhindert werden. Unter dem Namen DNSSEC wurden inzwischen von der Internet Engineering Task Force (IETF) eine Reihe von Erweiterungen und Ergänzungen standardisiert. DNSSEC ist zwar schon lange in der Entwicklung, eine weite Verbreitung und Einführung im Internet haben diese Sicherheitserweiterungen jedoch bisher noch nicht gefunden. DNSSEC beschränkt sich ausschließlich auf die Quellenauthentisierung, das heißt auf die Sicherung des Pfades zwischen Nameservern und validierenden DNS-Clients, wobei auch dazwischen liegende Server und Resolver mit ihren Caches mit in die Sicherheitskette eingeschlossen sind. DNSSEC sichert mit seiner Signatur den Transport und die Zwischenspeicherung; es bürgt dafür, dass die Daten unterwegs nicht verändert wurden. Die Signatur zeigt an, dass die Daten von einer dazu berechtigten Stelle signiert wurden. DNSSEC beinhaltet jedoch keine Vorgaben bezüglich Bundesamt für Sicherheit in der Informationstechnik 7
DNSSEC-Unterstützung durch Heimrouter BSI-Studie einer Überprüfung der Authentizität der Identität. Eine DNSSEC-Signatur ist daher nicht mit einer qualifizierten elektronischen Signatur im Sinne des Signaturgesetzes vergleichbar. Ob Daten vom Inhalt her richtig sind, ob die Rechtmäßigkeit von Eintragungen geprüft wurde, ob Daten vor der Eingabe manipuliert wurden oder absichtlich falsche oder irreführende Daten eingetragen wurden, wird von DNSSEC nicht behandelt. DNSSEC prüft die Daten an Hand von kryptografisch gesicherten Signaturen, die über die zu schützenden Daten errechnet werden und zusammen mit den Daten an den Client übertragen werden. Die Prüfung der Daten erfolgt dann im Client oder in dem davor liegenden Resolver gegenüber den zur jeweiligen Zone passenden öffentlichen Schlüsseln. Diese Schlüssel können am einfachsten wiederum aus dem DNS abgerufen werden. Dies ist dann optimal und ohne Bruch des Sicherheitsmechanismus möglich, wenn auch dieser Transfer mit Hilfe von DNSSEC abgesichert erfolgt und lediglich der für den Beginn der Kette notwendige Schlüssel im Client fest hinterlegt oder per Konfiguration eingepflegt wurde. Solange dieses hierarchische System, ausgehend von einer signierten root, noch nicht eingeführt ist, kann mit geeigneten Verteilungsfunktionen außerhalb von DNS für eine vertrauenswürdige Verteilung der benötigten Schlüssel gesorgt werden. Nach derzeitigem Stand ist die Signierung der root- Zone zum 01. Juli 2010 geplant. DNSSEC ist ein Baustein, um den Betrieb von DNS und damit das Internet sicherer zu machen. DNSSEC hilft gegen Fälschungen und das Unterschieben falscher Daten, wird jedoch Probleme wie Domain-Hijacking oder Manipulationen bei der Registrierung nicht verhindern. Die Vorteile von DNSSEC lassen sich erst dann komplett ausnutzen, wenn DNSSEC weitgehend von Hard- und Software unterstützt und von der überwiegenden Mehrheit der Resolver verwendet wird. Bis dahin sind nur Teile von DNSSEC nutzbar. Durch die Einführung von DNSSEC ergeben sich verschiedene Auswirkungen in Bezug auf das bei einer DNS-Abfrage verwendete DNS-Protokoll. So wächst durch das Anfügen der Signatur die Größe des Antwortpakets deutlich an. Weiterhin wurden zur Signalisierung von DNSSEC-Eigenschaften verschiedene Protokollbits neu hinzugefügt. Die ursprüngliche DNS-Spezifikation erlaubt über UDP nur den Transport von bis zu 512 Byte großen Antwortpaketen. Um größere Antwortpakete transportieren zu können, wurde die DNS-Protokollerweiterung EDNS0 spezifiziert. Tabelle 1 fasst diese Unterschiede, die in den nachfolgenden Kapiteln noch näher erläutert werden, zusammen. DNS DNS+DNSSEC Größe Antwortpaket < 512 Byte Häufig > 512 Byte DNSSEC-spezifische Headerbits EDNS0 DNS-Abfragen per TCP Tabelle 1: DNSSEC Protokollauswirkungen - Neue Bits: DO-Bit AD-Bit CD-Bit i.d.r. Nicht erforderlich i.d.r. Nicht erforderlich Unterstützung erforderlich zur Übertragung von DO-Bit und UDP-Antwortpaketen > 512 Byte Alternativ bei Problemen mit EDNS0 erforderlich 8 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 3.3 Heimrouter Als Heimrouter werden nachfolgend Geräte (Router) bezeichnet, die typischerweise auf Endkundenseite zur Terminierung der Internetanbindung verwendet werden (DSL-Router, WLAN-Router, Kabelmodems mit Routingfunktion und ähnliche Geräte). Die in den Heimroutern eingesetzte Software bietet meist neben weiteren Funktionen auch DNS- Dienste an. Teilweise handelt es sich dabei um einfache DNS-Proxies, die Abfragen immer an vorkonfigurierte Nameserver des jeweiligen Internetproviders (ISP) weiterleiten. Daneben existieren aber auch eine Reihe von Geräten, die DNS-Abfragen zusätzlich aus einem internen Cache beantworten. Die dabei eingesetzte Software ist auf geringen Platzbedarf und geringe CPU-Belastung hin ausgesucht. Bundesamt für Sicherheit in der Informationstechnik 9
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 4 Ziele der Studie Im Rahmen der Studie wurde die Umsetzung verschiedener Sicherheitseigenschaften sowie die Einhaltung von Protokollstandards und Implementierungsempfehlungen in den einzelnen Heimroutern untersucht. Der Schwerpunkt der Untersuchungen lag dabei auf den Protokollstandards und Implementierungsempfehlungen, deren Einhaltung für eine Kompatibilität mit der DNS-Protokollerweiterung DNSSEC erforderlich sind. Dies beinhaltete unter anderem: Generelle UDP und TCP-Unterstützung bei DNS-Abfragen EDNS0-Unterstützung Umgang mit DNSSEC-Protokollbits Daneben wurden verschiedene weitere (Sicherheits-)eigenschaften überprüft: WLAN-Sicherheit Von außen offene Ports Umsetzung der Port-Randomisierung IPv6-Unterstützung 4.1 Vorausgehende Untersuchungen / Motivation Die Schwedische TLD-Registry.se hat nach Beobachtung von Auffälligkeiten im Heimrouterbereich nach Einführung von DNSSEC unterhalb der Top-Level-Domain.se eine Untersuchung verschiedener für den schwedischen Markt relevanter Heimrouter durchgeführt, in der die Kompatibilität der Heimrouter mit DNSSEC geprüft wurde. Die Ergebnisse dieser Untersuchung (http://iis.se/docs/routertester_en.pdf) wiesen auf verschiedene Kompatibilitätsprobleme der untersuchten Heimrouter in Verbindung mit DNSSEC hin. Der für die TLD.uk zuständige Betreiber Nominet hat daraufhin ebenfalls noch in 2008 eine ähnliche Studie durchgeführt, in der für den britischen Markt relevante Heimrouter auf ihre Kompatibilität mit DNSSEC untersucht wurden. Auch die Ergebnisse dieser Studie (http://download.nominet.org.uk/dnssec-cpe/dnssec-cpe-report.pdf wiesen auf verschiedene Probleme der Geräte mit DNSSEC hin. Die Veröffentlichung der Untersuchungsergebnisse dieser beiden Studien, die bei der Auswahl der untersuchten Heimrouter auf ihren jeweiligen Heimatmarkt ausgerichtet waren, zeigten die oft noch fehlende DNSSEC-Unterstützung dieser Anwendungsklasse. Die Hersteller wurden im Nachgang mit den Ergebnissen der Studien konfrontiert. Weiterhin wurde der Internet-Draft DNS Proxy Implementation Guidelines (http://www.ietf.org/id/draft-ietf-dnsext-dnsproxy-06.txt ) veröffentlicht, in der Implementierungsempfehlungen für die Hersteller von Heimroutern gegeben werden. Die vorgenannten Studien sowie die Veröffentlichung dieser Implementierungsempfehlungen bildeten auch die Motivationsgrundlage für die vorliegende Studie, da in Deutschland zum einen größtenteils andere Geräte als in Schweden oder Großbritannien marktrelevant sind, und zum anderen seit den Veröffentlichungen ggf. Reaktionen seitens der Hersteller erfolgt sein könnten. 10 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 5 Geräte Im Rahmen der Studie wurden insgesamt 36 Heimrouter untersucht, von denen 23 Geräte mit einem integrierten DSL-Modem ausgestattet waren. Die getesteten Geräte wurden überwiegend von Internetprovidern (20 Geräte) und Herstellern entsprechender Produkte für die Tests zur Verfügung gestellt. Insgesamt berücksichtigt die Studie ca. 90% der zum Zeitpunkt des Studienbeginns im Zusammenhang mit DSL-Anschlüssen in Deutschland angebotenen Router. Daneben wurden einige frei erhältliche Geräte in das Testfeld aufgenommen. Bundesamt für Sicherheit in der Informationstechnik 11
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 6 Methodik Die Untersuchung der verschiedenen Eigenschaften erfolgte in einer Laborsimulation (Zeichnung 1), mit der eine bei einem DSL-Heimanschluss typischerweise vorhandene Netzinfrastruktur inklusive DSL-Leitung simuliert wurde. Der in der Zeichnung aufgeführte DSLAM (Digital Subscriber Line Access Multiplexer) bildet hierbei das Gegenstück zu den häufig in die Heimrouter integrierten DSL-Modems. LAN-Analyser Client Heimrouter DSLAM Caching- Resolver Autoritativer- Nameserver Zeichnung 1: Simulation DSL Heimanschluss Im Rahmen der Tests wurden unter anderem verschiedene Abfragen signierter und unsignierter DNS-Einträge (Resource Records) durchgeführt und die Antworten mit einem zuvor festgelegten erwarteten Ergebnis verglichen. Bei Auffälligkeiten wurde zusätzlich die Kommunikation mittels LAN-Analyser, der eine genaue Untersuchung des Datenverkehrs ermöglicht, untersucht. Eine detaillierte Beschreibung sämtlicher Tests sowie den Ergebnissen findet sich in den folgenden Kapiteln 7 und 8. Für eine abschließende Einstufung der Heimrouter hinsichtlich ihrer Kompatibilität mit DNSSEC ist eine kombinierte Auswertung verschiedener Einzeltests erforderlich. Diese wird in Kapitel 9 vorgenommen. 12 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 7 Tests der in die Router implementierten DNS- Proxies Der Schwerpunkt der Studie lag auf der Prüfung der Kompatibilität der in den Heimroutern implementierten DNS-Proxies mit den Spezifikationen des DNS-Protokolls, insbesondere sofern sie die Funktionsweise der Protokollerweiterung DNSSEC betreffen. In den nachfolgenden Unterkapiteln wird der jeweilige Testinhalt zunächst erläutert, die Testdurchführung sowie die für das Bestehen notwendigen Testkriterien beschrieben, die Testergebnisse präsentiert und abschließend eine Implementierungsempfehlung gegeben, die sich an den DNS Proxy Implementation Guidelines (http://www.ietf.org/id/draft-ietf-dnsext-dnsproxy-06.txt ) orientiert. 7.1 RFC1035-Konformität Die Basis-Spezifikation des DNS erfolgt in dem Dokument RFC1035 der IETF. Bevor weitergehende Untersuchungen hinsichtlich der DNSSEC-Kompatibilität bei den einzelnen Geräten durchgeführt wurden, wurde zu Beginn zunächst das Vorhandensein und die grundsätzliche Funktion eines DNS-Proxies geprüft, um Seiteneffekte auf spätere Tests auszuschließen. 7.1.1 Durchgeführte Tests Es wurden die Reaktion des Heimrouters auf unterschiedliche DNS-Abfragen (A-Record, TXT- Record, NS-Record) ausgewertet. Der Test galt als bestanden, sofern die RFC1035-konformen Abfragen korrekt beantwortet wurden. 7.1.2 Testergebnisse Von den 36 getesteten Geräten konnten drei Geräte nicht alle gestellten Abfragen beantworten (Abbildung 7.1). Insbesondere wurden durch diese drei Geräte Abfragen nach TXT-Resource- Records nicht beantwortet. 3 RFC1035 kompatibel partielle Implementierung 33 Abbildung 7.1: RFC1035 Konformität der DNS Proxies Bundesamt für Sicherheit in der Informationstechnik 13
DNSSEC-Unterstützung durch Heimrouter BSI-Studie Diese drei Geräte blieben in den weiteren DNS-Proxy Tests unberücksichtigt, da bei den weiteren Tests teilweise TXT-Resource-Records verwendet wurden. 7.1.3 Empfehlung Sofern ein DNS-Proxy in den Geräten vorhanden ist, sollte dieser RFC-konform implementiert sein und sämtliche DNS-Abfragen einschließlich der nachfolgenden DNSSEC-Abfragen unterstützen. 7.2 EDNS0 RFC1035 spezifiziert die maximale Paketgröße eines DNS-UDP-Pakets mit 512 Bytes. RFC2671 (EDNS0) erweitert diese Grenze auf UDP-Pakete bis zu 65535 Bytes (in gängigen Nameserver- Implementierungen wurde eine Grenze von 4096 Byte implementiert). Um eine Abwärtskompatibilität sicherzustellen, spezifiziert der DNS-Client bei einer Abfrage die maximale Paketgröße, bis zu deren Grenze er Antwortpakete verarbeiten kann (maximale Puffergröße). Würde eine Antwort auf eine Abfrage die angegebene Größenbeschränkung überschreiten, setzt der Nameserver in der Antwort stattdessen das Truncation-Bit (TC-Bit). Auch ein DNS-Proxy, der nur Antworten bis zu einer gewissen Puffergröße verarbeiten kann, sollte bei Abfragen, in denen ein darüber liegender Wert angegeben ist, die Abfrage nicht weiterleiten sondern stattdessen direkt eine Antwort mit gesetztem TC-Bit generieren. Die Unterstützung von EDNS0 ist Voraussetzung für die Übermittlung des DNSSEC DO-Bits (siehe Kapitel 7.5), da dieses im EDNS0-Protokollheader definiert wurde. 7.2.1 Durchgeführte Tests Im Rahmen dieses Tests wurden Abfragen von TXT-Resource-Records unterschiedlicher Größe per UDP durchgeführt. 7.2.1.1 EDNS0-Abfrage < 512 Byte Bei diesen Tests wurden EDNS0-Abfragen eines 400 Byte großen TXT-Resource-Records unter Angabe unterschiedlicher maximaler Puffergrößen per UDP durchgeführt. Der Test galt als bestanden, sofern das Antwortpaket in allen Fällen vollständig übermittelt wurde. 7.2.1.2 512 Byte < EDNS0-Abfrage < 1024 Byte Bei diesen Tests wurden EDNS0-Abfragen eines 800 Byte großen TXT-Resource-Records unter Angabe unterschiedlicher Puffergrößen per UDP durchgeführt. Der Test galt als bestanden, sofern das Antwortpaket bei Angabe einer ausreichend großen Puffergröße vollständig übermittelt wurde, und das bei Angabe einer zu kleinen Puffergröße ansonsten vom Server gesetzte TC-Bit ebenfalls korrekt zurück übermittelt wurde. 14 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 7.2.1.3 1600 Byte < EDNS0-Abfrage Bei diesen Tests wurden EDNS0-Abfragen von TXT-Resource-Records mit den Größen 1600 Byte, 2400 Byte sowie 3200 Byte unter jeweiliger Angabe unterschiedlicher Puffergrößen per UDP durchgeführt. Der Test galt als bestanden, sofern das Antwortpaket bei Angabe einer ausreichend großen Puffergröße vollständig übermittelt wurde, und das bei Angabe einer zu kleinen Puffergröße ansonsten vom Server gesetzte TC-Bit ebenfalls korrekt zurück übermittelt wurde. 7.2.2 Testergebnisse Sämtliche DNS-Proxies haben den 400 Byte großen TXT-Resource-Record unabhängig von der angegeben Puffergröße korrekt verarbeitet. Bei Antwortpaketen, die größer als 512 Byte waren, haben jedoch viele Proxies nur die ersten 512 Byte übermittelt. Weitere Geräte haben das Antwortpaket abhängig von der WAN-MTU-Größe beschnitten. Weiter wurde beobachtet, dass manche DNS-Proxyimplementierungen ein bereits vom Server gesetztes TC-Bit nicht korrekt durchreichen, sondern das Bit in ihrer Antwort an den Client entfernen. Sämtliche DNS-Proxies, die mit Paketen der Größe 1600 Byte umgehen konnten, konnten auch die 2400 Byte sowie 3200 Byte großen Antworten verarbeiten. Im Detail: Nur vier DNS-Proxies konnten mit allen getesteten Paketgrößen umgehen. Weitere zwölf Geräte waren in der Lage, Pakete bis zu der getesteten Größe von 929 Byte (800 Byte Resource-Record + Protokolldaten) zu verarbeiten. Die Hälfte dieser Geräte haben bei Abfragen mit größeren Puffergrößen diese existierende Beschränkung jedoch nicht korrekt per TC-Bit dem Client signalisiert. Die verbleibenden 17 Geräte, die nur Pakete kleiner als 512 Byte verarbeiten konnten, haben gleichzeitig auch alle das TC-Bit nicht korrekt weitergeleitet bzw. ihre Beschränkung nicht signalisiert. Dies ist deshalb besonders problematisch, da dies zu unvollständig übermittelten DNS-Antwortpaketen führt, die einen Verarbeitungsfehler auf der Client-Seite verursachen können. Die Abbildung 7.2 fasst die Ergebnisse zusammen. Bundesamt für Sicherheit in der Informationstechnik 15
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 4 6 6 17 Ja Paketgröße <MTU ok, TC-Bit ok Paketgröße <MTU, kein TC-Bit nur Paketgröße <512 Byte, kein TC-Bit 7.2.3 Empfehlung Abbildung 7.2: EDNS0 Kompatibilität DNS Proxy Da spätestens mit der Einführung von DNSSEC auch DNS-UDP-Pakete mit einer Größe über 512 Byte regelmäßig zu erwarten sind, sollte der DNS-Proxy auch mit solchen Paketen korrekt umgehen können. Bei UDP-Paketen die auch die WAN-MTU-Grenze überschreiten, sollte eine der folgenden Methoden implementiert sein: 1. Die vom Nameserver erhaltenen IP-Paketfragmente der DNS-Antwort werden einzeln an den DNS-Client zurückgeliefert. 2. Die vom Nameserver erhaltenen IP-Paketfragmente der DNS-Antwort werden im DNS-Proxy zusammengesetzt und ggf. erneut fragmentiert an den DNS-Client weitergeleitet. 3. Der DNS-Proxy berechnet die maximal vom ihm unterstützte UDP-Paketgröße (entspricht der WAN-MTU abzüglich des IP-Headers) und liefert bei Abfragen, die eine höhere UDP-Paketgröße anfordern, eine Antwort mit gesetztem TC-Bit zurück. Zusätzlich sollte der DNS-Proxy Abfragen per TCP unterstützen. 7.3 TCP-Unterstützung Wenn eine DNS UDP-Abfrage scheitert, wird als Standard-Fallback-Mechanismus die Abfrage erneut über TCP gestellt. Die Unterstützung von TCP für DNS-Abfragen ist zwar in der DNS-Spezifikation nicht zwingend vorgeschrieben, wird aber dennoch von nahezu sämtlichen DNS-Client Implementierungen unterstützt. Eine fehlende TCP-Unterstützung in einem DNS-Proxy verhindert den Erfolg des Fallback-Mechanismus. 7.3.1 Durchgeführter Test Im Rahmen dieses Tests wurde überprüft, ob der DNS-Proxy Abfragen über TCP entgegen nimmt. Der Test galt als bestanden, sofern DNS-Abfragen über TCP möglich waren und korrekt beantwortet wurden. 16 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 7.3.2 Testergebnisse Nur acht der 33 Geräte mit DNS-Proxies akzeptieren DNS-Abfragen über TCP (Abbildung 7.3). 8 UDP & TCP nur UDP 25 7.3.3 Empfehlung Abbildung 7.3: TCP Unterstützung durch DNS Proxy Ein DNS-Proxy sollte auch TCP unterstützen, da zu erwarten ist, dass DNS-Clients zukünftig verstärkt im Rahmen des Fallback-Mechanismus eine Verbindung per TCP versuchen werden. 7.4 Zusammengefasste Betrachtung von EDNS0 und TCP Abbildung 7.4 fasst die Ergebnisse der EDNS0 sowie TCP-Fähigkeit der DNS-Proxies zusammen. 4 8 EDNS0 & TCP Nur EDNS0 Nur TCP weder noch 21 Abbildung 7.4: Voll EDNS0 oder TCP kompatibel Interessanterweise bot kein einziges der getesteten Geräte sowohl eine vollständige Unterstützung von EDNS0 als auch von TCP. Bundesamt für Sicherheit in der Informationstechnik 17
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 7.5 Umgang mit DNSSEC-Protokollbits Im Zusammenhang mit der DNS-Protokollerweiterung DNSSEC wurden in RFC3225 sowie in RFC2535 einige neue DNS-Protokollbits (DO-Bit, AD-Bit, CD-Bit) spezifiziert, die im Zusammenhang mit DNSSEC verwendet werden. Mit dem DNSSEC OK (DO)-Bit signalisiert der DNS-Client dem Server seine DNSSEC Kompatibilität. Ein vom Nameserver in der Antwort gesetztes Authenticated Data (AD)-Bit signalisiert eine erfolgreiche DNSSEC-Validierung an den DNS-Client. Gemäß eines aktuellen Vorschlags soll ein Client außerdem zukünftig mit einem in der Abfrage gesetzten AD-Bit seine Fähigkeit, dass AD-Bit in der Antwort auszuwerten, signalisieren können. Mit dem Checking Disabled (CD)-Bit kann ein DNS-Client dem Server mitteilen, dass dieser selbst keine DNSSEC-Validierung durchführen soll. 7.5.1 Durchgeführte Tests Im Rahmen der Test wurde überprüft, ob das DO-Bit korrekt an den Nameserver weitergeleitet wird, ein in Abfragen oder Antworten gesetztes AD-Bit korrekt weitergeleitet wird, ein in Abfragen oder Antworten gesetztes CD-Bit korrekt weitergeleitet wird. 7.5.2 Testergebnisse Bei den durchgeführten Tests haben sich die meisten Geräte als kompatibel hinsichtlich der mit DNSSEC eingeführten neuen Signalisierungsbits erwiesen. Lediglich vier Geräte konnten die Bits nicht transparent weiterreichen (Abbildung 7.5). Eines dieser Geräte lieferte bei einem in der Abfrage gesetzten AD- oder CD-Bit überhaupt keine Antwort mehr zurück, es kam stattdessen zu einem Connection-Timeout. 18 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 4 Ja Nein 29 7.5.3 Empfehlung Abbildung 7.5: Durchreichen von DNSSEC Protokollbits DNS-Proxies sollten transparent sämtliche DNSSEC-Protokollbits in beiden Richtungen unverändert durchreichen. 7.6 DNSSEC-Kompatibilität der DNS-Proxies Für eine Kompatibilität mit DNSSEC muss der in die Router implementierte DNS-Proxy die nachfolgenden Eigenschaften erfüllen: 1. Der DNS-Proxy leitet die DNSSEC-Protokollbits korrekt weiter. 2. Der DNS-Proxy unterstützt vollständig EDNS0 oder alternativ zumindest TCP und leitet das TC-Bit korrekt weiter. 9 17 voll DNSSEC kompatibel eingeschränkt DNSSECtauglich (<MTU) inkompatibel 7 Abbildung 7.6: DNSSEC Tauglichkeit der DNS Proxies Bundesamt für Sicherheit in der Informationstechnik 19
DNSSEC-Unterstützung durch Heimrouter BSI-Studie Das in Abbildung 7.6 aufgeführte Ergebnis ergibt sich aus einer Bewertung der Einzelergebnisse der Tests 7.2, 7.3 und 7.5. Leider waren drei von den in Kapitel 7.3 genannten acht Geräten mit TCP-Unterstützung nicht transparent in der Verarbeitung der DNSSEC-Protokollbits, so dass lediglich neun Geräte im Testfeld die vorgenannten Eigenschaften in vollem Maße erfüllen und somit bei Nutzung des eingebauten DNS-Proxies voll kompatibel mit der Sicherheitserweiterung DNSSEC sind. Weitere sieben sind eingeschränkt kompatibel und könnten Antwortpakete bis zu einer getesteten Größe von 929 Byte verarbeiten. 7.7 Caching-Funktionalität Neben den in den vorangegangenen Kapiteln beschriebenen Tests wurde auch untersucht, ob einzelne DNS-Proxies Abfragen zwischenspeichern oder ob alle Geräte nur eine reine Weiterleitung von Abfragen und Antworten durchführen. 7.7.1 Durchgeführte Tests Es wurden verschiedene DNS-Abfragen gezielt wiederholt, um zu beurteilen, ob eine erneute Abfrage direkt durch den DNS-Proxy beantwortet oder erneut an den externen Nameserver weitergeleitet wird. 7.7.2 Testergebnisse Wie in Abbildung 7.7 dargestellt, haben 13 der getesteten DNS-Proxies erneute Abfragen aus einem internen Cache beantwortet. 13 20 Proxies mit Cache Proxies ohne Cache Abbildung 7.7: DNS Proxies mit Caching Funktion Bei den Geräten mit Caching-Funktion wurde weiterhin untersucht, wie eine DNS-Abfrage zu einer signierten Domain mit gesetztem DO-Bit beantwortet wurde, nachdem zuvor eine Abfrage der gleichen Domain, jedoch ohne gesetztes DO-Bit, durchgeführt wurde. In allen Fällen wurden hier die zweiten Abfragen aus dem Cache ausgeliefert mit dem Ergebnis, dass die zugehörigen Signaturen 20 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter nicht mitgeliefert wurden. Dies führt zu Problemen, wenn an dem Heimrouter sowohl Endgeräte mit DNSSEC-Unterstützung als auch Geräte ohne DNSSEC-Unterstützung angeschlossen sind. 7.7.3 Empfehlung Eine Caching-Implementierung sollte die Protokollerweiterung DNSSEC mit den sich daraus ergebenden Konsequenzen berücksichtigen. 7.8 Umgang mit RFC1918-Abfragen In RFC1918 wurde ein sogenannter privater Adressraum reserviert, der üblicherweise im Zusammenhang mit Network Address Translation (NAT) in privaten Netzen eingesetzt wird. Ein wichtiger Aspekt dabei ist, dass keine DNS-Abfragen zu diesen privaten Adressen an öffentliche Nameserver im Internet gestellt werden sollten, da sie aufgrund ihrer Uneindeutigkeit nicht sinnvoll behandelt werden können. Dies gilt insbesondere für die Rückwärtsauflösung dieser Adressen in Hostnamen. Leider zeigt sich in der Praxis, dass öffentliche DNS-Abfragen für diese privaten Adressen in hoher Zahl auftreten. 7.8.1 Durchgeführter Test Im Rahmen des Tests wurde untersucht, ob DNS-Abfragen zu privaten Adressen an einen externen Nameserver weitergeleitet oder lokal beantwortet wurden. 7.8.2 Testergebnisse Abbildung 7.8 zeigt, dass nur zehn der getesteten Geräte DNS-Abfragen privater Adressen lokal beantworten. Alle anderen Geräte leiten diese Abfragen an den externen Nameserver weiter. Bundesamt für Sicherheit in der Informationstechnik 21
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 10 23 Lokale Beantwortung von RFC1918 Abfragen Weiterleitung von RFC1918 Abfragen 7.8.3 Empfehlung Abbildung 7.8: Umgang mit RFC1918 Abfragen Ein DNS-Proxy sollte Abfragen zu privaten Adressen nicht weiterleiten sondern lokal beantworten. 7.9 Secret Key Transaction Authentication for DNS (TSIG) RFC2845 spezifiziert TSIG als Methode zur Authentisierung von DNS-Abfragen und -Antworten auf Paketebene. Veränderungen, die ein DNS-Proxy innerhalb des DNS-Teils eines Abfrage- bzw. Antwortpakets durchführt, führen unweigerlich zu einer fehlschlagenden Authentisierung mittels TSIG. 7.9.1 Durchgeführter Test Bei diesem Test wurde untersucht, ob eine TSIG-Authentisierung über den DNS-Proxy funktioniert. 7.9.2 Testergebnisse Die Untersuchung ergab, dass nur bei fünf der getesteten Geräte (Abbildung 7.9) eine TSIG- Authentisierung bei Nutzung des DNS-Proxies möglich war. In allen anderen Fällen wurden durch den DNS-Proxy Veränderungen an der DNS-Abfrage vorgenommen, so dass die TSIG-Authentisierung fehlschlug. 22 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 5 TSIG kompatibel Nicht TSIG kompatibel 28 7.9.3 Empfehlung Abbildung 7.9: TSIG Kompatibilität DNS-Proxies sollten Pakete entweder unverändert weiterleiten oder TSIG vollständig implementieren. 7.10 0x20 Bit-Unterstützung Der Internet-Draft Use of Bit 0x20 in DNS Labels to Improve Transaction Identity spezifiziert eine weitere Methode, um DNS-Manipulationen weiter zu erschweren. Hierzu wird bei einer DNS- Abfrage die Groß- und Kleinschreibung des angefragten Domainnamen zufällig variiert. Da ein Nameserver eine Kopie der Abfrage zusammen mit der Antwort ausliefert, kann der DNS-Client die in der Antwort enthaltene Abfrage mit der von ihm ursprünglich gestellten Abfrage vergleichen. 7.10.1 Durchgeführter Test Bei diesem Test wurden verschiedene DNS-Abfragen unter Modifizierung der innerhalb der Abfrage verwendeten Domainnamens durchgeführt. Der Test galt als bestanden, wenn in der Antwort die Abfrage in identischer Form enthalten war. 7.10.2 Testergebnisse Einer der in den Geräten implementierten DNS-Proxies (Abbildung 7.10) nahm Veränderungen an der gewählten Groß-/Kleinschreibung vor und war somit nicht kompatibel mit diesem Verfahren. Bundesamt für Sicherheit in der Informationstechnik 23
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 1 0x20 kompatibel Nicht 0x20 kompatibel 32 7.10.3 Empfehlung Abbildung 7.10: 0x20 Kompatibilität Die 0x20 Methode sollte unterstützt werden. Für eine korrekte Funktionsweise ist es erforderlich, dass der DNS-Proxy die erhaltenen Daten unverändert weiterleitet. 24 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 8 Untersuchung weiterer (Sicherheits-)eigenschaften In Kapitel 7 wurden die Fähigkeiten der in den Heimroutern implementierten DNS-Proxies untersucht. Im Rahmen der Studie wurden darüber hinaus auch noch weitere Eigenschaften, wie zum Beispiel die von den Herstellern getroffenen Absicherungsmaßnahmen eines ggf. vorhandenen WLAN- Zugangs im Auslieferungszustand, untersucht. Diese Testergebnisse werden nachfolgend vorgestellt. 8.1 WLAN-Sicherheit Die Vorzüge der drahtlosen Funknetzwerke ( Wireless Local Area Networks, kurz WLAN), überzeugen immer mehr Unternehmen und auch private Haushalte: Nach Schätzungen des Bundesverbands Informationswirtschaft, Telekommunikation und neue Medien (BITKOM) wurden Ende 2006 deutschlandweit bereits knapp sieben Millionen Breitband-Anschlüsse per WLAN betrieben. Sie ermöglichen die kabelfreie Kommunikation zwischen mehreren lokalen Computern ebenso wie einen mobilen Einstiegsweg ins Internet. Allerdings bringt die grenzenlose Mobilität auch Probleme mit sich: Werden Daten durch Funk übertragen, so treten neben Störungen oder Netzausfällen vor allem Sicherheitsprobleme auf. Wenn sie zuvor nicht ausreichend verschlüsselt und geschützt wurden, können auf diese Weise übertragene Informationen von Dritten empfangen, aufgezeichnet und manipuliert werden. Außerdem ermöglicht ein unzureichend geschütztes WLAN die (unter Umständen missbräuchliche) Nutzung des bereitgestellten Internetzugangs durch Dritte. Dies kann rechtliche Konsequenzen für den Betreiber eines solchen Anschlusses zur Folge haben 2. 8.1.1 Durchgeführter Test Bei diesem Test wurde untersucht, mit welchen WLAN-Einstellungen die Heimrouter mit WLAN- Funktion ab Werk ausgeliefert wurden. 8.1.2 Testergebnisse 33 der 36 untersuchten Geräte boten eine WLAN-Funktion. Bei sämtlichen dieser Geräte war das WLAN im Auslieferungszustand eingeschaltet. 16 der Geräte waren ab Werk mit einem individuellen WPA2-Schlüssel abgesichert, der zusammen mit dem Gerät ausgeliefert wurde (z. B. an der Unterseite des Gerätes aufgedruckt). Die anderen 17 Geräte hatten ab Werk ein eingeschaltetes, offenes, also ungesichertes WLAN. Bei acht dieser Geräte erfolgte bei der Erstkonfiguration immerhin ein diesbezüglicher Hinweis an den Benutzer, der jedoch weg geklickt werden konnte. Abbildung 8.1 fasst die Ergebnisse zusammen. 2 siehe z.b. Urteil des OLG Düsseldorf, 2009, AZ I-20 W 146/08, Haftung des Inhabers eines nicht gesicherten WLAN- Anschlusses für einen Missbrauch durch Urheberrechtsverletzung seitens unberechtigter Dritter Bundesamt für Sicherheit in der Informationstechnik 25
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 9 16 WPA2 gesichert Offen, mit Hinweis Offen 8 Abbildung 8.1: WLAN Sicherheit Betrachtet man bei der Auswertung nur die Heimrouter, die von Internet-Providern bereitgestellt wurden, ergibt sich ein besseres Bild (Abbildung 8.2). 3 2 WPA2 gesichert Offen, mit Hinweis Offen 13 Abbildung 8.2: WLAN Sicherheit der ISP Heimrouter Möglicherweise existieren bereits entsprechende Auswahlkriterien der Provider. 8.1.3 Empfehlung Ein im Auslieferungszustand aktiviertes WLAN sollte unter Verwendung eines individuellen Kennwortes mit WPA2 verschlüsselt sein. Der dazugehörige Schlüssel kann dem Nutzer beispielsweise über ein beigefügtes Informationsblatt mitgeteilt werden. Keinesfalls sollte der WLAN-Zugang im Auslieferungszustand ungeschützt aktiviert sein. Auch ein bei Inbetriebnahme des Routers erscheinender Hinweis auf ein unverschlüsseltes WLAN wird leicht durch den Anwender weg geklickt und genügt nicht. Ein Hinweis, dass das vorkonfigurierte Kennwort durch den Anwender durch ein geeignetes neues Kennwort ersetzt werden sollte, erscheint dagegen sinnvoll. Wünschenswert wäre auch eine Unterstützung des Anwenders bei der Erstellung eines sicheren Kennwortes. 26 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 8.2 Widerstandsfähigkeit gegen Angriffe In dieser Testreihe wurden verschiedene Aspekte geprüft, die sich unter dem Oberbegriff Widerstandsfähigkeit gegen Angriffe zusammenfassen lassen. Im Einzelnen sind dies: 1. Keine Bereitstellung eines Open Resolvers Wenn der DNS-Proxy auch Abfragen über die WAN-Schnittstelle entgegen nimmt, kann der Heimrouter für DNS-Reflektor-Angriffe missbraucht werden. Bei DNS-Reflektor- Angriffen werden DNS-Abfragen unter Angabe einer gefälschten Quelladresse an einen Resolver gerichtet. Dieser sendet das Antwortpaket an die übermittelte Quelladresse. Da DNS-Antwortpakete deutlich größer als Abfrage-Pakete sind, ermöglicht dieses Vorgehen einem Angreifer eine Steigerung seiner Angriffsstärke. 2. Quellport-Randomisierung Es wurde beobachtet, dass viele DNS-Proxies bei der Weiterleitung von DNS-Abfragen eine neue Query ID vergeben, um die spätere Weiterleitung der dazugehörigen Antwort an den Client zu erleichtern. Dieses Verfahren ist RFC-konform und ist auch mit TSIG (siehe Kapitel 7.9 auf Seite 22) kompatibel. Die Query IDs sollten allerdings bei jeder Abfrage zufällig erzeugt und nicht sequentiell vergeben werden, um DNS Cache Poisoning Angriffe nicht zu erleichtern. Gleiches gilt für die Vergabe von Quellport-Nummern, sowohl durch den DNS-Proxy als auch durch die in den Heimroutern implementierten NAT-Funktionen. 3. Keine offenen Ports im Auslieferungszustand Über die WAN-Seite des Heimrouters erreichbare Ports stellen ein Sicherheitsrisiko dar. 8.2.1 Durchgeführte Tests Im Rahmen der Tests wurde überprüft, ob der Heimrouter DNS-Abfragen an der WAN-Schnittstelle entgegen nimmt und beantwortet, die Query-IDs sowie die Quellport-Nummern bei jedem Verbindungsaufbau zufällig vergeben wurden oder ob eine sequentielle Vergabe dieser Nummern stattfand, bei einzelnen Geräten im Auslieferungszustand offene Ports auf der WAN-Seite vorhanden sind. 8.2.2 Testergebnisse Erfreulicherweise fungierte kein einziges der getesteten Geräte als Open Resolver, der DNS-Proxy beantwortete also in keinem Fall Abfragen, die über die WAN-Schnittstelle gestellt wurden. Schlechter sah das Ergebnis bei der Randomisierung von Quellports und Query-IDs aus. Während auch hier sämtliche Geräte die Query-IDs zufällig vergaben, war bei immerhin vier Geräten, wie in Abbildung 8.3 ersichtlich, eine sequentielle Vergabe von Quellports zu beobachten. Bundesamt für Sicherheit in der Informationstechnik 27
DNSSEC-Unterstützung durch Heimrouter BSI-Studie 4 Quell-Port Randomisierung findet statt Sequentielle Vergabe von Quellports 32 Abbildung 8.3: Quellport Randomisierung Bezüglich der Ergebnisse des mittels nmap durchgeführten Portscans ergibt sich ein differenziertes Bild. Bei acht Geräten wurde der Port 5060 (SIP) im Auslieferungszustand als offen gemeldet. Sämtliche dieser Geräte verfügen über eingebaute VOIP-Funktionen. Bei einem Gerät wurde der Port 5190 (AOL) im Auslieferungszustand als offen gemeldet. Auf diesem Gerät war ein AOL Instant Messenger Proxy aktiv. Bei einem weiteren Gerät wurde der Port 8000 als offen und von außen erreichbar identifiziert. Die verbleibenden 26 Geräte hatten im Auslieferungszustand keine offenen Ports. Abbildung 8.4 fast die Ergebnisse zusammen. 8 1 1 26 Port 5060 SIP offen Port 5190 AOL offen Port 8000 offen Keine offenen Ports 8.2.3 Empfehlung Abbildung 8.4: Ergebnisse des Portscans Der DNS-Proxy sollte Abfragen nur aus dem internen Netz beantworten. 28 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter Die Query-IDs und Quellport-Nummern sollten bei jedem Verbindungsaufbau zufällig vergeben werden. Im Auslieferungszustand des Routers sollten von außen keine Ports geöffnet sein. 8.3 DHCP Diese Testreihe untersucht verschiedene Aspekte im Zusammenhang mit dem Dynamic Host Configuration Protocol (DHCP). Über DHCP stellt der Heimrouter den angeschlossenen Endgeräten Netzkonfigurationseinstellungen bereit. Im Zusammenhang mit DNS sind dabei die folgenden beiden Optionen relevant. 1. DHCP Option 6 (Domain Name Server) Über das DHCP Optionsfeld 6 besteht die Möglichkeit, angeschlossene Endgeräte mit Informationen bezüglich der zu verwendenden Nameserver zu versorgen. Neben der Fragestellung, ob und welche Einträge hier im Auslieferungszustand übermittelt werden, wurde auch betrachtet, ob eine manuelle Konfigurationsmöglichkeit der übermittelten Einträge vorhanden ist. 2. DHCP Option 15 (Domain Name) Bei einer signifikanten Anzahl der an die DNS-Rootserver gestellten Abfragen handelt es sich um Abfragen zu ungültigen Top-Level-Domains. Diese Abfragen können teilweise darauf zurückgeführt werden, dass an Heimrouter angeschlossene Geräte per DHCP eine ungültige Top-Level-Domain übermittelt bekommen. 8.3.1 Durchgeführte Tests Im Rahmen der Test wurde überprüft, ob und falls ja, welche Nameserver über das DHCP-Optionsfeld 6 an angeschlossene Endgeräte übermittelt werden, inwiefern der Router eine manuelle Einstellmöglichkeit für die per DHCP übermittelten Nameserver bietet, ob im Auslieferungszustand der in den Heimroutern implementierte DHCP-Server im DHCP- Optionsfeld 15 einen Domainnamen übermittelt. 8.3.2 Testergebnisse Die Mehrzahl (30) der untersuchten Geräte übermittelten im Auslieferungszustand die IP-Adresse des eingebauten DNS-Proxies an die angeschlossenen Endgeräte aus. Fünf weitere Geräte lieferten vor dem DSL-Verbindungsaufbau ebenfalls die IP-Adresse des eingebauten DNS-Proxies aus, änderten aber ihr Verhalten nach erfolgtem Verbindungsaufbau. Drei dieser Geräte lieferten nach erfolgtem Verbindungsaufbau sowohl die IP-Adresse des eingebauten DNS-Proxies als auch die IP-Adresse eines vom Provider mitgeteilten Nameservers aus, die anderen beiden ausschließlich die IP-Adresse(n) der vom Provider mitgeteilten Nameserver. Eines der getesteten Geräte hatte keinen DHCP-Server implementiert. Bundesamt für Sicherheit in der Informationstechnik 29
DNSSEC-Unterstützung durch Heimrouter BSI-Studie Abbildung 8.5 fasst die Testergebnisse zusammen. 1 2 3 Proxy Proxy und ISP-NS ISP NS Kein DHCP 30 Abbildung 8.5: Per DHCP Option 6 übermittelte Nameserver Erfreulicherweise war bei der Mehrzahl der untersuchten Geräte eine manuelle Konfiguration der per DHCP übermittelten Nameserverdaten möglich. Bei sieben getesteten Geräten fehlte jedoch die Möglichkeit einer manuellen Konfiguration (Abbildung 8.6). 7 DHCP DNS-Eintrag manuell konfigurierbar DHCP DNS-Eintrag nicht manuell konfigurierbar 29 Abbildung 8.6: Konfigurationsmöglichkeit DHCP DNS Eintrag Ein ähnliches Bild (Abbildung 8.7) ergab sich bei der Untersuchung des DHCP Optionsfelds 15. Bei neun Geräten wurden hier Einträge ausgeliefert, die restlichen Geräten lieferten keinen Eintrag aus. 30 Bundesamt für Sicherheit in der Informationstechnik
BSI-Studie DNSSEC-Unterstützung durch Heimrouter 9 Eintrag vorhanden Kein Eintrag vorhanden 27 8.3.3 Empfehlung Abbildung 8.7: DHCP Option 15 Eintrag Es ist wünschenswert, dass in den Konfigurationseinstellungen des Heimrouters auch andere Nameserver spezifiziert werden können, deren IP-Adressen dann über DHCP an die angeschlossenen Geräte verteilt werden. Andernfalls wäre eine Umgehung des eingebauten Proxies nur noch durch eine manuelle Konfiguration auf jedem einzelnen angeschlossenen Gerät möglich. Heimrouter sollten im Auslieferungszustand in der DHCP Option 15 keinen Domain Name zurück liefern, das Feld sollte leer sein. 8.4 IPv6 Eine Einschätzung zum gegenwärtig im Internet überwiegend verwendeten Internetprotokoll Version 4 (IPv4) besagt, dass Mitte 2012 sämtliche zur Verfügung stehende Adressen vergeben sein werden (Quelle: http://www.potaroo.net/tools/ipv4/index.html ). Als Nachfolger wurde das Internetprotokoll Version 6 (IPv6) spezifiziert. Neben den in den vorangegangenen Kapiteln beschriebenen Tests wurde daher auch untersucht, ob in den Konfigurationsoberflächen der Heimrouter bereits Einstellmöglichkeiten bezüglich IPv6 vorhanden waren. Lediglich drei der untersuchten Geräte boten hier bereits entsprechende Einstellmöglichkeiten. 8.5 DNS(SEC)-Abfragen unter Umgehung des implementierten DNS-Proxies Die in Kapitel 7 beschriebenen Tests dienten der Überprüfung des in die Heimrouter implementierten DNS-Proxies. Sämtliche der dort beschriebenen DNS-Abfragen waren daher an die DNS-Proxies in den Heimroutern gerichtet. Um zu untersuchen, ob die dort identifizierten Probleme durch eine direkte DNS-Abfrage eines externen Nameservers umgangen werden können, wurden sämtliche in Kapitel 7 aufgeführten Bundesamt für Sicherheit in der Informationstechnik 31