goSecurity BLOG

Das Domain Name System (DNS) wurde in den 80er-Jahren mit dem Aufkommen des Internets eingeführt und ist seitdem ein fester Bestandteil des World Wide Web. Das Problem mit DNS jedoch ist, dass es sich seit der Erfindung hinsichtlich Sicherheit nicht verändert hat. Während überall Verschlüsselungen eingeführt wurden und diese andauernd verbessert werden, findet die DNS-Kommunikation immer noch hauptsächlich unverschlüsselt statt. Auch die übertragenen Daten vor Veränderung zu schützen oder deren Authentizität zu prüfen, ist im Standard-Protokoll DNS nicht vorgesehen.

Deshalb habe ich mich auf den Weg gemacht, um Sie als versierten DNS-Administrator über die Möglichkeiten aufzuklären, wie Sie das Verfahren absichern können.

Angriffe

Aufgrund der grossen Sicherheitsmängel ist das DNS schon seit langem ein beliebtes Ziel für Angriffe. Wenn nämlich aufgrund der fehlenden Prüfung der Daten auf Integrität, das Opfer schon vor der ersten Kommunikation auf den falschen Server geleitet wird, nützt auch all die schicke Verschlüsselung des HTTPS nichts. Wobei man hierbei von einem DNS-Spoofing spricht.

„Neue“ Funktionen

Nun sind die Problematiken mit DNS natürlich schon länger bekannt. Die IETF (Internet Engineering Task Force) hat deshalb bereits 1993 begonnen, eine Lösung zu suchen, damit veränderte Daten erkannt werden können. Die Lösung wurde aber erst 2005, 12 Jahre später, mit der DNSSEC (Domain Name System Security Extensions) veröffentlicht.

DNSSEC

Mit DNSSEC kann jeder DNS-Eintrag digital signiert werden. Damit können sowohl die Authentizität als auch die Integrität der Daten gewährleistet werden. Wichtig bei der Signierung ist, dass dies über alle Stufen geschieht. Alle Stufen bedeutet: auf dem Root-Server, auf den Servern, welche die Top-Level-Domains verwalten, und auf den Servern der DNS-Hoster. Ebenso muss die Kontrolle wiederum auf allen Resolvern geschehen, ansonsten ist die Massnahme wirkungslos. Genaue Details sind im FAQ von Switch.ch nachzulesen.

Das grosse Problem hierbei ist, dass keine Prüfung auf den Enduser-Geräten stattfindet. Es ist schlicht keine Technik vorhanden, welche diese ausführen könnte (Stand: Februar 2019). Nur auf den Resolver ist das integriert.

Meiner Meinung nach liegen aber Client-Geräte eher im Fokus der Angreifer. Es ist zum Beispiel wesentlich einfacher die Kommunikation zwischen einem Client und einem Resolver zu manipulieren, als die zwischen zwei DNS-Server.

Das ist auch der Grund, weshalb die DNSSEC keine grosse Verbreitung geniesst. Internet Grössen wie Google, Microsoft oder Twitter, sowie auch Grossbanken wie UBS oder Credit Suisse haben auf ihren Domänen keine DNSSEC (Stand: Februar 2019).

Jedoch ist das Prinzip nicht grundsätzlich schlecht und die vorhandenen Schwachstellen können mit anderen Sicherheitsverfahren behoben werden.

Zum Beispiel kann die Kommunikation zwischen den Clients und dem internen DNS-Server mittels Domain-Isolation verschlüsselt werden. Ab dem DNS-Server kann dann wieder die DNSSEC verwendet werden.

Geräte, welche die Firma verlassen, beispielsweise Laptops oder Tablets, können so eingerichtet werden, dass immer ein VPN in die Firma aufgebaut werden muss. Damit wäre auch wieder der anfälligste Teil verschlüsselt. Wenn VPN auf dem Hotspot geblockt wird? Tja, dann nützt das auch nichts mehr.

Falls Sie sich entscheiden DNSSEC auf Ihrer Domäne zu verwenden, hat die Firma Verisign eine Seite aufgeschaltet, mit welcher Sie die korrekte Funktionsweise prüfen können. Ebenfalls gibt es eine Webseite, um zu prüfen, ob der verwendete DNS-Resolver DNSSEC unterstützt.

Verschlüsselt

Nochmals 11 Jahre hat es gedauert bis die IETF den ersten Standard für den verschlüsselten DNS-Verkehr herausgebracht hat. Mittlerweile sind auch ein paar nicht standardisierte Verfahren vorhanden, jedoch habe ich mich in meinem Blog auf die zwei Anerkannten DoT (DNS over TLS) und DoH (DNS over HTTPS) konzentriert. Beide bringen nebst der Verschlüsselung auch noch den Vorteil, dass diese TCP (Transmission Control Protocol) verwenden. Somit ist die Kommunikation verbindungsorientiert.

DNS over TLS

Beim DoT wird die Kommunikation mittels TLS (Transport Layer Security) verschlüsselt. Dabei werden teilweise von DNS-Servern, welche das schon unterstützen, der Standard TLS 1.3 verwendet. Dieser bietet signifikante Verbesserungen gegenüber dem TLS 1.2, auch in der Performance. Eine Liste mit verfügbaren DoT-Severn finden Sie auf der Seite DNSPrivacy.org.

