Zum Hauptinhalt springen

6. Zonenintegrität

Die Gewährleistung der Integrität übertragener Zonendaten ist entscheidend für die Aufrechterhaltung der Sicherheit und Zuverlässigkeit der DNS-Infrastruktur. Dieser Abschnitt diskutiert Integritätsüberlegungen für AXFR und empfiehlt Best Practices.

Integritätsbedrohungen

Zonentransfers unterliegen mehreren Integritätsbedrohungen:

  1. Man-in-the-Middle-Angriffe: Ein Angreifer, der sich zwischen dem AXFR-Client und dem Server befindet, könnte Zonendaten während der Übertragung abfangen und modifizieren.

  2. Spoofing-Angriffe: Ein Angreifer könnte einen AXFR-Server imitieren und gefälschte Zonendaten an einen AXFR-Client senden.

  3. Replay-Angriffe: Ein Angreifer könnte einen legitimen Zonentransfer erfassen und später wiederholen, was möglicherweise dazu führt, dass der Client zu veralteten Zonendaten zurückkehrt.

  4. Nicht autorisierte Änderungen: Ohne ordnungsgemäße Authentifizierung und Integritätsprüfungen könnte ein Angreifer während eines Zonentransfers Ressourceneinträge einfügen, löschen oder modifizieren.

Integritätsschutzmechanismen

Um sich gegen diese Bedrohungen zu schützen, SOLLTEN AXFR-Implementierungen einen oder mehrere der folgenden Integritätsschutzmechanismen einsetzen:

TSIG (Transaction Signature)

TSIG [RFC2845] bietet Authentifizierung und Integritätsschutz auf Nachrichtenebene unter Verwendung gemeinsamer geheimer Schlüssel und HMAC-Algorithmen.

Wie TSIG für AXFR funktioniert:

  1. Der AXFR-Client fügt einen TSIG-RR in seine Abfragenachricht ein, signiert mit einem vorverteilten Schlüssel.

  2. Der AXFR-Server validiert die TSIG-Signatur der Abfrage. Wenn die Validierung fehlschlägt, antwortet der Server mit RCODE NOTAUTH oder REFUSED.

  3. Wenn die Abfrage gültig ist, fügt der AXFR-Server TSIG-RRs in seine Antwortnachrichten ein:

    • Die erste Antwortnachricht MUSS einen TSIG-RR enthalten.
    • Zwischennachrichten KÖNNEN TSIG weglassen (zur Effizienz), aber die Sequenz wird dennoch durch das TSIG in der ersten und letzten Nachricht geschützt.
    • Die letzte Antwortnachricht MUSS einen TSIG-RR enthalten.
  4. Der AXFR-Client validiert die TSIG-Signaturen der Antwortnachrichten. Wenn eine Validierung fehlschlägt, MUSS der Client den gesamten Zonentransfer verwerfen.

Vorteile: TSIG bietet starken Integritätsschutz und gegenseitige Authentifizierung. Es wird in DNS-Implementierungen weit verbreitet unterstützt.

Einschränkungen: Erfordert vorverteilte Schlüssel, die sicher verteilt und verwaltet werden müssen.

SIG(0) (Signature)

SIG(0) [RFC2931] bietet auf öffentlichen Schlüsseln basierende Nachrichtenauthentifizierung unter Verwendung von DNSSEC-Stil-Signaturen.

Wie SIG(0) für AXFR funktioniert:

  1. Der AXFR-Client signiert seine Abfragenachricht mit seinem privaten Schlüssel und fügt den resultierenden SIG(0)-RR in die Abfrage ein.

  2. Der AXFR-Server validiert die Signatur unter Verwendung des öffentlichen Schlüssels des Clients (über DNS abgerufen oder von einem lokalen Vertrauensanker).

  3. Der AXFR-Server KANN seine Antwortnachrichten mit seinem eigenen privaten Schlüssel signieren, wodurch der Client die Authentizität der Antwort verifizieren kann.

Vorteile: Eliminiert die Notwendigkeit vorverteilter Geheimnisse. Geeignet für Szenarien, in denen die Schlüsselverteilung herausfordernd ist.

Einschränkungen: Komplexer zu implementieren und zu konfigurieren als TSIG. Verlässt sich auf Public-Key-Infrastruktur.

DNSSEC

