Saltar para o conteudo
Avanet

Regra do Sophos Firewall não está correspondendo: Verifique as causas

Sophos Firewall

Quando uma regra de firewall não está correspondendo, raramente é porque o firewall está “quebrado”. Normalmente, uma condição não está correta, uma regra mais geral está acima, o NAT altera a visão sobre o tráfego, a correspondência de usuário não é atendida ou o registro não está devidamente ativado.

Esta lista de verificação ajuda a abordar o problema de forma sistemática, em vez de ajustar regras aleatoriamente.

Orientação

Começa com um caso de teste claro antes de alterar regras ou funcionalidades de segurança.

Qual artigo é adequado?

Problemas de regras rapidamente se sobrepõem a NAT, roteamento, VPN, Device Access ou recursos de segurança. Para a análise, deve-se primeiro esclarecer qual nível está afetado:

Essa separação é importante porque uma regra de firewall não controla todos os tipos de acesso. Serviços locais do firewall, decisões de NAT, roteamento e recursos de segurança têm seus próprios pontos de verificação.

Delimitação rápida

No início, não se deve mover regras ou alterar objetos imediatamente. Primeiro, delimite onde o tráfego está se perdendo.

  • Contador de regras permanece 0: Posição da regra, zona, origem, destino, serviço ou agendamento não correspondem
  • Log Viewer mostra uma regra diferente: Uma regra mais geral ou gerada automaticamente está acima
  • Log Viewer não mostra nada: Registro ausente ou o tráfego não chega ao firewall
  • Packet Capture não vê pacote: Problema está antes do firewall: cliente, VLAN, switch, gateway, provedor ou grupo de segurança na nuvem
  • Packet Capture vê pacotes, mas não encaminha: Regra de firewall, NAT, roteamento ou recurso de segurança bloqueia
  • Packet Capture vê encaminhamento, mas não há resposta: Verifique rota de retorno, sistema de destino, NAT ou firewall externo

Essa separação economiza tempo. Se o firewall não vê um pacote, nenhuma alteração em uma regra de firewall ajudará. Se o Log Viewer mostrar uma outra Rule ID, a ordem é mais importante do que a regra de destino afetada. Se o fluxo de pacotes e a Rule ID estiverem corretos, a análise se desloca para NAT, caminho de retorno ou recursos de segurança.

Definir claramente o caso de teste

Uma regra só pode ser testada de forma significativa se o caso de teste for claro. Declarações como “Internet não funciona” ou “VPN não funciona” são muito amplas. Para a solução de problemas, é necessário um fluxo concreto.

Antes do teste, deve-se estabelecer:

  • IP de origem: Cliente 10.10.20.35
  • Zona de origem: LAN, VPN, DMZ ou zona personalizada
  • Usuário: usuário autenticado ou sem correspondência de usuário
  • Destino: IP do servidor, FQDN, IP público ou objeto WAN
  • Serviço: TCP 443, UDP 53, ICMP, serviço personalizado
  • Regra esperada: Nome da regra ou Rule ID, se conhecido
  • Regra NAT esperada: NAT Rule ID ou nome da regra, se NAT estiver envolvido
  • Hora do teste: hora exata para Log Viewer e arquivos de log posteriores

Depois, o mesmo teste é repetido sempre. Se durante a análise o IP de origem, destino, resolução DNS ou porta mudarem, não se está mais comparando o mesmo caso.

Combinar corretamente as ferramentas de análise

O Sophos Firewall oferece várias ferramentas que respondem a diferentes perguntas. Nenhuma delas é, por si só, uma prova completa.

  • Contador de regras: O novo tráfego de teste atinge a regra em princípio? Não mostra por que uma aplicação ainda falha
  • Log Viewer: Qual Rule ID, NAT Rule ID, ação, usuário ou função de segurança foi registrada? Depende do registro e do fim da sessão
  • Policy Tester: Qual lógica de política se aplicaria a um fluxo definido? Não substitui um fluxo de pacotes real e não representa totalmente o SD-WAN
  • Packet Capture: Os pacotes chegam, são encaminhados ou descartados? Não explica cada camada de aplicação e requer filtros restritos
  • Logs de serviço: Um módulo como Web, IPS, autenticação ou VPN tem um problema próprio? Só faz sentido quando o serviço afetado é delimitado

