bk99.de entertain the web since 1997

bk99.de
Lutz Donnerhacke · SicherheitKuratiert

DirectAccess zerstört DNSSEC

Zusammenfassung

Lutz Donnerhacke prüft im Mai 2017 im Labor, wie sich Microsofts Fernzugriff DirectAccess mit einer DNSSEC-signierten Zone verträgt. Über DirectAccess kommen Antworten ohne Signatur an, und sobald der Client per Gruppenrichtlinie validieren muss, schlägt die Auflösung fehl. Selbst ein echter AAAA-Eintrag, der keine Umschreibung durch DNS64 braucht, erreicht den Client nicht mehr.

Was erwartbar war und was nicht

Im Labor von Lutz Donnerhacke erreicht der entfernte Client das IPv4-Ziel über DNS64, wie die Antwort mit einer IPv6-Adresse für einen reinen IPv4-Server zeigt. DNS64 erzeugt dabei AAAA-Einträge, die es in der Zone nicht gibt. RFC 6147 beschreibt, dass ein Endgerät, das selbst validiert, solche synthetisierten Daten nicht bestätigen kann. Der erste Fehlschlag im Test ist also im Standard angelegt: DNSSEC erkennt die Veränderung.

Überraschend ist der zweite Teil. Für test.sec.adatum.com gibt es einen echten, signierten AAAA-Eintrag, den DNS64 gar nicht umschreiben müsste. Trotzdem liefert der DirectAccess-Resolver keine Antwort, und für einen nicht existierenden Namen meldet der Client „Unsecured DNS packet“. Der Resolver unterdrückt also auch gültige Signaturen.

Heutiger Stand

Microsoft empfiehlt für neue Installationen ausdrücklich Always On VPN statt DirectAccess. Das Muster bleibt lehrreich: Jede Komponente, die DNS-Antworten verändert oder neu erzeugt, ob DNS64, Captive Portal oder Filterproxy, verträgt sich nur dann mit DNSSEC, wenn der Client der validierenden Stelle vertraut.

Ideen

  • DNS64 erzeugt AAAA-Einträge, die in keiner signierten Zone stehen.
  • Ein validierender Client erkennt synthetisierte Antworten als ungesichert.
  • Die Validierung lässt sich unter Windows per Gruppenrichtlinie je Domain erzwingen.
  • Positive und negative Antworten müssen getrennt getestet werden.
  • Der DirectAccess-Resolver unterdrückte im Test auch echte Signaturen.

Einsichten

  • DNSSEC und Umschreibung im DNS schließen sich am Endgerät gegenseitig aus.
  • Ein Labor mit Fehlerfällen findet Fehler, die der Normalbetrieb verdeckt.
  • Wer validiert, muss festgelegt werden: der Resolver oder das Endgerät.

Zitate

  • Nein, der DirectAccess-Resolver macht DNSSEC kaputt. (Lutz Donnerhacke)

Fakten

  • Die Testzone sec.adatum.com wurde mit DNSSEC signiert und die Vertrauensanker in der Domäne verteilt.
  • Über DirectAccess kam die Antwort mit der DNS64-Adresse fd68:d6bf:56b6:7777::ac10:a an.
  • RFC 6147 beschreibt, dass synthetisierte AAAA-Daten beim validierenden Endgerät scheitern.
  • Microsoft empfiehlt für neue Installationen Always On VPN statt DirectAccess.

Referenzen

Bemerkungen

  • Der erste Fehlschlag ist in RFC 6147 vorgesehen, erst der zweite deutet auf einen Fehler im DirectAccess-Resolver.

Empfehlungen

  • Teste DNSSEC hinter VPN- und Übersetzungsdiensten mit existierenden und nicht existierenden Namen.
  • Lege fest, ob Resolver oder Client validiert, und dokumentiere es.
  • Plane bei neuen Fernzugängen keine Abhängigkeit von DNS64 für signierte interne Zonen.

Originalartikel lesen

Im Webarchiv suchen

Lutz Donnerhacke · 2001

Firewall-FAQ: Sicherheit ist ein gepflegtes Konzept

Lutz Donnerhackes FAQ zur Newsgroup de.comp.security.firewall beantwortet die Fragen, die Neulinge dort immer wieder stellten. Eine Firewall ist danach ein organisatorisches und technisches Konzept zur Trennung von Netzbereichen samt korrekter Umsetzung und dauerhafter Pflege. Die FAQ räumt mit Irrtümern über NAT, Desktop-Firewalls, Portscans und gesperrtes ICMP auf.

RFC · 2012

RFC 6698: DANE: TLS-Schlüssel über DNSSEC binden

Paul Hoffman und Jakob Schlyter beschrieben im August 2012 mit RFC 6698 DANE, ein Verfahren, mit dem der Betreiber einer Domain im DNSSEC-gesicherten DNS festlegt, welche Zertifikate oder Schlüssel für seine TLS-Dienste gelten. Dafür führt es den Eintragstyp TLSA ein, der unter Namen wie _443._tcp.www.example.com steht. Durchgesetzt hat sich DANE vor allem zwischen Mailservern, während Browser es nie übernommen haben.

CLT · 2010

DNSSEC: sichere Namensauflösung im Internet

Heiko Schlittermann, IT-Dienstleister aus Dresden, erklärte bei den Chemnitzer Linux-Tagen 2010 DNSSEC, die Sicherheitserweiterung des Domain Name System. DNS übersetzt Namen in IP-Adressen und ist damit ein Fundament des Internets. DNSSEC stellt sicher, dass DNS-Antworten echt und unverändert sind.