Testar com sucesso uma regra de Sophos Firewall

Uma regra de firewall não deve apenas ser salva, mas também testada especificamente. Especialmente em casos de filtragem da web, inspeção TLS, NAT, IPS ou correspondência de utilizador, uma regra pode parecer correta visualmente e ainda assim não funcionar conforme o esperado.

Diversas ferramentas podem ser usadas para testes:

• Log Viewer para eventos reais e decisões de regras
• Policy tester para web, firewall e lógica de política SSL/TLS
• Captura de pacotes para fluxo real de pacotes
• tcpdump para capturas mais longas, ficheiros PCAP e casos de suporte

A ordem correta é importante: primeiro verifica-se se o teste está bem definido e se a regra gera registos. Log Viewer mostra então qual decisão a firewall realmente registou. Policy tester ajuda com a lógica de política esperada, mas não testa o fluxo real de pacotes. Packet Capture é a melhor evidência quando o encaminhamento, NAT, VLAN, VPN, o provedor ou um sistema de destino pode estar envolvido. Se o teste precisar ser executado por mais tempo, um ficheiro PCAP for necessário ou a captura precisar ser avaliada pelo suporte Sophos, tcpdump at Sophos Firewall é a melhor ferramenta.

Um bom teste de regras não responde apenas se uma regra “funciona”. Ele mostra qual Rule ID realmente correspondeu, qual NAT ID participou, se funções de segurança estavam envolvidas e se as viagens de ida e volta seguem o mesmo caminho esperado.

Qual item é adequado?

Este artigo é a introdução correta caso precise testar uma tentativa de ligação específica com IP de origem, destino, serviço e horário. Para problemas relacionados, um artigo mais específico costuma ser mais rápido:

• Uma regra não corresponde ou ganha outra regra: Sophos Firewall regra não corresponde: revisão causa.
• DNAT, SNAT, MASQ ou a ordem de NAT estão envolvidos: Entenda NAT em Sophos Firewall.
• Um servidor interno é publicado na Internet: Servidor de publicação usando DNAT.
• Packet Capture mostra quedas, Violation ou motivos inesperados para queda: Analisar pacotes descartados em Sophos Firewall.
• SSL VPN está ligado, mas os destinos internos não estão funcionando: Configurar Remote Access SSL VPN em Sophos Firewall.
• Site-to-Site-IPsec ou Remote-Access-IPsec apresenta problemas: Resolução de problemas de IPsec VPN em Sophos Firewall.
• As ferramentas WebAdmin não são suficientes e os logs locais são necessários: Mapear corretamente os logs de serviço Sophos Firewall.
• Um caso de suporte precisa de ficheiro de log, dados de IPsec ou ficheiros PCAP: Salvar logs de Sophos Firewall para suporte e análise.

Esta delimitação evita que um problema específico de NAT, VPN, encaminhamento ou serviço seja investigado de forma muito ampla com um teste prático.

Classificação correta das ferramentas

• Log Viewer: mostra ID de regra, ID NAT, decisões de ação, utilizador e função de segurança. Não mostra pacotes que não alcançam a firewall.
• Policy tester: mostra a política esperada de firewall, web e SSL/TLS para entradas definidas. Ele não demonstra o caminho de retorno real, SD-WAN, perda de pacotes ou comportamento do provedor.
• Captura de pacotes: mostra se os pacotes chegam, são encaminhados e se as respostas retornam. Ele não explica automaticamente a intenção funcional por trás de uma regra ou política da Web.
• tcpdump: é para capturas mais longas, filtros BPF muito precisos, ficheiros PCAP e análises no Wireshark. As decisões de ID de regra, ID NAT ou Política da Web não são vistas diretamente em WebAdmin.
• Central Reporting ou Syslog: ajuda para histórico, relatórios, correlação SIEM e avaliação posterior. Para fluxo de pacotes em tempo real e detalhes de serviços locais, as ferramentas locais geralmente são mais rápidas.

Se uma regra supostamente “não funciona”, a regra em si não deve ser alterada imediatamente. Muitas vezes a causa é NAT, encaminhamento, uma regra superior, registo em log ausente ou um recurso de segurança. Para resolução de problemas sistemática, Regra para Sophos Firewall não corresponde: Verifique as causas também é adequado.