Para um diagnóstico confiável, combina-se pelo menos o Log Viewer e um teste real. Em caso de resultados contraditórios, o Packet Capture geralmente é o próximo passo, pois mostra se os pacotes realmente chegam e continuam.

Árvore de decisão para o primeiro teste

Para a primeira análise, muitas vezes basta uma breve árvore de decisão. Ela evita que se trabalhe imediatamente em regras, NAT e roteamento ao mesmo tempo.

  • Packet Capture não vê pacote: Verifique cliente, VLAN, switch, gateway, provedor, grupo de segurança na nuvem ou firewall anterior
  • Packet Capture vê pacote, Log Viewer permanece vazio: Verifique registro, tipo de log, fim da sessão e filtro BPF adequado
  • Log Viewer mostra outra Rule ID: Compare ordem das regras, zonas, origem, destino, serviço e agendamento
  • Firewall Rule ID está correta, NAT Rule ID não está: Verifique ordem do NAT e campos Original
  • Rule ID e NAT ID estão corretas, mas não há resposta: Verifique rota de retorno, sistema de destino, firewall local no servidor ou bloqueio externo
  • Regra só não corresponde para determinados usuários: Verifique correspondência de usuário, grupo, autenticação e usuário sem cliente

Isso mantém a análise controlada: primeiro, prova-se se o tráfego atinge o firewall. Depois, verifica-se qual regra e qual regra NAT realmente correspondem. Só quando esses dois pontos estão corretos, vale a pena procurar no caminho de retorno, recursos de segurança ou camada de aplicação.

Compreender o matching de regras

Sophos Firewall processa regras por ordem. A primeira regra adequada vence.

Primeiro princípio: A primeira regra correspondente vence

O Sophos Firewall processa as regras de firewall de cima para baixo. Assim que uma regra corresponde, as regras subsequentes não são mais verificadas. O mesmo princípio básico também se aplica às regras NAT.

Importante:

  • A posição na lista decide a avaliação.
  • A Rule ID é apenas uma referência e não diz nada sobre a ordem atual.
  • Grupos de regras ajudam na visão geral, mas não são uma lógica de correspondência própria.
  • Uma regra geral acima pode “absorver” completamente uma regra específica abaixo.

Se uma regra não está correspondendo, verifica-se primeiro a posição.

Regras de firewall do Sophos Firewall com ordem de regra marcada
A posição na lista de regras de firewall decide a avaliação. A primeira regra correspondente vence, não a Rule ID mais baixa.

Redefinir contador de regras

Em caso de correspondências incertas, ajuda redefinir o contador de regras.

  1. Abra Rules and policies > Firewall rules.
  2. Encontre a regra afetada.
  3. Abra o menu de três pontos.
  4. Selecione Reset data transfer count.
  5. Reproduza o tráfego novamente.
  6. Verifique o contador após o teste.
Menu de três pontos do Sophos Firewall com Reset data transfer count
Com Reset data transfer count, redefine-se o contador de regras. Depois, é fácil ver se o novo tráfego de teste realmente cai nesta regra.

Se o contador não aumentar, a regra não está correspondendo. Se aumentar, mas a aplicação ainda não funcionar, o problema está mais provavelmente em Perfis de Segurança, NAT, roteamento, caminho de retorno ou sistema de destino.

Verificar campos de correspondência

