Netzsicherheit 17: DNSSEC

Transkript

1 Netzsicherheit 17: DNSSEC Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Session 2 / 1

2 Einführung DNS Kurze Geschichte des DNS Ursprung: hosts.txt des Arpanet einfaches Textfile mit Zuordnung Name IP-Adresse manuell aktualisiert vom Stanford Research Institute Verteilung per an alle Computer Netzwerklast: Proportional zu (Anzahl der Computer) : Geburt des Domain Name System als verteilte Datenbank Paul Mockapetris programmiert den ersten DNS-Server RFC 920 Berkeley Internet Name Domain (BIND) DNS für Unix Einführung DNS Was ist das DNS? Weltweit verteilte, redundant ausgelegte Datenbank Ordnet Domainnamen wie IP-Adressen zu (und umgekehrt) Speichert Informationen zum -Routing stellt Informationen für weitere Internet-Dienste bereit X.500-Verzeichnis für Rechner Session 2 / 2

3 Einführung DNS Domainnamen und der DNS-Namensraum DNS-Namensraum Struktur der Datenbank in Form eines Baumes Die Wurzel dieses Baumes hat das Label NULL oder. Jeder nachfolgende Knoten wird mit einem weiteren Label versehen, das auf dieser Ebene eindeutig sein muss Labels für die Top-Level-Domain (erste Ebene unterhalb der Wurzel) sind vorgegeben und reglementiert Ein Domainname ist ein absoluter Pfad in diesem Baum Eine Domain ist ein Teilbaum des DNS-Baumes, unterhalb des Knotens mit dem entsprechenden Domainnamen Einführung DNS com edu... de fr... test verisign rub netz1 www crl www nds h14 crl.verisign.com h14.netz1.test Session 2 / 3

4 Einführung DNS Domainnamen und die DNS-Namensraum Beispiele: Die Domain ruhr-uni-bochum.de enthält alle Rechner der RUB. Die Domain rub.de enthält die Teilmenge dieser Rechner, für die *.rub.de als Alias konfiguriert ist. Beide Domains gehören zu der Zone, die vom Rechenzentrum verwaltet wird. Das Rechenzentrum betreibt dazu die autoritativen Nameserver für diese Zone, einen Primary DNS und mindestens einen Secondary DNS als Backup. Die Domain nds.rub.de wird vom Lehrstuhl NDS verwaltet. Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Session 2 / 4

5 Einführung DNS Delegation und Zonen. com edu... de verisign rub bund www crl www nds www bsi crl.verisign.com Einführung DNS Delegation und Zonen Das Domain Name System ist eine riesige Datenbank, die nicht zentral administriert werden kann. Die Verantwortung muss daher aufgeteilt oder delegiert werden. Dazu wird der DNS-Namensraum in Zonen aufgeteilt. Zonen können Domains (d.h. komplette Teilbäume) oder Teile von Domains sein. Beispiel: Die Zone de delegiert die Verantwortung für die Domain rub.de an das Rechenzentrum der RUB, und dieses delegiert nds.rub.de weiter an NDS. Session 2 / 5

6 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Einführung DNS: Ressource Records Ressource Records (RR) Die Information über eine Zone wird in einem Zonefile gespeichert Das Zonefile besteht aus einzelnen Ressource Records (RR) Das Zonefile wird in einem Rechner in der Nähe des point of delegation gespeichert Beispiel: Das Zonefile für rub.de kann z.b. in nameserver1.rub.de gespeichert sein. RRs haben eine feste Struktur Session 2 / 6

7 Einführung DNS: Ressource Records Beispiel $TTL example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number ; ref = refresh = 2d 900 ; ret = update retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) IN NS ns1.example.com. IN NS ns2.example.com. ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. Einführung DNS: Ressource Records Start of Authority (SOA) Record mit Name der Zone, autoritativem Nameserver und -Adresse example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial ; ref = refresh = 2d 900 ; ret = retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) Session 2 / 7

8 Einführung DNS: Ressource Records example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial ; ref = refresh = 2d 900 ; ret = retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) serial: Versionsnummer des Zone file, sollte hochgezählt werden refresh: Zeit, nach der der Secondary NS seine Daten aktualisieren sollte retry: Zeit, die mindestens vergehen sollte, bevor ein fehlgeschlagener Refresh wiederholt wird. expiry: Spätestens nach dieser Zeit wird das Zone file ungültig. minimum: Minimale TTL, die für jeden RR aus diesem Zone file gilt (kann im RR überschrieben werden) Einführung DNS: Ressource Records Name Server (NS) Record Definiert die Primary und Secondary Nameserver für die Zone example.com. IN NS ns1.example.com. IN NS ns2.example.com. Session 2 / 8

