Sicheres DNS: DNSSEC und DNS over HTTPS (DoH)

Das Domain Name System (DNS) übersetzt lesbare Domainnamen in IP-Adressen. DNS wurde in den 1980er-Jahren entwickelt und ohne Sicherheitsmechanismen konzipiert – Abfragen und Antworten werden über UDP/TCP-Port 53 im Klartext und ohne Authentifizierung übertragen. Dadurch entstehen zwei wesentliche Schwachstellen: DNS-Cache-Poisoning (Einschleusen gefälschter DNS-Antworten, um Benutzer auf bösartige Server umzuleiten) und DNS-Abhören (die Beobachtung der von einem Benutzer abgefragten Domains gibt Aufschluss über dessen Surfaktivitäten). Zwei Standards begegnen diesen Problemen: DNSSEC verhindert Fälschungen und DNS over HTTPS (DoH) verhindert das Abhören.

DNS-Cache-Poisoning (Kaminsky-Angriff) nutzt die fehlende Authentifizierung des DNS-Protokolls aus. Ein Resolver sendet eine Abfrage an einen autoritativen DNS-Server und speichert die Antwort für die Dauer des TTL-Werts im Cache. Ein Angreifer, der die Transaktions-ID (16 Bit, vorhersehbar) und den Quellport erraten kann (der seit RFC 5452 als zusätzliche Entropie verwendet wird), kann gefälschte Antworten senden, die der Resolver zwischenspeichert. Dadurch werden alle Benutzer, die diesen Resolver abfragen, auf den Server des Angreifers umgeleitet. Sobald der Cache manipuliert wurde, werden Benutzer zu gefälschten Servern geleitet, obwohl sie die richtige Domain eingegeben haben. DNSSEC verhindert dies, indem DNS-Antworten digital signiert werden.

DNSSEC fügt DNS-Einträgen kryptografische Signaturen hinzu. Dadurch können Resolver überprüfen, ob Antworten von der legitimen Autorität der Zone stammen und nicht manipuliert wurden. DNSSEC führt neue Eintragstypen ein: RRSIG (Signatur eines Resource Records, also die eigentliche Signatur über einen Record-Satz), DNSKEY (öffentlicher Schlüssel zur Überprüfung von Signaturen), DS (Delegation Signer, verknüpft die Schlüssel der übergeordneten und der untergeordneten Zone) und NSEC/NSEC3 (authentifizierte Nichtexistenz – weist nach, dass ein Name nicht existiert). DNSSEC bildet eine Vertrauenskette von der Root-Zone (signiert von ICANN) über die TLDs bis zu den autoritativen Zonen.

DNSSEC verwendet zwei Arten von Signaturschlüsseln. Der Zone Signing Key (ZSK) signiert die einzelnen DNS-Record-Sätze (RRSIGs) und wird häufig (monatlich oder vierteljährlich) ausgetauscht, um einen flexiblen Betrieb zu ermöglichen. Der Key Signing Key (KSK) signiert den DNSKEY-Record-Satz und bildet den Vertrauensanker der Zone. Der KSK wird seltener (jährlich) ausgetauscht, da die übergeordnete Zone bei jeder Änderung des KSK mit dem neuen DS-Eintrag aktualisiert werden muss – ein Prozess, der Abstimmung erfordert. Der KSK überprüft den ZSK; der ZSK signiert die Daten. Diese zweistufige Struktur stellt ein Gleichgewicht zwischen Sicherheit (häufiger Austausch des ZSK) und betrieblichem Aufwand (seltener Austausch des KSK) her.

DNSSEC hat wichtige Einschränkungen. DNS-Abfragen werden nicht verschlüsselt – DNSSEC signiert Antworten lediglich zur Sicherstellung ihrer Integrität. Ein Lauscher kann weiterhin alle DNS-Abfragen sehen, aber keine Antworten fälschen. Auflistung der Zone: NSEC-Einträge (die die Nichtexistenz nachweisen) ermöglichen es Angreifern, die Zone systematisch zu durchsuchen und alle darin enthaltenen Domainnamen aufzulisten; NSEC3 erschwert dies durch gehashte Namen, ist jedoch nicht vollkommen sicher. Komplexität im Betrieb: Schlüsselverwaltung, Ablauf von Signaturen und die Abstimmung mit der übergeordneten Zone verursachen einen erheblichen Verwaltungsaufwand. Die Verbreitung von DNSSEC ist weiterhin unvollständig – viele TLDs und Registrare unterstützen DNSSEC, aber viele Organisationen haben es noch nicht implementiert.

DNS over HTTPS (DoH) verschlüsselt DNS-Abfragen innerhalb von HTTPS (RFC 8484) und verbirgt deren Inhalte vor Netzwerkbeobachtern. Die Abfragen werden an einen DoH-fähigen Resolver unter einer standardmäßigen HTTPS-URL gesendet, wodurch DNS-Datenverkehr nicht von anderem HTTPS-Datenverkehr zu unterscheiden ist. Dadurch wird verhindert, dass Internetdienstanbieter, Arbeitgeber und Angreifer entlang des Übertragungswegs sehen, welche Domains ein Benutzer abfragt – damit wird die Datenschutzlücke geschlossen, die DNSSEC offenlässt. Allerdings verlagert DoH das Vertrauen vom DNS-Resolver des Netzwerks auf den DoH-Anbieter (typischerweise Google 8.8.8.8, Cloudflare 1.1.1.1 oder den eigenen DoH-Resolver der Organisation). DoH wird inzwischen von den meisten gängigen Browsern nativ unterstützt.

