OpenBSD 7.7 como base robusta de firewall: uma pf.conf e uma sysctl.conf que estão do seu lado

O OpenBSD é conhecido há anos por seu ethos de segurança sem concessões: padrões sensatos, código limpo e “secure by default” como mandato, não como slogan. Se você procura um firewall confiável e explicável no dia a dia, o OpenBSD oferece uma base sólida. Ao mesmo tempo, padrões fortes são ótimos, mas alguns ajustes pontuais elevam de forma nítida o nível de segurança e a previsibilidade—sem transformar seu ambiente num experimento frágil.
Com este artigo, queremos fornecer uma linha de base prática que proteja com confiança redes pequenas, labs domésticos e muitos ambientes de PME—mantendo-se legível e fácil de manter.

Em vez de checklists intermináveis e dicas de tuning arbitrárias, você terá decisões fundamentadas com justificativas claras. Vamos mostrar por que cada opção é definida, quais riscos ela endereça e quais efeitos colaterais considerar. O objetivo não é cobrir todo cenário teórico de ataque, e sim dar um ponto de partida confiável: regras enxutas, poucas exceções e comportamento previsível.

Este guia segue um princípio claro: permita explicitamente; o resto, bloqueie. Do exterior para o interior, só é permitido o que o roteador realmente precisa; do interior para o exterior, apenas o que você quer que saia. Mantemos o DNS visível e controlável. DoH, DoT, DoQ e QUIC não ganham atalhos silenciosos, evitando “canais invisíveis”. Os estados são vinculados intencionalmente às interfaces, para que as conexões permaneçam onde se originaram. Isso torna o sistema previsível e o troubleshooting suportável. E, porque transparência vale mais do que dez truques, todos os caminhos críticos recebem rótulos: na operação diária você vê de imediato o que foi usado, o que foi negado e onde apertar o cerco.

Para manter tudo concreto, oferecemos dois perfis de pf para você escolher: uma variante somente roteador (router‑only) para cenários clássicos LAN‑internet, e uma variante roteador+DMZ para isolar serviços. Forçamos o DNS dos clientes exclusivamente para 1.1.1.1 (com 1.0.0.1 opcional como alternativa). Não é preciosismo—é uma decisão arquitetural deliberada: você recupera visibilidade e controle. Se um aplicativo quiser algo diferente, vai chamar atenção, e você decide conscientemente se e onde conceder uma exceção.

O arquivo sysctl.conf reforça essa postura no nível do kernel. O OpenBSD já traz muita coisa boa, mas alguns seletores entregam um ganho mensurável de robustez: uma configuração de malloc endurecida que faz bugs de memória falharem mais cedo e mais alto; desativação de SMT/Hyper‑Threading quando riscos de canal lateral não trazem benefício algum; W^X, que prefere encerrar processos a deixá‑los rodar em zonas cinzentas perigosas; desligamento de redirecionamentos e túneis dispensáveis; opções TCP modernas e limites de taxa moderados que amortecem o “ruído” de rede sem quebrar funções legítimas. Isso não são “tweaks” chamativos—é higiene consistente: menos superfície de ataque, menos surpresas, comportamento mais estável sob carga.

Ficam fora de escopo ataques altamente direcionados ou pilhas completas de IDS/IPS. Se você quer monitoramento em múltiplas camadas, inspeção profunda de protocolos ou feeds de inteligência de ameaças, essa configuração não atrapalha; ela é o fundamento sobre o qual você pode adicionar esses blocos metodicamente depois. Também omitimos de propósito políticas multi‑WAN complexas, paisagens elaboradas de port‑forwarding ou redes overlay exóticas. Tudo isso é viável, mas não sem diluir a clareza da linha de base.