Der Nachteil bei dieser Variante ist, dass für die Übertragung in den meisten Fällen der Port 853 verwendet wird. Das kann in Gäste- oder öffentlichen WLANs zu Problemen führen, da das kein Standard Port ist und deshalb von den Firewalls ausgehend blockiert wird.

DNS over HTTPS

Zum DoT hat die IETF 2018 den Standard für das DoH herausgebracht. Der grosse Vorteil an dieser Variante ist, dass das Protokoll HTTPS verwendet wird. Von diesem kann ausgegangen werden, dass dieser auf den meisten Firewalls freigegeben ist. Eine Liste mit verfügbaren DoH-Severn finden Sie auf GitHub.

Anwendungen

Nun können die DoT- und DoH-Server nicht in den gewohnten DNS-Einstellungen eingetragen werden, das wäre ja zu schön gewesen. In den meisten Betriebssystemen werden zusätzliche Anwendungen benötigt.

Die einzige Ausnahme ist zurzeit das Android 9 Pie [Stand: Januar 2018], bei welchem direkt ein DoT-Server eingetragen werden kann. Die Einstellung ist unter «Settings->Network & Internet->Advanced->Privat DNS» zu finden.

Stubby

Stubby wurde von einer Arbeitsgruppe der IETF mitentwickelt und ist mit Linux, macOS und Windows kompatibel. Mit diesem Programm können zurzeit nur DoT-Server angesprochen werden, in Zukunft sollten auch DoH-Server unterstützen werden [Stand: Januar 2018]. Das umständliche an Stubby ist, dass kein Dienst gestartet wird. Somit muss das Programm in den Autostart gepackt werden. Die Einstellungen werden beim Stubby in dem Config-File stubby.yml vorgenommen. In diesem sind die kompatiblen DNS-Server schon eingetragen und können durch das Löschen der Raute (#) aktiviert werden. Es können aber auch neue Server hinzugefügt werden, wenn die Liste nicht mehr aktuell ist.

Bevor das Programm gestartet werden kann, müssen die DNS-Server auf dem Windows Betriebssystem auf die Localhost-Adresse (127.0.0.1) angepasst werden. Damit werden die DNS-Anfragen an Stubby geschickt.

Um die Anwendung zu starten, kann entweder die EXE-Datei verwendet werden oder das BAT-File in einem Scheduled Task eingepflegt werden.

Simple DNSCrypt

Simple DNSCrypt hingegen ist ein GUI basiertes Programm, welches für Windows entwickelt wurde. Es wurde für den prioritären Standard DNSCrypt geschaffen, jedoch unterstützt es mittlerweile auch DoH-Server. Der Vorteil bei dieser Anwendung ist, dass ein Dienst gestartet wird. Im Hauptmenü kann definiert werden, welches Protokoll angesprochen werden soll. Zudem können die Anforderungen an die Server definiert werden.

Anhand der eingestellten Anforderungen und Protokolle sind unter «Resolve» die entsprechenden Server ersichtlich. Es kann definiert werden, dass die Server automatisch nach ihrer Verfügbarkeit oder manuell gewählt werden.

Wieder zurück im Hauptmenü kann der Dienst aktiviert werden.

Wie bei der Anwendung Stubby muss für Simple DNSCrypt ebenfalls die Localhost-Adresse als DNS-Server im Betriebssystem eingetragen werden.

AD-Integriert

Für meinen Blog habe ich Simple DNSCrypt in eine AD-Umgebung integriert. Dazu habe ich zwei Server aufgesetzt. Einer mit den Rollen AD und DNS, auf dem zweiten habe ich Simple DNSCrypt installiert.

Unter den DNS-Einstellungen des DNS-Dienstes habe ich den zweiten Server als Forwarder eingetragen.

Im Simple DNSCrypt muss noch beachtet werden, dass unter «Erweiterte Einstellungen» der Schalter «Globaler Resolver» gesetzt ist.

Was bleibt hängen?

Wie Sie sehen, wurden die Problematiken des DNS-Protokolls schon angegangen, jedoch meiner Meinung nach noch nicht zufriedenstellend.

DNSSEC ist im Grunde keine schlechte Sache, jedoch wurde ganz vergessen, dass der Fokus der meisten Angriffe auf den Clients liegt. Dieses Problem kann mittels anderer Mittel behoben werden. Einerseits steigt dann automatisch die Komplexität und Fehleranfälligkeit und andererseits kann einfach nicht jeder Fall abgedeckt werden.

Auch das Thema Verschlüsselung zeigt auf, dass noch viel geschehen muss. Nur in einem gängigen Betriebssystem und das bisher (Stand Januar 2019) nur in einer Version, ist die Unterstützung der verschlüsselten Server direkt integriert. Bei allen anderen muss auf Dritt-Anwendungen zurückgegriffen werden, was die Sache gerade für Laien erschwert. Und dann sind da natürlich noch die lokalen Provider, die ihre DNS-Server dringend nachrüsten müssten.

Es braucht noch einiges, bis die Modifikationen für dieses Grossvater-Protokoll massentauglich werden, aber da steht es ja nicht allein da, denken Sie nur einmal an SMTP…