DNS over TLS (DoT) (RFC 7858) verschlüsselt DNS-Abfragen mithilfe von TLS über den dedizierten TCP-Port 853, anstatt sie durch HTTPS zu tunneln. DoT bietet dieselben Datenschutzvorteile wie DoH – es verbirgt den Inhalt der Abfragen vor Lauschangriffen –, lässt sich von Netzwerkadministratoren jedoch leichter erkennen und filtern (Port 853 statt Port 443). Das ist ein zweischneidiges Schwert: DoT ist sichtbar und kann von Unternehmensfirewalls blockiert werden, während DoH schwerer zu blockieren ist, ohne den allgemeinen HTTPS-Datenverkehr zu beeinträchtigen. Stub-Resolver (auf Betriebssystemebene) verwenden häufiger DoT, Browser dagegen häufiger DoH.

Verschlüsseltes DNS stellt für Unternehmensumgebungen, die auf DNS-basierte Filterung und Sinkholes angewiesen sind, eine Herausforderung dar. Wenn Browser externe DoH-Resolver verwenden, werden interne DNS-Kontrollen umgangen. Gegenmaßnahmen in Unternehmen: einen internen DoH-/DoT-Resolver bereitstellen (Cisco Umbrella, Pi-hole mit DoH) und alle Geräte für dessen Verwendung konfigurieren; IP-Adressen externer DoH-Resolver an der Firewall auf Port 443 blockieren (Google 8.8.8.8, Cloudflare 1.1.1.1); per Group Policy DoH auf Browserebene auf verwalteten Endpunkten deaktivieren; sowie Regeln für einen transparenten Proxy verwenden, die DNS over TLS auf Port 853 abfangen. Ziel ist es, sämtliches DNS über den kontrollierten Resolver zu leiten, ohne verschlüsseltes DNS vollständig zu blockieren.

Eine vollständige DNS-Sicherheitsstrategie kombiniert mehrere Kontrollmechanismen. DNSSEC verhindert bei Ihren autoritativen Zonen die Manipulation des Caches Ihrer Domain. DNS-basierte Filterung (Cisco Umbrella, Cloudflare Gateway) blockiert bösartige Domains auf Resolver-Ebene. DoH/DoT zu einem kontrollierten Resolver schützt die Vertraulichkeit von Abfragen, ohne die Sichtbarkeit für die Filterung zu verlieren. DNS-Protokollierung im SIEM erfasst alle Abfragen zur Bedrohungssuche – DNS-Protokolle machen C2-Datenverkehr, Datenexfiltration durch DNS-Tunneling und Aktivitäten von Malware mit Domain Generation Algorithms (DGA) sichtbar. DNS-Telemetrie gehört zu den wertvollsten verfügbaren Quellen für Sicherheitsdaten.

DNS-Tunneling kodiert Daten in DNS-Abfragen und -Antworten, um Daten zu exfiltrieren oder C2-Kanäle über Netzwerke aufzubauen, in denen anderer ausgehender Datenverkehr blockiert wird. Tools wie iodine, DNScat und dnscat2 kodieren Nutzdaten in Subdomain-Labels (Abfrage von EXFILTRATEDDATA.evil.com) oder TXT-Records. Erkennung: ungewöhnlich lange DNS-Abfragen (>100 Zeichen), ein hohes Abfragevolumen von einem einzelnen Host, Abfragen nicht vorhandener übergeordneter Domains, ungewöhnliche Record-Typen (TXT, NULL) sowie eine Entropieanalyse der Domain-Labels (kodierte Daten weisen eine hohe Shannon-Entropie auf). Plattformen für DNS-Sicherheitsanalysen erkennen Muster von Tunneling automatisch.

DNS Response Policy Zones (RPZ) ermöglichen es DNS-Resolvern, lokale Überschreibungsrichtlinien auf DNS-Antworten anzuwenden – im Wesentlichen wird dadurch ein lokales Sinkhole auf Resolver-Ebene erstellt, ohne die globale DNS-Infrastruktur zu verändern. Fragt ein Client eine als bösartig bekannte Domain ab, gibt die RPZ-Richtlinie NXDOMAIN, eine Weiterleitung an eine Sinkhole-IP-Adresse oder eine unveränderte Antwort zurück. RPZ-Feeds sind von Anbietern für Threat Intelligence (Spamhaus, SURBL) verfügbar und können direkt in BIND- oder Unbound-Resolver importiert werden. RPZ ist ein leistungsfähiges Abwehrinstrument, da die Filterung auf DNS-Ebene für alle Geräte im Netzwerk gilt, ohne dass eine Konfiguration auf den Clients erforderlich ist.

Testen Sie Ihr Verständnis der Konzepte aus CompTIA Security+ (SY0-701) in dieser Lektion.

In dieser Lektion haben Sie gelernt: DNSSEC fügt DNS-Records mithilfe von KSK-/ZSK-Schlüsselpaaren kryptografische Signaturen hinzu, um Cache-Poisoning zu verhindern, verschlüsselt jedoch keine Abfragen; DNS over HTTPS (DoH) verschlüsselt DNS-Abfragen innerhalb von HTTPS, um Lauschangriffe zu verhindern, birgt jedoch das Risiko, dass die Filterung in Unternehmen umgangen wird; und DNS-Tunneling kodiert Daten in DNS-Abfragen und kann anhand von Abfragelänge, -volumen und Entropieanalysen erkannt werden. Als Nächstes befassen wir uns mit IPsec, VPN-Protokollen und der Sicherheit des Fernzugriffs.