Sécurité des noms de      domaine  Stéphane Bortzmeyer            AFNIC      bortzmeyer@nic.fr                            ...
Sécurité des noms de      domaine  Stéphane Bortzmeyer            AFNIC      bortzmeyer@nic.fr                            ...
Introduction Plan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques théoriques    ...
Introduction Introduction    Nous voulons tous de la sécurité pour nos noms.    Mais quel genre de sécurité ?      1   Con...
Introduction SécuritéS    Il n’y a pas la sécurité. Il y a plusieurs services de sécurité,    parfois contradictoires :   ...
Résolution DNSPlan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques théoriques   ...
Résolution DNSMenaces contre la résolution DNS    Résolution : demander aux serveurs DNS les    informations associées à u...
Résolution DNSRésolution DNS, suite                        8 / 45
Résolution DNSPannes matérielles    Plein d’ennemis possibles :        Pelleteuses (coupure de Prosodie en mai 2011)      ...
Résolution DNSPannes logicielles    La seconde qui tue    Le 1er juillet 2012, une bogue Linux liée à la seconde    interc...
Résolution DNSBogue au registre       Le 12 octobre 2009, tous les noms de domaine suédois       disparaissent pendant une...
Résolution DNSAttaque par déni de service    Déni de service : attaque qui vise à empêcher le service    de fonctionner.  ...
Résolution DNSExemples d’attaques par déni de service       Le 23 décembre 2009, un grand libraire en ligne stoppé       p...
Résolution DNSdDoS    Il y a très longtemps que les pirates n’utilisent plus uniquement    leurs propres machines !    Le ...
Résolution DNSModification des requêtes ou réponses dansle réseau    Problème surtout étudié en Chine    À l’intérieur du r...
Résolution DNSModification des requêtes ou réponse par lerésolveur    Résolveurs menteurs    Résolveurs du FAI qui donnent ...
Résolution DNSRésolveur menteur, pour le Bien ?     1   BIND a désormais un mécanisme pour le transformer en         mente...
Résolution DNSEmpoisonnement de cache (Kaminsky)       Découverte en janvier 2008 par Dan Kaminsky, annoncée       le 8 ju...
Résolution DNSChangement de résolveur     1   Les machines font une confiance aveugle à leur résolveur         (peu validen...
Résolution DNSEspionnage    Le trafic DNS nous en apprend beaucoup. . .    Tout gérant de serveur (faisant autorité ou réso...
Résolution DNSAttaques non techniques       La lecture de certains journaux pourrait le faire oublier       mais les attaq...
Avitaillement Plan du tutoriel     1   Introduction     2   Résolution DNS     3   Avitaillement     4   Risques théorique...
Avitaillement Enregistrement des noms    Les noms de domaine sont enregistrés auprès d’un registre,    souvent via un Bure...
Avitaillement Piratage d’un BE    Cas de google.co.ma en 2009    Piratage du BE (injection SQL) puis envoi des fausses don...
Avitaillement Piratage d’un registre    Piratage du registre .pr en 2009    Injection SQL au registre de Porto-Rico. micro...
Avitaillement Intermédiaire piraté ou malhonnête      1   Il peut y avoir d’autres acteurs, qui posent les mêmes          ...
Avitaillement Saisie légale    Opération « In Our Sites »    L’ICE (U.S. Immigration and Customs Enforcement, agence    ét...
Avitaillement La loi est nationale    Bien se rappeler qu’il n’existe pas de TLD    « international ».    Vous utilisez un...
Avitaillement Se faire prendre son domaine légalement en France         Pas de garantie pour le titulaire de noms de domai...
Avitaillement Détournement    Manœuvres pour mettre la main sur un domaine (envoi    de faux messages du titulaire, par ex...
Risques théoriquesPlan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques théorique...
Risques théoriquesCertains risques sont surtout pour lesconférences sécurité      1   Les orateurs aux conférences sécurit...
Risques théoriquesExemple, les IDN      1   En outre, dans ces conférences, tout le monde parle          anglais : on est ...
Réalités Plan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques théoriques    5   ...
Réalités Les attaques les plus courantes    Les attaques purement DNS sont très minoritaires    Ne vous focalisez pas sur ...
Solutions et recommandationsPlan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques...
Solutions et recommandationsRedondance     1   Avec le DNS, c’est facile, la redondance d’un service         faisant autor...
Solutions et recommandationsDiversité        Une bogue BIND et tous vos domaines sont fichus ?        Une bogue Linux et, l...
Solutions et recommandationsSupervision        Surveiller l’état de ses domaines, pour éviter d’être        prévenus par S...
Solutions et recommandationsBonnes pratiques de sécurité    Rien de spéficique aux noms de domaines, mais :     1   Bien vé...
Solutions et recommandations3C        Communication        Coopération        Coordination    Trop de gens sont encore iso...
Solutions et recommandationsDNSSEC     1   Objectif : détecter les empoisonnements de cache     2   Moyen : signature cryp...
Solutions et recommandationsDNSSEC, état     1   Tous les TLD importants signés,     2   Mais peu de domaines « utilisateu...
ConclusionPlan du tutoriel    1   Introduction    2   Résolution DNS    3   Avitaillement    4   Risques théoriques    5  ...
ConclusionQue faire ?     1   Encore beaucoup de progrès à faire     2   La plupart sur des pratiques de sécurité classiqu...
Merci !         www.afnic.fr      contact@afnic.fr     Twitter : @AFNIC    Facebook : afnic.fr
Prochain SlideShare
Chargement dans…5
×

JCSA 2012 Tutoriel Afnic par Stéphane Bortzmeyer : Securité des noms de domaines

5 500 vues

Publié le

1 commentaire
3 j’aime
Statistiques
Remarques
  • Retrouvez la vidéo de cette présentation sur http://www.youtube.com/watch?v=wg45iVWuEKE
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
5 500
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2 362
Actions
Partages
0
Téléchargements
83
Commentaires
1
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

JCSA 2012 Tutoriel Afnic par Stéphane Bortzmeyer : Securité des noms de domaines

  1. 1. Sécurité des noms de domaine Stéphane Bortzmeyer AFNIC bortzmeyer@nic.fr 1 / 45
  2. 2. Sécurité des noms de domaine Stéphane Bortzmeyer AFNIC bortzmeyer@nic.fr 2 / 45
  3. 3. Introduction Plan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 3 / 45
  4. 4. Introduction Introduction Nous voulons tous de la sécurité pour nos noms. Mais quel genre de sécurité ? 1 Contre les pannes ? 1 Physiques ? 2 Logicielles ? 2 Contre les attaques ? Menées par qui ? 1 L’État ? 2 Le lycéen dans son garage ? 3 La mafia ? 3 Contre les cafouillages administratifs ? 1 Non-renouvellement 2 Hijacking 4 / 45
  5. 5. Introduction SécuritéS Il n’y a pas la sécurité. Il y a plusieurs services de sécurité, parfois contradictoires : 1 La disponibilité (le service fonctionne) 2 L’intégrité (le service n’a pas été modifié subrepticement) 3 La confidentialité (le service ne laisse pas fuire des informations) Disponibilité et intégrité s’entendent souvent mal. 5 / 45
  6. 6. Résolution DNSPlan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 6 / 45
  7. 7. Résolution DNSMenaces contre la résolution DNS Résolution : demander aux serveurs DNS les informations associées à un nom de domaine (par exemple les adresses IP Il y a les serveurs résolveurs (typiquement fournis par le FAI) et les serveurs faisant autorité (ceux des titulaires de noms ou d’un hébergeur DNS). 7 / 45
  8. 8. Résolution DNSRésolution DNS, suite 8 / 45
  9. 9. Résolution DNSPannes matérielles Plein d’ennemis possibles : Pelleteuses (coupure de Prosodie en mai 2011) Femme de ménage Bâteau de pêche (dont l’ancre arrache les câbles) Écureuil (aux États-Unis, les câbles ne sont pas enterrés) 9 / 45
  10. 10. Résolution DNSPannes logicielles La seconde qui tue Le 1er juillet 2012, une bogue Linux liée à la seconde intercalaire plante de nombreux serveurs. Dont tous ceux du NIST (bureau états-unien des mesures). Tous les serveurs de time.gov sont en panne. Quand un domaine populaire s’arrête, tous les résolveurs se bloquent Le 19 mai 2009, presque tout l’Internet chinois paralysé par une panne du service de résolution de noms (attaque contre Baofeng, mais ayant rebondi sur les opérateurs réseaux). 10 / 45
  11. 11. Résolution DNSBogue au registre Le 12 octobre 2009, tous les noms de domaine suédois disparaissent pendant une heure. Le 12 mai 2010, les deux tiers des domaines allemands ont disparu pendant une heure et demie. 11 / 45
  12. 12. Résolution DNSAttaque par déni de service Déni de service : attaque qui vise à empêcher le service de fonctionner. Il ne s’agit pas de prendre le contrôle du service, juste de l’arrêter. Par exemple, envoi d’une énorme quantité de données au serveur. . . qui n’arrive plus à suivre. Il ne peut plus alors répondre aux requêtes légitimes. Se défendre contre ces attaques est très difficile. 12 / 45
  13. 13. Résolution DNSExemples d’attaques par déni de service Le 23 décembre 2009, un grand libraire en ligne stoppé par une attaque DNS réussie. Attaque (ratée) contre les serveurs racine de février 2007. Mais aussi menaces non suivies d’effet comme le 31 mars 2012 contre la racine. Importante recrudescence des attaques par déni de service contre le DNS depuis décembre 2011. Les attaques sont devenues banales. 13 / 45
  14. 14. Résolution DNSdDoS Il y a très longtemps que les pirates n’utilisent plus uniquement leurs propres machines ! Le pirate typique aujourd’hui est aux commandes d’un botnet (roBOT NETwork), des centaines de milliers de PC MS-Windows qui obéissent au doigt et à l’œil au C&C (Command & Control), le poste de commandement. 14 / 45
  15. 15. Résolution DNSModification des requêtes ou réponses dansle réseau Problème surtout étudié en Chine À l’intérieur du réseau, les réponses DNS sont modifiées (même si on avait demandé directement à un serveur étranger). 15 / 45
  16. 16. Résolution DNSModification des requêtes ou réponse par lerésolveur Résolveurs menteurs Résolveurs du FAI qui donnent délibérement de fausses réponses. Motivation la plus courante : rediriger vers des pages de pub. Censure légale ARJEL en France, projets SOPA et PIPA aux États-Unis : le résolveur DNS a l’obligation légale de mentir (« www.romecasino.com n’existe pas ») 16 / 45
  17. 17. Résolution DNSRésolveur menteur, pour le Bien ? 1 BIND a désormais un mécanisme pour le transformer en menteur, RPZ. Il permet en outre de distribuer les listes de domaines censurés via du transfert de zone. 2 Était-ce une bonne idée de filtrer les domaines potentiellement utilisés par le malware Conficker ? ikea, arte et sncf en ont été victime. Et Conficker n’a pas été stoppé. 17 / 45
  18. 18. Résolution DNSEmpoisonnement de cache (Kaminsky) Découverte en janvier 2008 par Dan Kaminsky, annoncée le 8 juillet 2008 puis publiée en août. A nécessité de patcher la plupart des résolveurs pour mettre des ports sources aléatoires. Exploite uniquement des failles connues mais avec un moyen de les rendre mille fois plus efficace. L’empoisonnement DNS était théoriquement possible, il devient facile. 18 / 45
  19. 19. Résolution DNSChangement de résolveur 1 Les machines font une confiance aveugle à leur résolveur (peu valident elles-même avec DNSSEC). 2 Changer le résolveur permet de tout faire (le résolveur du méchant peut alors répondre que www.mabanque.example est 192.0.2.1, adresse contrôlée par le méchant). Exemple :DNS Changer Logiciel malveillant qui changeait les résolveurs. Le trafic était détourné vers des sites Web payants. Le FBI a piraté les résolveurs du méchant pour analyser le trafic. Le 9 juillet, ce détournement cesse et les « utilisateurs » de DNS Changer seront dans le noir. 19 / 45
  20. 20. Résolution DNSEspionnage Le trafic DNS nous en apprend beaucoup. . . Tout gérant de serveur (faisant autorité ou résolveur) peut en apprendre sur les utilisateurs. 20 / 45
  21. 21. Résolution DNSAttaques non techniques La lecture de certains journaux pourrait le faire oublier mais les attaques les plus courantes sont non techniques. Ingéniérie sociale (« j’ai oublié le nom du fichier où il avait le mot de passe, vous pouvez me le rappeler ? ») Un bon exemple est le hameçonnage « votre compte vient d’être crédité de 10 000 $, allez en http://192.0.2.1/form.php pour valider ce transfert » 21 / 45
  22. 22. Avitaillement Plan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 22 / 45
  23. 23. Avitaillement Enregistrement des noms Les noms de domaine sont enregistrés auprès d’un registre, souvent via un Bureau d’Enregistrement (BE), et hébergés chez un hébergeur DNS (souvent le BE). Chacun de ces acteurs peut être défaillant Par piratage ou malhonnêteté 23 / 45
  24. 24. Avitaillement Piratage d’un BE Cas de google.co.ma en 2009 Piratage du BE (injection SQL) puis envoi des fausses données au registre 24 / 45
  25. 25. Avitaillement Piratage d’un registre Piratage du registre .pr en 2009 Injection SQL au registre de Porto-Rico. microsoft.com.pr, dell.com.pr, etc redirigés 25 / 45
  26. 26. Avitaillement Intermédiaire piraté ou malhonnête 1 Il peut y avoir d’autres acteurs, qui posent les mêmes problèmes de sécurité 2 Revendeur 3 Hébergeur DNS 26 / 45
  27. 27. Avitaillement Saisie légale Opération « In Our Sites » L’ICE (U.S. Immigration and Customs Enforcement, agence états-unienne) a saisi auprès du registre de .com des centaines de noms (sans jugement). 27 / 45
  28. 28. Avitaillement La loi est nationale Bien se rappeler qu’il n’existe pas de TLD « international ». Vous utilisez un .com, vous êtes soumis à la loi états-unienne. 28 / 45
  29. 29. Avitaillement Se faire prendre son domaine légalement en France Pas de garantie pour le titulaire de noms de domaine Le domaine peut être pris au titulaire de bonne foi, par jugement (affaire Milka en 2005) ou bien par menaces juridiques (affaire Madame Figaro en 2012). 29 / 45
  30. 30. Avitaillement Détournement Manœuvres pour mettre la main sur un domaine (envoi de faux messages du titulaire, par exemple) Connu grâce au célébrissime sex.com qui a ainsi changé de mains plusieurs fois (et qui a fait l’objet d’un livre, le seul nom de domaine dans ce cas) 30 / 45
  31. 31. Risques théoriquesPlan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 31 / 45
  32. 32. Risques théoriquesCertains risques sont surtout pour lesconférences sécurité 1 Les orateurs aux conférences sécurité aiment bien les exposés techniques rigolos, même s’ils sont irréalistes. 2 Dans ces conférences, on voit donc souvent passer des « vulnérabilités » qui ne marcheront qu’en labo (souvenez-vous de BEAST...) 32 / 45
  33. 33. Risques théoriquesExemple, les IDN 1 En outre, dans ces conférences, tout le monde parle anglais : on est donc sûr d’obtenir un succès en attaquant Unicode. 2 Exemple de légende urbaine répandue « Les IDN facilitent le hameçonnage, cìc.fr ressemble à cic.fr ». 3 Or, toutes les études sur le hameçonnage montrent que les utilisateurs ignorent l’URL, ne le comprenant pas (cic-secure.com. . . ). 4 Les spams de hameçonnage ne comprennent jamais d’URL et souvent uniquement des adresses IP ! 5 Mais le monde de la sécurité informatique n’est pas encore evidence-based. Les légendes ont la vie dure. 33 / 45
  34. 34. Réalités Plan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 34 / 45
  35. 35. Réalités Les attaques les plus courantes Les attaques purement DNS sont très minoritaires Ne vous focalisez pas sur les attaques techniques sophistiquées qui font la une. La plupart des attaques sont « bêtes » mais efficaces (ingéniérie sociale, faille exploitée par un script-kiddie, dDoS purement volumétrique). 35 / 45
  36. 36. Solutions et recommandationsPlan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 36 / 45
  37. 37. Solutions et recommandationsRedondance 1 Avec le DNS, c’est facile, la redondance d’un service faisant autorité est prévue dès le début (contrairement à HTTP), 2 Deux serveurs, ce n’est pas assez, mettez-en au moins quatre, 3 Sur-avitailler : machines et réseaux pouvant tenir trois à cinq fois la charge normale (pour les cas de dDoS), 4 Et, surtout, évitez le SPOF (Single Point of Failure). Ayez plusieurs sites physiques et, si possible, plusieurs opérateurs. . . 37 / 45
  38. 38. Solutions et recommandationsDiversité Une bogue BIND et tous vos domaines sont fichus ? Une bogue Linux et, le jour de la seconde intercalaire, aucun serveur ne marche ? Favoriser la diversité génétique Par exemple, il n’y a aucune raison de n’utiliser que BIND. « Nous vous rappelons qu’il existe d’autres possibilités. » 38 / 45
  39. 39. Solutions et recommandationsSupervision Surveiller l’état de ses domaines, pour éviter d’être prévenus par Slashdot et Zataz... (Surveiller le serveur Web est insuffisant.) Surveiller chaque serveur (autrement, vous serez prévenus seulement lorsque le dernier tombera en panne.) 39 / 45
  40. 40. Solutions et recommandationsBonnes pratiques de sécurité Rien de spéficique aux noms de domaines, mais : 1 Bien vérifier la sécurité du système d’enregistrement (ne pas mettre le mot de passe de votre compte auprès du BE sur un post-it sur l’écran), et de l’hébergement DNS, 2 Attention à l’ingéniérie sociale (« Bonjour, ici le service technique de votre registrar, il y a un problème technique, nous aurions besoin du mot de passe. ») 3 Développer une culture de sécurité informatique dans le service qui gère les noms de domaines. 40 / 45
  41. 41. Solutions et recommandations3C Communication Coopération Coordination Trop de gens sont encore isolés dans leur coin, sans utiliser l’information publique, et sans échanger avec les pairs. 41 / 45
  42. 42. Solutions et recommandationsDNSSEC 1 Objectif : détecter les empoisonnements de cache 2 Moyen : signature cryptographique des enregistrements 42 / 45
  43. 43. Solutions et recommandationsDNSSEC, état 1 Tous les TLD importants signés, 2 Mais peu de domaines « utilisateur » signés, 3 Et peu de résolveurs validents (le principal est Comcast aux USA). 43 / 45
  44. 44. ConclusionPlan du tutoriel 1 Introduction 2 Résolution DNS 3 Avitaillement 4 Risques théoriques 5 Réalités 6 Solutions et recommandations 7 Conclusion 44 / 45
  45. 45. ConclusionQue faire ? 1 Encore beaucoup de progrès à faire 2 La plupart sur des pratiques de sécurité classiques 3 Quelques nouvelles techniques (DNSSEC. . . ) 45 / 45
  46. 46. Merci ! www.afnic.fr contact@afnic.fr Twitter : @AFNIC Facebook : afnic.fr

×