Mathieu GAUTHIER-LAFAYE Présentation DNSSEC Mathieu GAUTHIER-LAFAYE

Plan Introduction Au LAPP / LAPTh Conclusion Rappel sur le fonctionnement de base Les attaques possibles DNSSEC: une solution Au LAPP / LAPTh Historique Les résolveurs Les serveurs de zones Schéma Problèmes rencontrés Evolutions Conclusion

Introduction

Rappel sur le fonctionnement de base cnrs.fr. 172800 IN NS ns1.cnrs.fr. www.cnrs.fr IN A fr. 172800 IN NS e.ext.nic.fr. www.cnrs.fr IN A cnrs.fr. 172800 IN A 193.55.76.228 www.cnrs.fr IN A e.ext.nic.fr Cache ? ns1.cnrs.fr www.cnrs.fr www.cnrs.fr IN A cnrs.fr. 172800 IN A 193.55.76.228

Rappel sur le fonctionnement de base Cree en 1983 pour remplacer les fichiers hosts Fonctionne cote serveur en utilisant le port 53 en UDP et en TCP Les serveurs racines sont redondes : 13 serveurs ([a-m].root-servers.net) Gere par différents organismes : ICANN, ISC, RIPE, VERISIGN, U.S. Army Research Lab, … Les serveurs sont en général multi-sites (par l’utilisation de l’unicast) Pour les zones (exemple: lapp.in2p3.fr), il est recommande d’avoir au moins deux serveurs sur deux réseaux différents (AS) Chaque enregistrement a une durée de vie (TTL)

Rappel sur le fonctionnement de base Il existe un diffèrent type d’enregistrements : SOA: Information sur la zone NS: Serveur de noms A: adresse IPv4 AAAA: adresse IPv6 PTR: résolution inverse CNAME: alias vers une autre adresse MX: messagerie SRV: service (…)

Les attaques possibles 208.77.188.166 134.158.96.8 lapp.in2p3.fr ?

Les attaques possibles 208.77.188.166 134.158.96.8 lapp.in2p3.fr ?

Les attaques possibles www.cnrs.fr ? 208.77.188.166 134.158.96.8 www.cnrs.fr ?

DNSSEC: une solution Des extensions de sécurité au protocole DNS : DNSSEC Intro RFC (RFC 4033) DNSSEC Records RFC (RFC 4034) DNSSEC Protocol RFC (RFC 4035) DNSSEC NSEC3 RFC (RFC 5155) DNSSEC + EPP RFC (RFC 5910) Il permet de vérifier : la provenance d’une réponse, l’intégrité d’une réponse, l’absence d’existence d’un enregistrement Sécurise le DNS de bout en bout (clients, résolveurs et zones) Utilisation de mécanisme de cryptographie : Signature des enregistrements par clefs publiques / clefs privés (RSA, DSA, ECDSA) Algorithme de hachage (SHA1, SHA256, SHA-512)

DNSSEC: une solution Nouveaux types d’enregistrements : RRSIG: Signatures d’un enregistrement DNS DNSKEY: clef publique DS: permet de déclarer la clef publique d’une zone enfant DLV: permet de créer un registre de clef publique NSEC: le prochain enregistrement NSEC3: le hash du prochain enregistrement (remplace NSEC) NSEC3PARAM: paramètres pour les enregistrements NSEC3 Nouvelles entêtes : DO: Demande l’inclusion des enregistrementsRRSIG à la réponse CD: Permet de désactiver la validation des enregistrements dans une requête AD: Permet au résolveur d’ indiquer que la réponse est authentifiée

