8. Considérations de sécurité

Ce document est une clarification d'un mécanisme décrit dans les RFC 1034 et 1035 et en tant que tel n'ajoute aucune nouvelle considération de sécurité. RFC 3833 [RFC3833] est entièrement consacré aux considérations de sécurité pour le DNS; sa Section 4.3 délimite les aspects de sécurité du transfert de zone des menaces de sécurité traitées par DNSSEC.

Les préoccupations concernant l'autorisation, le flooding de trafic et l'intégrité des messages sont mentionnées dans "Authorization" (Section 5), "TCP" (Section 4.1) et "Zone Integrity" (Section 6).

Préoccupations de sécurité principales

1. Divulgation de zone non autorisée : Les fichiers de zone peuvent contenir des informations sensibles sur l'infrastructure d'un réseau, y compris les noms et adresses IP des hôtes internes. Les transferts de zone non autorisés peuvent aider les attaquants dans des activités de reconnaissance. Les serveurs AXFR DOIVENT implémenter des mécanismes d'autorisation (Section 5) pour restreindre les transferts de zone aux clients de confiance.

2. Attaques de l'homme du milieu : Sans protection de l'intégrité, un attaquant positionné entre le client AXFR et le serveur pourrait intercepter et modifier les données de zone en transit. Les implémentations DEVRAIENT utiliser TSIG [RFC2845] ou SIG(0) [RFC2931] pour se protéger contre de telles attaques (Section 6).

3. Déni de service (DoS) : Les transferts de zone peuvent consommer une bande passante réseau et des ressources serveur importantes. Un attaquant pourrait tenter d'épuiser les ressources du serveur en initiant de nombreuses demandes de transfert de zone concurrentes. Les serveurs AXFR DEVRAIENT implémenter une limitation du débit et des limites de connexion pour atténuer les attaques DoS.

4. Intégrité des données : Les données de zone transférées doivent être protégées contre les modifications non autorisées. Les clients AXFR DEVRAIENT valider l'intégrité des données reçues en utilisant TSIG, SIG(0) ou la validation DNSSEC (Section 6).

5. Attaques par rejeu : Un attaquant pourrait capturer un transfert de zone légitime et le rejouer ultérieurement, causant potentiellement la réversion du client vers des données de zone obsolètes. TSIG et SIG(0) fournissent une protection contre les attaques par rejeu grâce à l'utilisation d'horodatages et de nonces.

Recommandations

1. Utiliser l'authentification : Les transferts de zone DEVRAIENT être authentifiés en utilisant TSIG ou SIG(0). Les transferts de zone non authentifiés sont vulnérables aux attaques par usurpation et par l'homme du milieu.

2. Implémenter des contrôles d'accès : Les serveurs AXFR DOIVENT implémenter des politiques de contrôle d'accès pour restreindre quels clients sont autorisés à demander des transferts de zone. Les ACL basées sur IP, TSIG et SIG(0) sont tous des mécanismes d'autorisation viables.

3. Protéger les zones confidentielles : Pour les zones contenant des informations sensibles, les opérateurs DEVRAIENT envisager d'utiliser un chiffrement au niveau réseau (par exemple, VPN, IPsec) en plus de l'authentification au niveau application.

4. Surveiller les transferts : Les opérateurs DEVRAIENT surveiller l'activité de transfert de zone pour détecter les anomalies, telles que des demandes de transfert inattendues ou des tentatives d'authentification échouées.

5. Limiter l'utilisation des ressources : Les serveurs AXFR DEVRAIENT implémenter des mécanismes pour limiter la consommation de ressources, tels que :

   • Restreindre le nombre de transferts de zone concurrents.
   • Implémenter une limitation du débit par client.
   • Définir des délais d'attente sur les connexions inactives.

6. Maintenir le logiciel à jour : Les opérateurs DEVRAIENT s'assurer que le logiciel DNS est maintenu à jour pour bénéficier des correctifs de sécurité et des améliorations.

Considérations DNSSEC

Pour les zones signées DNSSEC, le protocole AXFR transfère tous les enregistrements liés à DNSSEC (DNSKEY, RRSIG, NSEC, NSEC3, DS). Les clients AXFR recevant des zones signées DNSSEC DEVRAIENT valider les signatures DNSSEC sur les données transférées pour garantir l'intégrité.

Cependant, DNSSEC ne fournit pas de confidentialité ni ne protège le protocole AXFR lui-même. TSIG ou SIG(0) DEVRAIT toujours être utilisé pour authentifier les demandes de transfert de zone et se protéger contre les transferts non autorisés.

Analyse des menaces

Pour une analyse complète des menaces de sécurité DNS, y compris celles liées aux transferts de zone, les opérateurs et les implémenteurs devraient consulter RFC 3833 [RFC3833], "Threat Analysis of the Domain Name System (DNS)".