Uma regra de firewall só corresponde se todos os critérios relevantes forem atendidos.

  • Zonas de origem: Zona errada, VLAN está em outra zona, tráfego VPN vem de VPN
  • Redes e dispositivos de origem: Objeto errado, IP errado, grupo de hosts incompleto
  • Zonas de destino: Zona de destino errada, especialmente em DNAT ou VPN
  • Redes de destino: Confusão entre visão pré-NAT e pós-NAT
  • Serviços: Porta ausente, TCP/UDP trocados, aplicação usa portas adicionais
  • Usuários ou grupos: Usuário não autenticado ou grupo errado
  • Agendamento: O cronograma não é adequado no momento
  • Exclusões: Tráfego é excluído da regra e processado abaixo
Regra de firewall do Sophos Firewall com origem, destino e serviços
Uma regra de firewall só corresponde se a zona de origem, redes e dispositivos de origem, zonas de destino, redes de destino, serviços e agendamento corresponderem simultaneamente.

Para tráfego web, deve-se verificar adicionalmente se o QUIC está ativo. Quando navegadores enviam tráfego via UDP 443, algumas expectativas de filtro web e escaneamento se aplicam de forma diferente do HTTPS clássico via TCP.

Mais sobre isso: Sophos Firewall e o protocolo QUIC.

Não esquecer DNS, FQDN e IPv6

Uma regra pode parecer correta e ainda assim não corresponder se o cliente alcançar um destino diferente do esperado. Isso acontece frequentemente com objetos FQDN, DNS dividido, serviços CDN, IPv6 ou aplicações que usam vários destinos em paralelo.

Antes de alterar regras, deve-se verificar:

  • Qual IP o cliente realmente resolve?: Cache DNS, DNS dividido ou outro resolvedor podem fornecer um endereço diferente do esperado.
  • É IPv4 ou IPv6?: Regras IPv4 não correspondem ao tráfego IPv6. Se os clientes preferirem IPv6, o lado IPv6 deve ser verificado separadamente.
  • Um host FQDN é usado no firewall?: O firewall deve resolver o FQDN e conhecer o IP de destino atual. Serviços CDN ou em nuvem podem fornecer vários IPs variáveis.
  • A aplicação usa destinos adicionais?: Login, API, atualizações, telemetria ou caminhos de mídia podem usar domínios e portas diferentes da aplicação principal.
  • Um cliente interno usa o nome público de um serviço interno?: Então, DNS dividido, NAT loopback ou uma resolução pública incorreta são possíveis causas.

Para a solução de problemas, é crucial não apenas anotar o nome do host, mas comparar o IP de destino realmente usado no Log Viewer ou Packet Capture. Se uma regra aponta para um objeto FQDN ou host específico, mas o cliente usa um IP diferente, a regra não corresponderá.

Para resoluções de nomes internas, ajudam rotas de solicitação DNS limpas. O procedimento está em Configurar rotas de solicitação DNS no Sophos Firewall. Se o IPv6 estiver ativo no ambiente, deve-se verificar adicionalmente se o IPv6 está planejado conscientemente e se a política adequada está presente. Fundamentos sobre isso estão em Configurar delegação de prefixo IPv6 no Sophos Firewall.

Um caso especial frequente são objetos FQDN. Se os clientes preferirem IPv6, mas uma regra usar apenas objetos IPv4 ou um host FQDN com resolução IPv4, o fluxo IPv6 real não corresponde. A regra parece tecnicamente correta, mas não processa o tráfego que realmente passa na rede. Nestes casos, resposta DNS, versão IP e policy devem ser verificadas separadamente.

Tráfego para o próprio firewall é um caso especial

Nem todo acesso a um Sophos Firewall é controlado por regras de firewall normais. Se o cliente deve acessar o próprio firewall, por exemplo, WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS ou SNMP, Device Access e Local service ACL são decisivos.

