8. Sicherheitsüberlegungen

Dieses Dokument ist eine Klarstellung eines in RFC 1034 und RFC 1035 beschriebenen Mechanismus und fügt daher keine neuen Sicherheitsüberlegungen hinzu. RFC 3833 [RFC3833] ist vollständig Sicherheitsüberlegungen für DNS gewidmet; sein Abschnitt 4.3 grenzt Zonentransfer-Sicherheitsaspekte von den durch DNSSEC adressierten Sicherheitsbedrohungen ab.

Bedenken bezüglich Autorisierung, Traffic-Flooding und Nachrichtenintegrität werden in "Authorization" (Abschnitt 5), "TCP" (Abschnitt 4.1) und "Zone Integrity" (Abschnitt 6) erwähnt.

Hauptsicherheitsbedenken

1. Nicht autorisierte Zonenoffenlegung: Zonendateien können sensible Informationen über die Infrastruktur eines Netzwerks enthalten, einschließlich der Namen und IP-Adressen interner Hosts. Nicht autorisierte Zonentransfers können Angreifern bei Aufklärungsaktivitäten helfen. AXFR-Server MÜSSEN Autorisierungsmechanismen (Abschnitt 5) implementieren, um Zonentransfers auf vertrauenswürdige Clients zu beschränken.

2. Man-in-the-Middle-Angriffe: Ohne Integritätsschutz könnte ein Angreifer, der sich zwischen dem AXFR-Client und dem Server befindet, Zonendaten während der Übertragung abfangen und modifizieren. Implementierungen SOLLTEN TSIG [RFC2845] oder SIG(0) [RFC2931] verwenden, um sich gegen solche Angriffe zu schützen (Abschnitt 6).

3. Denial of Service (DoS): Zonentransfers können erhebliche Netzwerkbandbreite und Serverressourcen verbrauchen. Ein Angreifer könnte versuchen, Serverressourcen zu erschöpfen, indem er viele gleichzeitige Zonentransfer-Anfragen initiiert. AXFR-Server SOLLTEN Rate-Limiting und Verbindungslimits implementieren, um DoS-Angriffe zu mildern.

4. Datenintegrität: Übertragene Zonendaten müssen vor nicht autorisierten Änderungen geschützt werden. AXFR-Clients SOLLTEN die Integrität empfangener Daten mit TSIG, SIG(0) oder DNSSEC-Validierung validieren (Abschnitt 6).

5. 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. TSIG und SIG(0) bieten Schutz gegen Replay-Angriffe durch die Verwendung von Zeitstempeln und Nonces.

Empfehlungen

1. Authentifizierung verwenden: Zonentransfers SOLLTEN mit TSIG oder SIG(0) authentifiziert werden. Nicht authentifizierte Zonentransfers sind anfällig für Spoofing- und Man-in-the-Middle-Angriffe.

2. Zugangskontrollen implementieren: AXFR-Server MÜSSEN Zugriffskontrollrichtlinien implementieren, um einzuschränken, welche Clients Zonentransfers anfordern dürfen. IP-basierte ACLs, TSIG und SIG(0) sind alle praktikable Autorisierungsmechanismen.

3. Vertrauliche Zonen schützen: Für Zonen mit sensiblen Informationen SOLLTEN Betreiber zusätzlich zur Authentifizierung auf Anwendungsebene die Verwendung von Verschlüsselung auf Netzwerkebene (z.B. VPNs, IPsec) in Betracht ziehen.

4. Transfers überwachen: Betreiber SOLLTEN Zonentransfer-Aktivitäten auf Anomalien überwachen, wie unerwartete Transferanfragen oder fehlgeschlagene Authentifizierungsversuche.

5. Ressourcennutzung begrenzen: AXFR-Server SOLLTEN Mechanismen implementieren, um den Ressourcenverbrauch zu begrenzen, wie:

   • Beschränkung der Anzahl gleichzeitiger Zonentransfers.
   • Implementierung von Rate-Limiting pro Client.
   • Festlegung von Timeouts für inaktive Verbindungen.

6. Software aktuell halten: Betreiber SOLLTEN sicherstellen, dass DNS-Software auf dem neuesten Stand gehalten wird, um von Sicherheitskorrekturen und Verbesserungen zu profitieren.

DNSSEC-Überlegungen

Für DNSSEC-signierte Zonen überträgt das AXFR-Protokoll alle DNSSEC-bezogenen Einträge (DNSKEY, RRSIG, NSEC, NSEC3, DS). AXFR-Clients, die DNSSEC-signierte Zonen empfangen, SOLLTEN die DNSSEC-Signaturen auf den übertragenen Daten validieren, um die Integrität sicherzustellen.

DNSSEC bietet jedoch keine Vertraulichkeit und schützt nicht das AXFR-Protokoll selbst. TSIG oder SIG(0) SOLLTE weiterhin verwendet werden, um Zonentransfer-Anfragen zu authentifizieren und vor nicht autorisierten Transfers zu schützen.

Bedrohungsanalyse

Für eine umfassende Analyse von DNS-Sicherheitsbedrohungen, einschließlich solcher im Zusammenhang mit Zonentransfers, sollten Betreiber und Implementierer RFC 3833 [RFC3833], "Threat Analysis of the Domain Name System (DNS)", konsultieren.