Para resolução de problemas em tempo real, o Log Viewer local geralmente é mais rápido que Central Reporting ou SIEM. Os logs centralizados são importantes quando os eventos precisam ser reconstruídos posteriormente, correlacionados ou retidos por um longo período de tempo. Para configuração, Central Firewall Reporting e enviar Syslog para SIEM são adequados.

Breve procedimento para testar regras

Para a maioria dos casos de suporte, um procedimento claro é suficiente:

1. Defina o caso de teste com IP de origem, destino, serviço, utilizador e horário.
2. Ative Registrar tráfego de firewall na regra afetada.
3. Verifique a posição da régua e do contador de utilização.
4. Execute o teste exatamente uma vez.
5. Filtrar Log Viewer por IP origem, IP destino e serviço.
6. Nota ID da regra e ID NAT do registo real.
7. Use Policy tester apenas para lógica de política.
8. Inicie Packet Capture se Log Viewer e Policy tester não corresponderem.
9. Documente o resultado antes de mover ou alterar uma regra.

É importante alterar apenas um caso de teste por passagem. Se a posição da regra, NAT, DNS, encaminhamento e cliente forem alterados ao mesmo tempo, o sucesso subsequente não poderá mais ser atribuído de forma limpa.

Este procedimento evita que uma regra de trabalho seja modificada desnecessariamente, mesmo que o verdadeiro problema esteja no NAT, no encaminhamento, no DNS, na inspeção TLS ou em um sistema alvo.

Antes do teste

Primeiro deve anotar exatamente o que vai testar:

• IP de origem: 172.16.10.25
• Utilizador: user@domain.local
• Zona de origem: LAN
• Destino: https://www.example.com
• Serviço: HTTPS
• Regra esperada: LAN_to_WAN_Clients
• Ação esperada: permitido, bloqueado, descriptografado, não descriptografado

Em seguida, ative Registrar tráfego de firewall na regra de firewall afetada. Sem registo, Log Viewer tem ajuda limitada.

Passo 1: Verifique a posição da régua

Abra Rules and policies > Regras de firewall e verifique:

• A regra está acima de regras mais gerais?
• Está ativo?
• A visualização IPv4 ou IPv6 correta está selecionada?
• Está em um grupo de regras lógicas?
• Existem exclusões?
• Existe alguma regra criada automaticamente acima?

Se uma nova regra estiver sendo testada, o contador de utilização da regra deve ser zerado. Assim fica mais fácil ver se a regra foi realmente acionada durante o teste.

Etapa 2: Abra Log Viewer

Abra Log Viewer no canto superior direito do consola WebAdmin.

Filtros úteis:

• Módulo: Firewall
• IP de origem
• IP de destino
• Porta de destino
• ID da regra
• Nome da regra
• Ação
• Utilizador

Para tráfego da web, verifique adicionalmente:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Log Viewer é atualizado automaticamente. Para uma análise tranquila, é possível pausar a visualização ao vivo, filtrar e continuar.

Etapa 3: Faça o teste

O teste deve ser executado a partir de um cliente definido:

• Abrir site
• Enviar ping
• Porta de teste
• Iniciar aplicação
• Estabelecer ligação VPN
• Transferir ficheiro

Se possível, apenas um teste deve ser executado por vez. Caso contrário, os logs e os contadores de regras serão confundidos.

Em seguida, verifique:

• O contador de regras aumenta?
• Um log é visto em Log Viewer?
• Qual ID de regra é exibida?
• Qual ID de regra NAT é exibido?
• O tráfego é permitido ou bloqueado?
• Um recurso de segurança está ativado?

Se Log Viewer for deixado em branco, isso ainda não prova nada contra a regra. O registo, o filtro de tempo, o filtro do módulo e o fluxo real de pacotes devem ser verificados primeiro. Muitas vezes o tráfego nem chega à firewall, a regra não registra, o tipo de log errado é desativado ou o teste usa um IP de destino diferente do esperado.