Exemplos típicos:

  • WebAdmin de LAN ou WAN: Device Access, Local service ACL, MFA, permissão de administrador
  • VPN Portal ou User Portal: Device Access, configuração do portal, permissão de usuário
  • SSH no firewall: Device Access, Local service ACL, direitos de administrador, rede de origem
  • Conexão SSL VPN ou IPsec: Device Access para a zona apropriada, configuração VPN, autenticação
  • DNS para o firewall: Device Access, configuração DNS, caminho de solicitação
  • SNMP para o firewall: Device Access, configuração SNMP, fonte de monitoramento

Se uma regra de firewall não corresponder para esse tipo de tráfego, muitas vezes não é um erro da regra. O tráfego termina no firewall e é tratado como um serviço local. Para o fortalecimento desses serviços, Proteger o acesso ao Sophos Firewall: Configurar corretamente o Device Access é o artigo central. Para portais, também é adequado Visão geral dos portais Sophos.

Verificar NAT, DNAT e IDs

Para tráfego DNAT, as regras de firewall e NAT devem ser lidas em conjunto.

Ler corretamente o DNAT

No DNAT, a visão nas regras de firewall é especialmente importante. Como regra geral, pode-se lembrar:

Regras de firewall para tráfego DNAT usam a zona de destino após o NAT, mas o IP de destino antes do NAT.

Exemplo:

  • Cliente externo se conecta ao IP WAN do firewall.
  • NAT traduz para um servidor interno na DMZ.
  • A regra de firewall usa como zona de destino a zona do servidor interno, por exemplo, DMZ.
  • A rede de destino permanece o IP público ou o objeto WAN que o cliente acessou.

Se essa combinação estiver errada, a regra NAT pode parecer correta, mas a regra de firewall ainda assim não corresponderá.

Mais sobre isso: Publicar servidor via DNAT no Sophos Firewall.

Verificar regras NAT

O NAT não permite tráfego. O NAT apenas traduz. Sempre é necessária uma regra de firewall correspondente.

Em Rules and policies > NAT rules, deve-se verificar:

  • A regra NAT correspondente está acima de regras NAT mais gerais?
  • A regra está ativa?
  • Origem, destino e serviço originais estão corretos?
  • Origem, destino e serviço traduzidos estão corretos?
  • MASQ ou um IP SNAT fixo está sendo usado?
  • Existe uma Linked NAT Rule que está correspondendo inesperadamente?
  • Existe uma regra SNAT genérica que corresponde antes de uma regra mais específica?

A Sophos recomenda para ambientes simples, na maioria das vezes, regras NAT independentes, em vez de criar uma Linked NAT Rule por regra de firewall.

Mais sobre isso: Compreender NAT no Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Ler corretamente a Firewall Rule ID e a NAT Rule ID juntas

Quando o NAT está envolvido, a pergunta “Qual regra de firewall está correspondendo?” não é suficiente. Uma conexão pode atingir a Firewall Rule ID esperada, mas ainda assim passar por uma NAT Rule ID errada. Por outro lado, uma regra NAT pode parecer correta, enquanto uma regra de firewall mais geral acima já processa o tráfego.

Para o teste, deve-se anotar previamente:

  • Firewall Rule ID esperada: Mostra se a regra de firewall correta permite ou bloqueia o tráfego
  • NAT Rule ID esperada: Mostra se a regra SNAT, DNAT, MASQ ou PAT correta está traduzindo
  • IDs reais no Log Viewer: Comprova se o firewall processa o fluxo conforme planejado
  • IDs no Packet Capture: Ajuda quando o Log Viewer parece incompleto ou o caminho de retorno está incerto

A interpretação é relativamente simples, mas economiza muito tempo de busca:

  • Firewall Rule ID está correta, NAT Rule ID está errada: Verifique ordem do NAT, campos Original e regras NAT mais gerais
  • NAT Rule ID está correta, Firewall Rule ID está errada: Verifique ordem das regras de firewall, zonas, origem, destino e serviço
  • Ambas as IDs estão corretas, mas a conexão ainda falha: Verifique caminho de retorno, servidor de destino, recurso de segurança ou aplicação
  • Nenhuma NAT Rule ID visível, embora o NAT seja esperado: Verifique fluxo de teste, critérios NAT, direção e registro novamente