Für Zonen, die DNSSEC-signiert sind, kann der AXFR-Client die Integrität der übertragenen Zonendaten unter Verwendung von DNSSEC-Signaturen (RRSIG-Einträge) validieren.

Wie DNSSEC AXFR schützt:

  1. Der AXFR-Server überträgt die Zone, einschließlich aller RRSIG-, DNSKEY- und NSEC/NSEC3-Einträge.

  2. Der AXFR-Client validiert die RRSIG-Signaturen auf den übertragenen RRsets unter Verwendung der DNSKEY-Einträge in der Zone.

  3. Wenn die DNSSEC-Validierung fehlschlägt, SOLLTE der Client die Zonendaten NICHT bereitstellen.

Vorteile: Bietet End-to-End-Integritätsschutz für Zonendaten, nicht nur während der Übertragung, sondern auch wenn die Daten an Resolver bereitgestellt werden.

Einschränkungen: Erfordert, dass die Zone DNSSEC-signiert ist. Schützt nicht das AXFR-Protokoll selbst (z.B. gegen nicht autorisierte Clients).

Sicherheit auf Netzwerkebene

Zusätzlich zu Sicherheitsmechanismen auf Anwendungsebene KÖNNEN AXFR-Transfers mit Sicherheit auf Netzwerkebene geschützt werden:

  1. TLS/SSL: Das Verschlüsseln der TCP-Verbindung mit TLS oder SSL bietet Vertraulichkeits- und Integritätsschutz für den Zonentransfer. (Hinweis: DNS-over-TLS für Zonentransfers ist zum Zeitpunkt der Erstellung dieses Dokuments nicht standardisiert.)

  2. IPsec: Zonentransfers über IPsec-geschützte Verbindungen profitieren von der durch IPsec bereitgestellten Vertraulichkeit, Integrität und Authentifizierung.

  3. VPNs oder private Netzwerke: Die Durchführung von Zonentransfers über ein privates Netzwerk (wie ein VPN) kann eine zusätzliche Sicherheitsebene bieten.

Empfehlungen

  1. TSIG oder SIG(0) verwenden: AXFR-Server und -Clients SOLLTEN TSIG oder SIG(0) unterstützen und verwenden, um Zonentransfers zu schützen. TSIG ist die am häufigsten eingesetzte Lösung und wird für die meisten Bereitstellungen EMPFOHLEN.

  2. Übertragene Daten validieren: AXFR-Clients SOLLTEN die Integrität empfangener Zonendaten validieren, bevor sie in ihre lokale Zonendatenbank übernommen werden. Für DNSSEC-signierte Zonen umfasst diese Validierung die Verifizierung von DNSSEC-Signaturen.

  3. Sichere Schlüsselverwaltung: Für TSIG-basierte Bereitstellungen MÜSSEN Betreiber sicherstellen, dass gemeinsame Schlüssel mit kryptografisch starken Zufallszahlengeneratoren erzeugt und sicher gespeichert und verteilt werden.

  4. Auf Anomalien überwachen: Betreiber SOLLTEN Zonentransfers auf Anomalien überwachen, wie unerwartete Änderungen der Zonengröße, ungewöhnliche Transferfrequenzen oder fehlgeschlagene Integritätsprüfungen.

  5. Starke Algorithmen verwenden: Bei Verwendung von TSIG SOLLTEN Betreiber starke HMAC-Algorithmen wie HMAC-SHA256 oder HMAC-SHA512 anstelle schwächerer Algorithmen wie HMAC-MD5 verwenden. Siehe [RFC4635] und [RFC5702] für Anleitungen zur Algorithmusauswahl.

Umgang mit Integritätsfehlern

Wenn ein AXFR-Client einen Integritätsfehler erkennt (z.B. TSIG-Validierungsfehler, DNSSEC-Validierungsfehler), MUSS er:

  1. Alle vom fehlgeschlagenen Zonentransfer empfangenen Daten verwerfen.
  2. Den Fehler zu Audit- und Fehlerbehebungszwecken protokollieren.
  3. Optional den Zonentransfer nach einer geeigneten Verzögerung erneut versuchen (mit Backoff).

Ein AXFR-Client DARF KEINE teilweise empfangenen oder integritätsfehlerhaften Zonendaten in seine autoritative Zonendatenbank übernehmen, da dies dazu führen könnte, dass falsche oder bösartige Daten an DNS-Clients bereitgestellt werden.