Minimiser les risques liés à l’utilisation de DoH et DoT
Protection DoH et DoT
Contrôlez-vous votre trafic DNS ? Les organisations investissent beaucoup de temps, d’argent et d’efforts dans la sécurisation de leurs réseaux. Cependant, un domaine qui ne reçoit souvent pas suffisamment d’attention est le DNS.
Un bon aperçu des risques que présente le DNS est à la conférence Infosécurité.
31 % des classes de ransomwares interrogées utilisaient le DNS pour l'échange de clés.
31 % des classes de ransomwares interrogées utilisaient le DNS pour l'échange de clés.
Le problème est grave. Selon le laboratoire de recherche de l'unité 42 de Palo Alto Networks, environ 85 % des logiciels malveillants utilisent le DNS pour établir un canal de commande et de contrôle, permettant aux attaquants d'injecter facilement des logiciels malveillants dans votre réseau et de voler des données. Depuis sa création, le trafic DNS est en grande partie non chiffré et peut être facilement analysé par les mécanismes de sécurité NGFW.
De nouveaux protocoles DNS sont apparus visant à accroître la confidentialité des connexions DNS. Ils sont activement pris en charge par les principaux fournisseurs de navigateurs et d'autres fournisseurs de logiciels. Le trafic DNS crypté va bientôt commencer à croître dans les réseaux d'entreprise. Le trafic DNS crypté qui n'est pas correctement analysé et résolu par les outils présente un risque de sécurité pour une entreprise. Par exemple, une telle menace concerne les cryptolockers qui utilisent le DNS pour échanger des clés de chiffrement. Les attaquants réclament désormais une rançon de plusieurs millions de dollars pour rétablir l'accès à vos données. Garmin, par exemple, a payé 10 millions de dollars.
Lorsqu'ils sont correctement configurés, les NGFW peuvent refuser ou protéger l'utilisation du DNS-over-TLS (DoT) et peuvent être utilisés pour refuser l'utilisation du DNS-over-HTTPS (DoH), permettant ainsi d'analyser tout le trafic DNS sur votre réseau.
Qu’est-ce que le DNS crypté ?
Qu'est-ce que le DNS
Le système de noms de domaine (DNS) résout les noms de domaine lisibles par l'homme (par exemple, l'adresse ) aux adresses IP (par exemple, 34.107.151.202). Lorsqu'un utilisateur saisit un nom de domaine dans un navigateur Web, le navigateur envoie une requête DNS au serveur DNS, demandant l'adresse IP associée à ce nom de domaine. En réponse, le serveur DNS renvoie l'adresse IP que ce navigateur utilisera.
Les requêtes et réponses DNS sont envoyées sur le réseau en texte brut, non crypté, ce qui le rend vulnérable à l'espionnage ou à la modification de la réponse et à la redirection du navigateur vers des serveurs malveillants. Le cryptage DNS rend difficile le suivi ou la modification des requêtes DNS pendant la transmission. Le cryptage des requêtes et des réponses DNS vous protège des attaques Man-in-the-Middle tout en exécutant les mêmes fonctionnalités que le protocole DNS (Domain Name System) traditionnel en texte clair.
Au cours des dernières années, deux protocoles de cryptage DNS ont été introduits :
-
DNS sur HTTPS (DoH)
-
DNS sur TLS (DoT)
Ces protocoles ont un point commun : ils cachent délibérément les requêtes DNS à toute interception… et aux agents de sécurité de l’organisation également. Les protocoles utilisent principalement TLS (Transport Layer Security) pour établir une connexion cryptée entre un client effectuant des requêtes et un serveur résolvant les requêtes DNS sur un port qui n'est normalement pas utilisé pour le trafic DNS.
La confidentialité des requêtes DNS est un gros plus de ces protocoles. Cependant, ils posent des problèmes aux agents de 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 diffèrent entre le DoH et le DoT.
DNS sur HTTPS (DoH)
DNS dans HTTPS
DoH utilise le port bien connu 443 pour HTTPS, pour lequel la RFC indique spécifiquement que l'intention est de « mélanger le trafic DoH avec d'autres trafics HTTPS sur la même connexion », « de rendre difficile l'analyse du trafic DNS » et ainsi de contourner les contrôles de l'entreprise. ( ). Le protocole DoH utilise le cryptage TLS et la syntaxe de requête fournie par les normes communes HTTPS et HTTP/2, ajoutant des requêtes et des réponses DNS en plus des requêtes HTTP standard.
Risques associés au DoH
Si vous ne parvenez pas à distinguer le trafic HTTPS normal des requêtes DoH, les applications au sein de votre organisation peuvent (et contourneront) 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 détruit la possibilité de contrôler le trafic DNS. Idéalement, vous devriez contrôler DoH à l’aide des fonctions de décryptage HTTPS.
И dans la dernière version de leurs navigateurs, et les deux sociétés s'efforcent d'utiliser DoH par défaut pour toutes les requêtes DNS. sur l'intégration de DoH dans leurs systèmes d'exploitation. L’inconvénient est que non seulement les éditeurs de logiciels réputés, mais aussi les attaquants ont commencé à utiliser DoH comme moyen de contourner les mesures de pare-feu traditionnelles des entreprises. (Par exemple, consultez les articles suivants : , и .) Dans les deux cas, le trafic DoH, bon comme malveillant, ne sera pas détecté, laissant l'organisation aveugle à l'utilisation malveillante de DoH comme canal pour contrôler les logiciels malveillants (C2) et voler des données sensibles.
Assurer la visibilité et le contrôle du trafic du DoH
En tant que meilleure solution pour le contrôle DoH, nous vous recommandons de configurer 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 NGFW est configuré pour déchiffrer HTTPS, selon .
Deuxièmement, créez une règle pour le trafic des applications « dns-over-https », comme indiqué ci-dessous :
Règle NGFW de Palo Alto Networks pour bloquer le DNS sur HTTPS
Comme alternative provisoire (si votre organisation n'a pas entièrement implémenté le déchiffrement HTTPS), NGFW peut être configuré pour appliquer une action « refuser » à l'ID d'application « DNS-over-https », mais l'effet sera limité au blocage de certains puits. serveurs DoH connus par leur nom de domaine, donc sans décryptage HTTPS, le trafic DoH ne peut pas être entièrement inspecté (voir et recherchez "dns-over-https").
DNS sur TLS (DoT)
DNS dans TLS
Alors que le protocole DoH a tendance à se mélanger avec d'autres trafics sur le même port, DoT utilise par défaut un port spécial réservé à ce seul but, interdisant même spécifiquement que le même port soit utilisé par le trafic DNS non chiffré traditionnel ( ).
Le protocole DoT utilise TLS pour fournir un cryptage qui encapsule les requêtes du protocole DNS standard, le trafic utilisant le port bien connu 853 ( ). Le protocole DoT a été conçu pour permettre aux organisations de bloquer plus facilement le trafic sur un port, ou d'accepter le trafic mais d'activer le déchiffrement sur ce port.
Risques associés au DoT
Google a implémenté DoT dans son client , avec le paramètre par défaut pour utiliser automatiquement DoT si disponible. Si vous avez évalué les risques et êtes prêt à utiliser DoT au niveau organisationnel, vous devez alors demander aux administrateurs réseau d'autoriser 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
En tant que bonne pratique pour le contrôle DoT, nous recommandons l'une des solutions ci-dessus, en fonction des exigences de votre organisation :
-
Configurez NGFW pour décrypter tout le trafic pour le port de destination 853. En déchiffrant le trafic, DoT apparaîtra comme une application DNS à laquelle vous pourrez appliquer n'importe quelle action, telle que l'activation de l'abonnement. pour contrôler un domaine DGA ou un domaine existant et anti-spyware.
-
Une alternative consiste à demander au moteur App-ID de bloquer complètement le trafic « dns-over-tls » sur le port 853. Ceci est généralement bloqué par défaut, aucune action n'est requise (sauf si vous autorisez spécifiquement l'application ou le trafic de port « dns-over-tls » 853).
Source: habr.com