Cyber Security – DNS

Einleitung

1. DNS – Domain Name System

Das Domain Name System (vgl.: DNS) ist eine der ältesten Techniken und Protokolle, das heute noch zum Einsatz kommt. Ursprünglich war es ein Ersatz für die lokalen Host Dateien, die in einem „vertrauenswürdigen“ Netz untereinander ausgetauscht wurden. Vertraulichkeit und Integrität waren in diesem beschränkten Netz von Haus aus vorhanden.

1987 wurden zwei Request For Comments (vgl.: RFCs) veröffentlicht, die DNS zum Inhalt haben – RFC1034 und RFC1035. In keiner von beiden RFCs sind Sicherheits- noch Kontrollspezifikationen aufgeführt.

Mit dem rasanten Wachstum und Angebot im und über das Web steigt auch der Gebrauch und vor allem die Notwendigkeit einer intakten DNS Infrastruktur. Anfang der 90iger Jahre entspann sich auch eine öffentliche Diskussion zum Thema Datenschutz, damals als Schutz der Privatsphäre (vgl.: RFC6973, DS-RL95, DSG2000 …) Auf technischer Seite wurde zumindest die Notwendigkeit von Sicherheits- und Vertraulichkeitsmaßnahmen festgestellt. Eine Umsetzung erfolgt aber nur schleppend.

Es folgt eine Darstellung in chronologischer Abfolge von Ansätzen, um die Sicherheit von DNS Infrastrukturen umzusetzen.

2. DNS Grundlage

Eine ausführliche Beschreibung, wie DNS funktioniert findet sich hier. In aller Kürze lässt sich die Funktionalität eines DNS so beschreiben, dass dieser zu einem Namen die IP Adresse zurückliefert. Beteiligt sind an einer DNS Abfrage mehrere Parteien.

• Endgerät/ Client – (Webfähig) und hier sitzt der Benutzer in der Regel
• DNS Resolver – dieser Dienst kann lokal, oder auch extern laufen
• Root DNS – die „Quelle der Wahrheit“. Diese Server halten die originalen Einträge zu einer Domäne. Man spricht in diesem Fall auch von autoritativen DNS.

Die oberste Stufe aller Domänen sind die sogenannte Top Level Domain (vgl.: TLD) und die TLD Authority, die sie verwaltet und beauskunftet. Derzeit gibt es etwas mehr als 1500 TLDs, einen Überblick findet sich hier auf Wikipedia.

Die funktionale Beschreibung einer DNS Abfrage sieht drei Möglichkeiten einer Namensauflösung vor.

(1) Der Eintrag ist im Zwischenspeicher des Resolvers vorhanden. Der Zwischenspeicher ist durch die Anzahl der „Stubs“ (vgl.: Platzhalter) beschränkt.

(2) Der rekursive Resolver bekommt die Antwort von einem autoritativen Server, zu dem die Domäne gehört.

(3) Antwort von einem Server an einen Server

ad (1): Es handelt sich um eine Abfrage von einem Benutzer an die Namensauflösung durch einen rekursiven Resolver.

ad (2) + (3): Die Auflösung erfolgt über die offizielle DNS Infrastruktur.

Der Benutzer muss höchstens die IP Adresse seines DNS Resolvers kennen. Meist wird ihm diese aber auch schon automatisch über den DHCP zur Verfügung gestellt. Die Kommunikation erfolgt mittels UDP auf den Zielanschluss (vgl.: Port) 53 am DNS.

Aus Sicht der Netzwerkadministration gibt es zwei Alternativen.

• Alternative 1: Errichten und Betreiben eines eigenen (rekursiven) DNS, der mit den Root und TLD Servern kommuniziert.
• Alternative 2: Verwendung eines DNS Forwarders, der sich öffentlicher (rekursiver) Resolver bedient. (Z.B.: OpenDNS etc.)

Welche Alternative auch gewählt wird, ein DNS arbeitet immer auf zwei Arten – rekursiv und/ oder iterativ – und das möchte ich jetzt kurz beleuchten.

2.1. Rekursiv

Beschreibt den Vorgang alle Informationen einzuholen, wenn der Server eine Anfrage von einem Benutzer bekommt. Dieses Einholen beinhaltet:

