Minimisation des risques liés à l'utilisation de DoH et DoT
Protection contre DoH et DoT
Contrôlez-vous votre trafic DNS ? Les organisations investissent beaucoup de temps, d'argent et d'efforts pour sécuriser leurs réseaux. Cependant, l'un des domaines souvent négligés est le DNS.
Une bonne vue d'ensemble des risques liés au DNS est à la conférence Infosecurity.
31 % des types de ransomwares examinés utilisaient le DNS pour l'échange de clés. Conclusions de l'étude
31 % des types de ransomwares examinés utilisaient le DNS pour l'échange de clés.
Le problème est sérieux. Selon le laboratoire de recherche Palo Alto Networks Unit 42, environ 85 % des logiciels malveillants utilisent le DNS pour établir un canal de commande et de contrôle, permettant aux cybercriminels d'infiltrer facilement des logiciels malveillants dans votre réseau, ainsi que de voler des données. Depuis sa création, le trafic DNS a principalement été non chiffré et facilement analysable par des systèmes de protection NGFW.
De nouveaux protocoles pour le DNS ont vu le jour, visant à améliorer la confidentialité des connexions DNS. Ils sont activement soutenus par les principaux fournisseurs de navigateurs et d'autres fournisseurs de logiciels. Une augmentation du trafic DNS chiffré commencera bientôt dans les réseaux d'entreprise. Le trafic DNS chiffré, qui n'est pas correctement analysé et autorisé, représente une menace de sécurité pour l'entreprise. Par exemple, une telle menace est celle des rançongiciels qui utilisent le DNS pour l'échange de clés de chiffrement. Les attaquants exigent maintenant des rançons de plusieurs millions de dollars pour restaurer l'accès à vos données. Par exemple, la société Garmin a payé 10 millions de dollars.
Avec une configuration correcte, des NGFW peuvent interdire ou protéger l'utilisation de DNS-over-TLS (DoT) et peuvent être utilisés pour interdire l'utilisation de DNS-over-HTTPS (DoH), ce qui permet d'analyser tout le trafic DNS sur votre réseau.
Qu'est-ce que le DNS chiffré ?
Qu'est-ce que le DNS
Le système de noms de domaine (DNS) convertit des noms de domaine lisibles par l'homme (par exemple, l'adresse ) à une adresse IP (par exemple, 34.107.151.202). Lorsque l'utilisateur saisit un nom de domaine dans un navigateur web, le navigateur envoie une requête DNS à un serveur DNS, demandant l'adresse IP associée à ce nom de domaine. En réponse, le serveur DNS retourne l'adresse IP que ce navigateur utilisera.
Les requêtes et les réponses DNS sont transférées sur le réseau sous forme de texte ordinaire non chiffré, ce qui les rend vulnérables à l'espionnage ou à la modification des réponses, redirigeant ainsi le navigateur vers des serveurs malveillants. Le chiffrement DNS complique le suivi des requêtes DNS ou leur modification pendant la transmission. Le chiffrement des requêtes et des réponses DNS vous protège contre les attaques de type Man-in-the-Middle, tout en remplissant les mêmes fonctions que le protocole DNS traditionnel (système de noms de domaine) en texte clair.
Au cours des dernières années, deux protocoles de chiffrement DNS ont été mis en œuvre :
DNS-over-HTTPS (DoH)
DNS-over-TLS (DoT)
Ces protocoles ont un point commun : ils cachent délibérément les requêtes DNS de toute interception… y compris pour les responsables de la sécurité de l'organisation. Les protocoles utilisent principalement le protocole TLS (Transport Layer Security) pour établir une connexion chiffrée entre le client effectuant les requêtes et le serveur répondant aux requêtes DNS, via un port qui n'est généralement pas utilisé pour le trafic DNS.
La confidentialité des requêtes DNS est un grand avantage de ces protocoles. Cependant, ils posent des problèmes aux responsables de la sécurité qui doivent surveiller le trafic réseau et détecter et bloquer les connexions malveillantes. Étant donné que les protocoles diffèrent dans leur mise en œuvre, les méthodes d'analyse varieront entre DoH et DoT.
DNS over HTTPS (DoH)
DNS à l'intérieur de HTTPS
DoH utilise le port bien connu 443 pour HTTPS, pour lequel la RFC précise que le but est de "mélanger le trafic DoH avec d'autres trafic HTTPS dans la même connexion", "compliquer l'analyse du trafic DNS" et ainsi contourner les mesures de contrôle corporatif ( ). Le protocole DoH utilise le chiffrement TLS et la syntaxe des requêtes fournies par les standards courants HTTPS et HTTP/2, ajoutant les requêtes et réponses DNS au-dessus des requêtes HTTP standards.
Les risques liés à DoH
Si vous ne pouvez pas distinguer le trafic HTTPS normal des requêtes DoH, alors les applications au sein de votre organisation peuvent (et vont) contourner les paramètres DNS locaux en redirigeant les requêtes vers des serveurs tiers répondant aux requêtes DoH, ce qui contourne toute surveillance, c'est-à-dire annihile la possibilité de contrôler le trafic DNS. Idéalement, vous devez contrôler DoH en utilisant des fonctionnalités de déchiffrement HTTPS.
Et dans la dernière version de leurs navigateurs, et les deux entreprises travaillent à l'utilisation de DoH par défaut pour toutes les requêtes DNS. pour intégrer DoH dans ses systèmes d'exploitation. Le revers est que non seulement des entreprises respectées dans le développement de logiciels, mais aussi des cybercriminels ont commencé à utiliser DoH comme moyen de contourner les mesures traditionnelles de pare-feu d'entreprise. (Par exemple, consultez les articles suivants : , et .) Quoi qu'il en soit, tant le trafic DoH légitime que malveillant restera inaperçu, rendant l'organisation aveugle à l'utilisation malveillante de DoH comme canal de gestion de logiciels malveillants (C2) et de vol de données sensibles.
Assurer la visibilité et le contrôle du trafic DoH
Comme meilleure solution pour contrôler DoH, nous recommandons de configurer le NGFW pour déchiffrer le trafic HTTPS et bloquer le trafic DoH (nom de l'application : dns-over-https).
Tout d'abord, assurez-vous que le NGFW est configuré pour déchiffrer HTTPS, conformément au .
Ensuite, créez une règle pour le trafic de l'application « dns-over-https », comme illustré ci-dessous :
Règle Palo Alto Networks NGFW pour bloquer DNS-over-HTTPS
Comme alternative intermédiaire (si votre organisation n'a pas complètement mis en œuvre le déchiffrement HTTPS), le NGFW peut être configuré pour appliquer l'action « interdire » à l'identifiant de l'application « dns-over-https », mais l'effet sera limité à le blocage de certains serveurs DoH bien connus par leur nom de domaine, car sans le déchiffrement HTTPS, le trafic DoH ne peut pas être entièrement validé (voir. et recherchez la phrase « dns-over-https »).
DNS over TLS (DoT)
DNS dans TLS
Alors que le protocole DoH cherche à se fondre avec d'autres trafics sur le même port, le DoT utilise par défaut un port spécial réservé à ce seul objectif, interdisant même spécifiquement l'utilisation du même port pour le trafic DNS non chiffré traditionnel ( ).
Le protocole DoT utilise le protocole TLS pour assurer le chiffrement des requêtes standards du protocole DNS, utilisant le port bien connu 853 ( ). Le protocole DoT a été conçu pour simplifier aux organisations le blocage du trafic sur le port, soit en acceptant son utilisation, mais en incluant un déchiffrement sur ce port.
Risques associés au DoT
Google a implémenté le DoT dans son client , avec une configuration par défaut qui active automatiquement le DoT si disponible. Si vous avez évalué les risques et êtes prêts à utiliser le DoT à l'échelle de l'organisation, il est nécessaire que les administrateurs réseau autorisent explicitement le trafic sortant sur le port 853 à travers leur périmètre pour ce nouveau protocole.
Assurer la visibilité et le contrôle du trafic DoT
Comme bonne pratique pour le contrôle du DoT, nous recommandons l'une des options suivantes, selon les besoins de votre organisation :
Configurez le NGFW pour déchiffrer tout le trafic destiné au port 853. Grâce au déchiffrement du trafic, le DoT apparaîtra comme une application DNS à laquelle vous pouvez appliquer des actions, comme activer un abonnement pour le contrôle des domaines DGA ou pour le et anti-logiciels espions.
En alternative, vous pouvez bloquer complètement le trafic ‘dns-over-tls’ via le moteur App-ID sur le port 853. Il est généralement bloqué par défaut, aucune action n'est requise (sauf si vous avez spécifiquement autorisé l'application ‘dns-over-tls’ ou le trafic sur le port 853).
Source : habr.com
