Il s'agit d'une question canonique sur la sécurisation des résolveurs DNS publics

Les serveurs DNS ouverts semblent assez soignés et pratiques, car ils fournissent des adresses IP que nous pouvons utiliser de manière cohérente dans toute notre entreprise, quel que soit leur emplacement. Google et OpenDNS offrent cette fonctionnalité, mais je ne suis pas sûr de vouloir que ces sociétés aient accès à nos requêtes DNS.

Je veux mettre en place quelque chose comme ça pour notre entreprise, mais j'entends beaucoup parler de cette pratique dangereuse (en particulier en ce qui concerne les attaques d'amplification ) et je veux m'assurer que nous le faisons correctement. Quelles sont les choses que je dois garder à l'esprit lors de la construction de ce type d'environnement?

Il y a quelques choses que vous devez comprendre avant de commencer:

Il s'agit d'un problème d'ingénierie réseau.

La plupart des personnes qui souhaitent configurer ce type d'environnement sont des administrateurs système. C'est cool, je suis aussi administrateur système! Une partie du travail consiste à comprendre où se terminent vos responsabilités et où commence quelqu'un d'autre, et croyez-moi, ce n'est pas un problème que les administrateurs système peuvent résoudre par eux-mêmes. Voici pourquoi:

• UDP est un protocole sans état. Il n'y a pas de prise de contact client.
• Les requêtes sur un serveur DNS sont une transaction en deux étapes non authentifiée (requête, réponse). Le serveur n'a aucun moyen de savoir si l'adresse IP source est usurpée avant de répondre.
• Au moment où une requête a atteint le serveur, il est déjà trop tard pour empêcher un paquet UDP usurpé. L'usurpation ne peut être évitée que par une pratique connue sous le nom de filtrage d'entrée , un sujet couvert par les documents BCP 38 et BCP 84 . Ceux-ci sont mis en œuvre par les périphériques réseau situés devant votre serveur DNS.
• Nous ne pouvons pas vous expliquer comment configurer votre centre de données de bout en bout, ni comment mettre en œuvre ces meilleures pratiques. Ces choses sont très spécifiques à vos propres besoins. Le format Q&A ne fonctionne tout simplement pas pour cela, et ce site n'est pas destiné à se substituer à l'embauche de professionnels pour effectuer un travail professionnel.
• Ne présumez pas que votre entreprise, trop grosse pour faire faillite, d'un milliard de dollars implémente correctement le filtrage d'entrée.

Ce n'est pas une meilleure pratique. La meilleure pratique est de ne pas le faire.

Il est très facile de configurer un résolveur DNS Internet. Il faut beaucoup moins de recherche pour en créer un que pour comprendre les risques encourus. C'est l'un de ces cas où les bonnes intentions permettent par inadvertance les méfaits (et les souffrances) d'autrui.

• Si votre serveur DNS répond à n'importe quelle adresse IP source qu'il voit, vous exécutez un résolveur ouvert. Celles-ci sont constamment utilisées dans des attaques d'amplification contre des parties innocentes. Chaque jour , de nouveaux administrateurs système tiennent debout les résolveurs ouverts , ce qui rend rentable pour les individus malveillants de les rechercher en permanence. Il n'est pas vraiment question de savoir si votre résolveur ouvert va être utilisé dans une attaque: à partir de 2015, c'est à peu près acquis. Ce n'est peut-être pas immédiat, mais ça va arriver à coup sûr.
• Même si vous appliquez une ACL à l'aide de votre logiciel DNS (c'est-à-dire BIND), tout cela ne fait que limiter les paquets DNS usurpés auxquels votre serveur répondra. Il est important de comprendre que votre infrastructure DNS peut être utilisée non seulement pour attaquer les périphériques de l'ACL, mais également tous les périphériques réseau entre votre serveur DNS et les périphériques pour lesquels il répondra. Si vous ne possédez pas le centre de données, c'est un problème pour plus que vous.

Google et OpenDNS le font, alors pourquoi pas moi?

Parfois, il est nécessaire de peser l'enthousiasme contre la réalité. Voici quelques questions difficiles à vous poser:

• Est-ce quelque chose que vous voulez mettre en place sur un coup de tête, ou est-ce quelque chose que vous avez quelques millions de dollars à investir pour le faire correctement?

• Avez-vous une équipe de sécurité dédiée? Équipe dédiée aux abus? Les deux ont-ils les cycles pour faire face aux abus de votre nouvelle infrastructure et aux plaintes que vous recevrez de parties externes?

• Avez-vous une équipe juridique ?

• Lorsque tout cela sera dit et fait, tous ces efforts commenceront-ils à distance à se rentabiliser, à générer des bénéfices pour l'entreprise ou à dépasser la valeur monétaire de la gestion des inconvénients qui vous ont conduit dans cette direction?

En terminant, je sais que ce fil est Q & A est une sorte de déception pour la plupart d'entre vous qui y sont liés. Serverfault est là pour fournir des réponses, et une réponse de «c'est une mauvaise idée, ne le faites pas» n'est généralement pas perçue comme très utile. Certains problèmes sont beaucoup plus compliqués qu'ils ne le semblent au départ, et c'est l'un d'entre eux.

