Como o Social Dork cria uma firewall doméstica com OPNsense

Agradecemos a The Social Dork | Cibersegurança por partilhar uma configuração de firewall doméstica OPNsense no ZimaBoard 2. Uma máquina virtual trata do encaminhamento e das políticas da firewall, um ponto de acesso fornece Wi-Fi e o Pi-hole filtra o DNS dos clientes ligados. Veja o tutorial original do YouTube para assistir à demonstração completa.

Veja antes de ler: Este vídeo de cerca de dez minutos é útil se quiser separar o gateway da rede do ponto de acesso sem fios. O criador explica a topologia, inicia o OPNsense no Zima Virtual Machine, atribui interfaces e DHCP e, em seguida, verifica um portátil ligado por Wi-Fi e a respetiva filtragem de DNS.

O marco demonstrado é um portátil a aceder à rede através da nova firewall e a usar o filtro DNS escolhido. O vídeo apresenta um tutorial para ligar o primeiro cliente. A preocupação inicial do vídeo com os dispositivos IoT vulneráveis exigiria uma separação adicional da rede e políticas de acesso; colocar os dispositivos num novo SSID não os isola, por si só, uns dos outros.

Decida quais as funções que o gateway existente deve manter

A discussão da topologia distingue três funções que um router tudo-em-um pode ocultar: a ligação ao operador, o limite da firewall com encaminhamento e o acesso sem fios. Uma ligação Ethernet pode alimentar a nova firewall, enquanto um serviço DSL ou por cabo continua a precisar do modem ou equipamento adequado do operador. Substituir a função de encaminhamento não elimina esse requisito de ligação física.

Na configuração funcional do criador, o router doméstico existente liga-se ao lado WAN da firewall, e um ponto de acesso liga-se ao lado LAN. Se o gateway a montante também efetuar tradução de endereços de rede, isso cria uma situação de NAT duplo. Pode ser aceitável para um teste inicial, mas pode complicar os serviços de entrada e a resolução de problemas. A disponibilidade dos modos de ponte ou passthrough depende do equipamento e do serviço do operador; confirme isso antes de alterar a ligação em produção.

Anote as definições atuais voltadas para o fornecedor antes da migração. Um vídeo que mostra uma ligação Ethernet não permite determinar os requisitos de autenticação, VLAN ou modem do seu ISP. Mantenha disponível a configuração do gateway antigo enquanto testa o novo percurso com um único cliente. Assim, será possível distinguir um problema no serviço a montante de um erro na nova LAN.

NAT duplo descreve duas fronteiras de tradução encaminhadas; é diferente de simplesmente ter um ponto de acesso a jusante. Se o dispositivo sem fios também continuar a encaminhar tráfego, pode introduzir outra fronteira e outro serviço DHCP. Confirme o modo de funcionamento efetivo e a disposição dos cabos, em vez de identificar a função do dispositivo pelo rótulo do produto na caixa.

Associe as interfaces virtuais a uma fronteira WAN e LAN real

The Social Dork transfere uma imagem de instalação do OPNsense e inicia-a no Zima Virtual Machine, no ZimaBoard 2. Trata-se de uma demonstração de firewall virtualizada. O anfitrião continua a executar o ZimaOS, pelo que a respetiva configuração de rede também faz parte do projeto, tal como as definições do OPNsense no sistema convidado.

Para uma implementação semelhante, associe explicitamente cada interface virtual à porta física pretendida ou a uma rede isolada do anfitrião. Um par de tomadas de rede não estabelece essa associação automaticamente. Mantenha o caminho voltado para a WAN separado dos serviços normais do anfitrião e certifique-se de que o tráfego dos clientes da LAN tem de atravessar a firewall para chegar à ligação a montante. Se um cliente tiver outro caminho que contorne a VM, a firewall não poderá aplicar políticas a esse tráfego.

Utilize as instruções de instalação do OPNsense e as orientações para máquinas virtuais atuais para a imagem e a plataforma selecionadas. Registe como aceder ao anfitrião e à consola da VM antes de alterar as interfaces. Um reinício do anfitrião, um problema de armazenamento ou o encerramento da VM podem interromper este gateway, por isso programe a manutenção tendo em conta a ligação à Internet da casa.

Torne explícito o plano das interfaces