É importante não reconstruir imediatamente ambos os conjuntos de regras ao mesmo tempo. Primeiro, decide-se se o problema está na correspondência de firewall ou na correspondência de NAT. Só depois deve-se alterar uma posição de regra concreta, um objeto ou um campo. A avaliação mais detalhada do NAT está na seção Ler corretamente a Firewall Rule ID e a NAT Rule ID.

Verificar utilizadores, routing e funcionalidades de segurança

User Matching, routing, NAT, logging e perfis de segurança podem influenciar se uma regra se aplica.

Verificar correspondência de usuário e autenticação

Regras com correspondência de usuário ou grupo muitas vezes parecem corretas, mas só correspondem se o firewall puder realmente atribuir o usuário ao tráfego naquele momento.

Para verificar:

  • O usuário está visível no Log Viewer?
  • O tráfego vem do dispositivo esperado ou de outro cliente?
  • O usuário está no grupo de firewall correto?
  • O AD SSO, STAS, Captive Portal, RADIUS ou Entra ID SSO estão funcionando?
  • Uma regra sem correspondência de usuário está acima da regra de usuário planejada?
  • Existem usuários sem cliente que são tratados de forma diferente?
  • O MFA ou acesso ao portal são bem-sucedidos, mas a regra de firewall para o tráfego real está errada?

No acesso remoto, deve-se separar problema de usuário e problema de VPN. Um usuário pode se autenticar com sucesso, mas ainda assim não conseguir acessar uma aplicação interna se o pool VPN, regra de firewall, NAT ou roteamento não estiverem corretos. Para fundamentos do AD, veja Adicionar Active Directory no Sophos Firewall, para cenários de acesso remoto baseados em Entra, veja Microsoft Entra ID SSO para Sophos Connect e VPN Portal. Se o usuário estiver logado via Captive Portal com Entra ID SSO, veja Configurar Microsoft Entra ID SSO para Sophos Firewall Captive Portal.

Separar login de usuário e correspondência de regra

Um login bem-sucedido no VPN Portal, User Portal, Captive Portal ou via Microsoft Entra ID SSO não prova que a regra de usuário planejada está correspondendo ao tráfego real. O login confirma apenas a autenticação. Depois, o firewall deve combinar corretamente o usuário, o IP de origem, o grupo e o fluxo de tráfego.

Para a análise, deve-se verificar separadamente:

  • Usuário se autentica, contador de regras permanece 0: Verifique pool VPN, zona de origem, rede de origem, condição de grupo ou posição da regra
  • Campo de usuário no Log Viewer está vazio: Verifique STAS, Captive Portal, AD SSO, Entra ID SSO ou usuário sem cliente
  • Usuário está visível, mas regra errada corresponde: Verifique ordem das regras, filtro de grupo ou regra mais geral acima
  • Apenas usuários VPN são afetados: Verifique zona VPN, pool VPN, configuração SSL/IPsec e perfil Sophos Connect
  • Apenas usuários individuais são afetados: Compare UPN, endereço de e-mail, grupo importado e grupo de firewall

Em ambientes AD locais, ajudam STAS e Adicionar Active Directory no Sophos Firewall. Em configurações baseadas em Entra, deve-se verificar, dependendo do caminho de login, Microsoft Entra ID SSO para Sophos Connect e VPN Portal ou Entra ID SSO para Captive Portal. Se muitos usuários ou usuários sem cliente estiverem envolvidos, o Limite de ID de usuário do Sophos Firewall pode ser relevante.

Verificar roteamento e SD-WAN

Se a regra corresponder, mas a conexão não funcionar, o roteamento pode ser o problema.