• (1) Überprüfen, ob der Eintrag bereits im lokalen Zwischenspeicher vorhanden ist. Wenn kein Eintrag vorhanden ist, dann
• (2) weitervermitteln der Anfrage an autoritative und TLD Server im Internet. Die Abfrage erfolgt iterativ – schrittweise – in Bezug auf die hierarchische Stellung.

Eine schematische Darstellung des Ablaufes findet sich in der Grafik. Die Grafik stellt den DNS Verkehr dar, wenn aus dem lokalen Netz die Webseite des ORF abgerufen wird.

Die Antwort auf die ursprüngliche Anfrage, welche Adresse hat orf.at, wird in Form einer IP Adresse zurückgeliefert. Die Hauptlast liegt augenscheinlich am Rekursiven DNS. Dieser muss konkret zumindest drei weitere DNS anfragen und auch auf deren Antworten warten, um die eigentliche Clientanfrage abarbeiten zu können.

2.2. Iterativ

Diese Methode kommt zur Anwendung, wenn der DNS seine eigenen Einträge gegenüber der Anfrage prüft und entsprechend antwortet. Die Antwort gliedert sich in,

• (1) Antwort und wenn kein lokaler Eintrag vorhanden ist, dann
• (2) Verweis auf den nächsten autoritativen DNS. (In der Regel eine Hierarchiestufe höher)

Daraus lässt sich schliessen, dass bei dieser Art auch die Last am rekursiven DNS, dem Resolver, liegt. Aus Sicht der Netzwerkadministration und der Effizienz des Mittel- und Ressourceneinsatzes kommt es in der Regel somit zum Gebrauch von öffentlichen rekursiven DNS. Solche öffentliche Server werden meist vom Internet Service Provider (vgl.: ISP) zur Verfügung gestellt. Die Verwendung öffentlicher rekursiver DNS benötigt keinen eigenen Administrationsaufwand. Es ist aber zu beachten, dass öffentliche DNS zumindest gefilterte Antworten liefern (müssen). Dieser Zwang hat seinen Grund meist in rechtlich verbindlichen Vorgaben – der ISP Magenta zum Beispiel führt diese Netzsperren hier auf.

2.3. Weitere Grundkonzepte für DNS

Auf der obersten Ebene einer Domäne finden sich die sogenannten Resource Records (vgl.: RR) die in die Zuständigkeit der Domäne fallen, zusammengefasst sind sie in der Start of Authority (vgl.: SOA) einer Domäne. SOA besteht somit aus einer Liste von RRs einer bestimmten Domäne und beinhaltet auch den Gültigkeitszeitraum von DNS Einträgen und auch Hostnamen. RR entsprechen den Diensten, die eine Domäne anbietet, wie Webservice, Email, Canonical Names, usw. Eine genau Auflistung der Parameter kann hier nachgelesen werden.

3. DNS Sicherheit

DNS Sicherheit wurde lange nicht die oberste Priorität bezüglich Umsetzung von Sicherheits- und Kontrollmechanismen zugemessen. Ersichtlich vor allem an der seit Jahren existierenden Möglichkeit DNS als Grundlage für Distributed Denial of Service Attacken (vgl.: DDOS) zu verwenden – Stichwort DNS Reflektion etc. In letzter Zeit aber gibt es wieder vermehrt Initiativen DNS und sein Umfeld sicherer zu machen. Auslöser sind hier Datenschutzverletzungen, Angriffe gegen DNS Infrastrukturen und aber auch staatliche Lenkungsmaßnahmen.

3.1. DNS Sicherheit – warum?

Die Frage lautet eigentlich, warum sollte man überhaupt in Betracht ziehen eine der folgenden Lösungen umzusetzen. Datenschutz, Spionage, Benutzerverhalten (zB.: Surfverhalten), Denial of Service und auch Daten unerkannt aus einem Unternehmen herausschleusen sind nur einige der möglichen Angriffsvektoren aus dem Bereich Datenschutz und Datensicherheit. Im allgemeinen kann man Angriffe gegen DNS in vier Kategorien gliedern. (Anm.: Damit sind die Hauptangriffsvektoren gemeint und es gibt sicher noch einige weitere Angriffsvektoren, die aber hier nicht von Relevanz sind)