9 Einführung DNS: Ressource Records A (Address) Record: Ordnet DNS-Namen eine IP-Adresse zu CNAME Record: Ordnet einem (Alias-)DNS-Namen einen Canonical Name (eindeutig pro Rechner) zu ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. Name Klasse Typ RData RRSet: Nur RData ist verschieden (Bspl. host2...) Einführung DNS: Ressource Records PTR (Pointer) Record zu jedem A-RR gibt es ein PTR-RR ordnet jeder IP-Adresse einen oder mehrere Domainnamen zu IP-Adressen liegen in der Domain in-addr.arpa. IP-Adressen werden in umgekehrter Reihenfolge angegeben, da DNS-Namen von rechts nach links gelesen werden in-addr.arpa. IN PTR host2.example.com in-addr.arpa. IN PTR host2.example.com in-addr.arpa. IN PTR host4.example.com. Session 2 / 9

10 Einführung DNS: Ressource Records Aufbau eines Ressource Records Domain_name: Name der Domain, für die dieses Record gilt. Dies ist der primäre Suchschlüssel für die Datenbank. Time_to_live (optional): Angabe (in Sek.), wie stabil der Eintrag ist (TTL=86400: stabil, TTL=60: instabil, z.b. temporäre IP-Adressen) Class: fast immer IN für Internet, aber auch andere Werte sind möglich. Type: Typ des Records (siehe übernächste Folie) Value: Der gesuchte Wert, oft die IP-Adresse. Einführung DNS: Ressource Records Aufbau eines Ressource Records / / / NAME / TYPE CLASS TTL RDLENGTH / RDATA / / / Session 2 / 10

11 Einführung DNS: Ressource Records Häufigste Typen von Ressource Records SAO (6; Start of Authority): Parameter für diese Zone A (1; IP-Adresse): 32-Bit-Wert MX (15; Mail Exchange): Name des Hosts, der bereit ist, E- Mails für diese Domain zu akzeptieren NS (2; Name Server): Nameserver für diese Domain CNAME (5; Canonical Name): Übersetzt einen Alias der Domain in den echten Namen PTR (12; Pointer): Alias für eine IP-Adresse HINFO (13; Host description): CPU und OS in ASCII TXT (16; Text): Uninterpretierter ASCII-Text Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Session 2 / 11

12 7. DNS-Software Ein DNS-Client wird Resolver genannt. Systemaufruf an Resolver: getbyname(host) Unter Unix: /etc/resolv.conf enthält die lokale Domain und die DNS-Server für diese Domain. domain rpi.edu nslookup ist ein interaktiver Resolver zur direkten Kommunikation mit dem DNS-Server. Nachfolger von nslookup: dig. Meistverwendeter DNS-Server: BIND 7. DNS-Software nslookup ist auch unter Windows verfügbar Session 2 / 12

13 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Einführung DNS Auflösung von Domainnamen Rekursive Abfrage: Die Anfrage wird von Nameserver zu Nameserver weitergeleitet, bis der autoritive Server gefunden ist. Iterative Abfrage: Der Nameserver erhält auf seine Frage jeweils eine Liste mit Nameservern zurück, die er als nächste fragen soll. Client stellt rekursive Anfrage an Default-Nameserver, dieser kann sie rekursiv oder (besser) iterativ auflösen. Session 2 / 13

14 Rekursive Abfrage NS für.com Authoritative NS für example.com Zone File Cache Response Name Server Query Name Server hosts.txt Query Response Query User Query Response Resolver Response Name Server Default-NS PC Cache Cache Einführung DNS Rekursive Abfrage: Beispiel 1. Host fragt beim Default-Nameserver (muss konfiguriert werden) nach. 2. Dieser leitet die Anfrage an den de-nameserver weiter 3. de-ns fragt bei rub.de-ns nach 4. rub.de-ns fragt bei nds.rub.de-ns nach 5. Antwort von NS für nds.rub.de läuft über alle Nameserver zurück. Session 2 / 14

15 Iterative Abfrage Authoritative NS für example.com Zone File Name Server NS für.com Cache Name Server hosts.txt Query Response Query Referral User Query Response Resolver Query Response Name Server Default-NS PC Cache Cache Einführung DNS Iterative Abfrage: Beispiel 1. Host fragt beim Default-Nameserver (muss konfiguriert werden) nach. 2. Dieser leitet die Anfrage an den de-nameserver weiter 3. de-ns liefert Referral auf Adresse des rub.de-ns zurück 4. Default-NS fragt bei rub.de-ns nach 5. rub.de-ns liefert Referral auf Adresse des nds.rub.de- NS zurück 6. Default-NS fragt bei nds.rub.de-ns nach 7. Antwort von NS für nds.rub.de wird über den Default-NS an den Client weitergegeben Session 2 / 15