Si vous voulez essayer de faire fonctionner cela, vous pouvez toujours nous demander de l'aide pendant que vous essayez de mettre en œuvre ce type de solution. La principale chose à réaliser est que le problème est trop important en soi pour que la réponse soit fournie dans un format Q&R pratique. Vous devez déjà avoir investi beaucoup de temps dans la recherche sur le sujet et nous approcher des problèmes de logique spécifiques que vous avez rencontrés lors de votre implémentation. Le but de ce Q&R est de vous donner une meilleure compréhension de la situation dans son ensemble et de vous aider à comprendre pourquoi nous ne pouvons pas répondre à une question aussi large que celle-ci.

Aidez-nous à protéger Internet! :)

Que vous exécutiez un récurseur DNS ouvert ou un serveur DNS faisant autorité, le problème est le même et la plupart des solutions possibles sont également les mêmes.

La meilleure solution

Les cookies DNS sont une norme proposée qui donne aux serveurs DNS un moyen d'exiger des clients qu'ils envoient un cookie afin de prouver que l'adresse IP du client n'a pas été usurpée. Cela coûtera un aller-retour supplémentaire pour la première recherche, ce qui est le coût le plus bas qu'une solution pourrait offrir.

Remplacement pour les clients plus âgés

Étant donné que les cookies DNS ne sont pas encore standardisés, il sera bien sûr nécessaire de prendre en charge les clients plus âgés maintenant et pour les années à venir.

Vous pouvez évaluer les demandes de limite des clients sans prise en charge des cookies DNS. Mais les limites de taux permettent à un attaquant de faire plus facilement DoS votre serveur DNS. Sachez que certains serveurs DNS ont une fonction de limite de débit conçue uniquement pour les serveurs DNS faisant autorité. Étant donné que vous posez des questions sur un résolveur récursif, ces implémentations de limitation de débit peuvent ne pas vous être applicables. La limite de débit par conception deviendra le goulot d'étranglement pour votre serveur, et donc un attaquant devra vous envoyer moins de trafic afin de provoquer la suppression des demandes légitimes qu'il ne l'aurait fait s'il n'y avait pas de limite de débit.

Un avantage des limites de taux est que dans le cas où un attaquant inonde votre serveur DNS de requêtes DNS, vous avez plus de chances d'avoir une capacité restante qui vous permettra de ssh vers le serveur et d'enquêter sur la situation. De plus, les limites de débit peuvent être conçues pour supprimer principalement les demandes des adresses IP clientes envoyant de nombreuses demandes, ce qui peut être suffisant pour vous protéger contre le DoS contre les attaquants qui n'ont pas accès à l'usurpation d'adresses IP clientes.

Pour ces raisons, une limite de débit légèrement inférieure à votre capacité réelle peut être une bonne idée, même si elle ne protège pas réellement contre l'amplification.

Utilisation de TCP

Il est possible de forcer un client à utiliser TCP en envoyant un code d'erreur indiquant que la réponse est trop grande pour UDP. Cela présente quelques inconvénients. Il en coûte deux allers-retours supplémentaires. Et certains clients défectueux ne le prennent pas en charge.

Le coût de deux allers-retours supplémentaires peut être limité à la première demande en utilisant cette approche:

Lorsque l'adresse IP du client n'a pas été confirmée, le serveur DNS peut envoyer une réponse tronquée pour forcer le client à basculer vers TCP. La réponse tronquée peut être aussi courte que la demande (ou plus courte si le client utilise EDNS0 et la réponse ne le fait pas), ce qui élimine l'amplification.

Tout IP client qui termine une négociation TCP et envoie une demande DNS sur la connexion peut être temporairement mis sur liste blanche. Une fois sur liste blanche, IP peut envoyer des requêtes UDP et recevoir des réponses UDP jusqu'à 512 octets (4096 octets si vous utilisez EDNS0). Si une réponse UDP déclenche un message d'erreur ICMP, l'adresse IP est à nouveau supprimée de la liste blanche.

La méthode peut également être inversée à l'aide d'une liste noire, ce qui signifie simplement que les adresses IP des clients sont autorisées à interroger UDP par défaut, mais tout message d'erreur ICMP entraîne la liste noire de l'IP, nécessitant une requête TCP pour sortir de la liste noire.

Un bitmap couvrant toutes les adresses IPv4 pertinentes pourrait être stocké dans 444 Mo de mémoire. Les adresses IPv6 devraient être stockées d'une autre manière.

Je ne sais pas si un serveur DNS a mis en œuvre cette approche.

Il a également été signalé que certaines piles TCP peuvent être exploitées lors d'attaques d'amplification. Cela s'applique cependant à tout service basé sur TCP et pas seulement au DNS. Ces vulnérabilités devraient être atténuées par la mise à niveau vers une version du noyau où la pile TCP a été corrigée pour ne pas envoyer plus d'un paquet en réponse à un paquet SYN.