Domain Poisoning	Veränderung der Antwort (IP Adresse) bei vorhandener Domäne
Amplification DDOS	Ausnutzung von Schwachstellen, um Zielsysteme mit DNS Verkehr zu überlasten.
Records forgery (hijacking)	In etwa: IP Adresse am autoritativen Nameserver ändern.
Fast Flux/ Double Flux	Angreifer ändert die IP seiner Schaddomäne. Änderung von Domäne und IP Adresse ist dann Double Flux.

Zwei weitere Angriffsvektoren sind noch am Rand zu nennen.

(1) Typosquatting: Eine ähnlich lautende, oder dem Schriftbild ähnliche Domäne, wird verwendet, um zum Beispiel für Phishing verwendet zu werden. (Z.B.: googel.at vs google.at etc….)

(2) Domain Generating Algorithm (vgl. DGA) – Namen von Domänen werden automatisiert erstellt, um über eine Vielzahl von Domän Namen Schadcode zu verteilen. Zu finden vor allem im „as a Service“ Bereich.

3.2. DNS Sicherheit – Geschichte

DNS, sowie alle anderen Internet basierenden Technologien, haben anfangs keine Sicherheits- und Kontrollmechanismen vorgesehen. Es war aufgrund des beschränkten Teilnehmerkreises und der persönlichen Vertrauensstellung anfangs auch nicht notwendig. Mit der Zeit, und vor allem mit dem Wachstum und der Entwicklung der Internet Technologien, findet in vielen Bereichen eine laufende Weiterentwicklung statt. Anpassungen des Protokolls, vor allem nach Sicherheitsvorfällen, führen dazu, dass vermehrt das Augenmerk auf Sicherheits- und Kontrollmechanismen gelegt wird. In einem ersten Schritt wurde die Richtigkeit, Authentizität, von Einträgen auf Root/ Autoritativen DNS behandelt.

• Ein erster Vorschlag wird seit 1995 diskutiert – DNS Security Extensions (vgl.: DNSSEC). Dieser Vorschlag wurde 1997 in der RFC2065 konkretisiert.
• Mit der Veröffentlichung von RFC2535 wurde der Protokoll Standard 1999 vervollständigt.
• BIND, ab Version 9.5, ist der erste DNSSEC-fähige DNS.
  Implementierungen hatten meist Performanceeinbußen zur Folge.
• Im Rahmen der Behebung dieser Probleme entstanden die RFCs 4033, 4034 und 4035. Diese ersetzen die ursprüngliche RFC 2535.
• DNSSEC hat keine einheitliche Basis für die zu verwendende Verschlüsselungstechnologie vorgesehen. Das führt dazu, dass es entsprechend viele Möglichkeiten für eine vertrauliche Kommunikation gibt.
• 2008 wurde DNScurve und DNSCrypt als freie Software (vgl.: Open Source) veröffentlicht. Damit wird versucht beide Problemkreise – Authentizität und Verschlüsselung – in den Griff zu bekommen.
• 2011 kam die Gültigkeitsprüfung mittels TLS Zertifikaten hinzu – RFC 6698. Genannt DNS based Authentication of Named Entities (vgl.: DANE)
• Seit 2013 besteht die Internet Corporation for Asigned Names and Numbers (vgl.: ICANN) auf der Verwendung von DNSSEC für generische Top Level Domänen (vgl.: TLD)
• Seit 2014 beschäftigt sich die Internet Engineering Task Force (vgl.: IETF) damit die Client Seite sicher zu machen. Dazu wurde die Arbeitsgruppe DNS Private Exchange (vgl.: DPRIVE) ins Leben gerufen. Zum Aufgabenfeld gehören von Sicherheitslösungen für den Betrieb eines DNS bis hin zur sicheren Punkt zu Punkt Kommunikation.
• Seit 2019 unterstützen große Service Provider und Diensteanbieter verschiedene Arten DNS mit Datenschutzfunktionen – DNS over HTTPS (vgl.: DoH) und DNS over TLS (vgl.: DoT)
• Firefox, als Browser, unterstützt seit 2019 mit „Mosaic Killer“ DoH. Standardmäßig ist diese Funktionalität nicht aktiviert. Öffentlich verfügbare DNS von Google unterstützen DoT.

