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:
-
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.
-
Spoofing-Angriffe: Ein Angreifer könnte einen AXFR-Server imitieren und gefälschte Zonendaten an einen AXFR-Client senden.
-
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.
-
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:
-
Der AXFR-Client fügt einen TSIG-RR in seine Abfragenachricht ein, signiert mit einem vorverteilten Schlüssel.
-
Der AXFR-Server validiert die TSIG-Signatur der Abfrage. Wenn die Validierung fehlschlägt, antwortet der Server mit RCODE NOTAUTH oder REFUSED.
-
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.
-
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:
-
Der AXFR-Client signiert seine Abfragenachricht mit seinem privaten Schlüssel und fügt den resultierenden SIG(0)-RR in die Abfrage ein.
-
Der AXFR-Server validiert die Signatur unter Verwendung des öffentlichen Schlüssels des Clients (über DNS abgerufen oder von einem lokalen Vertrauensanker).
-
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:
-
Der AXFR-Server überträgt die Zone, einschließlich aller RRSIG-, DNSKEY- und NSEC/NSEC3-Einträge.
-
Der AXFR-Client validiert die RRSIG-Signaturen auf den übertragenen RRsets unter Verwendung der DNSKEY-Einträge in der Zone.
-
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:
-
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.)
-
IPsec: Zonentransfers über IPsec-geschützte Verbindungen profitieren von der durch IPsec bereitgestellten Vertraulichkeit, Integrität und Authentifizierung.
-
VPNs oder private Netzwerke: Die Durchführung von Zonentransfers über ein privates Netzwerk (wie ein VPN) kann eine zusätzliche Sicherheitsebene bieten.
Empfehlungen
-
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.
-
Ü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.
-
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.
-
Auf Anomalien überwachen: Betreiber SOLLTEN Zonentransfers auf Anomalien überwachen, wie unerwartete Änderungen der Zonengröße, ungewöhnliche Transferfrequenzen oder fehlgeschlagene Integritätsprüfungen.
-
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:
- Alle vom fehlgeschlagenen Zonentransfer empfangenen Daten verwerfen.
- Den Fehler zu Audit- und Fehlerbehebungszwecken protokollieren.
- 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.