DNSSEC - NSEC und NSEC3

DNS Workshop

Created: 2019-08-29 Thu 09:53

Agenda

  1. NSEC
  2. NSEC3
  3. NSEC3 "narrow mode" (PowerDNS)

Authenticated Denial of existence

  • DNSSEC schützt positive Antworten aus dem DNS mit Signaturen über die gelieferten Daten
  • aber auch negative Antworten müssen geschützt werden
    • Angreifer könnten Denial-of-Service Angriffe durchführen und darin behautpen, das bestimmte DNS-Daten nicht existieren

Authenticated Denial of existence

  • DNS kennt zwei negative Antworten: NXDOMAIN und NODATA/NXRRSET
    • NXDOMAIN: der angefragte Domain-Name existiert nicht
    • NODATA/NXRRSET: der angefragt Domain-Name existiert, aber der gefragte DNS-Record-Type existiert für diesen Namen nicht
  • Fehlermeldungen aus dem DNS wie SERVFAIL, FORMERR oder REFUSED können nicht vom DNSSEC abgesichert werden

NSEC Record (2)

  • Die Lösung: der NSEC-Record bildet eine Liste aller existierenden Daten in einer DNS-Zone (Namen und Record-Typen).
    • wird eine negative Antwort benötigt, so liefert der DNS-Server den passenden NSEC-Record (plus Signatur) zurück, welcher beweist das die angefragten Daten nicht existieren

NSEC Record (3)

nsec-chain.png

NSEC Record (4)

  • Für die Benutzung des NSEC-Records müssen alle DNS-Record-Einträge in einer Zone in eine Reihenfolge gebracht werden
  • alle Domain-Namen (Owner-Names) werden als FQDN geschrieben
  • DNS-Records mit weniger Label im Owner-Namen werden an den Anfang der Zone sortiert, DNS-Records mit mehr Label im Namen werden an das Ende sortiert
  • Alle Domain-Namen mit der gleichen Anzahl von Label werden in alphabetischer Reihenfolge sortiert
  • bei jeder Änderung der Domain-Namens in der Liste der sortierten DNS-Records wird ein NSEC-Record eingefügt. Die NSEC-Records zeigen vom eigenen Owner-Name auf den nächsten existierenden Owner-Name in der Zone
  • für jeden Owner-Name listet der NSEC-Record die für den Namen existierenden Record-Typen auf
  • Hinter dem letzten Record in einer Zone wird ein NSEC-Record eingefügt, der an den Beginn der Zone zeigt

NSEC Antworten

  • bei einer NXDOMAIN-Antwort liefert der DNS-Server den in der Sortierreihenfolge über dem angefragten Namen liegenen NSEC-Records zurück.
    • Dieser beweist die Nicht-Existenz des angefragten Namen durch die Angabe des davor und danach existierenden Namen.

NSEC Antworten

  • bei einer NODATA/NXRRSET-Antwort liefert der DNS-Server den NSEC-Record des angefragten Domain-Namens zurück.
    • Dieser Record listet die existierenden DNS-Record-Typen für den Namen auf und beweist damit, das der angefragte Typ für diesen Namen nicht existiert.

Probleme mit NSEC

  • Der NSEC-Record ist eine elegante Lösung des Problems, hat aber einen entscheidenen Nachteil:
  • Angreifer können sehr einfach den gesamten Zoneninhalt auflisten
  • für viele Zonen ist dies kein Problem, wenn z.B. die Inhalte der Zone bekannt sind (SOA, NS-Records, WWW-A, MX-Records)
  • bei Zonen mit sensitiven Inhalten (Mail-Adressen, Hostnamen von kritischen Maschinen, neuen Produktnamen etc) ist der NSEC-Record problematisch
  • TLD-Betreiber meiden den NSEC-Record, da es externen erlaubt, die Änderungen (Registierungen und Löschungen) von Domain-Namen in der TLD-Zone mitzuprotokollieren

Beispiel:

    ldns-walk paypal.com

Der NSEC3-Record

  • RFC 5155 aus dem Jahre 2008 definiert den NSEC3-Record als Alternative zu NSEC
  • NSEC3 wird heute von allen DNSSEC-fähigen DNS-Servern unterstützt
  • der NSEC3-Record funktioniert ähnlich wie NSEC, nur das die Owner-Namen im NSEC3-Record als SHA1-Hash gespeichert werden
  • der NSEC3-Record macht es schwerer, aber nicht unmöglich, den Zoneninhalt aufzulisten

