Il y a quelques mois à peine, il y avait beaucoup de buzz parce que l'IETF dans un délai accéléré (environ un an) a accepté le DNS sur HTTPS (DoH) comme standard (
RFC-8484 ). Les discussions à ce sujet se poursuivent en raison de sa controverse. Mon opinion personnelle est que le DoH est bon pour la vie privée (si vous savez comment l'utiliser et faites confiance à votre fournisseur DNS) mais c'est un risque pour la sécurité des entreprises. DNS sur TLS (
DoT ) est une meilleure alternative pour les entreprises uniquement parce qu'il utilise un port TCP bien défini mais pour la confidentialité personnelle, il n'est pas bon pour la même raison (facile à bloquer).
Malgré les différences, DoH et DoT résolvent essentiellement le même problème - la sécurisation des communications DNS. Un acteur malveillant ne peut donc pas espionner le trafic DNS non chiffré et l'utiliser pour identifier un maillon faible et pour une attaque. Cela a été beaucoup discuté, mais il semble qu'un sujet ait été complètement oublié ou pas largement couvert - le transfert des zones de politique de réponse (RPZ).
Le pare-feu RPZ / DNS est une fonction de sécurité qui est prise en charge par plusieurs serveurs DNS: ISC Bind, PowerDNS, KnotDNS et les produits basés sur eux. RPZ est facile à implémenter, à prendre en charge et très évolutif avec un impact minimal sur les performances, de sorte qu'un serveur DNS peut être inclus dans la sécurité de l'organisation comme couche supplémentaire. Les zones de politique de réponse peuvent être maintenues localement ou téléchargées à partir de fournisseurs tiers comme Infoblox, SURBL, Farsight, etc. Le protocole de transfert de zone DNS standard est utilisé pour fournir des flux RPZ. Habituellement, les zones DNS sont transmises via TCP et signées par la clé TSIG, de sorte que le contenu ne peut pas être facilement modifié, mais il n'est pas crypté et cela peut potentiellement conduire à des problèmes plus graves. Si un acteur malveillant intercepte ce trafic, les indicateurs bloqués (domaines, IP) sont exposés et il est possible de contourner la couche de sécurité DNS. DNS RPS (Response Policy Service) est une nouvelle fonctionnalité ISC Bind qui résoudra probablement le problème, mais pour le moment, elle est mal documentée et non prise en charge par d'autres serveurs DNS.
Les RFC DoT et DoH ne limitent pas les types de demandes et les réponses peuvent être transférées sur un canal crypté, il est donc possible de tirer parti de ces normes pour les transferts de zone DNS, y compris les flux RPZ.
Avec ce blog, je suis heureux d'annoncer que
ioc2rpz nativement (aucun proxy ou logiciel supplémentaire requis) prend en charge DoT, de sorte que les flux RPZ peuvent être distribués en toute sécurité sur des canaux / Internet non sécurisés. Il s'agit de la première version (avec DoT), il existe donc certaines limitations: une seule demande par session et TLS 1.2 uniquement sont pris en charge, DNS Notify et TLS PIN ne sont pas pris en charge.
ioc2rpz.gui (une interface Web) ne prend pas en charge la configuration DoT en ce moment (c'est dans la feuille de route) mais la configuration est vraiment simple. Un serveur vérifie une configuration et démarre des écouteurs TLS si la configuration contient un certificat (et une clé privée).
MISE À JOUR:
Vous pouvez tester les flux de pare-feu
RPZ / DNS sur
ioc2rpz.net Le service est alimenté par ioc2rpz.