Quelques réflexions sur le papier: un défi-réponse pratique pour le DNS – Bien choisir son serveur d impression
Cet article présente les idées suggérées dans le document: Practical Challenge-Response for DNS, 2018, par Rami Al-Dalky, Michael Rabinovich et Mark Allman.
Étant donné que la vitesse du DNS est essentielle à la performance de toute connexion sur le réseau, il est très important de rendre les serveurs DNS rapides, y compris un logiciel optimisé capable de répondre aux requêtes en quelques millisecondes, et de connecter les serveurs DNS au réseau via liens haut débit. Pour préparer le terrain aux attaques DDoS massives basées sur le système DNS, ajoutez un troisième point: les réponses DNS ont tendance à être beaucoup plus volumineuses que les requêtes DNS. En fait, une réponse DNS prudente peut être plusieurs fois supérieure à la requête.
Pour utiliser un serveur DNS en tant qu'amplificateur lors d'une attaque DDoS, l'attaquant envoie alors une requête à un certain nombre de serveurs DNS accessibles au public. La source de cette requête est l'adresse du système à attaquer. Si la requête DNS est soigneusement conçue, l’attaquant peut envoyer de petits paquets qui poussent plusieurs serveurs DNS à envoyer des réponses volumineuses à une adresse IP unique, provoquant de grandes quantités de trafic sur le système attaqué.
Transporter DNS sur TCP est un moyen d’essayer de résoudre ce problème car TCP nécessite une négociation à trois. Lorsque l'attaquant envoie une requête avec une adresse source usurpée, le serveur tente de créer une session TCP avec le système possédant l'adresse spoofée, ce qui échouera. Un point clé: les paquets de négociation TCP à trois voies sont beaucoup plus petits que la plupart des réponses DNS, ce qui signifie que le flux de paquets de l'attaquant n'est pas amplifié (en taille) par le serveur DNS.
DNS sur TCP pose toutefois problème. Par exemple, de nombreux résolveurs DNS ne peuvent pas atteindre un serveur DNS faisant autorité en utilisant TCP en raison de filtres de paquets avec état, de traducteurs d'adresses réseau et d'autres processus qui modifient ou bloquent les sessions TCP sur le réseau. Qu'en est-il de DNSSEC? Cela n'empêche pas l'utilisation abusive d'un serveur DNS. il ne valide que les enregistrements contenus dans la base de données DNS. DNSSEC signifie simplement que l'attaquant peut envoyer encore plus gros vraiment enregistrements DNS sécurisés vers un système sans méfiance.
Une autre option consiste à créer un système de type challenge-response à l’instar du protocole TCP, mais à l’intégrer dans le système DNS. Les enregistrements CNAME constituent l'endroit le plus évident pour intégrer un tel système défi-réponse. Supposons qu'un serveur DNS récursif demande un enregistrement particulier; un serveur faisant autorité peut répondre avec un enregistrement CNAME en demandant au serveur récursif de demander à quelqu'un d'autre. Lorsque le serveur récursif envoie la seconde requête, probablement à un serveur différent, il inclut les informations de réponse dont il dispose pour donner au second serveur le contexte de sa requête.
Pour créer un système de demande de challenge, le serveur faisant autorité renvoie un CNAME demandant au serveur récursif de contacter le même serveur faisant autorité. Afin de garantir l'efficacité de la négociation à trois voies, l'adresse IP source du serveur DNS récursif interrogateur est codée dans la réponse CNAME. Lorsque le serveur faisant autorité reçoit la seconde requête, il peut vérifier l'adresse source codée dans la seconde requête de résolution par rapport à la source du paquet contenant la nouvelle requête. S'ils ne correspondent pas, le serveur faisant autorité peut supprimer la deuxième requête. la poignée de main à trois voies a échoué.
Si la source de la demande initiale est usurpée, la victime reçoit une réponse CNAME lui demandant de redemander la réponse – à laquelle la victime ne répondra jamais car elle n'a pas envoyé la demande initiale. Comme les réponses de CNAME sont faibles, cette tactique supprime l’amplification espérée par l’attaquant.
Cette solution présente toutefois un problème: les résolveurs DNS sont souvent regroupés derrière une seule adresse anycast. Envisagez un pool de serveurs DNS de résolution avec deux serveurs étiquetés A et B. Le serveur A reçoit une demande DNS d'un hôte et, constatant qu'il ne possède aucune entrée de cache pour la destination, envoie récursivement une demande à un serveur faisant autorité. Le serveur faisant autorité, à son tour, envoie un défi à l'adresse IP du serveur A. Cette adresse est toutefois une adresse anycast attribuée à l'intégralité du pool de serveurs récursifs. Pour une raison quelconque, le défi – une réponse de CNAME demandant au serveur récursif de demander à un emplacement différent – est dirigé vers B.
Si le logiciel DNS est configuré correctement, B répondra à la demande. cependant, cette réponse proviendra de l'adresse IP de B, plutôt que de A. N'oubliez pas que la source de la requête d'origine est codée dans la réponse CNAME du serveur ayant répondu. Etant donné que l'adresse encodée dans la requête suivante ne correspond pas à l'adresse de B, le serveur faisant autorité supprime la requête.
Pour résoudre ce problème, les auteurs de cet article suggèrent une réponse enchaînée. Plutôt que de supprimer la demande avec une adresse source mal codée, codez la nouvelle adresse source dans le paquet et envoyez un autre défi sous la forme d'une réponse CNAME. En supposant qu'il n'y ait que deux serveurs dans le pool, la requête suivante contenant la liste codée d'adresses IP de la réponse CNAME correspondra nécessairement à l'une des deux adresses sources disponibles et le serveur faisant autorité pourra répondre avec les informations correctes.
Que se passe-t-il si le pool de serveurs récursifs est très volumineux – de l'ordre de centaines ou de milliers de serveurs? Alors qu’un ou deux «allers-retours» sous la forme d’une poignée de main à trois voies n’auraient pas un impact trop important sur les performances, des milliers de personnes pourraient poser problème. Pour résoudre ce problème, les auteurs suggèrent de tirer parti de l'observation selon laquelle, une fois que les paquets transmis entre le demandeur et le serveur sont aussi volumineux que la demande elle-même, tout gain d'amplification dont un attaquant pourrait tirer parti a été effacé. Une fois que le paquet CNAME a atteint la même taille qu'une demande DNS en ajoutant les adresses source observées dans le processus de négociation à trois voies, le serveur doit simplement répondre à la requête. Cela (généralement) réduit le nombre d'allers-retours à trois ou quatre avant que le DNS ne produise plus de données que l'attaquant ne pourrait envoyer directement à la victime et améliore considérablement les performances du schéma.
Après avoir lu ce document, il me restait une question: il existe des requêtes DNS soigneusement conçues qui peuvent provoquer des réponses très volumineuses sur plusieurs paquets. Celles-ci ne sont pas du tout mentionnées dans le document. cela semble être un domaine sur lequel il faudrait réfléchir et approfondir la recherche. Dans l’ensemble, cependant, cela semble être un système efficace pour réduire ou éliminer l’utilisation de serveurs faisant autorité dans les attaques par réflexion DDoS.
Commentaires
Laisser un commentaire