1. Identifique as portas físicas do anfitrião e registe qual o cabo que chega à ligação a montante.
2. Associe a interface WAN do convidado à rede a montante pretendida.
3. Associe a interface voltada para a LAN a uma rede distinta a jusante.
4. Confirme que o acesso de gestão e os serviços normais do anfitrião não ficam inadvertidamente expostos através do lado WAN.
5. Ligue um dispositivo de teste a jusante e confirme o respetivo gateway predefinido antes de adicionar outros dispositivos.

O nome de uma interface dentro do sistema convidado pode não corresponder ao rótulo impresso junto a uma porta física. Use o mapeamento de rede do hipervisor e a consola do sistema convidado para estabelecer a correspondência. Volte a verificá-la depois de alterar os adaptadores virtuais. O vídeo demonstra uma configuração funcional na máquina do criador, mas não apresenta um inventário completo de todas as pontes ou definições de adaptadores do anfitrião que poderá encontrar.

Atribua recursos à firewall, deixando capacidade para o ZimaOS e os outros serviços no anfitrião. O atual guia de virtualização do OPNsense indica um mínimo de 3 GB de RAM, um disco virtual mínimo recomendado de 8 GB e orientações de compatibilidade de rede. São condições de partida, não uma promessa de débito. Os registos, as VPN, as funcionalidades de inspeção e outras cargas de trabalho podem alterar a margem necessária.

Esta é uma consequência operacional de partilhar uma máquina: uma atualização ou um reinício do anfitrião também pode desligar a VM do gateway. Decida como a VM será iniciada após o arranque e como irá recuperá-la caso não inicie. Uma forma de acesso estável à consola é particularmente útil quando uma configuração de rede incorreta torna a interface Web inacessível.

Deixe que um único serviço DHCP faça a gestão de cada rede de clientes

O criador utiliza redes IPv4 diferentes a montante e a jusante: o lado a montante usa endereços 192.168.0.x e a LAN dos clientes usa endereços 192.168.1.x. Estes são exemplos do vídeo. Escolha sub-redes sem sobreposição adequadas à sua rede, em vez de copiar endereços que já possam estar em uso.

O ponto de acesso fornece a ligação rádio, enquanto o OPNsense atribui concessões DHCP aos clientes a jusante. O tutorial aborda o modo AP e a desativação do serviço DHCP do antigo router sem fios. Em equipamentos sem um modo AP dedicado, desativar apenas o DHCP não garante um comportamento transparente de ponto de acesso: confirme as ligações LAN a LAN e os requisitos de encaminhamento/NAT do fabricante. Mantenha o endereço de gestão acessível sem conflitos com o conjunto de endereços DHCP.

Teste a concessão DHCP resultante num portátil. Deverá receber um endereço na LAN pretendida, o endereço LAN da firewall como gateway predefinido e o servidor DNS pretendido. Uma associação Wi-Fi bem-sucedida só comprova que a ligação rádio funciona. O endereço, o gateway e o resolvedor mostram se o cliente aderiu efetivamente ao novo percurso de rede.

Planeie separadamente os endereços fixos e o conjunto de concessões DHCP

O que se segue é um plano ilustrativo para uma LAN /24, não uma transcrição dos endereços exatos do criador. Adapte-o às suas redes existentes. Reserve os endereços fixos da infraestrutura fora do conjunto atribuído dinamicamente e mantenha a rede a montante diferente da LAN a jusante.

Se o Pi-hole estiver realmente noutra sub-rede ou numa rede virtual do anfitrião, use o respetivo endereço real acessível e configure o encaminhamento e as políticas necessários. O endereço do exemplo não faz com que o serviço fique disponível na LAN por si só. Uma entrada DHCP informa os clientes para onde enviar um pedido; não estabelece a rota nem inicia o servidor.

Depois de alterar o DHCP, verifique a concessão no portátil, em vez de consultar apenas a página de configuração do servidor. Confirme o endereço atribuído, a máscara, a gateway e as entradas DNS. Um cliente que ainda tenha uma concessão antiga pode fazer com que uma nova configuração correta pareça estar avariada. Um endereço ou uma gateway inesperados também podem indicar que continua ativo outro servidor DHCP.

Use a primeira regra de permissão como teste de conectividade

O criador começa com uma regra de saída permissiva para o único portátil de teste e fala sobre impedir ligações não solicitadas da WAN para a LAN. O OPNsense usa filtragem com estado, pelo que as respostas a uma ligação permitida são tratadas através do estado da ligação. A documentação das regras da firewall do OPNsense explica como a interface, a direção e a ordem das regras afetam esse comportamento.