NSEC3-Record

DNSSEC-NSEC3-validation-01.png

Figure 2: NSEC3 1


NSEC3-Record

DNSSEC-NSEC3-validation-02.png

Figure 3: NSEC3 2

NSEC3-Record

DNSSEC-NSEC3-validation-03.png

Figure 4: NSEC3 3

NSEC3-Record

DNSSEC-NSEC3-validation-04.png

Figure 5: NSEC3 4

NSEC3-Record

DNSSEC-NSEC3-validation-05.png

Figure 6: NSEC3 5

NSEC3-Record

DNSSEC-NSEC3-validation-06.png

Figure 7: NSEC3 6

NSEC3-Record

DNSSEC-NSEC3-validation-07.png

Figure 8: NSEC3 7

NSEC3-Record

DNSSEC-NSEC3-validation-08.png

Figure 9: NSEC3 8

NSEC3-Record

DNSSEC-NSEC3-validation-09.png

Figure 10: NSEC3 9

NSEC3-Record

DNSSEC-NSEC3-validation-10.png

Figure 11: NSEC3 10

NSEC3 Record

nsec-chain1.png

Figure 12: NSEC3 chain

NSEC3-Parameter

  • Der NSEC3-Record beinhalten eine Reihe von Parametern
  • den Hashing-Algorithmus (derzeit SHA1)
  • Flags (Benutzung: opt-out, Überspringen von nicht DNSSEC-gesicherten Delegationen)
  • Anzahl der Hash-Iterationen
  • Salt

NSEC3-Parameter

  • Jede mit NSEC3 gesicherte Zone besitzt einen NSEC3PARAM Record. Dieser Record gibt den authoritativen DNS-Server Informationen, wie bei einer negativen Antwort der dazugehörige NSEC3-Record gefunden wird
  • Beispiel: (SHA1, keine Flags, 20 Iterationen, Salt "ABBACAFE")
    nsec3.dnslab.org.    0   IN  NSEC3PARAM 1 0 20 ABBACAFE

NSEC3 Iterationen und Salt

  • Die Angabe der Iterationen ermöglicht es dem Zonenbetreiber die Schwierigkeit der Hash-Berechnungen anzupassen
    • damit wird das Brechen der NSEC3-Kette für Angreifer schwieriger, aber die authoritativen DNS-Server und die DNS-Resolver müssen mehr Berechnungen durchführen
    • Die Iterationen sollten regelmäßig geprüft und an den Sicherheitslevel der Zone und die technische Entwicklung beim Berechnen von Hashes angepasst werden

NSEC3 Iterationen und Salt

  • Die Angabe des Salt macht es dem Angreifer unmöglich, Hashes für die Zone vorzuberechnen (Rainbow-Table http://en.wikipedia.org/wiki/Rainbow_table)
  • Das Salt ist eine Hexadezimale Zahl. Jede Hex-Ziffer hat 4bit

NSEC3 Iterationen und Salt

  • die empfolene Salt-Größe ist 32-64bit (8-16 Hex-Ziffern)
  • RFC 5155 empfielt das Salt bei jeder Änderung in der Zone neu zu setzen
  • damit müssten alle NSEC3-Records in der Zone, und alle Signaturen über die NSEC3-Records neu berechnet werden. Das ist Overkill.
  • Heutige Empfehlung ist, das Salt bei jedem Wechsel des ZSK neu zu setzen (beim der Änderung des ZSK werden die Signaturen neu berechnet)

NSEC3 Narrow-Mode

  • RFC 5155 beschreibt eine spezielle Variante der NSEC3-Benutzung, den sogenannten "Narrow-Mode"
  • beim "Narrow-Mode" werden die NSEC3-Records nicht beim signieren der Zone vorberechnet, sondern zum Zeitpunkt der negativen Antwort erstellt und "online" signiert
    • jeder authoritative DNS-Server muß hierfür die privaten Schlüssel (ZSK) der Zone im Lesezugriff haben!

NSEC3 Narrow-Mode

  • Der NSEC3-Narrow Mode gibt keine Kette der wirklich existierenden Namen in der DNS-Zone zurück, sondern nur einen NSEC3-Record welcher nur die Nicht-Existenz des angefragten Records beweist
  • Implementationen:
    • Phreebird (Dan Kaminski, Proof-of-Konzept, nicht gewartet)
    • PowerDNS
    • Cloudflare CDN (Closed Source Implementierung)

Fragen?