16 Iterative Abfrage (aus Hinshelwood) Auflösung von Domainnamen: iterativ, ohne Caching Iterative Abfrage (aus Hinshelwood) Auflösung von Domainnamen: iterativ, mit Caching Session 2 / 16

17 DNS Query Domain Name System (query) Transaction ID: 0x0002 Flags: 0x0100 (Standard query) = Response: Message is a query = Opcode: Standard query (0) = Truncated: Message is not truncated = Recursion desired: Do query recursively = Z: reserved (0) = Non-authenticated data OK: Nonauthenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries type A, class inet Name: Type: Host address Class: inet DNS Response (1) Domain Name System (response) Transaction ID: 0x0002 Flags: 0x8580 (Standard query response, No error) = Response: Message is a response = Opcode: Standard query (0) = Authoritative: Server is an authority for domain = Truncated: Message is not truncated = Recursion desired: Do query recursively = Recursion available: Server can do recursive queries = Z: reserved (0) = Answer authenticated: Answer/authority portion was not authenticated by the server = Reply code: No error (0) Questions: 1 Answer RRs: 2 Authority RRs: 3 Additional RRs: 3 Queries type A, class inet Name: Type: Host address Class: inet Session 2 / 17

18 DNS Response (2) Answers type CNAME, class inet, cname www1.rz.ruhr-uni-bochum.de Name: Type: Canonical name for an alias Class: inet Time to live: 1 day Data length: 26 Primary name: www1.rz.ruhr-uni-bochum.de www1.rz.ruhr-uni-bochum.de: type A, class inet, addr Name: www1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: DNS Response (3) Authoritative nameservers rz.ruhr-uni-bochum.de: type NS, class inet, ns ns1.rz.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns1.rz.ruhr-uni-bochum.de rz.ruhr-uni-bochum.de: type NS, class inet, ns ns1.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns1.ruhr-uni-bochum.de rz.ruhr-uni-bochum.de: type NS, class inet, ns ns2.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns2.ruhr-uni-bochum.de Session 2 / 18

19 DNS Response (4) Additional records ns1.rz.ruhr-uni-bochum.de: type A, class inet, addr Name: ns1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: ns1.ruhr-uni-bochum.de: type A, class inet, addr Name: ns1.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: ns2.ruhr-uni-bochum.de: type A, class inet, addr Name: ns2.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Session 2 / 19

20 Sicherheitsprobleme des DNS Fälschen der Zuordnung Domain Name IP DNS als sicherheitskritischer Infrastrukturdienst: Online-Banking, MS Passport, Yahoo Login, Web Services DNS Spoofing: (W)LAN, bösartige Nameserver, Drive-by- Pharming DNS Cache Poisoning: hosts.txt, Geburtstagsparadoxon, DNS Name Chaining DNS als Angriffsvektor für DoS Fälschen der Zuordnung Domain Name IP Angriffsszenario Authoritative NS für example.com Zone File Name Server Gefälschte Response Query NS für.com Cache Name Server Trojaner hosts.txt Query Query Response User Query Response Resolver DriveByPhar. Response Name Server Default-NS Cache PC Cache Session 2 / 20

21 Sicherheitsprobleme des DNS DNS als sicherheitskritischer Infrastrukturdienst: MS Passport, Yahoo Login,...: sicherheitskritische Informationen werden als SECURE Cookies transportiert durch DNS Spoofing/Pharming in Kombination mit einem selbstgenerierten SSL-Zertifikat kann man diese Cookies abfangen Web Services Adressierung erfolgt fast ausschließlich über URLs! VoIP Hinterlegung der Zuordnung Rufnummer IP im DNS Sicherheitsprobleme des DNS DNS Spoofing (W)LAN: DNS-Abfragen können mitgelesen und die Antworten gefälscht werden Bem.: In jedem WLAN-Hotspot wird DNS-Spoofing betrieben. Da das Login meit über einen Webbrowser erfolgt, wird der Aufruf einer beliebigen Seite/URL immer auf diese Login-Seite umgeleitet. bösartige Nameserver: Durch Änderung des Default- Nameservers kann der Angreifer die Antworten beliebig manipulieren (z.b. durch den Trojaner QHosts-1) Drive-by-Pharming: Änderung des Default-Nameservers durch Besuch einer Webseite Session 2 / 21