3.3. DNS Sicherheit – Lösungen

Eine Möglichkeit Lösungen zu gliedern ist sie nach den drei Grundelementen der Informationssicherheit zu betrachten. Datenschutz ist in diesem Schritt nicht explizit Teil der Betrachtung. Aber wenn eine der Grundlagen der Datensicherheit nicht erfüllt ist, dann kann Datenschutz erst recht nicht gewährleistet werden.

Das sogenannte Dreigestirn sind Vertraulichkeit, Integrität und Verfügbarkeit. Diese Paradigmen lassen sich nun aufteilen in zwei Zonen. Eine Zone, die die Abfrage durch den Benutzer, oder durch die Infrastruktur betrifft. Hier ist die Vertraulichkeit die oberste Prämisse. Die zweite Zone kümmert sich vor allem um die Integrität der Information auf den nachgelagerten Systemen. Hier ist die Prämisse Integrität. Verfügbarkeit an sich wird von keiner der Lösungen an sich versucht umzusetzen. Man bedient sich entsprechend bestehender Ansätze und Lösungen.

Es gibt Lösungen in allen Schattierungen. Eine oder beide Prämissen können mit einer Lösung erreicht werden. Es gibt auch Lösungen, die bei allen Teilnehmern eine einheitliche Software voraussetzen.

Zone 1	Vertraulichkeit Namesauflösung durch den Bentuzer
Zone 2	Integrität DNS Namensauflösung

4. Vertraulichkeit

Um die Vertraulichkeit der Kommunikation zu gewährleisten muß diese zwischen allen Kommunikationspartnern gewährleistet sein. Das heisst im Allgemeinen den DNS Verkehr zu verschlüsseln. Damit wird die Auswahl der Optionen eingeschränkt durch:

(1) Sind die Grundlagen für eine Verschlüsselung vorhanden, wie vertrauenswürdiger Schlüsselgenerator usw.

(2) Effizienz der Verarbeitung in Hinsicht auf Geschwindigkeit vor allem.

(3) Benutzte Anschlüsse (vgl.: Port), um mit einem DNS zu kommunizieren. Achtung, meist sieht eine Fallbacklösung vor, dass auf unverschlüsselte Kommunikation zurückgestiegen wird. Dieser Rückstieg kann auch absichtlich erzwungen werden. Das tritt auch dann ein, wenn der Anschluss gesperrt ist durch eine aktive Netzwerkkomponente.

Allgemein bekannte Lösungen sind:

• DNSCrypt (2008)
• Confidential DNS (2013)
• DNSoD (2015)
  DNS over Datagram Transport Layer Security
• DoT (2016)
  DNS over TLS
• DoQ (2017)
  DNS over QUIC
• DoH (2018)
  DNS over HTTPS

4.1. DNSCrypt

Kommt ursprünglich aus der Open Source Welt. Es handelt sich nicht um einen Standard. Veröffentlicht wurde DNSCrypt 2008 und basiert auf DNScurve, um sicher Schlüssel auszutauschen und DNS Abfragen zwischen Benutzer und Server zu verschlüsseln. Im Jahr 2011 wurde dies in die OpenDNS Infrastruktur übergeführt, die heute Teil von Cisco Umbrella ist.

Die Arbeitsweise ist, dass ein lokaler Prozess, quasi als lokaler rekursiver DNS, alle Anfragen des Benutzers entgegennimmt. Der Prozess verpackt alle Anfragen und sickt sie an den entsprechenden DNS, verschlüsselt weiter. Das Augenmerk liegt hier vor allem darauf die Kommunikation vom Benutzer mit dem externen DNS abzusichern. Lokal bleibt der Verkehr unverschlüsselt.

4.2. Confidential DNS