fedoraproject.org. IN DNSKEY DNSSEC: une solution fedoraproject.org. 3 IN DNSKEY 256 3 5 AwEAAcCWNQWl5(...)IzSrw60TmGAKTvM9v iL3ByeCN fedoraproject.org. 3 IN DNSKEY 257 3 5 AwEAAdTXJc0jo(...)D4Duup5xGOmdtC O4GSpM1YH6c= fedoraproject.org. 3 IN RRSIG DNSKEY 5 2 300 20140917175817 20140818175817 7725 fedoraproject.org. PJGhYVq7RvT4N(...)uaxQR2l+H0 HKs= fedoraproject.org. 3 IN RRSIG DNSKEY 5 2 300 20140917175817 20140818175817 16207 fedoraproject.org. Gzu+b2nu6LG8(...)Ry6gqM6yP /okRyw== fedoraproject.org. IN DNSKEY fedoraproject.org. IN A fedoraproject.org. IN A fedoraproject.org. 60 IN A 209.132.181.16 fedoraproject.org. 60 IN A 85.236.55.6 fedoraproject.org. 60 IN RRSIG A 5 2 60 20140917065024 20140818065024 7725 fedoraproject.org. cIfMhYfVJ/y8(…)I4dS+0d09ds/6tt4NAk9+ UOc=

DNSSEC: une solution org. IN A DNSKEY fedoraproject.org. IN DS org. 458 IN DNSKEY 257 3 7 AwEAAZTjbIO(...)A2r 8ti6MNoJEHU= org. 458 IN DNSKEY 256 3 7 AwEAAZbIb38(...)GJuQ moBv5JKj org. 458 IN DNSKEY 256 3 7 AwEAAcuIkF/(...)veP6 NjCJRXkZ org. 458 IN DNSKEY 257 3 7 AwEAAYpYfj3(...)wSI lzbaAQN49PU= org. 420 IN RRSIG DNSKEY 7 1 900 20140907155051 20140817145051 9795 org. Ehc/p0s4n/x5LAE4AC(...)x+5UPcdzKi/c gZGnaQ== org. 420 IN RRSIG DNSKEY 7 1 900 20140907155051 20140817145051 17915 org. Fjqh27oZ1kryZMISCkq(...)oPC57aUJc VbM= org. 420 IN RRSIG DNSKEY 7 1 900 20140907155051 20140817145051 21366 org. Q4qYZpWEzdfvtXTaZw4Eu(...)xsIwI g4t5Tw== fedoraproject.org. 67386 IN DS 301 5 2 17D5A4A61B88AF2F6F7BA9B6F952354B4C4E1487040168949D64D3F7 5DE59968 fedoraproject.org. 67386 IN DS 16207 5 2 A7C9BF5AFE374C9650ED678F3D36931A7DE9256B86A7BC34D6DEED7D 4E492E5E fedoraproject.org. 67386 IN DS 63721 5 2 0DF6AEC61BE8F2579A1D0A7C974A6C20E692B94EB070F9212E8AF618 805DCDC3 fedoraproject.org. 67386 IN RRSIG DS 7 2 86400 20140907155051 20140817145051 17915 org. RuEK5YFoC(...)m35A5N+ Xsw= org. IN A DNSKEY fedoraproject.org. IN DS

DNSSEC: une solution . IN DNSKEY . 171317 IN DNSKEY 257 3 8 AwEAAagAIK(...)QxA+Uk1ihz0= . 171317 IN DNSKEY 256 3 8 AwEAAbSuNN(...)AWq6d/iEs rhjs5HPX . 171317 IN RRSIG DNSKEY 8 0 172800 20140903235959 20140820000000 19036 . joM1+5kiZgdYhppR(...)ZgLHqNKeWN8MkdVOy gCp40g== org. 5341 IN DS 21366 7 1 E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2 org. 5341 IN DS 21366 7 2 96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA org. 5341 IN RRSIG DS 8 1 86400 20140831000000 20140823230000 8230 . CElSKnyVN(...)opsSPdeMI7n wYU= 209.132.181.16 85.236.55.6 . IN DNSKEY org. IN DS . 172800 IN DNSKEY 257 3 8 AwEAAagAIK(…)QxA+Uk1ihz0=

DNSSEC: une solution Graphique généré avec le site internet : http://dnsviz.net/

DNSSEC: une solution Pour garantir la sécurité, les zones doivent renouveler leur clef suivant leur propre politique : KSK: Key Signing Key (exemple 1 an) ZSK: Zone Signing Key (exemple 1 mois) Les signatures des enregistrements ont une période de validité (exemple 1 mois) Fonctionnalités attendues par le déploiement de DNSSEC: SSHFP : validation des clefs publiques des serveurs SSH DANE (TLSA): validation des certificats des serveurs WEB

DNSSEC: une solution Avec DNSEC Sans DNSSEC

DNSSEC: une solution Extension DNSSEC/TLSA Validator pour Firefox

Au LAPP / LAPTh

Historique En 2011, nous avions : 2 serveurs virtuels Mélange des rôles de résolution et d’hébergement de zones Sensibles aux attaques par empoisonnement du cache (port 53 ouvert depuis l’extérieur) La version du serveur DNS (Bind) était incompatible avec DNSSEC L’utilisation du mécanisme standard de résolution montrait ses limites : Utilisation du primaire / secondaire de la configuration réseau Ralentissement important (ex: LDAP, SYSLOG, …)

Les résolveurs En 2012 mise en place d’un résolveur hautement disponible : 2 serveurs virtuels dédiés 512 Mo de cache Traite plus de 150 requêtes par seconde 1 adresse IP qui peut basculer automatiquement d’un serveur a l’autre (Pacemaker) Utilisation d’un logiciel dédie a la résolution DNS (Unbound) Validation DNSSEC pour les domaines signés La haute disponibilité nous a permis : D’effectuer les mises a jour de sécurité sans interruption de service D’effectuer des migrations d’OS avec moins d’une minute d’arrêt Disponibilité du service depuis le début de l’année : 100%

Les serveurs de zones En 2013, mise en place de deux serveurs de zones : Utilisation du logiciel BIND et d’OpenDNSSEC Utilisation des mécanismes de réplication standard entre le maître et l’esclave (TSIG) Ils servent 11 zones (lapp.in2p3.fr, lapth.cnrs.fr, …) Ils servent également de copie locale pour la zone in2p3.fr, 158.134.in-addr.arpa, 82.48.193.in-addr.arpa) Nous utilisons des serveurs DNS secondaires hors LAPP pour les zones les plus importantes (CC IN2P3, DSI CNRS) Signature de certaines zones avec DNSSEC (en général par DLV): lapth.cnrs.fr msif.cnrs.fr phystev.cnrs.fr lapptest.in2p3.fr private.lapp.in2p3.fr 159.10.in-addr.arpa

Les serveurs de zones OpenDNSSEC s’occupe de : la génération et le stockage des clefs privées (SoftHSM) la signature des fichiers zones, du roulement des clefs ZSK, Notification de la présence de nouvelles DNSKEY (KSK) La publication des DS est faite manuellement Mise en place d’une surveillance importante du système DNS avec Nagios (vérification de la validité des signatures, …) Politique choisie : KSK : 1 ans ZSK : 1 mois Validité des signatures : 1 mois Rafraichissement des signatures : 21 jours

Schéma

Problèmes rencontrés Les coupures du lien extérieur entrainait des problème de validation sur des zones internes (DLV) : Ajout des clefs publiques des zones au résolveur Le nombre de requêtes DNS sur le résolveur était trop important pour le pare-feu (iptables) : Désactivation du suivi des connexions UDP sur le port 53 Certains serveurs DNS refusent de servir des zones secondaires signées Lié à un changement pour DNSSEC du protocole DNS pour les enregistrements de type CNAME Des incompatibilités entre des versions différentes de Bind avec les transfères de zones par clefs TSIG

Evolutions Mise en place des enregistrements DS dans les zones parentes (in2p3.fr, cnrs.fr) Utilisation des enregistrements TLSA (DANE) et SSHFP Intégration des sous zones Active Directory (_tcp, _udp, …) par des mécanismes de mises à jour dynamique Généralisation progressive de l’utilisation de TSIG pour le transfert des zones entre les serveurs DNS maîtres et esclaves Avoir 1 serveur de zone maître non relié ou non ouvert sur internet (fantôme) Protéger nos serveurs contre leurs utilisations dans des attaques par amplification

Conclusion Résolveur : DNSSEC : Gain en terme de disponibilité Gain en terme de maintenabilité Gain en terme de sécurité DNSSEC : Actuellement peu de zones sont signées Pour les utilisateurs : c’est transparent Déploiement lent : pas ou peu d’intérêt financier et il y a des risques (comme pour IPv6) IPv6 étant maintenant presque déployé partout, il nous fallait bien un nouveau sujet de discutions pour l’internet du futur ;)

Merci de votre attention