22 Drive-By-Pharming (Stamm, Ramzan, Jakobsson) 1. Java Applet/ Javascript 2. Finde interne IP-Adresse 3. http Request / Response 5. verändere Einstellungen 4. interpretiere Skriptfehler Sicherheitsprobleme des DNS DNS Cache Poisoning: hosts.txt: Pharming-Trojaner (z.b. Trojan.DOS.Qhost.b/ Kasperky) überschreibt die lokale Datei hosts.txt Geburtstagsparadoxon: Sende gleichzeitig viele Anfragen und Antworten mit unterschiedlichen Sequenznummern das Geburtstagsparadoxon garantiert, dass mit hoher Wahrscheinlichkeit eine Sequenznummer in den gefälschten Antworten zu einer Sequenznummer in einer Anfrage des NS passt. DNS Name Chaining: Nameserver für eine Domain stehen oft in anderen Domains Session 2 / 22

23 Sicherheitsprobleme des DNS Quelle: DNS Cache Poisoning The Next Generation. Joe Stewart, GCIH DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) Attacker DNS resolver DNS server for victim.org Query: aaa.victim.org Answer: aaa.victim.org AR: Query: aab.victim.org Answer: aab.victim.org AR: Forward Query: aaa.victim.org Forward Query: aab.victim.org Geburtstagsparadoxon: Attacke erfolgreich nach ca. 10 Sekunden Session 2 / 23

24 DNS Cache Poisoning: Dan Kaminski (Black Hat 2008) Geburtstagsparadox für DNS bekannt seit 2002 (Joe Stewart: DNS Cache Poisoning The Next Generation). Additional Ressource Records: Ein DNS-Server darf Daten senden, die nichts mit der Anfrage zu tun haben. Dies wurde in der Vergangenheit für Angriffe ausgenutzt, und darum wurden additional RRs auf die gleiche Domain beschränkt (in-bailwick). Dan Kaminski: Clevere Kombination beider Attacken, um Sicherheitsmaßnahmen zu umgehen. Angreifer sendet viele Anfragen für die gleiche Domain Gleichzeitig sendet er viele gefälschte Antworten auf diese Anfragen, die additional RRs für (in-bailwick) enthalten Erfolgreich nach etwa 320 Queries Gegenmaßnahme: Source port randomization Sicherheitsprobleme des DNS DNS als Angriffsvektor für DoS ripe52-plenary-dnsamp.pdf Session 2 / 24

25 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC DNNSEC: Beispiel Das Beispiel example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number ; ref = refresh = 2d 900 ; ret = update retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) IN NS ns1.example.com. IN NS ns2.example.com. ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. wird zu Session 2 / 25