Etapa 4: Usar Policy tester

Policy tester é útil se se quiser verificar qual regra de firewall, regra de inspeção SSL/TLS ou política da web teoricamente se aplicaria ao tráfego da web.

Caminho do menu:

Diagnostics > Policy tester

Entradas típicas:

• URL
• Utilizador
• Hora e dia
• IP de origem
• Zona de origem
• Método de teste

Como método de teste, por exemplo, Firewall, SSL/TLS e web é escolhido, se se quiser verificar a combinação de regra de firewall, regra de inspeção SSL/TLS e política da web.

O Policy tester não exibe apenas Accepted ou Blocked, mas também a regra de firewall correspondente, o destino reconhecido, a zona de origem e, dependendo do método de teste, mais informações da web ou SSL/TLS. Isso permite ver rapidamente se o tráfego se enquadra fundamentalmente na regra esperada.

Importante:

⚠️ O Policy tester não substitui um teste real de fluxo de pacotes. Os resultados dos testes de política não refletem de forma confiável as rotas SD-WAN. Portanto, o comportamento real pode ser diferente se SD-WAN, encaminhamento ou gateways estiverem envolvidos.

SFOS 22: Policy tester pode exibir resultados incorretos

Em SFOS 22.0 GA e SFOS 22.0 MR1, os resultados dos testes de política devem ser avaliados com cauecrã especial. Teste de Política e Teste de Rota de Política podem mostrar o tráfego como bloqueado ou atribuí-lo à regra errada em certos casos, mesmo que o tráfego de produção esteja fluindo corretamente através da firewall.

Para administradores, a consequência é importante: se Policy tester mostra um resultado inesperado, mas Log Viewer, o contador de regras e Packet Capture confirmam o fluxo real de pacotes, as regras de firewall ou NAT não devem ser alteradas imediatamente. Deve primeiro verificar se isso afeta apenas a exibição de diagnóstico.

Procedimento prático para resultados contraditórios:

1. Documente claramente o teste com origem, destino, serviço e IP do utilizador.
2. Filtrar Log Viewer por IP origem, IP destino e serviço.
3. Verifique o ID da regra e o ID da regra NAT do registo real.
4. Inicie Packet Capture com um filtro estreito.
5. Compare o tráfego de entrada, encaminhamento e retorno.
6. Trate o resultado Policy tester apenas como uma indicação, não como um único teste.
7. Verifique a versão do firmware e os problemas conhecidos do Sophos antes de alterar as regras de produção.

Esta precaução é especialmente importante durante as janelas de manutenção. Um resultado de diagnóstico incorreto não deve levar ao reordenamento de regras produtivas em funcionamento ou ao ajuste de regras NAT sem evidências.

O Policy tester é especialmente bom para:

• Política da Web
• Categorização de URL
• Contexto do utilizador
• Programação
• Regra de inspeção SSL/TLS
• Regras de firewall correspondentes para tráfego da web

É menos bom para:

• decisões reais de encaminhamento
• caminho de retorno NAT
• perdas de pacotes
• problemas com provedor ou switch
• aplicações com múltiplas ligações e portas

Etapa 5: Usar Packet Capture

Se Log Viewer e Policy tester não forem suficientes, Diagnostics > Packet capture será usado.

O filtro deve ser estreito, por exemplo:

• IP de origem do cliente
• IP de destino do servidor
• Porta de destino
• Protocolo

Então:

1. Iniciar Packet Capture.
2. Faça o teste.
3. Pare Packet Capture.
4. Compare eventos recebidos e encaminhados.
5. Compare o ID da regra e o ID NAT com Log Viewer.

Interpretação:

• Nenhum pacote chega: verifique o cliente, VLAN, switch, gateway, provedor ou Cloud Security Group.
• O pacote entra, mas não sai: verifique regra de firewall, NAT, encaminhamento ou função de segurança.
• Pacote sai, mas falta resposta: verifique caminho de retorno, sistema de destino, NAT ou firewall externo.
• O pacote possui status Violation: verifique Política, IPS, filtro web ou Application Control.
• ID NAT é inesperado: verifique a ordem de NAT e regras genéricas NAT.