Nosso compromisso com a legibilidade também significa preferir mecânica a magia. O NAT é estático onde protocolos em tempo real se beneficiam e dinâmico onde não faz diferença. QUIC fica de fora para que o DNS não se esconda dentro de fluxos TLS. IPv6 é bloqueado inicialmente para evitar “IPv6 pela metade”, quando clientes preferem v6 enquanto o firewall não o controla; mais adiante você encontrará uma receita limpa para habilitar IPv6 do jeito certo, se precisar. E, onde ajuda, marcamos casos de borda com rótulos—não para colorir logs, mas para obter respostas: quem tentou falar DoT? Quais hosts bateram na regra anti‑rebind? O que dispara os bloqueios de saída?

Para quem é isso? Para você que trata a administração como ofício e prefere investir uma hora numa base limpa a passar três semanas caçando efeitos colaterais estranhos. Para você que quer entender sua rede, em vez de ser surpreendido por permissões padrão. E para você que se sente “entre cadeiras”: sem tamanho para um SOC/time azul, mas exigente demais para um roteador doméstico comum. Esta linha de base não é truque de mágica; é um padrão sensato: pequeno o suficiente para dominar e robusto o bastante para manter.

Modelo de ameaça: contra o que defendemos—e contra o que não

Esta linha de base é pensada para ambientes sem time azul dedicado que ainda assim desejam padrões confiáveis. Ela protege do ruído típico que atinge sua borda diariamente: varreduras amplas, exploits oportunistas, abuso de protocolo (o “DNS sobre qualquer coisa”), configurações equivocadas ou políticas de egress permissivas que viabilizam exfiltração de dados. Ela encapsula servidores opcionais numa DMZ, impedindo movimentação lateral rumo à LAN. Não estão no foco ataques altamente direcionados ou pilhas completas de IDS/IPS—você pode adicioná‑los depois, sobre este fundamento.

Princípios de design: pouca superfície de ataque, responsabilidades claras

A configuração segue diretrizes que ajudam também em ajustes futuros:

Fail‑closed. Se algo não for explicitamente permitido, fica fechado—tanto na entrada quanto na saída. Assim, nos testes você descobre cedo o que um app realmente precisa e mantém o controle.

Estados determinísticos. if-bound garante que a conexão permaneça vinculada à interface onde se originou. Em roteadores single‑WAN, isso põe fim à caça por “estados flutuantes” mágicos e facilita o troubleshooting.

Minimalismo de saída (egress). Do interior para o exterior, apenas o necessário: web clássico, submissão de e‑mail, faixas UDP definidas para VoIP/WebRTC—e DNS somente para onde você determinar.

Transparência em vez de adivinhação. Bloqueamos QUIC e também DoH/DoT/DoQ. Sim, pode ser incômodo para alguns apps. Em troca, você ganha clareza: DNS é DNS, TLS é TLS. Se alguém precisa de “DNS à sombra”, vai aparecer.

Padrões robustos. Scrubbing, limite de MSS, IDs aleatórias, filtros de bogons, anti‑spoofing, higiene de flags TCP e limites de taxa sensatos para ICMP e RST. Nada espetacular; em conjunto, higiene sólida.

IPv6 por escolha. IPv6 vem desligado por padrão. Se você quiser, há um caminho limpo no artigo para habilitar. Evitamos de forma consistente o “IPv6 pela metade”.

sysctl.conf — Alavancas de segurança no kernel que realmente importam

O OpenBSD já traz bons padrões, mas alguns ajustes elevam claramente a segurança e a previsibilidade. Aqui vai o essencial—sem listas intermináveis, com razões claras.

Endurecimento de memória (vm.malloc_conf=CFGJRS). Guard pages, padrões “junk”, red zones e canaries dificultam a exploração de bugs clássicos e fazem processos falharem “em voz alta” em vez de corromper silenciosamente. O pequeno overhead compensa em praticamente todos os cenários de roteador.

CPU/Hardware: SMT desligado, aperture fechada. hw.smt=0 reduz riscos de canal lateral (Hyper‑Threading); em roteadores, o impacto costuma ser mínimo. machdep.allowaperture=0 fecha acessos tipo /dev/mem—ideal para equipamentos headless. Se você precisa de X11/KMS, saberá; se não, deixe fechado.