26 DNNSEC: Beispiel example.com IN SOA ns1.example.com. hostmaster.example.com. ( ; serial ; refresh (2 days) 900 ; retry (15 minutes) ; expire (2 weeks) 3600 ; minimum (1 hour) ) SOA SIG ( GiVY6piouHMs6GBeTKZXJCtH1zFmMn37gkSn hxdltmqnluh1bbxwugorm4nhsxkonlkejfpq vmn8japysksnwafr4ig5potucx3ut47ewkpe t/mybudolwkrxk38kclovnsteas/5pntbanu 1M5iFsVeqnCqZ5WGCA/hg3x+O/Q= ) ns1.example.com NS NS ns2.example.com SIG NS ( RdsrMFE3j2p1XMjLvotUxybVhGCNjrJ3eaR2 d+iccwsd2hfkchg6gdshm9/1pcpksyzqinf1 OMddD2RJycHxGQJosxHgK6vnzzetgPP05tAc hqdhpbfroinjdim3hy+m9d0qvrrxbuo+fuol FY+ppcTHnXbCBwguGD+MzSUbPls= ) ( KEY AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = host2.example.com. NS SOA SIG KEY NXT NXT SIG NXT ( defefl2lorju0ekwuybkenvit6trtk3i1tmw lfqcxcm13+6t17m8f6f/i+7wj1dewcfndsbe ZCeUwyUQs0KJduNqPlBzLS6nZO7ocCO6NAQV vcu14f18eoppgzriko8eetgx3fp33gcg6u6h brfnlg2rfkpooqyagcqf7bz2fm0= ) host2.example.com IN A IN A SIG A ( S3yTxBrgCOSjVeEAHeGSzPjyJALunjL51DkK z7wpkpswm1l+fl8+9zfmuubdfffj24zfuwbg NKQ6H0QLJA5u46MSdB0wgxpuAaTYZKzTJzpF uv1ehbx1recl1deonzwjygfoiizrtxuwbckm jekkeitcwlermvc7wqlllkemv+s= ) host4.example.com. A SIG NXT NXT SIG NXT ( A1sXJloJvtIJBVA+5mjMeJVaDXVep6ktiVs7 VEHmYKJYCAGENk3KOe2M5CGjxp6B2+JvRLIA L5jfu4hr9q4YHO8+7DO8NAwlUxCZNasfg5ma RG1q+j6URIWHUSw2bYvtqIAoQfJAQ9LP9Mkk Uo5zykb6/m/D0jjQXD/69IJIHHY= ) host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) ns1.example.com. A SIG NXT NXT SIG NXT ( UH3qy4MlObeEIdzCt4Ekf2kBMAdq01RfRq66 2k5zrEoKl/s1VaX5UDXrmgG+Xtipqe9pXnQb z/0nvzqz8+l3nfgdqcxrfrp5wxaqvtvqg7pq VEKVlhPZ3DYBXEVs3Sur/dtfFbkCEWS6BAoB UByA1k+V11QqAMBU0Buc5UcPP70= ) CNAME host2.example.com. ns1.example.com IN SIG CNAME ( jf8ygmpvlfkq+hzhbdgnwd6ufzeql9xstjq8 yhslst2ygkkok3p8h9ra5umrvhtc6+hmp6mp 1M/dde7qOwSzurBcdHTRKz6JX5S+ODw5yWOi bqndg+cjif1rebrxui9domusaidgexv37zb/ K5ab5OvWzwezxMEI3xRTGzGhB8Y= ) ns2.example.com. CNAME SIG NXT NXT SIG NXT ( f8gjwfa5a1r3py7hfdjkdzu11rhdm+1tmp1x THTRuoXyasCEO0uRWMaR4Q/+ubU9EZtM/xrt /T77RjfNGb5rmM8OC/dzAMsp0cD/ZNnF0TOi Gl9Vep9am1vG4lXKkNDDsttY+rnTwFg6nPst y0dkfyy2hoas9ssr8+1jrlil+hs= ) ns2.example.com IN A SIG A ( C3e/g9FeemMJag1lIKIYSMXQjLFh/aVgms94 r4vam2k8t7cow/n/vxf6gztncna5ybvhj9go huqxezufs897djctfqdp61iwjlokguc28nea Aa7RcSpQw+1i3XWoP5petvMohfJYALfQ6NUY O5aGzqQTRpuAT4aqGy6OMRmaOr8= ) NXT example.com. A SIG NXT SIG NXT ( b4vob1/nptpp3xb6ngkhrpkyk53lkocou+ym FXt4ulVfFtt3i+TsSW8Iyl1zlouvQrWekKGm EZtlDfo0KlrzYleAKluBMCvizjeGzolgnUwT eqwqy7dxvig8ngo51bxh1lpha7shx9vmpiwx 4a8xzDPx0OPIbIEZkUopvHjMzDs= ) DNSSEC: Vorgehensweise mit BIND Der Befehl dnssec-keygen -a RSA -b n ZONE -r /dev/urandom example.com liefert Kexample.com key (öffentlicher Schlüssel als KEY-RR) und Kexample.com private (privater Schlüssel) Einbinden des öffentlichen Schlüssels mit $include Kexample.com key Signieren des Zonefiles mit dnssec-signzone -r /dev/urandom -t example.com Kexample.com Session 2 / 26

