O Que Faz A Regra Abaixo Acl Localnet Src 192.168.1.0/24

Entendendo regras de firewall IPFW no dia a dia

A maior parte das pessoas que trabalha com FreeBSD se depara pela primeira vez com a configuração do IPFW quando precisa restringir o acesso à rede interna. A sintaxe parece complicada no começo, mas na prática é mais simples do que parece. Eu passei horas tentando entender por que uma regra não estava funcionando como esperado antes de perceber que o problema estava na ordem de avaliação e não no conteúdo em si. O IPFW avalia as regras na ordem em que aparecem na configuração. A primeira que corresponde ao pacote é a que age. Isso significa que uma regra mal posicionada pode bloquear totalmente o tráfego ou permitir acesso que você não pretendia abrir. É um detalhe que causa dor de cabeça constante.

o que faz a regra abaixo acl localnet src 192.168.1.0/24

A regra acl localnet src 192.168.1.0/24 define uma política de acesso permitindo que pacotes vindos da sub-rede 192.168.1.0/24 sejam classificados como parte da rede local. O componente acl é um access list no IPFW que serve para marcar pacotes com um identificador, permitindo que regras posteriores façam ações específicas baseadas nessa marcação. O src indica a origem, ou seja, o endereço de onde o pacote está vindo. Na prática, eu usei essa configuração em um servidor que precisava liberar acesso SSH apenas para a rede interna e bloquear tentativas externas. A regra marcava todos os pacotes vindos de 192.168.1.0/24 como trusted, e depois eu criava uma regra de allow para conexão na porta 22 apenas para pacotes marcados. Funcionou perfeitamente, mas demorei para entender que o IPFW não aplicava a marcação se a regra ACL estivesse depois de uma regra reject genérica. O formato completo normalmente seria algo como: allow tcp from 192.168.1.0/24 to any 22. A parte acl por si só não permite ou bloqueia nada. Ela apenas classifica. É importante não confundir classificação com ação. Muitas pessoas colocam a regra ACL sozinha e ficam confusas quando o tráfego continua sendo bloqueado pelas regras subsequentes.

Outro ponto que causa confusão é o tratamento do /24. Ele significa que qualquer endereço de 192.168.1.0 até 192.168.1.255 se encaixa na regra. Se você tiver hosts com IPs fora dessa faixa e esperar que sejam aceitos também, vai precisar adicionar regras específicas para cada sub-rede adicional. O IPFW não faz suposições.

Configuração prática no sistema

Para aplicar essa regra, você precisa editar o arquivo de configuração do IPFW, normalmente em /etc/sysctl.conf ou em um script separado chamado firewall.sh. O comando sysctl net.inet.ip.fw.enable=1 ativa o firewall, mas a carga das regras vem do rc.conf com a variável firewall_enable="YES". Sem isso, o serviço nem sobe na inicialização. Eu já perdi tempoando problemas porque a regra estava no arquivo certo, mas o serviço não estava habilitado no rc.conf. O IPFW fica inerte se não for carregado explicitamente. Um detalhe bobo, mas que trava iniciantes. Depois de declarar a regra ACL, você precisa de uma regra de ação. Algo como: allow tcp from 192.168.1.0/24 to any 22. Sem essa linha, a marcação existe mas não gera efeito prático. O firewall vai continuar aplicando o comportamento padrão, que em configurações limpas costuma ser bloqueio de tudo que não foi explicitamente permitido.

Uma coisa que ninguém conta nos tutoriais básicos é que o IPFW tem um modo de logging embutido. Você pode adicionar a palavra log antes ou depois da ação para registrar no /var/log/messages os pacotes que passaram por aquela regra. Foi assim que eu descobriu que um host na rede estava fazendo scanning de portas, algo que as regras normais não bloqueavam porque vinham de dentro do range permitido.

Problemas comuns e como resolver

O erro mais frequente é a ordem das regras. Se você colocar uma regra reject all antes da sua regra ACL, a ACL nunca será atingida. O IPFW para na primeira correspondência. Sempre coloque as regras específicas antes das regras genéricas de bloqueio. Essa ordem inversa é contra-intuitiva para quem vem de iptables, onde a lógica pode ser diferente. Outro problema recorrente é a máscara de rede. Se sua rede real for 192.168.1.0/25 e você colocar /24, estará liberando endereços que não existem na sua topologia. Pode parecer inofensivo, mas em ambientes corporativos isso abre brechas que auditores de segurança levam semanas para identificar. Sempre confirme a faixa real com um ipcalc ou comando similar antes de escrever a regra. Um caso específico que eu enfrentei foi com VLANs. Meu servidor tinha duas interfaces de rede, cada uma ligada a uma VLAN diferente. A regra ACL com src 192.168.1.0/24 só avaliava o source IP, sem considerar a interface de entrada. Pacotes de outra VLAN mas com IP na mesma faixa conseguiam passar. A solução foi adicionar a condição in interface_name para vincular a regra à interface correta.

Performance também merece atenção. Regras ACL demais podem aumentar o tempo de processamento de cada pacote, especialmente em servidores com alto throughput. Em testes práticos, uma configuração com mais de cinquenta regras ACL começou a mostrar latência perceptível em conexões simultâneas. A recomendação é consolidar ranges quando possível e usar tabelas externas para listas grandes de endereços.

Alternativas e quando não usar

Se o seu cenário for simples, talvez pf ou even nftables sejam mais adequados. O IPFW é poderoso mas exige familiaridade com sua lógica de avaliação. Para usuários que precisam de uma solução rápida e menos propensa a erros de ordem, o pf do OpenBSD oferece uma sintaxe mais previsível e documentação mais acessível. Eu mesmo migrei parte da minha infraestrutura para pf justamente porque o IPFW estava causando problemas de manutenção em longo prazo. Regras que funcionavam há anos pararam de fazer sentido após atualizações de sistema, e o debug ficava cada vez mais caro em tempo. Nem todo mundo precisa do IPFW, e admitir isso evita sofrimento desnecessário. O importante é entender o que cada linha faz antes de aplicar. Copiar regras da internet sem ler é a causa número um de violações acidentais em servidores FreeBSD. A regra acl localnet src 192.168.1.0/24 é útil, mas apenas quando combinada corretamente com as ações que realmente.