A propos du choix aléatoire des ports source DNS

Cet article a été écrit spécialement pour la majorité d'entre vous qui ne gérez pas vos propres serveurs DNS (Domain Name System), parce que chacun est concerné dans l'affaire, pas seulement les administrateurs systèmes.

Quand une application (disons, un navigateur web ou un client de messagerie par exemple) doit communiquer avec un ordinateur distant, elle invoque le service de noms de domaines (DNS). Pour les systèmes Linux, cela se fait par l'intermédiaire d'une petite librairie (héritage un peu inquiètant de l'ancien et peu cohérent code de Bind 8) incluse dans la librairie système en C, et appelée résolveur. Ce résolveur, qui est un composant côté client du système de noms de domaines sous TCP/IP, utilise /etc/resolv.conf (sous Linux) comme principal fichier de configuration (parfois aussi /etc/nsswitch.conf, mais nous n'allons pas approfondir maintenant).

Pour les 98% d'entre vous qui obtenez votre adresse IP ainsi que la configuration du service de noms de domaines et du routage, etc., via le service DHCP, ce fichier resolv.conf est modifié fréquemment, chaque fois que votre bail DHCP est renouvelé. Jetez un oeil à votre fichier /etc/resolv.conf. Ce fichier est très simple. Voici son contenu sur mon serveur :

search linuxmafia.com deirdre.org
nameserver 198.144.192.2
nameserver 198.144.192.4
nameserver 198.144.195.186 

La première ligne signifie « si quelqu'un cherche à accéder à une machine sans donner son nom complet, essayer d'ajouter au nom fourni le suffixe 'linuxmafia.com' par défaut, ou encore 'deirdre.org' avant d'abandonner ». Les trois dernières lignes donnent les adresses IP des trois serveurs DNS auxquels le resolveur (client) transmettra les demandes.

Vous vous rappelez que ces lignes sont communiquées par votre serveur DHCP (il est également possible de modifier le comportement du client DHCP sur ce point). Si vous gérez votre propre serveur DHCP, par exemple associé à un boitier pare-feu, vous pouvez spécifier quelles données de configuration vont être transmises avec votre bail DHCP.

Peu importe comment, votre résolveur va transmettre chaque requête à un des serveurs de noms de domaines mentionnés dans le fichier resolv.conf. Que fait alors le serveur contacté ? Tout se passe comme quand vous effectuez une recherche : ou bien vous trouvez la réponse, ou bien vous connaissez quelqu'un qui doit connaître la réponse. Dans le système DNS, cela se traduit par :

Il est connu depuis très longtemps qu'un tel système de résolution récursive est techniquement complexe, et présente des écueils importants au niveau de la sécurité. Parmi les risques les plus importants, se trouve une possibilité de corrompre ("poisoning") la mémoire cache d'un de ces serveurs de résolution récursive que votre résolveur local interroge. Il est possible d'effectuer de telles corruptions simplement par le biais de requêtes adressées par un résolveur (client DNS) à un serveur qui l'aurait autorisé à effectuer une telle demande parce que l'adresse IP du résolveur se trouverait dans sa liste d'IP admises. Souvenez-vous que lorsque vous vous abonnez auprès d'un fournisseur d'accès internet, celui-ci vous transmet une courte liste de serveurs de noms de domaines de résolution récursive utilisables, qui se trouve communiquée à de nombreuses personnes, au minimum tous ses clients, sachant que certains prestataires permettent à n'importe qui d'interroger leurs serveurs publics.

Donc, leçon n°1, une des méthodes les plus simples pour réduire votre exposition aux risques liés aux failles de sécurité du système DNS est d'éviter d'utiliser les serveurs de noms de domaines des fournisseurs d'accès à internet (la plupart) pour vos besoins DNS habituels. Vous pouvez y parvenir en installant votre propre serveur de noms de domaines. Ce qui est probable, c'est que peu de personnes mis à part les administrateurs systèmes savent que c'est très simple à effectuer. Il vous suffit la plupart du temps d'installer un paquet et tout fonctionne très bien automatiquement. Pas de réglage à faire. Vous devez juste vous assurer que resolv.conf pointe sur votre machine. Cela consommera un peu de mémoire vive sur votre système, mais c'est tout. Tout le monde devrait songer à faire ainsi ; même sur les portables.