Roteamento e protocolos: IPv4 ativo, IPv6 intencionalmente inativo. net.inet.ip.forwarding=1 transforma sua máquina em roteador IPv4. net.inet6.ip6.forwarding=0 evita roteamento “acidental” de IPv6. Desativamos ainda túneis desnecessários (IP‑in‑IP, GRE, ESP/AH, EtherIP). Menos maquinaria de cifra/encapsulamento = menos superfície de ataque e menos surpresas.

Desarmando armadilhas legadas. Broadcasts dirigidos desligados, redirecionamentos ignorados (IPv4 e IPv6). Redirecionamentos ICMP são um clássico “tiro no pé”; se for alterar rotas, faça isso explicitamente no roteamento ou no PF, não por atalhos.

ICMP com parcimônia. Sem eco para broadcast, sem timestamps/netmask; pacotes de erro com limite de taxa razoável. Isso amortece ruído de DDoS sem quebrar funções legítimas. ICMP não é inimigo, mas precisa de guarda‑corpos.

Endurecimento UDP/TCP sem mágica. Checksums UDP obrigatórios; buffers de socket sensatos evitam perdas feias. No TCP, mantemos recursos modernos (window scaling, timestamps, SACK) ativados para melhorar a estabilidade. ECN fica ligado; raramente causa problemas e ajuda sob carga. Limites de SYN cache/bucket e rate‑limit de RST absorvem ondas típicas de varredura.

Filas, BPF e W^X. Uma fila de interface (if‑queue) maior reduz drops em rajadas. Buffers BPF mais largos são um presente para o seu “eu do futuro” ao depurar. kern.wxabort=1 cumpre W^X: código é ou gravável ou executável, nunca ambos. Violações encerram o processo—fail‑closed, como queremos. Criptografia de swap permanece ativa, para que resíduos sensíveis não caiam em disco em claro.

Esta seleção de sysctl é deliberadamente sóbria. Move a curva de “costuma funcionar” para “se comporta com consistência sob estresse”. Carregue com sysctl -f, confira alguns contadores (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) e lembre: se você mexer em orçamentos de mbuf/cluster, pode precisar ajustar limites do PF como set limit frags.

pf.conf: regras que você consegue explicar

O pf dá possibilidades infinitas. Nossa linha de base toma exatamente o que você precisa para padrões robustos—nem mais, nem menos.

Macros, tabelas e rótulos: metade da batalha é estrutura. Comece com interfaces e redes definidas com clareza: WAN, LAN e—na variante com DMZ—DMZ. Adicione tabelas para bogons, abusers, scanners e uma watchlist para endpoints DoH suspeitos. Não é decoração: com persist elas sobrevivem a recargas e, via overload, fontes ruidosas entram nelas automaticamente. Rótulos consistentes nas regras dão visibilidade operacional sem precisar de pcap pesado: pfctl -vvsr ou systat pf mostram onde está a ação.

Opções globais: comportamento previsível. set block-policy drop e otimização “aggressive” são padrões conservadores sensatos. set state-policy if-bound ancora conexões à interface de entrada. Definimos limites de estados, fragmentos e src‑nodes, timeouts adaptativos e ativamos syncookies de forma adaptativa—úteis quando a maré sobe. loginterface dá estatísticas do WAN; set skip on lo0 evita “tiros no pé”.
No pf, o IPv6 é bloqueado por padrão, alinhado ao sysctl, e evita “IPv6 pela metade”. Se quiser, habilite de modo deliberado e visível.

ICMP de entrada: aberto o suficiente para manter a saúde. Na interface WAN, permitimos echo e “unreachable”, com estado e limite de taxa. Isso melhora o diagnóstico (como detectar problemas de MTU/rota, do contrário?) e protege de floods de ping. Todo o resto—especialmente redirecionamentos—fica desligado.