Der erste Entwurf stammt aus 2013. Er sieht vor, dass die Funktion der Namensauflösung, um zwei Parameter ergänzt wird. Die Verwendung der Parameter ist freigestellt, um Kompatibilität zu gewährleisten. Es handelt sich um ein zusätzliches Feld als RR mit dem Namen ENCRYPT, das auch zwischengespeichert werden kann. Die zweite Ergänzung in dem Entwurf ist die optionale Speicherung eines privaten Schlüssels, den sich Client und Server teilen. Sieht jetzt der Client in einer Abfrage, dass der RR ENCRYPTED vorhanden ist, dann kann er mit dem Server und einem asymmetrischen Verschlüsselungsverfahren einen privaten symmetrischen Schlüssel austauschen. Asymmetrische Verfahren stellen einen wesentlich höheren Aufwand an Rechenleistung dar. Damit wird der sichere Austausch eines symmetrischen, gemeinsamen, privaten Schlüssel effizient umgesetzt. Die folgende Kommunikation wird mit dem symmetrischen Schlüssel abgesichert und die Vertraulichkeit an sich bleibt gewährleistet.

Durchgesetzt hat sich dieses Verfahren bis dato nicht. Es sieht vor, dass der Client auch eine unverschlüsselte Kommunikation erzwingen kann. Damit ist die Wirkweise einer verschlüsselten Kommunikation nicht mehr gegeben. Ein Implementierungsaufwand ist sowohl auf Serverseite, wie auch Clientseite gegeben.

4.3. DNSoD

DNS over Datagram Transport Layer Security (vgl.: DNSoDTLS, oder auch DNSoD) kann eingesetzt werden, um die Kommunikation mit dem Benutzer abzusichern. Datagram Transport Layer Security (vgl.: DTLS) wurde nicht explizit für den Einsatz mit DNS entworfen. Die erste Spezifikation stammt aus dem Jahr 2006 durch die IETF – RFC 4347

Grundsätzlich geht es darum bei sogenannten verbindungslosen Protokollen, wie UDP, SIP, etc., etwas gleichwertiges, wie TLS einzuführen. Der erste explizite Entwurf von DNSoD wurde 2015 veröffentlicht. Der letzte aktuelle Entwurf – RFC 8094 – stammt aus dem Jahr 2017 und ist noch immer im Status experimentell. Die Kommunikation erfolgt über den Anschluß (vgl.: Port) 853. DNSoD findet bis dato keine große Verbreitung. Wie üblich kann hier durch den Client eine unverschlüsselte Kommunikation auch erzwungen werden.

4.4 DoT

DNS over TLS (vgl.: DoT) setzt im Gegensatz zum Standard DNS auf die Verwendung des Transport Control Protocls (vgl.: TCP). DNS Kommunikation wird in TLS verschlüsselter TCP Kommunikation eingebettet und an den Empfänger übertragen. Diese Funktionsweise wird in RFC 7858 beschrieben. Der Client verbindet sich auf Anschluss (vgl.: Port) 853 mit dem Server. Der Client hat lokalen Zugriff auf das Serverzertifikat und kann so beim Verbindungsaufbau den Server authentifizieren. Client und Server handeln in weiterer Folge die DNS Kommunikation über einen verschlüsselten Kanal ab. TLS Version 1.3 wird unterstützt, Android ab Version „P“ beherrscht ebenfalls den Umgang und vor allem Google unterstützt DoT. Bei Apple ist die native Unterstützung derzeit geplant, mittels Drittanbietersoftware kann DoT aber auch jetzt schon genutzt werden.

4.5. DoQ

DNS over QUIC (DoQ) ist ein gebündeltes, sicheres, Transportprotokoll, das auf dem Standardprotokoll – UDP – aufsetzt. Es ist ursprünglich als ein alternatives Transportprotokoll entworfen worden, damit Altsysteme weiterhin bedient werden können. Ein Großteil der Kommunikation, auch der Metadaten, erfolgt verschlüsselt. Der Entwurf stammt aus dem Jahr 2012 und ist von der IETF noch nicht für den Produktivstatus vorgesehen. Große Verbreitung ist bis dato nicht zu sehen, aber sowohl Google, wie auch die IETF machen sich für dieses Protokoll auf lange Sicht stark. Beide sehen in QUIC die Grundlage vor allem für den Standard von HTTP/3