27 DNNSEC: Beispiel example.com IN SOA ns1.example.com. hostmaster.example.com. ( ; serial ; refresh (2 days) 900 ; retry (15 minutes) ; expire (2 weeks) 3600 ; minimum (1 hour) ) SIG SOA ( GiVY6piouHMs6GBeTKZXJCtH1zFmMn37gkSn hxdltmqnluh1bbxwugorm4nhsxkonlkejfpq vmn8japysksnwafr4ig5potucx3ut47ewkpe t/mybudolwkrxk38kclovnsteas/5pntbanu 1M5iFsVeqnCqZ5WGCA/hg3x+O/Q= ) NS ns1.example.com NS ns2.example.com SIG NS ( RdsrMFE3j2p1XMjLvotUxybVhGCNjrJ3eaR2 d+iccwsd2hfkchg6gdshm9/1pcpksyzqinf1 OMddD2RJycHxGQJosxHgK6vnzzetgPP05tAc hqdhpbfroinjdim3hy+m9d0qvrrxbuo+fuol FY+ppcTHnXbCBwguGD+MzSUbPls= ) KEY ( AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = NXT host2.example.com. NS SOA SIG KEY NXT SIG NXT ( defefl2lorju0ekwuybkenvit6trtk3i1tmw lfqcxcm13+6t17m8f6f/i+7wj1dewcfndsbe ZCeUwyUQs0KJduNqPlBzLS6nZO7ocCO6NAQV vcu14f18eoppgzriko8eetgx3fp33gcg6u6h brfnlg2rfkpooqyagcqf7bz2fm0= ) DNNSEC: Beispiel host2.example.com IN A IN A SIG A ( S3yTxBrgCOSjVeEAHeGSzPjyJALunjL51DkK z7wpkpswm1l+fl8+9zfmuubdfffj24zfuwbg NKQ6H0QLJA5u46MSdB0wgxpuAaTYZKzTJzpF uv1ehbx1recl1deonzwjygfoiizrtxuwbckm jekkeitcwlermvc7wqlllkemv+s= ) NXT host4.example.com. A SIG NXT SIG NXT ( A1sXJloJvtIJBVA+5mjMeJVaDXVep6ktiVs7 VEHmYKJYCAGENk3KOe2M5CGjxp6B2+JvRLIA L5jfu4hr9q4YHO8+7DO8NAwlUxCZNasfg5ma RG1q+j6URIWHUSw2bYvtqIAoQfJAQ9LP9Mkk Uo5zykb6/m/D0jjQXD/69IJIHHY= ) Session 2 / 27

28 DNNSEC: Beispiel host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) NXT ns1.example.com. A SIG NXT SIG NXT ( UH3qy4MlObeEIdzCt4Ekf2kBMAdq01RfRq66 2k5zrEoKl/s1VaX5UDXrmgG+Xtipqe9pXnQb z/0nvzqz8+l3nfgdqcxrfrp5wxaqvtvqg7pq VEKVlhPZ3DYBXEVs3Sur/dtfFbkCEWS6BAoB UByA1k+V11QqAMBU0Buc5UcPP70= ) DNNSEC: Beispiel ns1.example.com IN CNAME host2.example.com SIG CNAME ( jf8ygmpvlfkq+hzhbdgnwd6ufzeql9xstjq8 yhslst2ygkkok3p8h9ra5umrvhtc6+hmp6mp 1M/dde7qOwSzurBcdHTRKz6JX5S+ODw5yWOi bqndg+cjif1rebrxui9domusaidgexv37zb/ K5ab5OvWzwezxMEI3xRTGzGhB8Y= ) NXT ns2.example.com. CNAME SIG NXT SIG NXT ( f8gjwfa5a1r3py7hfdjkdzu11rhdm+1tmp1x THTRuoXyasCEO0uRWMaR4Q/+ubU9EZtM/xrt /T77RjfNGb5rmM8OC/dzAMsp0cD/ZNnF0TOi Gl9Vep9am1vG4lXKkNDDsttY+rnTwFg6nPst y0dkfyy2hoas9ssr8+1jrlil+hs= ) Session 2 / 28

29 DNNSEC: Beispiel ns2.example.com IN A SIG A ( C3e/g9FeemMJag1lIKIYSMXQjLFh/aVgms94 r4vam2k8t7cow/n/vxf6gztncna5ybvhj9go huqxezufs897djctfqdp61iwjlokguc28nea Aa7RcSpQw+1i3XWoP5petvMohfJYALfQ6NUY O5aGzqQTRpuAT4aqGy6OMRmaOr8= ) NXT example.com. A SIG NXT SIG NXT ( b4vob1/nptpp3xb6ngkhrpkyk53lkocou+ym FXt4ulVfFtt3i+TsSW8Iyl1zlouvQrWekKGm EZtlDfo0KlrzYleAKluBMCvizjeGzolgnUwT eqwqy7dxvig8ngo51bxh1lpha7shx9vmpiwx 4a8xzDPx0OPIbIEZkUopvHjMzDs= ) DNNSEC: SIG-RR - RData type covered algorithm labels original TTL signature expiration signature inception key tag signer's name + / / / / / signature / / / Session 2 / 29

30 DNNSEC: SIG-RR host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) Dieser Teil ist auf der vorhergehenden Folie beschrieben. DNNSEC: SIG-RR Was wird signiert? type covered ist der Typ des Ressource Records (bzw. RRSets), der durch diese Signatur authentifiziert wird (in unserem Beispiel A ). Mit welchen Algorithmen wurde signiert? Für das Feld algorithm sind in RFC 2535 vier verschiedene Werte definiert (in unserem Beispiel 1 für MD5/RSA). Auf welcher Ebene des DNS-Baumes wurde signiert? Die ganze Zahl in label gibt an, aus wie vielen durch Punkt getrennten Teilen der Name des signierten Eintrags im Zonefile besteht. (Für die Signatur des Adresseintrags von host4.example.com muss hier somit die Zahl 3 stehen). Session 2 / 30

