Router portátil que protege a privacidade: adicionar suporte DNS-Over-TLS ao OpenWRT (LEDE) com Unbound

Hoje, gostaríamos de partilhar um guia detalhado sobre como configurar DNS-Over-TLS com o GL-AR750 escrito por Junade Ali. Para quem ainda não sabe o que é DNS-Over-TLS, aqui ficam algumas curiosidades:

O ISP que espia a sua atividade pode recolher dados minuciosos sobre todos os seus passos na Internet e vendê-los a anunciantes e empresas de marketing. O DNS-Over-TLS é uma nova ferramenta de segurança da navegação web para proteger a privacidade dos utilizadores. Encripta os pedidos DNS e impede a escuta indevida e a manipulação de dados DNS através de ataques man-in-the-middle.

---

Se quiser passar diretamente às instruções, avance para a secção seguinte. Mas eu, tal como uma negociação TLS, sou bastante prolixo, por isso espero que aprecie esta introdução.

Imagine o seguinte cenário: estou num restaurante e preciso de ter uma conversa telefónica privada, mas a bateria do meu telemóvel está descarregada. Para resolver o problema, peço o telemóvel emprestado a um amigo e marco o número. Para proteger a privacidade, saio do restaurante. Quando termino a chamada, volto a entrar e devolvo o telemóvel.

Embora o telemóvel não guarde a conversa, mantém um registo do número marcado recentemente. Se o amigo que me emprestou o telemóvel quisesse, poderia ver facilmente a quem liguei, mesmo sem saber exatamente o assunto da conversa.

Por vezes, os dados sobre com quem falou revelam muito sobre a conversa. Se alguém ligar para uma linha de apoio emocional ou para um cobrador de dívidas, provavelmente poderá deduzir muito sobre a conversa a partir da identificação da chamada.

Quando navegamos na Internet, utilizamos encriptação para tentar proteger as nossas conversas. Ao ligar-se a um site por HTTPS, acende-se um cadeado verde no navegador, indicando que a conversa está encriptada de forma a tornar computacionalmente difícil para um adversário entre si e o servidor do site perceber o que estão a comunicar.

Já escrevi anteriormente sobre como, em determinadas circunstâncias, é possível remover esta encriptação e sobre as medidas que os sites podem adotar para o evitar. Infelizmente, existe um problema muito mais fundamental para a privacidade online.

Como é sabido na área de TI, antes de o navegador estabelecer uma ligação HTTP a um site, por exemplo cloudflare.com, o cliente precisa de fazer uma consulta DNS para descobrir o endereço IP a que deve ligar-se. O mesmo acontece com qualquer outro protocolo da camada de aplicação quando se utiliza um nome de anfitrião em vez de um endereço IP. Para uma introdução ao DNS, temos um artigo sobre os seus fundamentos no nosso Learning Centre.

Embora as tecnologias de encriptação do próprio HTTP existam há bastante tempo, só recentemente estas técnicas foram normalizadas para DNS. Se não sabe se o seu tráfego DNS está encriptado, o mais provável é que não esteja.

Na prática, isto significa que, ao ligar-se a um site com HTTPS, mesmo que a conversa esteja encriptada, alguém capaz de intercetar a ligação consegue ver que site procura e, dependendo da proteção do site, pode até manipular a resposta para o levar a comunicar com outro servidor.

Isto é particularmente útil para quem escuta indevidamente o tráfego, seja a rede que disponibiliza o hotspot Wi-Fi gratuito e quer vender os seus dados a anunciantes, seja o hacker a beber um café com leite enquanto interceta o tráfego da rede, ironicamente vestido com uma camisola preta com capuz e uma balaclava.

Ao mudar o seu resolvedor DNS para o DNS Resolver da Cloudflare, obtém uma navegação mais rápida e garante que quem gere o resolvedor não vende esses dados para o direcionar com publicidade. No entanto, embora o Cloudflare Resolver suporte DNS-over-HTTPS e DNS-over-TLS, para garantir que a ligação entre si e o Cloudflare Resolver está encriptada poderá ter de realizar passos de configuração adicionais, como ativar um cliente DNS over HTTPS.

Este artigo explica como configurar um router OpenWRT para encriptar o tráfego de saída para o Cloudflare Resolver. É particularmente útil para proteger o tráfego de dispositivos domésticos que podem não suportar protocolos DNS encriptados, como o televisor ou uma torradeira com IoT. Embora os clientes locais ainda possam substituir explicitamente o resolvedor DNS local do router, muitos utilizam-no por predefinição.

OpenWRT (LEDE)

