SonicWall: Boas práticas para configuração de Access Rules

As Access Rules são o núcleo do controle de tráfego no SonicWall. Uma configuração mal estruturada resulta em brechas de segurança, tráfego bloqueado inesperadamente e dificuldade de manutenção. Este guia cobre as práticas que evitam esses problemas.

Como o SonicWall processa as regras

O SonicWall percorre as regras de cima para baixo e aplica a primeira que corresponder ao tráfego. As regras têm prioridade por posição — regras no topo têm precedência sobre as abaixo.

Existe uma regra implícita no final: negar todo o tráfego de zonas menos confiáveis para mais confiáveis (ex: WAN → LAN é negado por padrão). Você não precisa criar regras de deny explícito na maioria dos casos, mas pode querer fazê-lo para registrar o bloqueio em log.

Princípio do menor privilégio

Nunca crie regra “Any → Any” entre zonas diferentes. Essa é a maior falha de configuração vista em campo.

Em vez disso:

Errado	Correto
Source: Any, Destination: Any, Service: Any	Source: Rede-Financeiro, Destination: Servidor-ERP, Service: HTTPS
SSL-VPN → LAN: Any/Any/Any	SSL-VPN → LAN: VPN-Users/Servidores-Internos/RDP+HTTP
DMZ → LAN: Any/Any/Any	DMZ → LAN: Servidor-Web/DB-Server/MySQL

Restrinja sempre ao mínimo necessário. Se surgir dúvida sobre o serviço exato, capture com Packet Capture e ajuste depois — não abra tudo “por precaução”.

Organização das regras

Nomeclatura consistente

Use nomes descritivos que identifiquem origem, destino e propósito:

[ORIGEM]-para-[DESTINO]-[SERVICO]

Exemplos:

• LAN-para-WAN-HTTP-HTTPS
• SSL-VPN-para-LAN-RDP
• DMZ-para-LAN-MySQL
• WAN-para-DMZ-HTTPS-Publicacao

Evite nomes como “Regra1”, “teste”, “nova-regra” — impossível auditar depois.

Ordem recomendada

1. Regras de negação explícita (bloqueios específicos que devem ter prioridade) — ex: bloquear IP de atacante conhecido
2. Regras permissivas específicas — do mais específico para o mais genérico
3. Regras permissivas genéricas — ex: LAN → WAN para acesso à internet
4. Regra de deny final com log (opcional, mas útil para visibilidade)

Address Objects e Service Objects

Crie Address Objects para cada rede ou servidor recorrente. Isso torna as regras legíveis e fáceis de atualizar.

Acesse Object → Match Objects → Addresses → Add.

Nome: Servidor-ERP
Tipo: Host
IP: 192.168.1.50

Quando o servidor mudar de IP, basta atualizar o objeto — todas as regras que o usam são atualizadas automaticamente.

Faça o mesmo para serviços customizados em Object → Match Objects → Services.

Regras de saída (LAN → WAN)

Evite a tentação de criar uma única regra LAN → WAN: Any/Any/Any. Embora funcional, ela oferece zero visibilidade sobre o tráfego de saída.

Estrutura recomendada:

1. LAN → WAN | HTTP+HTTPS | Allow | Log habilitado
2. LAN → WAN | DNS (UDP 53) | Allow
3. LAN → WAN | NTP (UDP 123) | Allow
4. Servidores → WAN | SMTP (TCP 25) | Allow (apenas para servidores de e-mail)
5. LAN → WAN | Any | Deny | Log habilitado  ← captura tráfego inesperado

A última regra de deny com log vai revelar aplicações tentando sair por portas não autorizadas — comum em malware e aplicações shadow-IT.

Habilitando log nas regras críticas

Por padrão, o SonicWall não loga tráfego permitido — apenas bloqueados. Habilite log seletivo nas regras:

Edite a regra → aba Advanced → marque Log this rule.

Habilite log especialmente em:

• Regras de acesso à internet com restrição
• Regras de publicação de servidores (WAN → DMZ)
• Regra de deny final

Auditoria de regras

Periodicamente, revise as regras seguindo este checklist:

• Existem regras com Source: Any ou Destination: Any? Revise se são necessárias.
• Existem regras sem log habilitado em zonas sensíveis?
• Existem regras duplicadas ou mais permissivas que as anteriores (e portanto nunca atingidas)?
• Existem regras para servidores ou sistemas que foram descomissionados?
• As regras de VPN têm restrição de usuário/grupo configuradas?

Publicação de servidores (WAN → DMZ/LAN)

Para publicar serviços para a internet (servidor web, RDP, etc.), combine Access Rule com NAT Policy:

Access Rule:

• From: WAN → To: DMZ
• Source: Any (ou IPs autorizados, se acesso restrito)
• Destination: IP Público do servidor (ou Any se NAT na frente)
• Service: HTTPS (443)
• Action: Allow

NAT Policy:

• Original Source: Any
• Translated Source: Original
• Original Destination: IP Público (X1 IP)
• Translated Destination: IP Privado do servidor (192.168.10.50)
• Original Service: HTTPS
• Translated Service: Original

Nunca publique RDP (3389) diretamente para a internet. Use VPN para acesso remoto. O RDP exposto é o vetor mais comum de ransomware.

Verificando qual regra está sendo aplicada

Quando o tráfego não se comporta como esperado, use o Packet Capture (INVESTIGATE → Packet Capture) com filtro no IP/porta problemático. O campo Drop Reason: Policy drop indica qual regra bloqueou.

---

Precisa de revisão nas Access Rules do seu SonicWall? A Callister realiza auditoria completa das políticas de firewall. Solicite uma avaliação.

Artigos relacionados

SonicWall Categorias de classificação de filtragem de conteúdo SonicWall CFS 5.0 17 de jul. de 2026 SonicWall SonicWall TZ370 e por que é hora de atualizar o firewall da sua empresa 17 de jul. de 2026 SonicWall SonicWall: Como usar o Packet Capture para diagnosticar problemas de rede 27 de mai. de 2025