Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009. IT-Security. Teil 7: DNS + DNSSec Dr. Erwin Hoffmann

Transkript

1 Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 7: DNS + DNSSec Dr. Erwin Hoffmann it-security@fehcom.de

2 Geschichte des DNS Am Anfang des Internets (=ARPANET) wurde das Mapping der IPv4 Adressen mit dem Hostname in einer einzigen Datei HOSTS.TXT, die zunächst zentral beim SRI-NIC gehalten wurde. Mit dem wachsenden Anschluss der Endknoten ans Internet war dieser zentrale Mechanismus nicht mehr zu halten und führte zu Inkonistenzen. In 1984 wurden die ersten Ansätze des Domain Name System geplant (RFC 882 und 883) und ein strukturierter und hierarchischer Aufbau des Domain Name Systems mit einer verteilten Datenhaltung vorgeschlagen Die RFC 1034 und 1035 (1987) beschreiben das heutige DNS. Diese RFC wurden/werden skzessive "neu interpretiert" und ergänzt: DNS für IPv6 Extended DNS (EDNS) DNS Security (DNSSec) DNS und die ENUM Domain sowie "semantisches" DNS DNS und die Internationalisierung der Domain Names (IDN)

3 Der Aufgabenstrauss des DNS Das DNS hat komplexe Aufgaben zu realisieren, die in den RFC nicht explizit sondern lediglich implizit beschrieben sind: Deklaration der DNS-Namen (FQDN), Definition und Aufbau der Resource Records (RR), Prinzipien der Namensauflösung (Query/Response), Interaktion DNS-Client/Cache-Server/Content-Server. Das eigentliche Trägerprotokoll DNS und sein "Wire-Format". Aufbau und Struktur des DNS-Namesraum (Zonen), Konfiguration und "Best Practic" für DNS Content- und Cache-Server; Server- Synchronisation. Prinzipien der Vergabe der sog. DNS Root-Server, Verwaltung der TLD/gTLD und speziell Administration der Domains in-addr.arpa, e164.arpa sowie ipv6.apra.

