Voltaire Mobile Shield: um escudo DNS inteligente para proteger os Androids da rede doméstica

1. O problema: os telemóveis são computadores — e os ataques começam frequentemente por um nome

Um smartphone é hoje um terminal bancário, um arquivo de correspondência, uma carteira digital e uma plataforma de autenticação. A maior parte das aplicações comunica com serviços remotos através de nomes de domínio. Antes de estabelecer muitas dessas ligações, o sistema precisa de transformar um nome legível num endereço IP: é essa a função do Domain Name System (DNS).

Se um domínio está associado a phishing, distribuição de malware ou infra-estruturas de comando e controlo, bloquear a sua resolução pode impedir determinadas ligações antes de o tráfego chegar ao destino. É uma camada de prevenção simples, mas útil. Não substitui o sistema de segurança do Android, nem garante que uma ameaça desconhecida seja detectada.

O ponto de partida do projecto foi rigoroso: proteger apenas os smartphones da casa, sem alterar o DNS normal do servidor, as máquinas virtuais, o WordPress ou a rede de câmaras IP. O desafio era, por isso, menos «instalar uma lista negra» e mais desenhar um serviço autónomo, controlável e reversível.

2. Uma decisão de arquitectura: separar para não perturbar

O servidor Ubuntu Voltaire já prestava vários serviços. Em vez de aplicar bloqueios globalmente à resolução DNS, foi configurado um segundo endereço de serviço no mesmo segmento de rede. O DNS original manteve-se em 192.168.10.18; a instância protegida passou a escutar em 192.168.10.19:53.

TELEMÓVEIS ANDROID (clientes autorizados)
                 |
                 v
       DNS dedicado: 192.168.10.19
           dnsmasq / Shield 3.0
              |          |
              |          +--> domínio nas listas --> 0.0.0.0 / ::
              |
              +--> domínio permitido --> Quad9 --> resposta DNS

COMPUTADORES / SERVIÇOS DO VOLTAIRE
                 |
                 v
       DNS normal: 192.168.10.18
       (sem as listas locais do Shield)

A independência das duas instâncias evita efeitos colaterais difíceis de diagnosticar. O UFW limita o acesso ao DNS protegido aos IPs autorizados; os telemóveis que devem ser protegidos apontam explicitamente para esse resolvedor. O isolamento por IP do cliente é uma política de acesso e não uma imposição universal de DNS: dispositivos ou aplicações que escolham outro caminho poderão contornar a filtragem.

3. A inteligência de ameaças: combinar fontes sem somar ilusões

A versão 2.4.2 continha uma lista focada em phishing. Na versão 3.0, o motor conserva a Phishing Army e acrescenta a HaGeZi Threat Intelligence Feeds — Mini. Esta última procura cobrir domínios relacionados com malware, fraude, phishing, cryptojacking e infra-estruturas maliciosas. O resolvedor externo escolhido é o Quad9 Secure, que também aplica políticas de bloqueio de ameaças conhecidas.

Os dois feeds partilhavam, naquela execução, 65 706 domínios. A contagem correcta não é, portanto, a soma aritmética das listas. Também não deve ser interpretada como «263 mil ataques impedidos»: representa nomes sujeitos a política de filtragem, não incidentes de segurança observados.

A selecção privilegia fontes orientadas para ameaças. Não foram acrescentadas, por defeito, listas agressivas de publicidade e rastreamento. Essa contenção ajuda a reduzir falsos positivos e interrupções em aplicações legítimas, como redes sociais, serviços de autenticação ou plataformas de trabalho.

4. O mecanismo: bloquear A e AAAA sem inspeccionar comunicações

O gestor normaliza os domínios, verifica a integridade básica dos feeds, gera regras locais do dnsmasq e aplica-as de modo controlado. A sintaxe de bloqueio usada é address=/dominio/#, compatível com a versão do dnsmasq utilizada no Voltaire: as consultas A recebem 0.0.0.0 e as AAAA recebem ::. O manual oficial do dnsmasq documenta o comportamento dos endereços locais e do registo de consultas.