Mais informações: Usar ferramenta Packet Capture em WebAdmin. Se os pacotes forem descartados, Analisar pacotes descartados em Sophos Firewall também será útil.

Leia Log Viewer e Packet Capture juntos

Log Viewer mostra a decisão, Packet Capture mostra o fluxo de pacotes. Na prática, ambas as visões são frequentemente necessárias.

• Log Viewer mostra o ID de regra esperado, Packet Capture mostra Forwarded: o teste de regra é plausível para a firewall. O caminho de retorno e o sistema de destino são verificados separadamente.
• Log Viewer mostra o ID de regra esperado, Packet Capture não mostra nenhuma resposta: verifique o sistema de destino, rota de retorno, NAT ou firewall externo.
• Packet Capture mostra Incoming, mas nenhum log adequado: log de verificação, filtro de módulo, regra padrão, Device Access ou análise de queda.
• Packet Capture mostra Consumed: o tráfego termina na própria firewall. Verifique Device Access e Local Service ACL.
• Packet Capture mostra Violation: compare Motivo, ID de Regra, ID NAT e módulo de segurança com Log Viewer.

Se ambas as ferramentas parecerem contraditórias, o caso de teste deve ser reduzido primeiro. Um único cliente, um destino, uma porta e um tempo de teste curto são melhores do que uma captura ampla com muito tráfego em segundo plano.

Use filtros Packet Capture estreitos

Packet Capture só é útil se o filtro for estreito o suficiente. Uma captura muito ampla mostra rapidamente muito tráfego em segundo plano, especialmente em firewalls de produção com tráfego da Web, DNS, VPN ou de servidor. Portanto, o filtro deve ser derivado do caso de teste definido.

Exemplos práticos de BPF:

• Cliente único para um destino: host 172.16.10.25 and host 203.0.113.10, quando origem e destino são conhecidos.
• Cliente para destino HTTPS: host 172.16.10.25 and port 443, quando o destino pode mudar para DNS ou CDN.
• Apenas tráfego de saída de um cliente: src host 172.16.10.25, ao verificar pela primeira vez se o cliente está enviando.
• Apenas tráfego de resposta do cliente: dst host 172.16.10.25, quando o caminho de retorno ou pacotes de resposta estão faltando.
• Teste DNS: host 172.16.10.25 and port 53, quando a resolução de nomes e o teste de regras devem ser verificados separadamente.
• Teste ICMP: icmp and host 172.16.10.25, quando um ping serve como um teste de acessibilidade simples.

Ao testar DNAT ou VPN, atenção especial deve ser dada à direção de visão. Um filtro no IP do servidor interno não mostra necessariamente o acesso original ao IP público. Por outro lado, um filtro no IP público não mostra automaticamente se o tráfego chega ao servidor interno após NAT. Nesses casos, duas capturas curtas são muitas vezes mais limpas: primeiro no lado público e depois no destino interno.

Após o teste, a captura deve ser interrompida imediatamente. Capturas longas aumentam o risco de capturar dados desnecessários, nomes de host internos ou ligações externas.

Quando mudar para tcpdump

O Packet Capture do WebAdmin é ideal para testes rápidos. Contudo, não é suficiente para todos os casos. Deve ser alterado para tcpdump se algum destes pontos for verdadeiro:

• A captura deve ser avaliada como um ficheiro PCAP no Wireshark ou pelo suporte.
• O teste dura mais do que um breve teste de reprodução manual.
• Filtros BPF muito precisos são necessários, por exemplo, para VoIP, VPN, DNS ou múltiplos hosts.
• O buffer WebAdmin é preenchido ou exibe apenas um fragmento.
• O tráfego relevante deve ser observado em uma interface específica por um período prolongado.

Também em tcpdump se aplica: definir filtros estreitos, anotar o tempo de teste, manter a captura curta e excluir o ficheiro após a transferência. O guia prático para CLI está em Sophos Firewall tcpdump: Capturar pacotes por CLI.

Etapa 6: Validar recursos de segurança individualmente

Se a regra correta corresponder, mas o tráfego não estiver funcionando, os recursos ativados devem ser verificados individualmente.