O vídeo também abre a interface Web a partir da sua rede privada a montante. Na sua própria implementação, restrinja o acesso administrativo a um percurso de gestão de confiança e mantenha uma opção de recuperação através da consola. A designação WAN descreve uma função relativa a este firewall; um segmento privado de laboratório a montante e a Internet pública representam condições de exposição diferentes.

Para resolver a preocupação com a IoT levantada no início, crie redes distintas com equipamento que as suporte e, em seguida, defina o tráfego permitido entre elas. Os dispositivos que trocam tráfego dentro do mesmo segmento local podem comunicar sem passar pelo firewall de encaminhamento. Para outra perspetiva prática sobre decisões relativas ao gateway e à privacidade, consulte a configuração de firewall OPNsense da cachito labs.

Distinga a conectividade do isolamento

Defina a origem, o destino, o protocolo e a finalidade pretendida antes de adicionar uma regra. Uma regra que comprova que um portátil consegue aceder à Internet não é uma política para todos os dispositivos de uma casa. Para segmentar a rede, use redes distintas e uma ligação através de um firewall entre elas. O tráfego trocado localmente no mesmo segmento pode nem sequer passar pelo gateway.

Quando uma alteração às regras parece não ter efeito, teste uma nova ligação e tenha em conta o estado da ligação. O guia de regras do OPNsense explica o processamento stateful. Os estados existentes podem afetar um novo teste, enquanto a reposição de todos os estados interromperia outras ligações ativas. Identifique o fluxo de teste específico antes de fazer uma alteração de diagnóstico abrangente.

Ligue o Pi-hole através de DHCP sem criar um ciclo DNS

Perto do fim, The Social Dork define o servidor DNS fornecido por DHCP como o endereço do Pi-hole. Assim, o projeto de bloqueio de anúncios com Pi-hole e Tailscale apresentado anteriormente passa a fazer parte da nova rede sem fios. O OPNsense controla o percurso do tráfego encaminhado; o Pi-hole avalia os nomes DNS pedidos através do seu serviço. Os dois componentes têm responsabilidades diferentes.

O guia de integração do Pi-hole com o OPNsense descreve a distribuição direta por DHCP e o encaminhamento através da firewall como configurações alternativas. Escolha um percurso consistente e certifique-se de que os servidores DNS não reencaminham consultas uns para os outros, criando um ciclo. Verifique também se os clientes têm permissão para aceder ao endereço do Pi-hole, caso este esteja noutra rede.

Escolha um percurso para o servidor DNS e trace-o de ponta a ponta

O vídeo utiliza o endereço do Pi-hole fornecido por DHCP para os clientes. A configuração de encaminhamento apresentada no guia oficial ligado é uma alternativa. Se a escolher, certifique-se de que o servidor DNS a montante do Pi-hole não reencaminha o pedido diretamente para a mesma cadeia de encaminhamento. Um percurso claro torna muito mais fácil diagnosticar a ausência de resposta.

O DNS também depende do transporte e do encaminhamento. Se o cliente e o resolvedor estiverem em redes diferentes, verifique o percurso e as regras aplicáveis à porta 53 TCP/UDP. Reveja os anúncios de DNS IPv6 e as definições de DNS independentes do cliente se o resultado observado for diferente da configuração DHCP. O simples acesso à interface Web do Pi-hole não é prova suficiente.

Para filtrar o tráfego fora de casa, consulte novamente o guia passo a passo do Pi-hole e do Tailscale. O acesso remoto por DNS, as regras da rede local e a saída de todo o tráfego para a Internet através de uma VPN são decisões distintas. Teste cada opção na ligação em que será realmente utilizada.

Verifique todo o percurso antes de mover cada dispositivo

A demonstração final muda a rede Wi-Fi do portátil e compara o mesmo site com e sem a configuração de filtragem. Ilustra o percurso do cliente selecionado, mas não prova que todos os sites estejam livres de anúncios nem que todos os dispositivos estejam isolados. Primeiro, valide o acesso à Internet e o DNS; depois, inspecione os registos relevantes do firewall e do Pi-hole para associar cada resultado ao cliente pretendido.

Antes de transferir a casa para a nova configuração, teste a renovação da concessão de um cliente, uma ligação permitida e uma ligação deliberadamente bloqueada entre redes separadas, se a segmentação fizer parte da sua configuração. Exporte uma configuração de firewall funcional e confirme o processo de recuperação. O objetivo é ter um gateway cujo encaminhamento, DHCP, filtragem e administração consiga explicar e manter. Veja o guia completo do The Social Dork para configurar um firewall doméstico com OPNsense para conhecer a topologia original e a sequência de configuração.