Verifique:

  • Existe uma rota padrão adequada?
  • Existe uma rota estática?
  • Uma rota SD-WAN está ativa?
  • O gateway está ativo?
  • Existem rotas de retorno no sistema de destino ou na rede remota?
  • O caminho de retorno é simétrico?
  • O tráfego passa por VPN, MPLS ou outra interface diferente do esperado?

Importante: O Policy Tester não representa totalmente o roteamento SD-WAN. Ele é muito útil para decisões de política de firewall, SSL/TLS e web, mas não substitui um teste de fluxo de pacotes real.

Mais sobre isso: Ajustar a prioridade de roteamento no Sophos Firewall.

Ativar registro

Sem logs, a solução de problemas se torna difícil. Verifique dois locais:

  1. Na regra de firewall, Log firewall traffic deve estar ativado.
  2. Em System services > Log settings, o tipo de log apropriado deve estar ativado localmente, para o Sophos Central ou para Syslog.

O Log Viewer geralmente mostra sessões de firewall quando o firewall encerra uma conexão e recebe um evento Destroy. Se uma conexão de internet simplesmente cair, pode ser que nem toda sessão apareça como esperado.

O Log Viewer é aberto no canto superior direito do console WebAdmin. Filtros úteis são:

  • IP de origem
  • IP de destino
  • Porta ou serviço
  • Rule ID
  • Nome da regra
  • Ação
  • Usuário
  • NAT rule ID
Log Viewer do Sophos Firewall com Firewall rule ID e NAT rule ID
No Log Viewer, vê-se quais Firewall Rule ID e NAT Rule ID processaram o tráfego. Isso é frequentemente mais rápido do que procurar apenas pelo nome da regra ou endereço IP.

Mais sobre isso: Solução de problemas no Sophos Firewall: Serviços e Logs.

Usar Packet Capture

Se o Log Viewer e o contador de regras não forem suficientes, use Diagnostics > Packet capture.

A pergunta mais importante é se o pacote chega, é encaminhado ou já fica retido no firewall.

Packet Capture do Sophos Firewall com filtro BPF, NAT ID e Rule ID
Packet Capture mostra se os pacotes chegam, por qual interface passam e quais NAT ID ou Rule ID são visíveis. O filtro BPF mantém a saída pequena e legível.
  • Nenhum pacote chega: Problema está antes do firewall: cliente, switch, VLAN, gateway, provedor, grupo de segurança na nuvem
  • Pacote entra, mas não sai: Verifique regra de firewall, NAT, roteamento ou recurso de segurança
  • Pacote sai, mas não há resposta: Verifique rota de retorno, sistema de destino, NAT ou bloqueio externo
  • Pacote é exibido com Violation: Política ou recurso de segurança bloqueia
  • Pacote mostra NAT ID e Rule ID: Compare correspondências de regra e NAT de forma direcionada

Mais sobre isso: Usar a ferramenta Packet Capture no WebAdmin.

Não altere várias coisas ao mesmo tempo

Em problemas de regras, é tentador ajustar posição, serviço, NAT, política web e roteamento ao mesmo tempo. Isso às vezes resolve o acesso a curto prazo, mas torna a causa difícil de rastrear mais tarde.

É melhor seguir uma abordagem passo a passo:

  1. Anote o estado inicial: Rule ID, NAT ID, origem, destino, serviço, hora.
  2. Faça exatamente uma alteração.
  3. Repita o teste com o mesmo IP de origem e destino.
  4. Compare novamente Log Viewer e Packet Capture.
  5. Documente o resultado.
  6. Só então verifique a próxima alteração.

Para regras produtivas, também deve estar claro se uma alteração é permanente ou apenas uma regra de teste. Regras temporárias devem ter um proprietário e uma data de expiração, caso contrário, muitas vezes permanecem no conjunto de regras por anos.

Verificar recursos de segurança individualmente

