{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimiser les risques li\u00e9s \u00e0 DNS-over-TLS (DoT) et DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimiserMinimisation des risques li\u00e9s \u00e0 l'utilisation de DoH et DoT<\/p>\n

Protection contre DoH et DoT<\/h2>\n

Contr\u00f4lez-vous votre trafic DNS ? Les organisations investissent beaucoup de temps, d'argent et d'efforts pour s\u00e9curiser leurs r\u00e9seaux. Cependant, l'un des domaines souvent n\u00e9glig\u00e9s est le DNS. <\/p>\n

Une bonne vue d'ensemble des risques li\u00e9s au DNS est la pr\u00e9sentation de Verisign<\/a><\/noindex> \u00e0 la conf\u00e9rence Infosecurity. <\/p>\n

\"Minimiser31 % des types de ransomwares examin\u00e9s utilisaient le DNS pour l'\u00e9change de cl\u00e9s. Conclusions de l'\u00e9tude<\/p>\n

31 % des types de ransomwares examin\u00e9s utilisaient le DNS pour l'\u00e9change de cl\u00e9s.<\/p>\n

Le probl\u00e8me est s\u00e9rieux. Selon le laboratoire de recherche Palo Alto Networks Unit 42, environ 85 % des logiciels malveillants utilisent le DNS pour \u00e9tablir un canal de commande et de contr\u00f4le, permettant aux cybercriminels d'infiltrer facilement des logiciels malveillants dans votre r\u00e9seau, ainsi que de voler des donn\u00e9es. Depuis sa cr\u00e9ation, le trafic DNS a principalement \u00e9t\u00e9 non chiffr\u00e9 et facilement analysable par des syst\u00e8mes de protection NGFW. <\/p>\n

De nouveaux protocoles DNS ont \u00e9merg\u00e9 pour am\u00e9liorer la confidentialit\u00e9 des connexions DNS. Ils sont activement soutenus par les principaux fournisseurs de navigateurs et d'autres fournisseurs de logiciels. Bient\u00f4t, nous assisterons \u00e0 une augmentation du trafic DNS chiffr\u00e9 dans les r\u00e9seaux d'entreprise. Le trafic DNS chiffr\u00e9, qui n'est pas correctement analys\u00e9 et autoris\u00e9, constitue une menace pour la s\u00e9curit\u00e9 de l'entreprise. Par exemple, les ransomwares utilisent DNS pour l'\u00e9change de cl\u00e9s de cryptage. Les attaquants demandent maintenant des ran\u00e7ons de plusieurs millions de dollars pour restaurer l'acc\u00e8s \u00e0 vos donn\u00e9es. Dans le cas de l'entreprise Garmin, par exemple, 10 millions de dollars ont \u00e9t\u00e9 pay\u00e9s.<\/p>\n

Avec une configuration correcte, des NGFW peuvent interdire ou prot\u00e9ger l'utilisation de DNS-over-TLS (DoT) et peuvent \u00eatre utilis\u00e9s pour interdire l'utilisation de DNS-over-HTTPS (DoH), ce qui permet d'analyser tout le trafic DNS sur votre r\u00e9seau.<\/p>\n

Qu'est-ce que le DNS chiffr\u00e9 ?<\/h2>\n

Qu'est-ce que le DNS<\/p>\n

Le syst\u00e8me de noms de domaine (DNS) convertit des noms de domaine lisibles par l'homme (par exemple, l'adresse www.paloaltonetworks.com<\/a><\/noindex> ) \u00e0 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\u00eate DNS \u00e0 un serveur DNS, demandant l'adresse IP associ\u00e9e \u00e0 ce nom de domaine. En r\u00e9ponse, le serveur DNS retourne l'adresse IP que ce navigateur utilisera.<\/p>\n

Les requ\u00eates et les r\u00e9ponses DNS sont transf\u00e9r\u00e9es sur le r\u00e9seau sous forme de texte ordinaire non chiffr\u00e9, ce qui les rend vuln\u00e9rables \u00e0 l'espionnage ou \u00e0 la modification des r\u00e9ponses, redirigeant ainsi le navigateur vers des serveurs malveillants. Le chiffrement DNS complique le suivi des requ\u00eates DNS ou leur modification pendant la transmission. Le chiffrement des requ\u00eates et des r\u00e9ponses DNS vous prot\u00e8ge contre les attaques de type Man-in-the-Middle, tout en remplissant les m\u00eames fonctions que le protocole DNS traditionnel (syst\u00e8me de noms de domaine) en texte clair. <\/p>\n