31 DNNSEC: SIG-RR Wie lange darf die Signatur maximal gecached werden? Der eigentliche TTL-Wert einer Signatur (Zahl vor dem SIG in unserem Beispiel in Bild 8.10), der mit dem TTL-Wert des geschützten RRSet identisch sein muss, ist nicht gegen Manipulationen geschützt. Beim Caching wird dieser Wert ständig erniedrigt. Die original TTL wird daher im SIG RR aufgenommen und mit signiert. Wie lange ist die Signatur gültig? Hier wird im Wire format Beginn und Ende der Gültigkeitsdauer der Signatur in Anzahl der Sekunden seit dem angegeben, in der ASCII-Darstellung des Zonenfiles wird dagegen das besser lesbare Format JJJJMMTThhmmss verwendet. DNNSEC: SIG-RR Welcher öffentliche Schlüssel zur Verifikation herangezogen werden muss, ist aus dem key tag-wert ersichtlich. (Der key tag unseres Beispielschlüssels ist die Zahl 16307, die auch in den Dateinamen der Public Key- Datei vorkommt.) Wer hat signiert? Hier wird natürlich der Domainname des Eigentümers des öffentlichen Schlüssels angegeben. (Im Beispiel example.com.) Natürlich muss auch die eigentliche Signatur angegeben werden, deren genaue Struktur von dem gewählten Algorithmus abhängt. (Base64-codiert Hdx... 6QA=.) Session 2 / 31

32 Wiederholung: Ressource Records Aufbau eines Ressource Records / / / NAME / TYPE CLASS TTL RDLENGTH / RDATA / / / DNNSEC: Berechnung der Signatur The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class. This covered RRset is thereby authenticated. To accomplish this, a data sequence is constructed as follows: data = RDATA RR(s)... where " " is concatenation, RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature, and RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order as defined in Section 8. How this data sequence is processed into the signature is algorithm dependent. These algorithm dependent formats and procedures are described in separate documents (Section 3.2). Session 2 / 32

