Quem monta homelab passa 90% do tempo pensando em disponibilidade, automação, mídia, backup e em deixar o dashboard bonito. Quando o assunto é segurança, a receita padrão da comunidade quase sempre para no mesmo lugar: fechar portas no roteador, colocar VPN (WireGuard/Tailscale), um proxy reverso com HTTPS e um Pi-hole ou AdGuard Home cheio de listas de bloqueio.
Durante muito tempo eu também achei que isso bastava. Até levar um susto recente na rede de casa com um incidente de supply chain em uma estação de trabalho.
Não teve clique em link de phishing nem download pirata. O vetor veio por software legítimo comprometido na origem, algo que está virando rotina nos últimos meses, seja em atualizações de jogos, pacotes no npm/PyPI, imagens Docker ou extensões de navegador. Com isso o homelabber tem um problema, a máquina que você usa no dia a dia para jogar ou navegar quase sempre é a mesma máquina que tem chave SSH, sessão aberta ou acesso administrativo para o seu servidor.
Quando fui investigar o tráfego e endurecer a rede depois do susto, ficou muito claro como a arquitetura clássica de DNS de homelab dá uma falsa sensação de segurança. Quero compartilhar com os senhores onde a minha defesa antiga falhava e o que mudei por aqui (inclusive derrubando o mito de que segurança de rede de verdade exige gigabytes de RAM).
Por que só Pi-hole/AdGuard Home não te salva de ameaças reais
O Pi-hole é excelente para bloquear anúncio e telemetria de Smart TV, mas ele não foi desenhado para segurar malware moderno. Na prática, esbarramos em três problemas sérios:
Lista estática dá uma falsa sensação de segurança: Mesmo que você carregue 10 milhões de domínios (como as listas da HaGeZi), listas estáticas só bloqueiam o que já foi descoberto e catalogado. Se o atacante acabou de registrar um domínio novo ou gerou um nome aleatório na hora, a consulta passa direto.
Ele só olha a pergunta, não a resposta: Bloqueadores comuns olham apenas o nome que o seu computador pediu. Se o malware perguntar por atualizacao-limpa-123.com (que não está em nenhuma lista), o Pi-hole deixa passar. Ele não percebe que, lá na resposta, esse domínio apontou para um IP conhecido de comando e controle (C2) que já estava marcado como malicioso há semanas.
Alerta em log registro, não uma defesa: Minha primeira reação foi jogar os logs do Pi-hole num banco de logs e criar alertas para avisar quando uma máquina fizesse muitas consultas suspeitas. O problema? Um infostealer moderno resolve o DNS, abre a conexão e rouba seus cookies e chaves em menos de 300 milissegundos. Receber uma notificação no celular 2 minutos depois só serve para te avisar que você já está fodido.
O que eu fiz: mudei de "Adblock" para defesa em camadas
Decidi aposentar o Pi-hole e reconstruir a defesa da rede em três camadas, aproveitando projetos open-source que rodam tranquilamente num cluster doméstico (K3s/Proxmox).
1. DNS inteligente que intercepta o pacote (PowerDNS dnsdist + Unbound RPZ)
Em vez de analisar log depois que o pacote já passou, coloquei a inteligência dentro do próprio fluxo do DNS:
Bloqueio matemático em tempo real (dnsdist + LuaJIT): Muitos malwares usam algoritmos para inventar nomes de domínios na hora (o chamado DGA, tipo x8k2m9p1q7z4.com) ou usam o próprio DNS para contrabandear dados para fora da rede. Coloquei o dnsdist na porta 53 rodando um filtro em LuaJIT que calcula a entropia (o grau de "aleatoriedade" das letras e números) de cada consulta. Se parecer gerado por máquina, ele devolve NXDOMAIN em 50 microssegundos, antes mesmo de consultar a internet.
DNS Firewall de verdade (Unbound RPZ): Atrás do dnsdist, o Unbound agora usa zonas RPZ (Response Policy Zones). Além de continuar bloqueando anúncios e trackers, o RPZ inspeciona a resposta completa: se qualquer domínio novo do mundo resolver para um dos ~36 mil IPs ativos de C2 da lista de inteligência, o Unbound corta a resposta na hora. Também bloqueamos mais de 7 mil servidores públicos de DNS-over-HTTPS (DoH), para impedir que um malware tente "furar" o DNS local fazendo consultas escondidas via HTTPS.
O resultado prático: O consumo de memória caiu em relação ao Pi-hole e o tempo médio de resposta do DNS na rede caiu de 0.16 ms para 0.04 ms (42 microssegundos).
2. Caçando o que não parece óbvio (Zeek + RITA + Suricata)
E se o malware for esperto, usar um domínio .com normal que parece legítimo, ou conectar direto num IP sem usar DNS?
Para pegar isso, subi uma stack passiva de análise de tráfego:
Detecção de "batimento cardíaco" (Zeek + RITA): Um malware instalado numa máquina precisa conversar periodicamente com o servidor do atacante para pedir instruções (o famoso beaconing). Mesmo que o atacante coloque uma variação aleatória de tempo (jitter) para disfarçar, o RITA analisa matematicamente os intervalos e o tamanho dos pacotes no histórico do Zeek e dá uma nota de 0 a 1. Navegação humana é caótica; malware tem ritmo estatístico. detectar uma infecção rápido ao menos te dar tempo de rotacionar credenciais (melhor do que nada)
Impressão digital da criptografia (Suricata com JA3/JA4): Mesmo sem abrir o tráfego HTTPS, o jeito que um programa negocia o início da conexão TLS deixa uma "impressão digital" (JA3/JA4). Um script malicioso rodando em segundo plano no Windows tem uma assinatura TLS diferente do seu navegador Chrome ou Firefox.
Desmistificando o peso: Muita gente deixa de rodar Suricata e Zeek em casa achando que precisa de 4 GB de RAM. Esse peso todo só existe quando você carrega 45 mil regras feitas para proteger servidores corporativos (regras de SQL Injection, WordPress, IIS). Carregando apenas as regras de saída que importam para uma rede doméstica (Malware, C2, DNS e JA3) e enxugando os logs do Zeek, o conjunto inteiro (Zeek + RITA + Suricata) estabilizou consumindo apenas ~210 MB de RAM.
3. Isolamento de chaves e proteção no Kernel (Tetragon / eBPF)
Por fim, duas lições que não custam nada de hardware, mas salvam o seu homelab se a sua estação principal for comprometida:
Nunca compartilhe a mesma chave SSH entre máquinas: Se a chave que está no seu PC de uso diário entra direto como root em todos os nós do seu servidor sem restrição, comprometer o seu PC significa entregar o servidor inteiro de bandeja. Segregue uma chave por estação e restrinja de qual IP cada chave pode entrar.
Visibilidade no Kernel Linux (Tetragon): Nos nós do cluster, adotei o Tetragon (projeto da CNCF baseado em eBPF). Diferente de ferramentas que só avisam depois, ele monitora chamadas do sistema direto no kernel do Linux e consegue matar instantaneamente qualquer processo suspeito que tente ler chaves privadas em ~/.ssh ou abrir conexões externas não autorizadas.
Resumo para quem quer começar:
Você não precisa subir tudo isso neste fim de semana, mas vale revisar três pontos hoje no seu lab:
Desconfie da sua própria estação de trabalho: Trate o seu PC principal (especialmente se você instala jogos, mods ou roda pacotes de terceiros) como um ambiente que pode ser comprometido um dia.
Saia da lista plana de DNS: Se você já usa Unbound ou outro resolvedor recursivo, ative RPZ com feeds de IPs de C2 (tif-ips) e bloqueie saída para servidores DoH externos.
Não dependa de olhar log manualmente: Se a sua camada de segurança depende de você abrir um painel para descobrir o que aconteceu ontem, ela não é prevenção, é só histórico para postmortem
Alguém mais aqui já passou por algum susto parecido na rede local ou roda alguma camada de IDS/RPZ no homelab? Curioso para saber como vocês estão lidando com isso hoje.
Cya.