4.5. DoH

DNS over HTTPS (vgl.: DoH) wurde im Jahr 2018 veröffentlicht und findet in der RFC 8484 seinen Niederschlag. Die Lösung sieht vor den DNS Verkehr über HTTPS – mittels TLS – abzuwickeln. Eine einfache, wie auch elegante, Lösung. Die Problematik ist auf der Seite der Verwaltbarkeit zu sehen. DNS Verkehr ist Teil des gesamten HTTP Verkehrs und kann nicht mehr getrennt gefiltert und überwacht werden.

5. Integrität

5.1. DNSSEC

Domain Name System Security Extensions (vgl.: DNSSEC) wurde wie bereits erwähnt 1997 in der RFC 2965 formuliert. DNSSEC wurde entworfen, um die Integrität der Informationen nachweisen zu können. Schutz der Privatsphäre war und ist nicht Teil des DNSSEC Konzepts. Die Arbeitsweise ist basierend auf Zertifikaten mit denen Informationen elektronisch signiert werden. Durch die frei zugänglichen Zertifikatsinformationen kann ein eindeutiger Nachweis, dass die Information unverändert ist und korrekt ist, geführt werden. Auf der obersten Stufe der Domänenhierarchie – der generischen TLDs – hat sich DNSSEC etabliert. Bedeutende Unternehmen, wie Google, Cisco und GoDaddy unterstützen und setzen DNSSEC produktiv ein.

5.2. DNScurve

Bezeichnet ein Verschlüsselungsverfahren für DNS Kommunikation, das auf Basis der elliptischen Kurven Kryptographie beruht (vgl.: EKK) Entwickelt wurde DNScurve von Daniel J. Bernstein. Die verwendete Kurve für die EKK wird als „curve25519“ bezeichnet und folgt den Vorgaben der IEEE für den Austausch von öffentlichen Schlüsseln Für die Verschlüsselung selbst wird der Algorithmus XSalsa20 poly1305 eingesetzt. Bei DNScurve wird das Paket mit öffentlichen Schlüsseln beider Seiten verschlüsselt, um die Kommunikation abzusichern. Dieses Verfahren findet seit 2010 Einsatz bei OpenDNS für die Kommunikation mit Benutzern und kommt als Bestandteil von DNSSEC zur Anwendung.

5.3. DANE

DNS based Authentication of Named Entities (vgl.: DANE) dient dazu den Verkehr zwischen Benutzer und Server abzusichern. Veröffentlicht wurde diese Methode 2011. Mit dieser Vorgehensweise wird die Authentifizierung auf Basis von TLS mit DNSSEC erweitert. Die Erweiterung ist nicht nur eine Gültigkeitsprüfung des Zertifikats, sondern auch, ob das verwendete Zertifikat zu dem Domänennamen gehört. Damit werden vor allem Man-in-the-middle Szenarien unterbunden. Auch wenn es sich um ein gültiges Zertifikat handelt wird die Verbindung als unsicher eingestuft, wenn nicht das passende Zertifikat laut DNS Eintrag vorhanden ist. Es ist bis dato nicht verbindlich, dass nur ein gültiges Zertifikat auf einen Domänennamen ausgestellt wird.

6. Ausblick

Kurzfristig wird sich eher DoH aufgrund seiner Einfachheit durchsetzen. DoQ wahrscheinlich auf lange Sicht, vor allem wegen der Fürsprecher, wie Google und IETF.

DNSSEC wird in Verbindung mit DANE mehr Zuspruch finden, wenn der Sicherheitsgedanken stärker ist, als die Benutzerfreundlichkeit. Aktuelle Firewalls zum Beispiel unterstützen die Filterung bereits, aber auch Anwendungen wie Mailprogramme und Browser können damit umgehen.

Auf alle Fälle ist das Thema komplexer, als es sich anfangs darstellt und vor allem eine Bedrohung der Sicherheit und des Datenschutzes. Es ist nur eine Frage der Zeit, bis im Rahmen der DSGVO und des DSG diesbezüglich aktive Maßnahmen eingefordert werden.