Scrubbing: menos fragmentação, menos frustração. Limpamos em ambos os sentidos: IDs de IP aleatórias, TTL mínimo conservador, MSS limitado a 1440 (valor saudável na prática) e reassemblagem TCP. Isso evita que pacotes fragmentados duvidosos entupam estados e reduz dores de PMTU. Com isso, dificilmente você precisará mexer em MSS via sysctl.

NAT: estático onde o tempo real importa; dinâmico onde não. UDP recebe portas estáticas—ouro para VoIP/WebRTC, jogos e muitos protocolos em tempo real. O restante usa uma faixa ephemeral alta para facilitar atribuição de saída em capturas e evitar colisões. O NAT se aplica a tudo, exceto destinos de gestão definidos explicitamente—sem caminhos surpresa.

Anti‑spoofing, bogons, portas nulas. antispoof vigia todas as interfaces relevantes. O que chega ao WAN com rota de origem quebrada cai cedo. Bloqueamos bogons na entrada e na saída; tráfego, por exemplo, de 10/8 ou 127/8 para a internet geralmente indica outros problemas. Também limpamos portas 0 e flags TCP inverossímeis—não é ciência de foguetes, mas poupa dor com scanners e ferramentas “criativas”.

Negação por padrão: a grande vassoura. Depois da higiene, vem o corte duro: block all. Daqui em diante, tudo é exceção consciente.

Entrada no WAN: apenas o que o roteador precisa. Permitimos DHCP de entrada se o upstream exigir. E só. Uma DMZ pública exposta à internet não é o propósito desta linha de base; para isso, você definiria port‑forwards—com parcimônia.

QUIC: HTTP/3 fica de fora. Bloqueamos UDP 80/443 no WAN. Isso sufoca o QUIC. Por que tão estrito? Porque QUIC é um túnel conveniente—inclusive para variantes de DoH e outros truques “tudo no mesmo fluxo”. Se mais tarde você realmente precisar de HTTP/3 para alvos específicos (e sabe por quê), adicione exceções cirúrgicas. A linha de base prioriza transparência em detrimento de velocidade.

Visibilidade para DoH/DoT/DoQ—com limites claros. DoT (853/TCP) e DoQ (784/UDP) são bloqueados na saída e registrados na entrada. Em LAN/DMZ rotulamos conexões TLS a hosts DoH conhecidos—sem mudar a política, a menos que você escolha a variante estrita. A ideia é: ver quando clientes tentam DNS encoberto.

Acesso administrativo ao firewall: enxuto e com controle de ritmo. SSH da LAN para o firewall é permitido com estado, higiene de flags e limitação suave de taxa. Caminhos de gestão upstream (por exemplo, a GUI de um modem/roteador) ganham passes direcionados; limites de taxa amortecem sprays e cliques equivocados. Rótulos mantêm esses caminhos visíveis.

Política de DNS sem resolvedor local: impor, não torcer. Ponto central: clientes na LAN (e na DMZ, se houver) só podem usar 1.1.1.1 e, opcionalmente, 1.0.0.1 na porta 53/TCP+UDP. Todo o resto para porta 53 é bloqueado e logado. Não é “nice to have”—é crucial para visibilidade. Você verá de cara tentativas de usar outros resolvers—ou DoH/DoT/DoQ, que são bloqueados separadamente. Pode trocar por outro resolver externo quando quiser; a mecânica é a mesma.

DMZ: sem portas laterais, sem atalhos. Na variante com DMZ não há comunicação intra‑DMZ, não há retorno para a LAN e só há saídas direcionadas para os serviços que ali vivem (web clássico, submissão de e‑mail, faixas UDP de VoIP/WebRTC). Acesso a qualquer GUI ascendente a partir da DMZ é proibido; assim você evita que um servidor comprometido toque sua rede de gestão. Todo o resto é bloqueado—e logado—para que você encontre rápido o parafuso que falta.