4 DNS und Einfluss der Politik Die 13 Root-Server a-m.root-servers.net [ stellen die zentrale Infrastruktur des DNS dar, sind geographisch sowie auf verschiedene Netzbereiche verteilt. Der Betrieb dieser Server wird von InterNIC periodisch ausgeschrieben und liegt indirekt in der Kontrolle der USA. Das Hinzufügen einer sog. gneric Top Level Domains (gtld) wird vom InterNIC kontrolliert (.xxx,.biz, info). Vergleichbares gilt für die geographischen TLDs (.eu). Damit eine Domain im DNS gefunden werden kann, muss sowohl der entsprechende Domain-Name, als auch der inverse Name im DNS vorhanden sein. Ersters geschieht über Delegation, letzteres über einen konkreten Eintrag in in-addr.arpa (IPv4). Neben der Vergabe der IP-Adresse, stellt dies ein starkes disziplinarisches Mittel dar.

5 DNS und Kommerz Zum Betrieb eines Netzes im Internet müssen sowohl IP(v4) Adressen als auch der zugehörige Domain-Name eingerichtet und publiziert werden. Internet Anbieter (T-Com, NetCologne, Arcor, Colt) haben Bündel von geographischen zugeordneten IP(v) Adressen "gepachtet" und bieten diese ihren Kunden an. Nur noch wenige IP-Subnetze sind als sog. "Private IP" PI Adresse verfügbar. Die Registrierung von Domains und Subdomains kann entweder über diese Anbieter oder über unabhängige Registrare erfolgen. Hierfür wird ein Obulus verlangt. Spammer nutzen teilweise sog. "Throw-Away" Domains (wenige Stunden aktiv), um hiervon ausgehend ihre s zu versenden. Komplexe Domain-Strukturen verlangen der Regel komplexe Software Architekturen (auch für interne Domains). Die Firmen ISC-BIND und Lucent (QIP), sowie Microsoft bedienen diesen Markt mit ihren Produkten.

6 DNS und Sicherheit DNS ist ein komplett unsicheres Protokoll. DNS-Pakete werden mittels UDP übertragen (Port 53), die Nutzinformation ist pro Paket auf 500 Byte beschränkt. Sowohl Man-in-the-Middle Attacken als auch die Kompromittierung der DNS-Server sind gängige Praxis. Der Anwender bzw. die Anwendung nutzt (unter Unix) in der Regel die sog. libresolv und libbind Bibliothek, als Stub-Resolver. Viele Versionen hiervon beinhalten bekannte Buffer-Overflows die sich einfach ausnutzen lassen [ Der bekannte Name-Server BIND kann bis einschliesslich Version 8 nur als Security Desaster bezeichnet werden [ Die in BIND vorhanden Konzeptionsfehler werden häufig bis dato als Eigenschaft von DNS angesehen und so (auch in den RFC) kolportiert.

7 DNS und neue Anforderungen Die Integration von IPv6 ins DNS war von Anfang an chaotisch: A4 vs. A6 Records (zur Zuordnung der IPv6 Adressen) ip6.arpa vs. ip6.int (reverse Zone für IPv6 PTR Adressen) Neue Aufgaben und Anforderungen bei DNSSec: DNSSec vs. TSIG und SIG(0) Notwendige Ergänzung durch EDNS (grosse UDP Pakete) Signierung der TLDs und gtlds DNS und ENUM, d.h. Einführung des "semantischen" DNS: Der Resolver wird aufgefordert, nicht nur die DNS-Records entgegenzunehmen, sondern diese zusätzlich nach gewissen Regeln auszuwerten. DNS und Internationalisierung der Domain-Namen: Statt 7-Bit ASCII in Domain-Namen wird zum Konstrukt des Puny-Codes gegriffen. Der (menschliche) Anwender hat praktisch keine Chance mehr, einen Domain- Namen als "korrekt" zu erkennen.

8 Organisation des DNS Namensraums Full Qualified Domain Name (FQDN): hostname(.subdomain).domain.(g)tld(.) Hostname Domainname Domain-Suffix (root) (jeweils max. 63 Zeichen)

9 Komponenten des DNS DNS ist ein Client/Server Protokoll: Der Client wird als Resolver bezeichnet, der Server steht als Content- oder Cache-Server zur Verfügung. Der DNS-Protokoll-Stack ist typischerweise Bestandteil des Betriebssystems oder der Anwendung. Die vom Betriebssystem den Anwendungen zur Verfügung gestellten DNS-Funktionen werden als Stub-Resolver bezeichnet. Ein Stub-Resolver kennt nur die (IP-)Adresse des nächsten DNS-Servers. Anwendungen mit einer DNS-Implementierung hingegen als Full- Resolver (nslookup, dig). Full-Resolver müssen a-priori Kenntnis über die 13 DNS-root-Server besitzen. Die Namens-Auflösung wird bei Full-Resolvern rekursiv - d.h. ausgehend von den InterNIC root-servern - vorgenommen, bis (mittels Referrals) die notwendige Information gefunden wurde (oder auch nicht).

10 Namens-Auflösung (Hostname => IP Adresse) Wie lautet die IP-Adresse für den FQDN:

11 Inverse Query (IP-Adresse => Hostname) Wie lautet der FQDN für die IP-Adresse ?

12 Organisation des Namensraumes Der DNS-Namensraumes ist in Zonen organisiert. Die Domain-Informationen liegen auf einem DNS-Content-Server in Form sog. Zonen- Dateien. DNS-Content-Server können eine oder mehrere Zonen beinhalten. Prinzipiell können in der Zonen-Datei auch Zonen-fremde Informationen beinhaltet sein. Sub-Domains können an nachgelagerte Content-Server delegiert werden. In der übergeordneten Zonen-Datei muss ein Verweis auf (den FQDN) des nachgeordneten Content-Servers erfolgen (= Delegation). Zusätzlich sollte auch dessen IP-Adresse als Glue angegeben werden; ansonsten spricht man von Glueless Delegation. Typischerweise sind (müssen aber nicht) die DNS-Content-Server redundant ausgelegt. Beide Server sind gegenüber den Clients gleichberechtigt Der Abgleich bzw. Synchronisation der Zonendaten wird als Zonentransfer bezeichnet. Typischerweise werden Änderung auf dem Primary-Server vorgenommen und dann zu den Secondary-Servern propagiert.

13 Zonendatei In der Zonendatei sind die sog. Resource Records (RR) zusammengeschlossen. Kategorien von Resource Records: Primär-(selbst)-delegierende RRs: Beginn der Zone mittels SOA-RR; Ankerpunkt für Zonentransfer. DNSKEY-RR mit dem öffentlichen Schlüssel der Zone. Primär-deklarierende RRs: A-Name: Hostname => IPv4 Adresse AAAA (A4)-Name: Hostname => IPv6 Adresse PTR: Inverse-IP-Adresse (*.in-addr.arpa, *.ipv6.arpa) => Hostname Sekundär-delegiernde RRs: NS: Domain => Hostname (FQDN) des NS der Domain DS (Delegation Signer): (Sub-)Domain-Name => Hashwert des öffentlichen DNSSec Schlüssel der untergeordneten Zone

14 Zonendatei und Resource Records Sekundär-deklarierende RR (mit einem A-Name): CNAME: Hostname => Hostname (A-Name) MX (Mail exchanger): Domain => Hostname (A-Name!) Informative RR: HINFO: Hostname => Information (OS...) WKS (Well Known Service): obsolet RRSIG: Hostname => Signatur eines Resource Record Set (RR) NSEC: Domain = > Next Secure Domain Text-semantische RRs: SPF (Sender Policy Framework): Domain => Sender-Erlaubnis DKIM (Domain Key): Domain => Sender-Erlaubnis NAPTR (Naming Authority PTR): Adresse (@) => Service

15 Aufbau von DNS-Nachrichten

16 Ablauf der Abfrage Der DNS-Client erzeugt eine DNS-Query mit Identification bzw. Transaction-ID (2 Byte): Zufallswert des Clients (Cookie) in der Abfrage zur Identifizierung der Antwort In der Query-Section wird der gesuchte Name und die Art der Abfrage übermittelt. Der DNS-Server teilt im Response die gleiche Transaction-ID mit und wiederholt in der Query-Section die Anfrage, die Answer-Section beinhaltet die Anwort, während die Authority-Section den Domain-Name sowie den Hostname des verantwortlichen DNS-Servers beinhaltet und die Additional-Section z.b. zusätzliche Glue-Angaben zu finden sind. => Per MitM Attacke können DNS-Pakete ohne Mühe "gespooft" werden. => Birthday Attack: DNS-Zufalls-Pakete für "Standard-Abfragen" ( per Flooding das gleiche Ziel erreichen.

17 Sicherheit bei DNS-Abfragen Zur "Sicherstellung" einer qualifizierten Antwort, kann der DNS- Client folgendes vornehmen: Obligatorisch: Die Transaction-ID muss übereinstimmen. Obligatorisch: Die Query-Sektion der Reply muss die Query beinhalten. Möglichkeit: Das IP-Paket mit der Antwort muss von der IP-Adresse stammen, die per DNS-Query angefragt wurde. Möglichkeit: Ein qualifiziertes "Port-Randomizing" muss vorgenommen werden. BIND8 BIND9 DJBDNS PRNG Analyse Quelle: SecurityFocus

18 BIND Birthday Angriff my.name.com? ns1.yahoo.com! ns1.yahoo.com IP= a.b.c.d Der Angreifer sendet einige Hundert Queries zum "Victim Nameserver" der Domain mit der Abfrage des zu spoofenden externen Namens (yahoo). Zur gleichen Zeit sendet er (falsche) Authoritive Replies (für die zu übernehmende Domain) zum Victim-NS aber mit der IP des tatsächlich authoritiven Nameservers. Die Transaktion-ID muss geraten werden (2 Byte). Beim Port kann der Angreifer davon ausgehen, dass BIND häufig den gleichen Quell- Port benutzt. Es reicht, wenn ein gespooftes Paket sein Ziel erreicht; damit wird der Cache des Victim-NS gefüllt und er leitet diese falsche Antwort an die Clients weiter.

19 Aufgaben der Content-DNS-Server (CNS) Die Integrität des DNS ist eng verknüpft mit einer (nicht immer gegebenen) klaren Aufgabenteilung: Der DNS-Content-Server stellt Zone (und RRs) für Domains bereit. Öffentliche Content-Name-Server (CNS) müssen von allen IP-Adressen ansprechbar sein. Nicht-öffentliche CNS dürfen Queries nur von authentisierten Clients entgegen nehmen. Ein CNS nimmt kein Caching vor und agiert nie als Resolver. Er gibt nur Referrals auf die ihm (persistent) bekannten untergeordneten (bzw. anderen) CNS. => Die Missachtung dieser Regel hatte 03/2006 zu einer "Amplification Attack" geführt und war mit dem Teilausfall der root-server verbunden [

20 Aufgaben der Caching-Server Ein Caching-Server (CS) vereinbart die Funktion eines (nicht-authoritiven) DNS-Servers für authentisierte Clients und eines Full- bzw. Recursive-Clients (Forwarders) zur Bereitstellung der DNS-Information. Die Sicherstellung der Integrität der DNS-Information ist im Besonderen mit der Arbeitsweise der CS verbunden. Daher ist es nicht angeraten, die Aufgaben eines CNS und eines CS in der gleichen SW-Instanz zu realisieren. CS sollen auf einer eigenen (nicht-öffentlichen) IP betrieben werden. Ein CS muss im besonderen auch die notwendige Überprüfung der DNSSec RR vornehmen; der Stub-Resolver ist dazu nicht in der Lage. Es ist sinnvoll, zentrale Server mit eigenen DNS-Caches auszustatten. Die Lebensdauer eines Cache-Eintrages entspricht der der ursprünglichen TTL des RR bzw. der der Domain. Auch negative Resultate (NXDOMAIN) werden gecacht.

21 Aufgabe der Stub-Resolver Der Stub-Resolver wird mit den Namen der Caching-Server direkt ausgestattet (Windows: Verbindung ->Internetprotokoll -> Eigenschaften - > Erweitert -> DNS; UNIX: /etc/resolv.conf) oder erhält die ihm zugeordneten DNS-Server per DHCP mitgeteilt. Der Stub-Resolver hat i.d.r. keine Möglichkeit, die Qualität der Information zu verifizieren oder zu validieren. Alle vom CS übermittelten Antworten werden als "nicht-authoritiv" übermittelt.

22 DNS und Internet-Anbindung Forwarder (CS): ge'nat'ed auf Content-Server (CNS): ge'nat'ed auf

23 Typische Bedrohungsszenarien bei DNS (1) Fälschen der Updates zu den Secondary DNS-Servern (CNS => CNS) (2) Manipulation der Dynamic Updates (DynDNS) (Client => CNS) (3) Cache Poisoning (=> CS, Clients)

24 Die avisierte Lösung: DNSSec Nach langer Entwicklungsgeschichte hat sich DNSSec nun in den RFC 4033, 4034 und 4035 manifestiert. Ziele: Sicherstellung der Authentizität: Stammen die angebotenen Daten wirklich vom authoritiven CNS? Sicherstellung der Integrität: Sind die empfangenen DNS-Daten korrekt, bzw. ggf. gefälscht? Weitere Ziele sind Sicherung des Zonentransfers, entweder mittels Symmetrischer Verschlüsselung der Daten (RFC 3645) [TSIG] oder Public/Private Key Verfahren (RFC 4031) [SIG(0)] Ablegen von Zertifikaten [CERT] und SSH Fingerprints [SSHFP] im DNS. => Die Hinterlegung von Zertifikaten bzw. Public Keys im DNS war nie erklärtes Ziel von DNSSec.

25 Notwendige Randbedingung: EDNS Folgende Randbedingungen existieren: DNS Query/Response nutzt UDP (Port 53) DNS Zonentransfer nutzt TCP (Port 53) Die Nutzdaten bei UDP sind beschränkt (~512 Byte). Grosse DNS-Nachrichten müssen daher auf mehrere UDP-Datagramme gesplittet werden, was sich nicht nachhalten lässt. Ausweg bietet Extended DNS (EDN0): Mittels der IP MTU PathDiscovery und dem DNS Pseudo RR OPT(ion) kann auf EDNS gewechselt werden. => Zur Nutzung von DNSSec beim Anwender muss EDNS im Stub-Resolver implementiert sein.

26 Was soll gesichert werden? Zur kryptographischen Sicherung von DNS-RRs müssen diese signiert werden. Hierzu ist zunächst ein DNS Public Key für eine Zone zu erstellen und zu veröffentlichen: Dies wird über den DNSKEY als Key Signing Key realisiert. Zusätzlich zum Domain-Name enthält der RR im Zuordnungsabschnitt (RDATA) neben dem öffentlichen Schlüssel natürlich auch die Angaben über seinen Type (RSA/DH...). Zur Signatur steht der RRSIG Resource Record zur Verfügung Prinzipiell könnte jeder einzelne RR signiert werden; dies stellt aber (vgl. CNAMES) speziell für den Resolver einen zu hohen Entschlüsselungs- Aufwand dar; von der zusätzlichen Menge der übertragenen Informationen abgesehen. Zuvor sind die RR in einer Canonical Order zu organisieren. => Die eigentliche Signierung von DNS RR ist von ihrer Darstellung und Organisation in der Zonendatei abhängig, was die Implementierung von DNSSec nicht unbedingt vereinfacht.

27 RRSIG und RRSet Ein Workaround in Bezug auf Signierungsaufwand und Datenhaltung stellt die Einordnung der Resource Records in Form sog. RRSets dar: Ein RRSet beinhaltet beispielsweise alle A-Name RRs, alle PTR-RRs, die MX-RRs sowie die NS-RRs oder aber Teile von ihnen. Der RRSIG RR umfasst die Angaben: Type Covered (A, MX, PTR, SOA,...) Signatur Algorithmus Anzahl der erfassten Domain Namen bzw. Labels, Angaben über die TTL der RRs, Lebensdauer und Erzeugungszeitpunkt der Signatur, Fingerprint des Public Key dem Signer des Signatur, die Signatur selbst. Mittels des NSEC RR kann mitgeteilt werden, welcher nachfolgende RRSet per DNSSec abgedeckt wird.

28 Chain of Trust Sind die RRs in einer Zone signiert fehlt noch die Angabe über den "Beglaubiger": Delegation Signer (DS). Dieser RR muss beim übergeordneten CNS vorhanden sein Hierin wird er Signatur-Hashwert der untergeordneten Zone angegeben. => Der Full-Resolver muss in der Ermittlung der DNS-Namen nun nicht mehr nur von "Oben nach Unten" vorgehen, sondern bei DNSSec auch die Validität der DNSSec Records von "Unten nach Oben" verifizieren. Es es absolut nicht klar, wie ein Resolver mit evtl. Lücken im "Authorisierungs-Raum" umgehen soll. Es ist darüber unklar, wie eine CS diese gewonne Information dem Stub- Resolver mitteilen soll.

29 DNS Praxis Die Anforderungen an die Umsetzung der DNS-Standards (in das konkret existierende DNS) sind weder besonders klar noch besonders stringent. Beispiele: MX Records müssen immer auf A-Names zeigen / you wish. Content Server sollten nur RR aus der eigenen Zone beinhalten / you wish. Glueless Delegation sollte vermieden werden / you wish. Content Server sollten immer auf der Glue-IP des übergeordneten NS binden (und nur da) / never. Es besteht keine Notwendigkeit, redundante CNS aufzusetzen / DENIC Praxis. CNAMES sollen nur auf A-Names zeigen / you wish.