Journée du conseil scientifique de l'AFNIC (JCSA) - Sécurité des noms de domaine

Bonjour à tous

Dans le cadre du programme de formation pour la sécurisation des sites Joomla!, J’ai eu la chance d’assister hier à la journée du conseil scientifique de l’AFNIC, journée très intéressante, que je vous recommande pour l’année prochaine !

La journée était constituée de deux parties, le matin tutoriel de Stéphane Bortzmeyer sur la sécurité des noms de domaine et l’après-midi, séminaire sur la résilience de l’Internet. Je vais résumer dans cet article le tutoriel, je ferai mon retour sur le séminaire plus tard.

Tout d’abord, un grand merci à Stéphane pour le dynamisme de sa conf (et de toutes ses interventions), qui ne laisse pas une seconde d’ennui aux participants. (Je précise qu’on peut retrouver son humour sur son compte Twitter #FF @bortzmeyer). Chaque élément était associé d’un exemple, ce qui rendait cette conférence sur la sécurit des noms de domaine beaucoup plus vivante.

Introduction:

La sécurité, c’est l’ensemble des 3 éléments suivants :

  • Disponibilité
  • Intégrité
  • Confidentialité

Le fonctionnement d’un résolveur DNS lors de son initialisation 

  1. Je  souhaite accéder à www.pulsar-informatique.com
  2. Bonjour serveur racine, je recherche www.pulsar-informatique.com
  3. Allez voir chez 204.175.42.11
  4. Bonjour 204.175.42.11, je recherche www.pulsar-informatique.com
  5. Allez voir chez 92.115.24.23
  6. Bonjour 91.115.24.23, je recherche www.pulsar-informatique.com
  7. J’ai la réponse, c’est chez 84.25.63.247 !
  8. Pour accéder au site pulsar-informatique.com, il faut se rendre à cette adresse : 84.25.63.247

Le résolveur conserve en cache chaque réponse obtenue, il n'aura donc plus à réexécuter tout ce chemin.

 

Comme on peut le constater ce système fonctionne merveilleusement bien mais a pour conséquence que l’indisponibilité ou la modification de l’un des serveurs faisant autorité ou pire encore de l’un des serveurs plus hauts comme les root name serveurs, associés à un TLD (extension) ou l’un des serveurs K-root empêche ou modifie l’accès à tous les sites associés. En effet les sites existent toujours mais vous ne savez simplement pas où les trouver, car vous ne connaissez pas leurs adresses IP, vous y accédez par le nom de domaine.

Le rôle joué par ces serveurs devient donc capital.

 

Les principaux risques sur la résolution DNS

Les différents événements pouvant survenir :

1- Les pannes :

Il y a les pannes matérielles : pelleteuses, femmes de ménage, bateaux de pêche, Scratts écureuils ou grand-mère arménienne, qui arrachent des câbles par mégarde.

Et les pannes logicielles :

La seconde tueuse (qui pour la petite histoire a fait planter le serveur du NIST, bureau états-unien des mesures ayant décidé de l’ajout de cette seconde…) ou un bug au registre, (table pleine ou disque plein)

 

2- Les attaques :

Logicielles:

Les dénis de service, une attaque par déni de service a par exemple empêché l’accès à Amazon le 24 décembre 2009

Les dDOS : piratages utilisant botnet, un réseau de robots qui obéissent à un poste de commande

Les modifications de requêtes ou réponses dans le réseau: on constate ainsi qu’en Chine la réponse est en fait modifiée Certaines censures légales peuvent aussi avoir lieu, avec ARJEL, SOPA ou PIPA.

Certaines méthodes d’empoisonnement du cache existent aussi : il s’agit en fait de répondre avant le vrai répondeur (le protocole UDP ne permet pas de vérifier si c'est ce dernier à qui il a envoyé la demande) , le résolveur conservera donc dans osn cache un l’adresse IP « du méchant » et redirigera vers lui et non vers le bon serveur.

Changement du résolveur :

Une attaque sur le résolveur permet de tout faire car une machine fait une confiance aveugle à son résolveur, on peut donc rediriger tous les sites où on le souhaite, sur des sites payants, etc.

Certaines méthodes d’espionnage existent aussi, car les DNS parlent et indiquent les chemins suivis par les internautes.

Il faut néanmoins savoir que d’autres méthodes d’attaque non techniques existent, ce sont en fait les plus employées car les plus efficaces, comme l’ingénierie sociale : appeler en prétendant avoir perdu le mot de passe, etc.

 

Les principaux risques sur l’avitaillement

Lors de l’enregistrement des noms aussi chaque acteur peut être défaillant

Le bureau d’enregistrement lui-même peut être piraté, le registre (celui de porto rico par exemple avait été un jour piraté, tous les .pr s’étaient retrouvés redirigés  ailleurs !).

Certaines saisies légales peuvent aussi avoir lieu, une opération de l’ICE avait par exemple saisi  des centaines de noms auprès de .com.

Des manoeuvres de détournement ont parfois aussi lieu, comme l’envoi de faux messages aux titulaires.

 

La réalité

D’autres risques sont possibles techniquement mais en fait l’expérience a prouvé que certains risques sont évoqués presqu’uniquement "pour la classe", tant leur probabilité de réalisation est faible. Souvent les attaques rencontrant le plus de succès sont les mails de richissime vieillarde tenant absolument, par philanthropie,  à vous léguer la moitié de sa fortune, mais nécessitant votre aide pour sortir l’argent de la banque. Si, si...et certains oseront encore prétendre désespérer de l'humain!

 

Solutions et recommandations

Redondance

  • 2 serveurs DNS ce n’est pas assez, il faut en mettre 4
  • Suravitailler poour prévoir des montées en charge
  • Eviter SPOF(Single point of failure) : plusieurs sites physiques et si possible, plusieurs opérateurs

Diversité

  • Bug BIND
  • Seconde tueuse sur Linux

=>entretenir une diversité des systèmes employés permet d’assurer que seule une partie du système soit affectée par un bug lié au système

(je trouve ça irréaliste d'un point de vue maintenance, mais bon...)

Supervision

  • Surveiller l'état de ses NDDs
  • Surveiller chaque serveur

Bonnes pratiques de sécurité

  • Pas le même mot de passe pour le compte du système d’enregistrement et pour l’hébergement
  • Se méfier de l’ingéniere sociale
  • Développer une culture de sécurité informatique

DNSSec

Permet de détecter l’empoisonnement de cache en signant les enregistrements

 

En conclusion

Encore beaucoup de progrès sont à faire pour sécuriser les noms de domaine, beaucoup de règles de sécurité à mettre en place sont des règles classiques, et une fois que celles-ci sont mises en place, il devient alors intéressant de mettre en place quelques nouvelles techniques comme le DNS Sec.

Encore merci à Stéphane !

Cet article n'est bien sûr que mon résumé, les slides de ce tutoriel sur la sécurité des noms de domaine sont accessibles sur http://web.dbee.com/afnic/20120704/index.php

merci pour les corrections apportées par Stéphane à la lecture de l'article, j'ai corrigé

 

Commentaires

Pas encore de commentaire
Already Registered? Login Here
Guest
mercredi 28 octobre 2020

Image Captcha

By accepting you will be accessing a service provided by a third-party external to https://www.pulsar-agency.com/