Utilize um teste de aceitação por etapas

1. Ligue-se à rede sem fios pretendida e inspecione a nova concessão do cliente.
2. Confirme o gateway predefinido e, quando adequado, teste uma ligação permitida baseada em IP.
3. Resolva um nome de anfitrião permitido através do resolvedor selecionado e localize a consulta.
4. Teste um domínio abrangido pela política ativa do Pi-hole e confirme a resposta esperada.
5. Se configurou a segmentação, teste uma ligação permitida e outra bloqueada através do limite entre as redes encaminhadas.
6. Volte a ligar o cliente ou renove a concessão e confirme que as definições pretendidas são aplicadas.
7. Durante uma janela de manutenção planeada, verifique o anfitrião e o processo de arranque da VM de gateway antes de depender deles continuamente.

Diagnostique por ordem de rede

Use os registos para responder a uma pergunta de cada vez. A documentação de registo do firewall do OPNsense explica que um fluxo com estado não gera necessariamente uma nova linha no registo em tempo real para cada pacote. O guia de diagnóstico do firewall apresenta a vista dos estados. Um registo silencioso, por si só, não prova que não passou tráfego pelo firewall.

Guarde uma configuração funcional antes de fazer uma alteração importante e mantenha um plano de reversão claro. Durante os testes, mantenha a ligação antiga disponível separadamente; evite ligar acidentalmente as redes a montante e a jusante em torno da firewall. Um plano de reversão eficaz restaura uma configuração conhecida do gateway e dos clientes, em vez de introduzir dois encaminhadores concorrentes no mesmo segmento de clientes.

Perguntas frequentes

A ZimaBoard 2 pode substituir, por si só, o rádio Wi-Fi?

Neste vídeo, um ponto de acesso separado fornece Wi-Fi. A placa aloja o gateway virtualizado e os serviços associados. O encaminhamento e o acesso sem fios são funções distintas.

Posso remover o modem do ISP?

Só se o encaminhamento do seu serviço deixar de o exigir. As configurações de DSL, cabo e outros serviços específicos dos fornecedores podem continuar a precisar do equipamento de terminação original. Confirme os requisitos físicos e do serviço antes de substituir um gateway.

Uma regra para permitir o tráfego de saída isola os dispositivos IoT?

Não cria separação de rede. Os dispositivos no mesmo segmento local podem comunicar sem passar pela firewall de encaminhamento. O isolamento exige redes distintas e uma política entre elas que tenha sido testada.

O Pi-hole deve ser executado dentro do OPNsense?

O projeto demonstrado utiliza um serviço Pi-hole juntamente com a firewall virtualizada e anuncia o respetivo endereço através de DHCP. O requisito essencial é um percurso DNS acessível e consistente; não parta do princípio de que a instalação do OPNsense também instala esse serviço.

Porque é que a máquina virtual da firewall precisa de dois caminhos de rede?

A configuração encaminhada precisa de um caminho voltado para a rede a montante e de outro caminho separado para a rede a jusante. O mapeamento correto entre o convidado e o anfitrião estabelece esse limite. A existência de dois nomes de adaptadores visíveis, por si só, não comprova que as redes estejam isoladas.

O que acontece quando o anfitrião ZimaOS é reiniciado?

A firewall para convidados e outros serviços alojados podem ficar indisponíveis. Planeie o arranque e a recuperação das máquinas virtuais e, depois, verifique-os durante uma janela de manutenção. A manutenção do anfitrião faz parte da disponibilidade do gateway quando o hardware é partilhado.

Conclusão

A configuração do The Social Dork é útil porque transforma um gateway multifunções num conjunto de tarefas fáceis de compreender: ligação ao fornecedor, encaminhamento virtualizado, acesso sem fios, atribuição de endereços e filtragem de DNS. O primeiro teste bem-sucedido com um portátil estabelece um ponto de partida. Um gateway doméstico bem mantido também precisa de limites de rede verificados, políticas adequadas a cada grupo de clientes e um plano de recuperação.

Conclua as verificações num único cliente antes de transferir toda a rede doméstica e, em seguida, valide separadamente qualquer segmentação adicional ou comportamento da VPN. Consulte o vídeo explicativo do OPNsense juntamente com o seu próprio plano de interface e a documentação oficial atualizada. O objetivo é ter uma rede cujo comportamento consiga explicar, testar e restaurar.