Mitigar riscos de saída: fechar os clássicos. Para fora, bloqueamos os suspeitos usuais: SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM e SMTP oportunista. Cada um tem seu lugar dentro da rede ou em caminhos deliberados; na internet, por padrão, não. Se precisar de exceção, defina‑a com consciência—e com rótulo.

O próprio firewall: pode sair, mas visível. O firewall pode acessar a internet—com estados, limites e rótulos. Você precisa disso para updates, pacotes e diagnóstico. Sem exagero: essa caixa é roteador e guardião, não um terminal de navegação.

Anti‑rebind, LAN→DMZ e a grande limpeza. Entre LAN e DMZ, apenas caminhos explícitos são permitidos (por exemplo, clientes até um serviço na DMZ); o retorno fica fechado. Regras anti‑rebind evitam que clientes alcancem alvos internos protegidos por truques de DNS via firewall. No resto, o PF diz “não” de forma clara—com return onde um erro rápido ajuda o diagnóstico.

Somente roteador vs. roteador+DMZ: qual perfil é o seu?

Se você só quer ligar uma LAN à internet, somente roteador é ideal: compacto, claro e ainda assim endurecido. Você ganha anti‑spoofing, filtros de bogons, postura estrita de saída, DNS forçado para 1.1.1.1/1.0.0.1, controles de DoH/DoT/DoQ/QUIC, SSH admin da LAN para o firewall e padrões limpos para scrubbing, estados e limites.

Assim que você hospeda serviços—mesmo que apenas internos—roteador+DMZ passa a fazer sentido. A DMZ contem falhas e reduz a chance de que um serviço comprometido vire trampolim para sua LAN. Comunicação intra‑DMZ permanece fechada; a saída é por lista branca e mais estreita do que na LAN. O DNS é igualmente estrito; NTP permanece fechado até você realmente precisar.

Habilitando IPv6 do jeito certo

A linha de base bloqueia IPv6 para que nada fique “meio aberto”. Se você precisa de IPv6, habilite deliberada e consistentemente: roteamento via sysctl, regras inet6 correspondentes no pf, um plano de saída limpo (sim, enforcement de DNS aqui também—só que para v6) e decisões claras sobre RA/DHCPv6. Espelhe as boas ideias do v4: anti‑spoofing, negação por padrão, gestão de QUIC/DoH/DoQ e exceções visíveis—nem mais, nem menos. Dica principal: não “escorregue” v6 em silêncio. Se for usar, que seja bem feito; se não, ainda não.

Operação, diagnóstico e forense: medir, não adivinhar

Uma política rígida só é boa se você consegue lê‑la no dia a dia. O pf ajuda por três canais:

Rótulos. Cada regra relevante traz um rótulo descritivo. Em pfctl -vvsr você vê quais caminhos são usados, quais são bloqueados e onde está a ação. Muitas vezes basta para isolar problemas.

Tabelas. Com pfctl -t <table> -T show você lê entradas de abusers/scanners. overload preenche essas tabelas automaticamente quando clientes abrem conexões em excesso. Não é punição; é um cinto de segurança.

pcap mínimo. tcpdump é seu amigo—use com intenção. Para controlar DNS/DoH, olhares rápidos como:
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
costumam bastar. Isso é forense com plano, não “Wireshark até arder o olho”.

Um cânone de testes saudável. Ao alterar regras, compile antes sem carregar: pfctl -nf /etc/pf.conf. Depois pfctl -f—e, se algo quebrar, rótulos e tabelas guiam o conserto. Para enforcement de DNS: drill @1.1.1.1 openbsd.org deve funcionar; drill @9.9.9.9 openbsd.org deve ser bloqueado. Para QUIC, verifique que curl -I --http3 https://example.com não vá por UDP e caia para HTTP/2. Valide DoT/DoQ tentando 1.1.1.1:853 e UDP 784—devem falhar, e você verá os contadores nas regras rotuladas.

