Bom dia a todos.
Revistamos neste post um assunto que já abordamos no passado que envolve aumentar a segurança da rede da vossa empresa/homelab usando para tal os vossos DNS como uma ferramenta activa de defesa.
Com eles conseguem controlar os pedidos de malware, botnet’s ou publicidade indesejada.
Devido ao crescente uso de microserviços (containers/docker), decidi que seria altura de rever o post original, usando microserviços de pihole, pretendendo-se uma maior optimização de recursos, decrescendo para tal o consumo global de recursos do servidor.
Como podem verificar pelo post inicial, a escolha original recaiu na altura em bind, que é a norma para este tipo de servidores de DNS.
Embora existam soluções mais rápidas (por exemplo powerdns), o bind ganha em consumo de recursos, riqueza de features e optimização em ambientes multi-core.
… até chegar a altura de carregar 127 mil domínios em blacklist.
Nessa altura, com uma blacklist musculosa, um simples processo com o bind chrooted que com 10 zonas úteis carregadas consome perto de 18mb de rss e 300mb shm, salta com o load de 127 mil zonas para 1GB rss e 3GB de shm.
A acompanhar este aumento enorme de memória é possível igualmente notar um aumento de latência na resposta de pedidos (notem que todos as medições foram feitas numa máquina sem swap para eliminar paginação de recursos).
Este aumento no consumo de recursos tem vindo a aumentar em linha com o aumento de domínios em blacklist, pelo que outra solução se impunha.
Enter the PI-HOLE.
Recentemente tenho encontrado no Reddit vários posts sobre este software, que inicialmente foi desenhado para correr em hardware pi.
Leve no processamento, rápido e extremamente consciente dos recursos que utiliza aparentava ser a opção perfeita para resolver o meu desgovernado comboio de bind.
Os componentes que o integram são:
a) dnsmasq.
b) lighttpd (ou apache).
c) Um daemon nativo em execução (não obrigatório).
d) Uma webpage de controle (não obrigatória).
Na pratica, o PiHole descarrega de sites escolhidos por nós listas de domínios que são reconhecidos por serem de suporte a malware/ads, efetua o parsing de ditas listas para o formato de dnsmasq com resolução de nome para o loopback ou outro IP que se deseje.
No core do pihole está o dnsmasq. O que é o dnsmasq?
Por definição do fabricante temos que o dnsmasq é:
Dnsmasq provides network infrastructure for small networks: DNS, DHCP, router advertisement and network boot. It is designed to be lightweight and have a small footprint, suitable for resource constrained routers and firewalls. It has also been widely used for tethering on smartphones and portable hotspots, and to support virtual networking in virtualisation frameworks.
No caso presente apenas vamos usar a componente de DNS para a nossa função, pois é reconhecida ter uma footprint extremamente pequena, mesmo com ficheiros de zona extremamente grandes.
Contudo, não desejo abandonar o bind que gere os DNS de perímetro do meu datacenter, ficando os PiHoles apenas para filtragem de pedidos.
O desenho final será algo como isto:
Datacenter –> DNS Internos –> DNS de Perimetro –> 2 X PiHOLE –> Public DNS Provider.
Após a instalação do container em RHEL7, o procedimento de instalação do software é extremamente simples:
curl -sSL https://install.pi-hole.net | bash
Depois aguardar que o processo de installer efectue a instalação dos pacotes e dependências.
Nota: SELinux não é suportado pelo fabricante mas é possível ser ativado procurando as violações das mesmas e corrigindo elas á mão.
Em seguida será necessário adicionar blacklists de domínios e colocar os bind’s a usar eles como forwarders.
Para terminar o processo de instalação e em relação ás blacklists a utilizar, encontrei este site que aparentemente está bastante completo pelo que o recomendo: https://wally3k.github.io/
Como resultado, o container que tem cada um dos PiHole (cada um como forwarder) consome apenas 128 MB de RAM com uma blocklist de 200 mil domínios, um claro passo em frente da solução híbrida entre o named e as blacklists que consumiam perto de 1GB por instancia.
Existem ainda mais features que podem despertar interesse desde a interface CLI como a interface Web extremamente rica para o tamanho que tem.
Como nota de rodapé final, informo que com um mínimo de esforço esta configuração pode ser utilizada em configurações de apache/bind já existentes, mantendo a elasticidade e poupança da solução enquanto se garante a retrocompatibilidade com software já em produção.
Concluindo, estou agora a utilizar a solução e tenho notado sobretudo o decréscimo no consumo de recursos dos meus DNS de perímetro, e aumento de velocidade na experiência de “navegar” na internet causado pela diminuição da latência na resposta aos pedidos enquanto aumento a segurança da minha rede, pois posso usar blocklists mais completos.
Recomendo vivamente que experimentem a solução, e caso tenham duvidas ou sugestões já sabem onde me encontrar.
Update: Após este post ontem, chamaram-me á atenção de uma thread no Reddit sobre como o Chrome consegue fazer bypass a este método de controle.
Nada mais longe da verdade. O controle é totalmente possível mas para isso é necessário garantir os seguintes passos:
a) A rede de onde estão a ligar não faz NAT indiscriminado para a internet.
b) Se a rede fizer, coloquem uma regra de NAT na vossa firewall de perímetro, que redirecione todos os pedidos UDP 53 para os IP’s dos vossos PiHoles.
Simples 🙂
Um abraço!
Nuno