33 DNNSEC: KEY-RR flags protocol algorithm / / public key / / / KEY ( AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = DNNSEC: KEY-RR Anwendungsgebiet ist im protocol-feld angegeben: DNSSEC (3), TLS (1), (2), und IPSEC (4). algorithm-eintrag definiert Typ des public key: 1 für RSA/MD5 [RFC 2537], 2 für Diffie-Hellman [RFC 2539], 3 für DSA [RFC 2536], und 4 für einen Algorithmus auf Basis elliptischer Kurven. flags-feld: Besonderheiten des Domain Name Systems spielen eine Rolle. Bspl: SOA RR aus unserer Beispieldatei enthält hostmaster.example.com. Das flags-feld definiert diesen Eintrag eindeutig als -Adresse. Session 2 / 33

34 DNNSEC: KEY-RR Anwendungsgebiet ist im protocol-feld angegeben: DNSSEC (3), TLS (1), (2), und IPSEC (4). algorithm-eintrag definiert Typ des public key: 1 für RSA/MD5 [RFC 2537], 2 für Diffie-Hellman [RFC 2539], 3 für DSA [RFC 2536], und 4 für einen Algorithmus auf Basis elliptischer Kurven. flags-feld: Besonderheiten des Domain Name Systems spielen eine Rolle. Bspl: SOA RR aus unserer Beispieldatei enthält hostmaster.example.com. Das flags-feld definiert diesen Eintrag eindeutig als -Adresse. DNNSEC: NXT-RR next domain name / type bit map / NXT ns.example.net. NS SOA MX SIG KEY NXT Session 2 / 34

35 DNNSEC: NXT-RR Problem: Alle Antworten müssen in DNSSEC digital signiert sein. Für existierende RRs kann diese Signatur vorberechnet werden Bei nicht existierenden Servernamen müsste sie on the fly berechnet werden. Dies ist zu rechenaufwändig. Lösung: Das NXT-RR spezifiziert den lexikographisch nächsten RR, zu dem dann eine vorberechnete Signatur vorliegt Zonefile wird nach Namen geordnet: Labels des Namens von rechts nach links, auf jeder Ebene lexikographisch. Ordnung ist zyklisch: Der letzte NXT-RR verweist wieder auf SOA-RR DNNSEC: DS-RR Key Tag Algorithm Digest Type / / / Digest / / / Session 2 / 35

36 DNNSEC: DS-RR Problem: Wo soll der Public Key einer Zone gespeichert sein? In der Zone selbst? So nicht vertrauenswürdig. In der übergeordneten Zone? Wie kommt er da hin? Lösung: Das Delegation Signer-RR (DS) Tag und Hashwert des Public Key werden in der übergeordneten Zone gespeichert. DNNSEC: DS-RR -Zonefile DS für.com Vergleich.com -Zonefile KEY für.com DS für example.com Vergleich example.com-zonef. KEY für example.com A für Session 2 / 36

37 DNNSEC: Verifikation eines Eintrags 1. Er fragt den Rootserver nach 2. Der Rootserver kennt diesen Namen nicht, er weiß aber, welche Nameserver für die Domäne.com zuständig sind. Wir erhalten in einer Referral genannten Nachricht die Namen der Nameserver (unsigniert, da Änderungen dieser Namen von der.com-domäne verwaltet werden) die IP-Adressen der Nameserver (unsigniert, s.o.) und den DS-RR für.com, einschließlich des SIG -RR dazu. 3. Der Resolver verifiziert das SIG-RR zum DS-RR mit Hilfe des vorkonfigurierten Schlüssels für die Root-Zone, und macht nur weiter, falls diese Verifikation positiv ist. DNNSEC: Verifikation eines Eintrags 4. Der Resolver fragt bei einem der.com-nameserver nach 5. Der.com-Nameserver kennt diesen Namen nicht, er weiß aber, welche Nameserver für die Domäne example.com zuständig sind. Wir erhalten in der Referral-Nachricht die Namen der Nameserver (unsigniert), die IP-Adressen der Nameserver (unsigniert), den KEY -RR für die Zone.com, einschließlich des zugehörigen SIG-RR und den DS-RR für example.com, einschließlich des SIG-RR dazu. Session 2 / 37

38 DNNSEC: Verifikation eines Eintrags 6. Der Resolver verifiziert diese Antwort, indem er den Hashwert des KEY-RR für die.com-zone mit dem in Schritt 2 erhaltenen DS-RR vergleicht, und den SIG-RR zum DS-RR mit dem öffentlichen Schlüssel der.com-zone verifiziert. 7. Der Resolver fragt bei einem der example.com- Nameserver nach 8. Der example.com-nameserver kennt diesen Namen und sendet die IP-Adresse von (A-RR), zusammen mit dem SIG-RR dafür, und den KEY-RR für die Zone.com, einschließlich des zugehörigen SIG-RR. DNNSEC: Verifikation eines Eintrags 9. Der Resolver verifiziert diese Antwort, indem er den Hashwert des KEY-RR für die example.com-zone mit dem in Schritt 5 erhaltenen DS-RR vergleicht, und den SIG-RR zum A-RR mit dem öffentlichen Schlüssel der example.com-zone verifiziert. Das Ganze wird noch etwas komplexer, wenn zwischen Key Signing Keys und Zone Signing Keys unterschieden wird. Session 2 / 38

39 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) Sicherheitsprobleme des DNS DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Probleme mit DNSSEC DNSSEC kann für DNS Amplification Attacks benutzt werden (s.o.) DNSSEC größte PKI aller Zeiten Session 2 / 39

40 Probleme mit DNSSEC DNSSEC größte PKI aller Zeiten Wer soll überprüfen, ob die ca. 70 Millionen Hashwerte, die die.com-zone signieren muss, alle echt sind? Probleme mit DNSSEC DNSSEC und DNS Amplification Attacks Angreifer sendet über UDP (verbidnungslos) Anfrage nach DNSSEC-geschützter Domain, mit IP-Adresse des Opfers Wenn der nachgefragte Name ein Alias war, müssen ein CNAME-Eintrag die Signatur dazu ein A-Eintrag die Signatur dazu evtl. der Key-RR mit zugehörigem Sig-RR Session 2 / 40

41 Implementierungen sponsored by The Foundation for Internet Infrastructure in Sweden. - operated by CAIRN (Collaborative Advanced Interagency Research Network), a DARPAsponsored network for collaborative research. - sponsored by NLnet Labs. Quellen DNSSEC: The Protocol, Deployment, and a Bit of Development by Miek Gieben, NLnet Labs. Internet Protocol Journal v7 no2, June David Hinshelwood: DNS, DNSSEC and the Future. SANS Reading Room Jürgen Pfleger: DNSSEC Resolver Algorithm. Diplomarbeit / Master Thesis FH Wiener Neustadt, 4/2003. Session 2 / 41