No fim de semana anterior à escrita deste artigo, encomendei um novo router sem fios, o GL.iNet GL-AR750. Tem um formato muito pequeno, é apresentado como um «router de viagem» e pode funcionar como repetidor Wi-Fi e como router Wi-Fi tradicional. O lado mais comprido do router tem aproximadamente o comprimento do meu dedo indicador:

Não encomendei este router apenas pelo formato: também inclui OpenWRT pré-instalado, um sistema operativo Linux embebido muito adequado a routers. Em maio de 2016, foi criada uma derivação do OpenWRT chamada LEDE (Linux Embedded Development Environment), que voltou a integrar-se no projeto OpenWRT em janeiro de 2018.

Se não tem um router com LEDE pré-instalado, pode acompanhar este artigo noutro router que permita instalar o firmware OpenWRT. Pode encontrar mais informações na página OpenWRT Support Devices. No entanto, tenha em atenção que, dependendo do dispositivo, isto pode implicar algum risco.

Suporte para DNS-over-TLS (ou a falta dele)

O router com que estou a experimentar tem uma opção para configurar o resolvedor DNS a montante que será utilizado quando uma consulta não estiver na cache do resolvedor interno. Este resolvedor local é depois sugerido aos clientes que se ligam ao router.

Para efeitos de teste, através da interface web, consigo configurar o router para utilizar 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 e 2606:4700:4700::1001 como servidores DNS a montante (com os endereços IPv6 atualizados se a rede não os suportar):

Ao ligar a porta WAN do router ao meu computador, consigo capturar o tráfego à saída do router com o Wireshark, antes de seguir para a WAN. Quando uma consulta DNS não está na cache do router, é encaminhada para 1.1.1.1. Como o router envia estas consultas sem encriptação, em vez de utilizar DNS-over-TLS, consigo ver as consultas DNS a circular pela Internet em formato não encriptado:

Embora o Cloudflare Resolver suporte DNS-over-TLS, infelizmente o meu router não o suporta e envia todas as consultas sem encriptação.

Configurar DNS-Over-TLS

Por predefinição, o LEDE utiliza Dnsmasq pré-instalado como resolvedor interno e, por isso, não suporta DNS-over-TLS. Para encriptar os pedidos, vamos substituir o Dnsmasq por Unbound e odhcpd. Baseei os passos que vou seguir na documentação, muito útil, do pacote OpenWRT Unbound.

Antes de começar, precisamos de aceder ao router por SSH. Se for pedida uma palavra-passe, provavelmente será a mesma que definiu para o portal web:

O LEDE utiliza ​opkg​ como gestor de pacotes. Primeiro, vamos atualizar a lista de pacotes e depois instalar o Unbound com Unbound-Control e a versão completa do odhcpd:

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Pode também instalar a aplicação Luci para Unbound se quiser controlá-lo através da interface padrão.

opkg install luci-app-unbound

Como o meu router não utiliza atualmente LEDE sem modificações, a sua interface não seria alterada se instalasse esta aplicação, e não testei pessoalmente este módulo.

Com o Unbound instalado, podemos acrescentar configurações para garantir que utiliza 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 e 2606:4700:4700::1001 como resolvedores DNS com encriptação TLS. Fi-lo acrescentando configurações a /etc/unbound/unbound_ext.conf através do Vim:

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

No ficheiro de configuração do Unbound em /etc/config/unbound, acrescentei alguns parâmetros necessários, conforme descrito na documentação do pacote. No meu caso, fiz uma cópia de segurança do ficheiro de configuração e utilizei simplesmente o seguinte:

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

Se o ficheiro tiver parâmetros adicionais, certifique-se de que nenhum substitui os valores definidos, tendo especial cuidado com o parâmetro unbound_control em particular.

Também combinei a configuração seguinte com /etc/config/dhcp (deixando algumas entradas existentes inalteradas):

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

Por fim, podemos ativar o arranque automático do Unbound e iniciá-lo:

service unbound enable
service unbound start

Aqui está a prova: ao intercetar consultas DNS entre o router e a Internet, vemos que estão encriptadas com TLS v1.2:

Conclusão

Neste artigo, vimos como a encriptação do tráfego DNS pode ajudar a proteger a privacidade da navegação na Internet. Ao substituir o Dnsmasq pelo Unbound, permitimos que o OpenWRT utilize DNS-over-TLS para ajudar a encriptar o tráfego web.

---

Agradecemos a Junade Ali por nos permitir partilhar este artigo no nosso site. O artigo foi originalmente publicado no site da Cloudflare a 9 de abril de 2018: https://blog.cloudflare.com/dns-over-tls-for-openwrt/