Se a regra corresponder, mas a aplicação não funcionar, um perfil de proteção pode estar interferindo:

  • Política Web
  • Regra de inspeção SSL/TLS
  • Perfil de Descriptografia
  • Política IPS
  • Controle de Aplicação
  • Verificação de Malware
  • Proteção contra ameaças de dia zero
  • Security Heartbeat
  • Modelagem de Tráfego

Para testes, não se pode desativar tudo permanentemente de forma geral. É melhor: verificar brevemente de forma direcionada, observar o Log Viewer e depois resolver a causa de forma limpa. Para inspeção TLS, o artigo Implantar inspeção TLS no Sophos Firewall gradualmente é útil.

Para regras produtivas, não se deve considerar recursos de segurança como um bloco único. É melhor delimitar um módulo após o outro:

  • Categoria web ou URL é bloqueada: Verifique política web, categoria, exceção e Log Viewer
  • Aplicação é reconhecida incorretamente: Verifique controle de aplicação e log IPS
  • Página HTTPS só carrega sem inspeção: Verifique regra de inspeção SSL/TLS, distribuição de CA, perfil de descriptografia e exceções
  • Conexão cai com grandes dados: Verifique MTU/MSS, caminho VPN, fragmentação e Packet Capture
  • Acertos em IPS ou Proteção contra ameaças de dia zero: Avalie assinatura, política, sistema de destino e risco de falso positivo
  • Apenas usuários individuais são afetados: Verifique correspondência de usuário, Security Heartbeat, grupo e autenticação

Se um perfil de proteção for removido para um teste, a alteração deve ser estritamente limitada: apenas a origem afetada, apenas o destino específico, apenas para o período de teste. Depois, a proteção original deve ser restaurada ou uma exceção documentada.

Verificar o histórico de alterações

Uma regra também pode deixar de corresponder porque algo mudou em segundo plano. Nem sempre a causa está na própria regra.

  • A regra funcionava anteriormente: Verificar Audit logs e última alteração
  • Objetos alterados: Comparar hosts, services, zones, groups e FQDN
  • Alteração via Sophos Central: Verificar Task Queue e estado da implementação
  • Vários administradores trabalham em paralelo: Clarificar proprietário, ticket e hora da alteração
  • Problema surge após restore ou importação: Comparar configuração, interfaces, zonas e NAT

Para rastrear alterações, são úteis verificar os Sophos Firewall Audit Trail Logs e utilizar o Sophos Firewall Config Studio. Se a alteração vier do Sophos Central, deve verificar também a Sophos Central Firewall Management Task Queue.

Processo prático e causas típicas

A maioria dos problemas de matching pode ser rapidamente delimitada com uma sequência fixa de troubleshooting.

Causas comuns

  • Contador de regras permanece 0: Posição da regra, zona de origem, zona de destino ou serviço incorretos
  • Log mostra outra regra: Regra mais geral está acima
  • Nenhum log visível: Registro não ativo ou tráfego não chega ao firewall
  • DNS funciona, web não: Verifique serviço, política web, inspeção TLS ou QUIC
  • Nome do host está correto, mas IP de destino é diferente: Verifique DNS, objeto FQDN, DNS dividido, CDN ou IPv6
  • HTTPS não é escaneado: Nenhuma regra de inspeção SSL/TLS correspondente ou CA não distribuída
  • DNAT não funciona: Regra de firewall usa zona de destino ou rede de destino incorretas
  • Tráfego VPN não corresponde: Verifique zona VPN, rota, interface de túnel ou contexto XFRM
  • Apenas alguns usuários são afetados: Verifique correspondência de usuário, grupo, SSO, Captive Portal ou Heartbeat

Procedimento prático

  1. Anote o problema com IP de origem, destino, porta, usuário e hora.
  2. Verifique a posição da regra.
  3. Redefina o contador de regras.
  4. Reproduza o teste.
  5. Filtre o Log Viewer com IP de origem e IP de destino.
  6. Verifique regra NAT e roteamento.
  7. Inicie Packet Capture com filtro restrito.
  8. Verifique perfis de segurança apenas de forma direcionada.
  9. Documente a alteração.