address=/dominio-malicioso.example/#

# Comportamento pretendido:
# A    -> 0.0.0.0
# AAAA -> ::

Os domínios permitidos são enviados ao Quad9 através de DNS convencional, segundo a configuração actual. Este processo não faz inspecção TLS, não examina ficheiros descarregados e não lê o conteúdo das páginas HTTPS. A defesa actua sobre a resolução do nome, não sobre todos os pacotes do dispositivo.

5. Robustez operacional: actualizar, testar e, se necessário, recuar

Um filtro DNS que arranque mal pode interromper o acesso à Internet. Por isso, a actualização não consiste simplesmente em substituir um ficheiro e esperar pelo melhor. O processo de instalação e actualização do Shield 3.0 incorpora várias salvaguardas:

• Pré-visualização: descarregamento e validação das fontes sem alterar as regras activas.
• Normalização e deduplicação: rejeição de entradas inválidas e geração de um conjunto consistente.
• Substituição atómica: preparação de novo ficheiro de regras e troca controlada.
• Validação de sintaxe: execução do teste do dnsmasq antes da aceitação da nova configuração.
• Testes DNS após aplicação: bloqueio A/AAAA e resolução normal de um domínio legítimo.
• Reversão: tentativa de reposição da lista anterior quando uma etapa falha, com sinalização explícita se a recuperação também falhar.
• Agendamento: actualizações automáticas através de uma unidade systemd timer.

O serviço protegido pode ser reiniciado sem reiniciar o DNS principal nem os restantes componentes do Voltaire. Essa fronteira de falha, deliberadamente estreita, é uma das características mais importantes da solução.

6. A prova experimental: tráfego real, não apenas um serviço «activo»

Na sessão de validação, primeiro foi confirmada a resolução distinta dos dois DNS. Depois, com um Android a utilizar a instância protegida, o tcpdump registou consultas A e AAAA dirigidas a 192.168.10.19. O teste de bloqueio do domínio amiprotected.it, presente na lista nessa data, produziu as respostas esperadas:

$ dig @192.168.10.19 amiprotected.it A +short
0.0.0.0

$ dig @192.168.10.19 amiprotected.it AAAA +short
::

$ dig @192.168.10.19 linkedin.com A +short
130.211.32.14

$ systemctl is-active voltaire-mobile-shield-android
active

A captura real mostrou ainda o pedido do telemóvel e a resposta de bloqueio do Shield na mesma transacção DNS. O resultado demonstra que aquele cliente usou o DNS filtrado e recebeu o bloqueio esperado. Não demonstra que toda a actividade futura do Android seja forçada a passar pelo mesmo caminho.

7. NiceGUI: um centro de controlo que não compromete o DNS

A segunda fase do projecto acrescentou um Dashboard em Python e NiceGUI. A interface apresenta o estado do serviço DNS, fontes e contagens, actualizações, histórico de consultas, bloqueios observados, clientes e gestão de excepções. A recolha usa log-queries=extra do dnsmasq e correlação por identificador de transacção para não confundir uma consulta com várias linhas de registo.

Os dados de observabilidade são guardados localmente em SQLite, com retenção aplicacional de sete dias. O journald conserva os seus próprios registos segundo a política do sistema — um pormenor importante para quem procura gerir a privacidade e o espaço em disco. Uma consulta DNS bloqueada é um evento técnico, não uma prova de que alguém tentou atacar o utilizador.

Para reduzir a superfície de ataque, o dashboard escuta apenas em 127.0.0.1:8097, exige autenticação e recomenda acesso através de túnel SSH. A versão corrigida utiliza um auxiliar de operações restritas por socket Unix, em vez de tentar escalar privilégios directamente dentro do processo web. Um erro no dashboard não deve derrubar a resolução DNS dos Androids.