Uma dica para mudanças de egress. Ao abrir algo, marque temporariamente com um rótulo bem explícito e, uma semana depois, verifique se há uso. Se não há, remova. Assim sua linha de base permanece enxuta.

Considerações de desempenho sem folclore

Este arranjo não está “no fio da navalha”—está calibrado para estabilidade. Algumas consequências importam:

Bloquear QUIC pode deixar alguns sites ligeiramente mais lentos. É uma troca deliberada: visibilidade acima de velocidade. Se tiver motivos válidos para permitir HTTP/3, faça isso cirurgicamente (alvos numa tabela, rótulo e pronto).

ECN ligado vai bem na maioria das redes modernas. Se alguma middlebox exótica não gostar, você perceberá rápido e poderá desativar naquele caso—a linha de base não briga com você.

Portas NAT estáticas para UDP são um presente para protocolos em tempo real. Quem já perseguiu problemas de WebRTC sabe: valem ouro. Não custam nada, exceto entender que “aleatoriedade” de porta no UDP não é recurso de segurança.

If‑queues e buffers BPF estão dimensionados com pragmatismo: folga para picos e sessões de depuração que não morrem com buffers de 4 KB. Se for realmente espremer throughput, meça e ajuste—não o contrário.

Armadilhas comuns—e como lidar com elegância

“Meu app só funciona com DoH!” Então precisa de uma exceção ou, melhor, de uma revisão honesta. DoH não é inerentemente ruim, mas atrapalha o controle de rede (casa/empresa). Pode permitir hosts específicos numa tabela; mantenha como exceção consciente, não abertura global.

“A videochamada engasga.” Primeiro verifique se as faixas UDP do seu provedor (Zoom/Teams/WebRTC) estão cobertas. Portas UDP estáticas ajudam, mas sem o corredor de saída certo nada melhora. Ajuste sob medida, não a esmo.

“Meu cliente de e‑mail não envia direto.” Correto: porta 25 de saída está bloqueada. E‑mail deve ir por submissão (465/587) ao provedor/servidor—não direto para a internet. Se necessário, permita essas portas de submissão—com rótulo.

“IPv6 quebrou do nada.” Nesta linha de base, v6 está bloqueado. Se clientes preferem v6 enquanto o firewall não roteia, virão timeouts. Ou habilite v6 corretamente (com regras) ou informe aos clientes (RA/ND) que ainda não há v6.

“Coisas estranhas após mudar uma regra.” Pense em estados. Os antigos sobrevivem por padrão. Ao mudar política central (por exemplo, abrir nova porta de saída), mate estados afetados (pfctl -k ...) ou, se preciso, flushe todos (pfctl -F state). Depois, o mundo volta a ser consistente.

Por que esta linha de base é “segura”—e o que segurança significa aqui

Segurança nunca é absoluta. Mas é mensurável quando você define objetivos claros e verifica o caminho com honestidade. Esta linha de base reduz a superfície de ataque porque:

minimiza toda exposição de entrada,

faz da saída (egress) exceção, não regra,

impõe e mantém visível o DNS,

bloqueia caminhos ofuscados (QUIC/DoH/DoT/DoQ),

desativa pseudo‑recursos (redirecionamentos, broadcasts),

aplica padrões robustos de TCP/ICMP,

torna o tratamento de estados determinístico,

e dá a você ferramentas para observar o uso no dia a dia.

Ao mesmo tempo, a configuração permanece sustentável. Ela não é “segura” por ter 3.000 linhas, e sim porque você consegue explicar cada linha.

Migração: como proceder

Se você vem de uma configuração pf existente, avance por etapas:

1. sysctl primeiro. Carregue o endurecimento que não derruba serviços. Verifique logs por ruídos anormais de ICMP/RST.
2. Teste a política do pf em paralelo. Use pfctl -nf e um lab ou janela de manutenção. Na primeira ativação, cuide do SSH da LAN para o firewall—nada pior do que se trancar para fora.
3. Aperte a saída (egress). Ative enforcement de DNS e observe. Depois, vá fechando progressivamente os serviços clássicos de risco. Uma ou duas semanas de monitoramento ajudam a achar pontos cegos.
4. Introduza uma DMZ (se fizer sentido). Migre serviços, mantenha fechados intra‑DMZ e DMZ→LAN. Abra apenas as saídas estritamente necessárias. Observe e refine.
5. Decida sobre IPv6 com intenção. Ou habilite do jeito certo—ou deixe desligado e informe os clientes.

Cada etapa eleva a segurança sem um “big bang” arriscado.

O que você pode estender facilmente mais tarde

Esta linha de base é um fundamento, não uma jaula. Extensões típicas:

• Exceções cirúrgicas para QUIC/DoH quando houver razões validadas—sempre com tabelas e rótulos.
• VPN site‑to‑site com mínima superfície de ataque; os sysctls padrão não limitam você se permitir explicitamente os protocolos.
• Monitoramento/alertas. Contadores do pf e systat pf servem para métricas básicas. Para mais, envie logs do pf a um sistema central.
• IPv6, espelhando integralmente a lógica do v4—não como enxerto.

Sobre atualizações e manutenção

O OpenBSD cumpre o que promete—mas leia as release notes em cada atualização, sobretudo sobre sintaxe do pf e padrões do kernel. Rótulos, tabelas e macros claras tornam rápida a validação entre versões. Mantenha a disciplina de comentar cada exceção: por que existe, quem precisa, quando foi a última revisão. Exceções não são pecado; exceções sem comentário viram dívida técnica.

Conclusão: clareza é o melhor endurecimento

Esta linha de base persegue um objetivo simples: clareza acima de complexidade. Você obtém um firewall OpenBSD previsível no dia a dia, com superfície de ataque reduzida, que mostra—por meio de rótulos, tabelas e padrões sensatos—o que realmente acontece. Priorizamos escolhas explícitas em vez de efeitos colaterais implícitos: política de saída estrita, DNS forçado para resolvers definidos, sem canais silenciosos via QUIC ou DoH/DoT/DoQ, estados determinísticos e alavancas robustas de kernel. O resultado não é uma peça acadêmica, e sim um ponto de partida duradouro no qual você pode construir com confiança.

Importa notar que esta linha de base intencionalmente assume sem resolvedor local e sem serviço NTP local. Ela mira ambientes que precisam estabilizar rapidamente, sem infraestrutura adicional. Se depois você quiser mais controle on‑prem, dá para adicionar sem atrito—a arquitetura já está pronta, sem abandonar a postura central.

Para poupar sua busca: abaixo você encontrará as propostas de configuração completas—ambos os perfis de pf.conf (somente roteador sem DMZ e roteador+DMZ com isolamento estrito), além do sysctl.conf endurecido. Este artigo explica as decisões; os arquivos abaixo as implementam ao pé da letra. Se você seguir a sequência “validar → carregar → medir”, chegará rapidamente a um resultado reproduzível.

Igualmente importante é ser honesto quanto ao escopo: não estão em foco aqui ataques altamente direcionados nem cenários completos de IDS/IPS. Isso não significa abrir mão deles—ao contrário. Este fundamento foi pensado para que você possa adicioná‑los com método. Três caminhos de extensão mostraram‑se úteis na prática.

Se você tem ideias para afinar regras específicas, requisitos especiais ou quer compartilhar observações da sua operação: fale com a gente. Feedback do mundo real é o melhor catalisador de melhorias significativas—e alimentará evoluções futuras. Segurança é um processo, não um sprint; com uma linha de base clara e uma comunidade que compartilha experiência, o “bom” vira “excelente” muito rápido.

Baixar sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
Baixar pf.conf (com DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
Baixar pf.conf (sem DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt