Mathieu GAUTHIER-LAFAYE

Présentation au sujet: "Mathieu GAUTHIER-LAFAYE"— Transcription de la présentation:

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

2 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

3 Introduction

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

5 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)

6 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 (…)

7 Les attaques possibles
lapp.in2p3.fr ?

8 Les attaques possibles
lapp.in2p3.fr ?

9 Les attaques possibles
? ?

10 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)

11 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

12 fedoraproject.org. IN DNSKEY
DNSSEC: une solution fedoraproject.org. 3 IN DNSKEY AwEAAcCWNQWl5(...)IzSrw60TmGAKTvM9v iL3ByeCN fedoraproject.org. 3 IN DNSKEY AwEAAdTXJc0jo(...)D4Duup5xGOmdtC O4GSpM1YH6c= fedoraproject.org. 3 IN RRSIG DNSKEY fedoraproject.org. PJGhYVq7RvT4N(...)uaxQR2l+H0 HKs= fedoraproject.org. 3 IN RRSIG DNSKEY fedoraproject.org. Gzu+b2nu6LG8(...)Ry6gqM6yP /okRyw== fedoraproject.org. IN DNSKEY fedoraproject.org. IN A fedoraproject.org. IN A fedoraproject.org IN A fedoraproject.org IN A fedoraproject.org IN RRSIG A fedoraproject.org. cIfMhYfVJ/y8(…)I4dS+0d09ds/6tt4NAk9+ UOc=

13 DNSSEC: une solution org. IN A DNSKEY fedoraproject.org. IN DS
org IN DNSKEY AwEAAZTjbIO(...)A2r 8ti6MNoJEHU= org IN DNSKEY AwEAAZbIb38(...)GJuQ moBv5JKj org IN DNSKEY AwEAAcuIkF/(...)veP6 NjCJRXkZ org IN DNSKEY AwEAAYpYfj3(...)wSI lzbaAQN49PU= org IN RRSIG DNSKEY org. Ehc/p0s4n/x5LAE4AC(...)x+5UPcdzKi/c gZGnaQ== org IN RRSIG DNSKEY org. Fjqh27oZ1kryZMISCkq(...)oPC57aUJc VbM= org IN RRSIG DNSKEY org. Q4qYZpWEzdfvtXTaZw4Eu(...)xsIwI g4t5Tw== fedoraproject.org IN DS D5A4A61B88AF2F6F7BA9B6F952354B4C4E D64D3F7 5DE59968 fedoraproject.org IN DS A7C9BF5AFE374C9650ED678F3D36931A7DE9256B86A7BC34D6DEED7D 4E492E5E fedoraproject.org IN DS DF6AEC61BE8F2579A1D0A7C974A6C20E692B94EB070F9212E8AF DCDC3 fedoraproject.org IN RRSIG DS org. RuEK5YFoC(...)m35A5N+ Xsw= org. IN A DNSKEY fedoraproject.org. IN DS

14 DNSSEC: une solution . IN DNSKEY
IN DNSKEY AwEAAagAIK(...)QxA+Uk1ihz0= IN DNSKEY AwEAAbSuNN(...)AWq6d/iEs rhjs5HPX IN RRSIG DNSKEY joM1+5kiZgdYhppR(...)ZgLHqNKeWN8MkdVOy gCp40g== org IN DS E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2 org IN DS EEB2FFD9B00CD4694E78278B5EFDAB0A B69F634DA078F0 D90F01BA org IN RRSIG DS CElSKnyVN(...)opsSPdeMI7n wYU= . IN DNSKEY org. IN DS IN DNSKEY AwEAAagAIK(…)QxA+Uk1ihz0=

15 DNSSEC: une solution Graphique généré avec le site internet :

16 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

17 DNSSEC: une solution Avec DNSEC Sans DNSSEC

18 DNSSEC: une solution Extension DNSSEC/TLSA Validator pour Firefox

19 Au LAPP / LAPTh

20 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, …)

21 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%

22 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, in-addr.arpa, 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 in-addr.arpa

23 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

24 Schéma

25 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

26 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

27 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 ;)

28 Merci de votre attention