Particularmente já perdi as contas sobre quantas vezes já presenciei discussões sobre a eficiência e segurança de se implementar bloqueio de conteúdos na web, numa rede de computadores, baseando-se apenas em ferramentas que o fazem através do protocolo DNS. A ideia sempre desperta muito interesse em grande parte dos sysadmins que estão configurando firewalls e buscam uma forma mais ‘rápida e didática’ de bloquear acesso a determinados sites simplesmente restringindo a pesquisa de nomes de domínio para os usuários e negando o acesso antes mesmo da conexão HTTP/HTTPS em si acontecer.
Em teoria, parece realmente muito bom. Existem várias ferramentas (gratuitas e comerciais) que oferecem este tipo de serviço. Algumas delas realmente possuem recursos interessantes como: versões para Linux/FreeBSD/pfSense (comumente usados no papel de firewall), autenticação em PDCs, criação de ACLs por grupos de usuários, relatórios de acesso integrados, etc..
Vídeo demonstrando DNS over HTTPS com Firefox 60
Mas na prática, a suposta simplicidade da metodologia não é tão eficiente quanto parece. Existe até mesmo uma documentação oficial da IETF falando sobre métodos que fazem DNS over HTTPS, ou seja, transportam conexões DNS por ‘dentro’ de conexões HTTPS – o que de cara, já impacta negativamente na eficiência este tipo de bloqueio.
Tela de configuração dos parâmetros de DNS sob HTTPS no Firefox
Várias ferramentas gratuitas ou livres, disponíveis na Internet para qualquer usuário minimamente antenado, exploram este tipo de metodologia para burlar estes esquemas frágeis de controle. A própria Google disponibiliza uma API para se implementar DNS over HTTPS e agora, basicamente qualquer “estudante do ensino médio” que use o Firefox 60 (ou posterior), consegue burlar os bloqueios de conteúdo por DNS como é demonstrado de forma muito didática no vídeo acima.
Mesmo a implementação de eventuais sistemas de IDS/IPS como o Snort ou Suricata, por exemplo, afim de melhorar o controle e coibir o DNS over HTTPS antes que ele aconteça, não é eficiente neste arranjo. Uma vez que o túnel HTTPS esteja fechado, o IDS não vai mais conseguir perceber e coibir a conexão, já que a mesma está criptografada.
A grande questão aqui, é que basicamente qualquer ferramenta de bloqueio de conteúdo por DNS precisa que as portas TCP 80/443 (de navegação web) continuem abertas no seu firewall, o que incorre num pecado original. Em resumo, entenda que esta metodologia é bastante frágil e por esta razão tende a ser ineficiente!