• Política Web: revise categoria, utilizador, cronograma e ordem das políticas.
• Verificar HTTP e HTTPS descriptografado: HTTPS só será verificado se já estiver descriptografado.
• Inspeção SSL/TLS: revise a regra apropriada, o perfil de descriptografia e o certificado CA nos clientes.
• IPS: revise assinatura, política e possíveis falsos positivos.
• Application Control: revise o aplicação detectado, a categoria e a detecção de aplicações em nuvem.
• Security Heartbeat: verifica se o Endpoint envia Heartbeat e se o status é verde, amarelo ou vermelho.
• Traffic Shaping: verifica se a política está ativa e corresponde à aplicação ou regra correta.
• NAT: Verifique a regra SNAT, DNAT ou PAT correta e a ordem das regras.

Para HTTPS: Uma regra de firewall com filtragem da web não é suficiente para inspecionar o conteúdo de HTTPS. Também é necessária uma regra de inspeção SSL/TLS adequada com descriptografia e certificado CA distribuído.

Mais informações: Inspeção TLS de fase em Sophos Firewall. Para erros NAT, Understanding NAT in Sophos Firewall é apropriado, pois uma regra NAT não permite tráfego, ela apenas traduz endereços ou portas.

Etapa 7: verificar os ficheiros de log

Caso as ferramentas WebAdmin não sejam suficientes, os ficheiros de log apropriados devem ser verificados.

Ficheiros típicos:

• Regra de firewall: firewall_rule.log
• NAT: nat_rule.log
• Conexões de firewall: fwlog.log
• IPS e DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Qual ficheiro de log pertence a cada módulo está resumido em Atribuir corretamente os logs de serviço de Sophos Firewall.

Em casos de suporte, um ficheiro de log ou CTR só é realmente útil se o tempo de teste e os IDs esperados estiverem documentados. Um pacote de log grande sem origem, destino, porta, utilizador, ID de regra e ID NAT geralmente produz mais perguntas.

Exemplo: regra web de teste de LAN a WAN

1. Criar regra de firewall LAN_to_WAN_Clients.
2. Ativar registo.
3. Configurar serviços em HTTP e HTTPS.
4. Selecione a política da web.
5. Deixe Block QUIC protocol ativado.
6. Ative Scan HTTP and decrypted HTTPS.
7. Criar regra de inspeção SSL/TLS para o grupo de teste.
8. Instale o certificado CA no cliente de teste.
9. Redefinir contador de regras.
10. Abra o site.
11. Filtrar Log Viewer por IP de origem.
12. Execute Policy tester para a mesma URL.
13. Iniciar Packet Capture em caso de discrepância.

Desta forma é possível ver se a regra corresponde, se HTTPS está realmente descriptografado e se o filtro web, IPS ou controlo de aplicação está envolvido.

Documente o resultado do teste

Após um teste de regra, o resultado deve ser brevemente documentado. Isto é especialmente importante se surgir um caso de suporte, uma janela de manutenção ou uma limpeza de regras subsequente.

É útil incluir:

• Data e hora do teste
• IP de origem, utilizador, destino, serviço e URL ou aplicação testada
• ID da regra esperado e realmente correspondente
• ID da regra NAT, se NAT estiver envolvido
• Ação em Log Viewer
• Captura de ecrã ou exportação de Packet Capture, se o fluxo de pacotes fosse relevante
• Regra, política da web, regra de inspeção SSL/TLS ou regra NAT modificada
• Ponto aberto, se o comportamento ainda não estiver totalmente explicado

Nas mudanças produtivas, deve-se observar também se a regra se destina a apenas um piloto, de forma permanente ou como solução temporária. As regras de teste temporário devem ter uma data de expiração ou proprietário claro para que não sejam deixadas como cargas herdadas no conjunto de regras.

Caso o teste da regra resulte em um caso de suporte, o ficheiro de log, Packet Capture ou tcpdump PCAP, período afetado e causas já descartadas também devem ser documentados. Para esta parte cabe Salvar logs Sophos Firewall para suporte e análise.

Perguntas frequentes