Fondamentalement, les serveurs de noms de domaines des fournisseurs d'accès à internet restent en général de faux amis. Ne les utilisez pas ! Le fait que j'utilise moi-même le fournisseur Raw bandwith est le reflet de la haute estime que je porte à Mike Durkin, mais cela ne doit pas être systématiquement généralisé à d'autres prestataires.

De nombreuses personnes, depuis des années, ont souligné le fait qu'il était dangereusement facile de construire des requêtes récursives (je veux dire construire des réponses artificielles contenant des données faussées, mais étant acceptées par le résolveur comme venant réellement du serveur qu'il a interrogé). Les requêtes récursives comportent une sorte d'identifiant unique de transaction, appelé identifiant de requête (query ID ou QID). Mais il ne s'agit que d'un nombre codé sur 16 bits, ce qui est assez insuffisant, rendant les réponses plus faciles à construire de toute pièce que si l'identifiant n'était, disons, un entier codé sur 32 bits.

Comme il n'est pas réalisable d'allonger les identifiants, le seul moyen restant en toute logique pour rendre plus difficile la construction de réponses artificielles aux requêtes récursives est de faire la requête initiale sur un port TCP ou UDP choisi au hasard plutôt que sur le port standard DNS 53. Vous devinez que la plupart des serveurs de noms de domaines non dotés du correctif paru le 8 juillet 2008 transmettent stupidement toutes leurs propres requêtes à partir du port 53... Le serveur de noms que vous utilisez en ce moment peut-être également. C'est une très mauvaise chose, comme l'ont démontré la société Matasano et le mathématicien allemand Halvar Flake, les « mauvais garçons » du web ayant déjà été —ou seront bientôt—capables de corrompre facilement le cache de tels serveurs de noms de domaines. Et rien ne rend plus dangereuse cette vulnérabilité que de transmettre les requêtes toujours par le même port.

La société Matasano a également soulevé un second problème : certains serveurs de noms de domaines ont tendance à accepter en même temps que des réponses attendues, des données en rapport avec un nom de domaine complètement différent. Fort heureusement, la plupart des serveurs de noms récents sont relativement épargnés, bien que certains demeurent concernés, ce point n'étant pas rectifié par le correctif du 8 juillet.

Beaucoup de gens ne songe pas à un aspect des choses, c'est que le résolveur DNS de la librairie libc est d'un type simplifié : il amorce une requête DNS avec le bit « récursif » positionné, ce qui implique que le serveur contacté doit transmettre la demande à un autre serveur s'il ne connait pas la réponse lui-même. N'y a-t-il pas là une vulnérabilité potentielle du même type que celle soulevée par la société Matasano ? Si, mais les résolveurs simplifiés ne mettent pas en mémoire cache les réponses qu'ils reçoivent, si bien que c'est moins grave (les données corrompues disparaissant immédiatement). Singulièrement, ce ne sont pas les composants logiciels des ordinateurs de bureau qui sont les plus concernés cette fois. Ce sont les services de noms de domaines fonctionnant sur tous les serveurs (par exemple ceux des fournisseurs d'accès à internet).

Les pare-feu vont devenir un réel problème pour deux raisons :

Tester le caractère aléatoire des ports source utilisés par votre serveur de noms de domaines

Saisissez la commande :

$ dig [adresse IP du serveur de nom ou nom d'hôte] porttest.dns-oarc.net in txt 

Le résultat inclue un commentaire et une appréciation de la qualité du caractère aléatoire des ports utilisés : GREAT (très bon) ou GOOD (bon), FAIR (faible), ou POOR (très faible)

Vous pouvez utiliser, pour plus de facilité, la page web suivante : https://www.dns-oarc.net/oarc/services/dnsentropy.

Vous devriez vous sentir concerné dés maintenant par ce problème. Ce n'est pas seulement le problème des autres.