Au cours des derni\u00e8res ann\u00e9es, deux protocoles de chiffrement DNS ont \u00e9t\u00e9 mis en \u0153uvre :<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    Ces protocoles partagent un point commun : ils cachent intentionnellement les requ\u00eates DNS \u00e0 tout interception\u2026 y compris de la part des responsables de la s\u00e9curit\u00e9 de l'organisation. Les protocoles utilisent principalement TLS (Transport Layer Security) pour \u00e9tablir une connexion chiffr\u00e9e entre le client qui \u00e9met les requ\u00eates et le serveur qui r\u00e9sout les requ\u00eates DNS, par une port qui est g\u00e9n\u00e9ralement pas utilis\u00e9 pour le trafic DNS.<\/p>\n

    La confidentialit\u00e9 des requ\u00eates DNS est un grand avantage de ces protocoles. Cependant, ils posent des probl\u00e8mes aux responsables de la s\u00e9curit\u00e9 qui doivent surveiller le trafic r\u00e9seau et d\u00e9tecter et bloquer les connexions malveillantes. \u00c9tant donn\u00e9 que les protocoles diff\u00e8rent dans leur mise en \u0153uvre, les m\u00e9thodes d'analyse varieront entre DoH et DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"MinimiserDNS \u00e0 l'int\u00e9rieur de HTTPS<\/p>\n

    DoH utilise le port bien connu 443 pour HTTPS, pour lequel la RFC pr\u00e9cise que le but est de \"m\u00e9langer le trafic DoH avec d'autres trafic HTTPS dans la m\u00eame connexion\", \"compliquer l'analyse du trafic DNS\" et ainsi contourner les mesures de contr\u00f4le corporatif ( RFC 8484 DoH, section 8.1<\/a><\/noindex> ). Le protocole DoH utilise le chiffrement TLS et la syntaxe des requ\u00eates fournies par les standards courants HTTPS et HTTP\/2, ajoutant les requ\u00eates et r\u00e9ponses DNS au-dessus des requ\u00eates HTTP standards.<\/p>\n

    Les risques li\u00e9s \u00e0 DoH<\/h2>\n

    Si vous ne pouvez pas distinguer le trafic HTTPS normal des requ\u00eates DoH, alors les applications au sein de votre organisation peuvent (et vont) contourner les param\u00e8tres DNS locaux en redirigeant les requ\u00eates vers des serveurs tiers r\u00e9pondant aux requ\u00eates DoH, ce qui contourne toute surveillance, c'est-\u00e0-dire annihile la possibilit\u00e9 de contr\u00f4ler le trafic DNS. Id\u00e9alement, vous devez contr\u00f4ler DoH en utilisant des fonctionnalit\u00e9s de d\u00e9chiffrement HTTPS. <\/p>\n

    Et Google et Mozilla ont impl\u00e9ment\u00e9 des capacit\u00e9s DoH<\/a><\/noindex> dans la derni\u00e8re version de leurs navigateurs, et les deux entreprises travaillent \u00e0 l'utilisation de DoH par d\u00e9faut pour toutes les requ\u00eates DNS. Microsoft d\u00e9veloppe \u00e9galement des plans<\/a><\/noindex> pour int\u00e9grer DoH dans ses syst\u00e8mes d'exploitation. Le revers est que non seulement des entreprises respect\u00e9es dans le d\u00e9veloppement de logiciels, mais aussi des cybercriminels ont commenc\u00e9 \u00e0 utiliser DoH comme moyen de contourner les mesures traditionnelles de pare-feu d'entreprise. (Par exemple, consultez les articles suivants : PsiXBot utilise maintenant Google DoH<\/a><\/noindex> , PsiXBot continue de se d\u00e9velopper avec une infrastructure DNS mise \u00e0 jour<\/a><\/noindex> et analyse du backdoor Godlua<\/a><\/noindex> .) Quoi qu'il en soit, tant le trafic DoH l\u00e9gitime que malveillant restera inaper\u00e7u, rendant l'organisation aveugle \u00e0 l'utilisation malveillante de DoH comme canal de gestion de logiciels malveillants (C2) et de vol de donn\u00e9es sensibles.<\/p>\n

    Assurer la visibilit\u00e9 et le contr\u00f4le du trafic DoH<\/h2>\n

    Comme meilleure solution pour contr\u00f4ler DoH, nous recommandons de configurer le NGFW pour d\u00e9chiffrer le trafic HTTPS et bloquer le trafic DoH (nom de l'application : dns-over-https). <\/p>\n

    Tout d'abord, assurez-vous que le NGFW est configur\u00e9 pour d\u00e9chiffrer HTTPS, conform\u00e9ment au guide des meilleures pratiques de d\u00e9chiffrement<\/a><\/noindex>.<\/p>\n

    Ensuite, cr\u00e9ez une r\u00e8gle pour le trafic de l'application \u00ab dns-over-https \u00bb, comme illustr\u00e9 ci-dessous :<\/p>\n

    \"MinimiserR\u00e8gle Palo Alto Networks NGFW pour bloquer DNS-over-HTTPS<\/p>\n

    Comme alternative interm\u00e9diaire (si votre organisation n'a pas compl\u00e8tement mis en \u0153uvre le d\u00e9chiffrement HTTPS), le NGFW peut \u00eatre configur\u00e9 pour appliquer l'action \u00ab interdire \u00bb \u00e0 l'identifiant de l'application \u00ab dns-over-https \u00bb, mais l'effet sera limit\u00e9 \u00e0 le blocage de certains serveurs DoH bien connus par leur nom de domaine, car sans le d\u00e9chiffrement HTTPS, le trafic DoH ne peut pas \u00eatre enti\u00e8rement valid\u00e9 (voir.  Applipedia de Palo Alto Networks<\/a><\/noindex>   et recherchez la phrase \u00ab dns-over-https \u00bb).<\/p>\n

    DNS over TLS (DoT)<\/h2>\n

    \"MinimiserDNS dans TLS<\/p>\n

    Alors que le protocole DoH cherche \u00e0 se fondre avec d'autres trafics sur le m\u00eame port, le DoT utilise par d\u00e9faut un port sp\u00e9cial r\u00e9serv\u00e9 \u00e0 ce seul objectif, interdisant m\u00eame sp\u00e9cifiquement l'utilisation du m\u00eame port pour le trafic DNS non chiffr\u00e9 traditionnel ( RFC 7858, Section 3.1<\/a><\/noindex> ).<\/p>\n

    Le protocole DoT utilise le protocole TLS pour assurer le chiffrement des requ\u00eates standards du protocole DNS, utilisant le port bien connu 853 ( RFC 7858, section 6<\/a><\/noindex> ). Le protocole DoT a \u00e9t\u00e9 con\u00e7u pour faciliter aux organisations le blocage du trafic sur ce port, soit en acceptant son utilisation, mais en incluant la d\u00e9chiffrement sur ce port.<\/p>\n

    Risques associ\u00e9s au DoT<\/h2>\n

    Google a impl\u00e9ment\u00e9 le DoT dans son client Android 9 Pie et versions ult\u00e9rieures<\/a><\/noindex> , avec une configuration par d\u00e9faut qui active automatiquement le DoT si disponible. Si vous avez \u00e9valu\u00e9 les risques et \u00eates pr\u00eats \u00e0 utiliser le DoT \u00e0 l'\u00e9chelle de l'organisation, il est n\u00e9cessaire que les administrateurs r\u00e9seau autorisent explicitement le trafic sortant sur le port 853 \u00e0 travers leur p\u00e9rim\u00e8tre pour ce nouveau protocole.<\/p>\n

    Assurer la visibilit\u00e9 et le contr\u00f4le du trafic DoT<\/h2>\n

    Comme bonne pratique pour le contr\u00f4le du DoT, nous recommandons l'une des options suivantes, selon les besoins de votre organisation :<\/p>\n