Para um fluxo de teste combinado, veja Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

Lista de verificação para solução de problemas de regras

  • Caso de teste concreto definido com origem, destino, serviço, usuário e hora.
  • Posição da regra verificada e contador de regras redefinido para o teste.
  • Log Viewer mostra a Rule ID esperada ou uma outra regra compreensível.
  • Resolução DNS, IP de destino real e versão IP foram comparados com o caso de teste.
  • Em DNAT, a zona de destino após NAT e a rede de destino antes do NAT estão corretamente definidas.
  • NAT Rule ID foi verificada, se o NAT estiver envolvido.
  • Tráfego para o próprio firewall foi separado do tráfego através do firewall.
  • Correspondência de usuário foi avaliada apenas se o usuário estiver visível no Log Viewer.
  • Em regras de usuário, login, atribuição de usuário e decisão de regra real foram avaliados separadamente.
  • Roteamento, SD-WAN, gateway e caminho de retorno foram verificados.
  • Packet Capture mostra Incoming, Forwarded, Violation ou resposta ausente de forma compreensível.
  • Recursos de segurança foram verificados individualmente e não desativados permanentemente de forma geral.
  • Alterações de teste estão documentadas e regras temporárias têm proprietário e data de expiração.

FAQ

Por que uma regra do Sophos Firewall não está correspondendo?

Geralmente, pelo menos um critério de correspondência não está correto: posição da regra, zona de origem, zona de destino, objeto de origem, objeto de destino, serviço, agendamento, correspondência de usuário ou contexto NAT. Primeiro, deve-se verificar Log Viewer, Rule ID e Packet Capture.

Por que o Log Viewer mostra uma regra diferente da esperada?

Provavelmente, uma regra mais geral está acima ou o tráfego parece diferente do esperado do ponto de vista do firewall. Posição da regra, zonas, NAT e campos de origem/destino são então mais importantes do que o nome da regra.

Por que não se vê nenhuma entrada de log?

Ou Log firewall traffic não está ativo na regra, o tipo de log apropriado está desativado ou o tráfego não chega ao firewall. Packet Capture ajuda a distinguir se o pacote chega ou não.

As regras de firewall também se aplicam ao WebAdmin, SSH ou VPN Portal?

Não como no tráfego de passagem normal. Acessos a serviços locais do firewall são controlados por Device Access e Local Service ACL. Regras de firewall normais são responsáveis pelo tráfego através do firewall.

Por que o DNAT não funciona, embora a regra NAT esteja correta?

Frequentemente, a regra de firewall correspondente está incorreta. No DNAT, a regra de firewall usa a zona de destino após o NAT, mas a rede de destino antes do NAT. Além disso, a ordem do NAT, o registro e o caminho de retorno devem estar corretos.

O Policy Tester é uma prova de tráfego real?

Não. O Policy Tester é útil para lógica de política, mas não é um teste de fluxo de pacotes real. Roteamento, SD-WAN, caminho de retorno, comportamento do provedor e sistemas de destino devem ser verificados com Log Viewer e Packet Capture.

Por que uma regra de usuário não está correspondendo, embora o login VPN funcione?

O login VPN prova apenas que a autenticação funciona. Para a regra de firewall, a zona de origem, pool VPN, atribuição de usuário, grupo, serviço, destino e posição da regra também devem corresponder. No Log Viewer, deve-se verificar se o usuário está realmente visível no tráfego afetado e qual Rule ID processa o fluxo.

Por que uma regra com destino FQDN não está correspondendo?

Frequentemente, o cliente usa um IP de destino diferente do esperado. As causas são cache DNS, DNS dividido, endereços CDN, outro resolvedor ou IPv6. No Log Viewer ou Packet Capture, o IP de destino realmente usado deve ser comparado com o objeto FQDN ou host da regra.