# Exemplo de acesso remoto privado ao dashboard
ssh -N -L 18097:127.0.0.1:8097 utilizador@servidor-voltaire

# Abrir no navegador local:
http://127.0.0.1:18097

8. Excepções e falsos positivos: segurança sem sacrificar a utilização

Nenhuma lista de ameaças é infalível. Serviços legítimos podem aparecer indevidamente numa fonte, ou uma aplicação pode depender de subdomínios que partilham infra-estrutura com conteúdos suspeitos. O Shield permite manter uma allowlist e aplicá-la através do gestor, com validação posterior.

A regra operacional é simples: libertar apenas o domínio estritamente necessário, depois de confirmar que se trata de um falso positivo. Uma excepção local também não garante que o Quad9 autorize o mesmo domínio: a política do resolvedor externo é independente. A depuração não se faz apagando o escudo inteiro à primeira dificuldade.

9. Raspberry Pi Edition: a segurança passa a ter uma máquina própria

O passo seguinte consiste em separar fisicamente a função DNS, instalando-a num Raspberry Pi com Ubuntu 20.04. Foi preparado um pacote autónomo com dnsmasq, gestor de feeds, timer, dashboard NiceGUI, telemetria e utilitários de diagnóstico e desinstalação. A edição para Raspberry utiliza uma versão do NiceGUI compatível com o Python 3.8 normalmente fornecido pelo Ubuntu 20.04; o pacote distingue arquitecturas ARM e verifica conflitos na porta 53 antes de instalar.

À data deste artigo, a edição Raspberry Pi estava preparada e sujeita a testes locais de código, mas ainda não tinha sido instalada e validada em hardware ARM real. A migração planeada é faseada: instalar, testar os bloqueios no Pi, transferir os DNS dos smartphones e só depois desligar a instância protegida no Voltaire. O DNS normal permanece intacto.

O Ubuntu 20.04 já ultrapassou o seu período de suporte standard. Para uma implementação permanente, deve utilizar-se suporte de segurança alargado ou planear a actualização do sistema operativo. Um equipamento de segurança com software desactualizado seria uma contradição pouco elegante.

10. O que o Mobile Shield não faz — e por que razão importa dizê-lo

O Android continua a precisar de actualizações, autenticação multifactor, permissões bem geridas, cuidados com aplicações instaladas e protecção contra engenharia social. O Shield é uma camada complementar no modelo de defesa em profundidade, não um substituto para todas as outras.

11. O verdadeiro produto: uma arquitectura pequena, independente e verificável

O projecto cresceu por evolução incremental: uma instância DNS selectiva, a expansão das fontes de ameaça, a automatização com rollback, a observabilidade NiceGUI e, por fim, a distribuição para Raspberry Pi. Cada incremento teve testes concretos e critérios de reversão. Houve também correcções necessárias no arranque da interface e na separação de privilégios — precisamente o género de problemas que uma engenharia honesta deve documentar, e não esconder.

O interesse do Voltaire Mobile Shield não está em competir com grandes plataformas comerciais de cibersegurança. Está em mostrar que Linux, Python, software livre e boas decisões de isolamento podem produzir um componente de protecção transparente, auditável e adaptável a uma rede doméstica ou a um pequeno laboratório.

Referências técnicas e documentação

1. dnsmasq — manual oficial — Directivas de filtragem local, encaminhamento e log-queries=extra.
2. Phishing Army — downloads oficiais — Lista de domínios e formatos de distribuição para filtros DNS.
3. HaGeZi — DNS Blocklists — Threat Intelligence Feeds e variantes Mini.
4. Quad9 — endereços e serviços — Resolvedores Secure, DNS tradicional, DoT e DoH.
5. Quad9 — Threat Blocking — Modelo de protecção por inteligência de domínios maliciosos.
6. NiceGUI — documentação — Interface web e dashboards em Python.
7. systemd — documentação — Agendamento de tarefas por timers.
8. Ubuntu — ciclo de suporte — Períodos de manutenção das versões Ubuntu LTS.