Analisar pacotes descartados no Sophos Firewall

Quando o Sophos Firewall descarta pacotes, isso não é automaticamente um erro. Muitas vezes, é exatamente a decisão de segurança desejada: uma regra não se aplica, uma política bloqueia, um pacote não pertence a uma conexão conhecida ou um módulo como Webfilter, IPS ou Application Control intervém.

Torna-se complicado quando um serviço não funciona e não está claro se o firewall está bloqueando, se o tráfego não chega ou se o tráfego de retorno segue por outro caminho. Então, é necessário seguir uma sequência clara: primeiro Log Viewer, depois Packet Capture, e, se necessário, logs de serviço ou CLI.

Para correspondência geral de regras, veja Testar regra de firewall com Log Viewer, Policy Test e Packet Capture. Este artigo foca em drops e pacotes descartados.

Qual artigo de resolução de problemas é adequado?

Nem todo problema de conexão é um problema de drop. Dependendo da observação, outra abordagem pode ser mais rápida:

• Um drop, Invalid traffic, Violation ou Firewall ID 0 é visível no Log Viewer ou Packet Capture: Este artigo.
• Uma regra de firewall esperada não é acionada: Verificar causas de regra de firewall do Sophos Firewall não correspondida.
• Uma regra deve ser validada após uma alteração: Testar regra de firewall do Sophos Firewall com Log Viewer e Packet Capture.
• Pacotes devem ser verificados no WebAdmin com filtro restrito: Usar Packet Capture no WebAdmin do Sophos Firewall.
• O WebAdmin mostra pouco e são necessários arquivos de log: Resolução de problemas do Sophos Firewall: Serviços e Logs.
• Logs devem ser mantidos por mais tempo ou correlacionados centralmente: Enviar Syslog do Sophos Firewall para SIEM.
• WebAdmin, SSH, DNS, VPN Portal ou SNMP para o próprio firewall é afetado: Proteger acesso ao Sophos Firewall: Configurar Device Access corretamente.
• O túnel IPsec está ativo, mas o tráfego não flui corretamente: Resolução de problemas de VPN IPsec no Sophos Firewall.
• Grandes transferências travam ou aplicações individuais falham: Verificar MTU e MSS no Sophos Firewall para problemas de VPN.

Esta seleção economiza tempo, pois não trata cada problema como um erro de regra de firewall. Primeiro, é necessário saber se o firewall vê o tráfego, qual regra ou módulo decide e se o caminho de retorno realmente segue pela mesma rota.

Drop não é igual a Drop

Para a análise, deve-se primeiro distinguir qual tipo de drop está presente. Caso contrário, a busca pode ser feita no lugar errado.

• Drop intencional: O firewall bloqueia conforme regra, Web Policy, IPS ou Threat Feed. Verificar se a política está correta.
• Drop inesperado: Tráfego legítimo é descartado por uma regra ou módulo. Verificar Rule ID, NAT ID, módulo e motivo no Log Viewer ou Packet Capture.
• Não é drop de firewall: O tráfego não chega ao firewall ou a resposta segue outro caminho. Verificar cliente, VLAN, switch, gateway, rota, SD-WAN ou caminho de retorno.

Esta classificação evita exceções desnecessárias. Se o drop for intencional, não é necessária uma correção técnica, mas uma decisão de política. Se o tráfego não chega ao firewall, uma nova regra de firewall não ajudará. Se um módulo de segurança bloqueia, não se deve criar cegamente uma regra de firewall ampla.

Primeira classificação

Antes da análise, deve-se delimitar o erro o mais concretamente possível.

Perguntas importantes:

• Quais IPs de origem e destino são afetados?
• Qual porta e protocolo são usados?
• Trata-se de cliente-Internet, VPN site-to-site, acesso remoto, DNAT, WAF ou tráfego interno?
• O erro é permanente ou esporádico?
• Afeta apenas uma aplicação, um usuário ou uma rede inteira?
• Uma regra de firewall, regra de NAT, rota, regra de SD-WAN, inspeção TLS ou Web Policy foi alterada recentemente?

Sem essas informações, a busca no Log Viewer é muitas vezes muito ampla. É melhor um teste reproduzível com horário, endereços IP e direção esperada.

Usar corretamente o Log Viewer

O Log viewer é o ponto de partida inicial. Ele mostra logs de eventos e pode ser filtrado por módulo, tempo, campo e texto livre.

O Log Viewer é aberto no canto superior direito da interface WebAdmin. Para drops, dependendo do caso, estes módulos são importantes:

• Firewall: Correspondência de regras, conexões permitidas e descartadas.
• Web: Web Policy, categoria, grupo de URL, verificação de malware.
• SSL/TLS inspection: Descriptografia, erros TLS, exceções.
• Application filter: Detecção de Application Control.
• IPS: Prevenção de intrusões e decisões DPI.
• Active threat response: Threat Feeds, NDR Essentials ou outros acertos ATR.
• Web server protection: WAF, Reverse Proxy e serviços web publicados.
• VPN: Eventos de IPsec, SSL VPN e acesso remoto.

Regras de firewall geralmente registram sessões quando o firewall recebe um evento Destroy e fecha a conexão. Se uma conexão termina sem este evento, ela pode não aparecer como esperado. Em conexões SSL/TLS, a conexão é registrada após o handshake e ao fechar.

A configuração de logs também é importante. Se um tipo de log não estiver ativado em System services > Log settings, ele não será visto de forma confiável localmente, no Sophos Central ou no Syslog. Para análise a longo prazo, veja Enviar Syslog do Sophos Firewall para SIEM ou Ativar Central Firewall Reporting.

Classificar Invalid Traffic Events

Invalid traffic é uma indicação importante, mas não é uma análise de causa completa. A firewall comunica tráfego que não se encaixa corretamente numa ligação válida ou numa decisão de policy. Casos típicos são pacotes fora do estado esperado da sessão, caminhos assimétricos, sessões expiradas, flags TCP inesperadas ou tráfego de retorno que não passa pelo mesmo caminho.

Nestes eventos, não se deve começar por criar uma regra Allow. É melhor seguir este processo:

1. Transferir source, destination, porta e hora do evento.
2. Verificar no Log Viewer se estão visíveis Firewall Rule ID, NAT Rule ID ou módulo.
3. Testar com Packet Capture se ambas as direções passam pela mesma firewall.
4. Verificar routing, SD-WAN, caminhos VPN, função HA e rota de retorno.
5. Só depois decidir se é necessário ajustar regra, lógica NAT, rota ou perfil de segurança.

Invalid traffic é especialmente valioso como indicação de problemas de estado ou de caminho de retorno. Se apenas se alargar a regra Allow, a causa real muitas vezes permanece.

Usar corretamente o Packet Capture

O caminho do menu é:

Diagnostics > Packet capture

Packet Capture mostra se os pacotes chegam a uma interface, são encaminhados, processados pelo próprio firewall ou descartados. Isso é especialmente importante quando nada claro aparece no Log Viewer.

Procedimento básico:

1. Delimitar o caso de teste: anotar IP de origem, IP de destino, porta e protocolo.
2. Abrir Diagnostics > Packet capture.
3. Definir o filtro de captura o mais restrito possível.
4. Ativar Packet Capture.
5. Reproduzir o problema.
6. Parar a captura.
7. Verificar entradas por origem, destino, Rule ID, NAT ID, status e motivo.

Packet Capture mostra, entre outros, Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID e Username. Esses campos ajudam quando não apenas uma regra de firewall, mas também Webfilter, IPS, Application Control ou NAT estão envolvidos.

Para o uso da ferramenta, veja Usar Packet Capture no WebAdmin para um guia mais detalhado.

Entender o status do Packet Capture

Os valores de status são cruciais para a análise. O Sophos Firewall oferece seis valores de status no filtro de exibição: Allowed, Violation, Consumed, Generated, Incoming e Forwarded.

• Incoming: Pacote chega a uma interface WAN ou LAN. Fonte alcança o firewall.
• Allowed: O pacote foi permitido pela regra de firewall ou política aplicável. Este status muitas vezes se sobrepõe a Forwarded na prática; se um pacote aparecer como Allowed, mas não como Forwarded, vale a pena verificar o roteamento, o caminho de retorno ou um módulo de segurança posterior.
• Forwarded: Pacote é encaminhado. Firewall permite a passagem do pacote.
• Consumed: Pacote é destinado ao próprio firewall. Device Access, VPN Portal, DNS, DHCP ou outro serviço local.
• Generated: Pacote é gerado pelo firewall. Resposta ou tráfego do sistema do firewall.
• Violation: Pacote é descartado devido a uma violação de política. Regra, módulo ou função de segurança bloqueia.

Um único Incoming sem um Forwarded correspondente pode significar que o firewall descarta o pacote, o processa internamente ou que o filtro não mostra todo o fluxo. Portanto, deve-se sempre considerar ambas as direções.

Após o primeiro status, não se deve criar imediatamente uma exceção. É melhor derivar o próximo teste do status:

• Apenas Incoming visível: Verificar filtro, capturar direção oposta, procurar Rule ID e excluir Firewall ID 0.
• Incoming e Forwarded, mas sem resposta: Verificar rota de retorno, sistema de destino, firewall local do servidor, NAT e roteamento assimétrico.
• Consumed visível: Verificar Device Access, Local service ACL e serviço de firewall local afetado.
• Generated visível: Verificar se o firewall responde ou gera tráfego do sistema.
• Violation visível: Comparar Reason, Rule ID, NAT ID e módulo afetado no Log Viewer.

Isso mantém a análise reproduzível: o status decide qual ferramenta é mais adequada a seguir. Em Violation, o Log Viewer é importante, na ausência de resposta, o foco é mais no caminho de retorno e Packet Capture, em Consumed, Device Access em vez de regra de firewall.

Triagem rápida de sintomas

Na prática, uma breve tabela de sintomas poupa tempo antes de aprofundar logs ou shell:

• Log Viewer mostra Invalid traffic: Estado da sessão, caminho de retorno, routing assimétrico. Verificar ambas as direções com Packet Capture.
• Packet Capture mostra apenas Incoming: Drop, serviço local, regra padrão ou filtro incompleto. Alargar filtro, executar Policy Test, verificar Firewall ID 0.
• Packet Capture mostra Forwarded, mas sem resposta: Sistema de destino, rota de retorno, NAT, firewall externo. Verificar pacotes de resposta e caminho de retorno.
• Packet Capture mostra Consumed: Tráfego para o próprio firewall. Verificar Device Access e Local service ACL.
• Packet Capture mostra Violation: Regra, módulo de segurança ou violação de policy. Comparar Reason, Rule ID, NAT ID e log do módulo.
• Log Viewer e Packet Capture não mostram nada: O tráfego não chega ao firewall. Verificar cliente, VLAN, switch, gateway ou alvo de teste errado.

Firewall ID 0 e regra Drop explícita

Se nenhuma regra de firewall explícita corresponder, a Sophos Firewall descarta o tráfego pela regra final integrada com Firewall ID 0 ou Policy ID 0. Esta regra está sempre no fim das regras de firewall. Importante para troubleshooting e SIEM: a regra Drop-all integrada não regista o tráfego por si só. Quem quiser ver todas as ligações descartadas de forma rastreável precisa de uma regra Drop explícita própria com logging ativo.

Se drops pela regra padrão não forem visíveis, a decisão de policy não está automaticamente errada. No Packet Capture, pode-se ver apenas Incoming, mas sem uma entrada correspondente de Violation Firewall. O problema é então a rastreabilidade no troubleshooting, não necessariamente a decisão real de drop.

É importante a classificação: o firewall não permite repentinamente o tráfego. O drop ainda ocorre corretamente. O problema é a rastreabilidade na resolução de problemas.

Se um caso de teste não corresponder a nenhuma regra e ainda assim nenhum drop for visível, deve-se verificar adicionalmente:

1. Usar Policy Test e verificar se o teste cai na Firewall ID 0 ou na regra padrão.
2. Verificar a ordem das regras e garantir que nenhuma outra regra acima corresponda inesperadamente.
3. Se necessário, criar uma regra de drop explícita no final da base de regras, por exemplo, uma regra de drop Any-para-Any documentada com logging ativo.
4. Realizar o teste novamente e verificar se o drop agora é visível com a ID de regra explícita.
5. Incluir a regra de drop explícita na documentação de mudanças e revisão de regras, para que não seja posteriormente mal interpretada como uma regra normal de Allow/Deny.

Esta regra final explícita é especialmente útil em ambientes onde se deve documentar drops de forma segura ou enviá-los para um SIEM. No entanto, tal regra não substitui uma estrutura de regras limpa. Se muito tráfego legítimo cair na regra final, provavelmente falta uma regra permissiva mais precisa acima ou uma rede está mal classificada.

Ler campos importantes no Packet Capture

Em drops, não é apenas o status que importa. Os campos adicionais mostram qual parte do firewall processou o tráfego.

• Rule ID: Regra de firewall correspondente. Corresponde à regra esperada?
• NAT ID: Regra de NAT correspondente. NAT é esperado, falta NAT ou uma regra de NAT errada está em vigor?
• Reason: Motivo para drop ou violação. Não ler isoladamente, mas comparar com status e módulo.
• Web filter ID: Decisão de Web Policy. Verificar categoria, grupo de URL e contexto do usuário.
• Application ID: Aplicação reconhecida. Application Control pode decidir de forma diferente do que a porta sugere.
• IPS policy ID: Política de IPS aplicada. Verificar assinatura, contexto da regra e risco de falso positivo.
• Username: Usuário reconhecido. Avaliar correspondência de usuário apenas se o usuário estiver realmente visível.

Se Rule ID ou NAT ID forem inesperados, não se deve criar imediatamente uma exceção. Primeiro, deve-se esclarecer se o caso de teste foi definido corretamente, se uma regra mais geral acima corresponde ou se o NAT altera a visão sobre origem e destino.

Usar Reason como orientação

O valor Reason não é um relatório completo de root cause, mas é uma boa indicação para o próximo módulo. Firewall aponta mais para base de regras, regra padrão ou lógica de zonas. LOCAL_ACL combina com Device Access e Local service ACL. INVALID_TRAFFIC aponta mais para estado de sessão, caminho de retorno ou routing assimétrico. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION ou VIRTUAL_HOST mostram que não se deve verificar apenas a regra de firewall.

Por isso, ajuda uma sequência curta: primeiro ler o status, depois classificar o Reason e só então abrir o módulo adequado no Log Viewer. Assim, uma entrada Violation isolada transforma-se num caminho de verificação rastreável em vez de num convite para criar uma exceção ampla.

Consumed e serviços de firewall locais

Consumed não é um drop normal. O status significa que o pacote é destinado ao próprio firewall. Destinos típicos são WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN ou SNMP.

Nesses casos, muitas vezes não é a regra de firewall normal que importa, mas sim Device Access e Local service ACL. Se, por exemplo, WebAdmin, SSH, VPN Portal ou SNMP não estiverem acessíveis, não se deve procurar apenas em Rules and policies > Firewall rules. O ponto de partida correto é geralmente Administration > Device access.

Para endurecimento e resolução de problemas em serviços de firewall locais, veja Proteger acesso ao Sophos Firewall: Configurar Device Access corretamente.

Causas comuns de drops

Nenhuma regra de firewall correspondente

A causa mais comum é uma regra que não corresponde. As razões podem ser:

• zona de origem incorreta
• rede de origem incorreta
• zona de destino incorreta
• IP de destino mal interpretado em DNAT
• serviço ausente ou protocolo incorreto
• usuário não autenticado
• horário não corresponde
• uma regra mais específica está abaixo de uma regra mais geral

Para a estrutura de regras, veja Entender e configurar corretamente regras de firewall do Sophos Firewall. Se DNAT estiver envolvido, deve-se também verificar Publicar servidor via DNAT no Sophos Firewall.

NAT ou caminho de retorno não correspondem

Às vezes, o firewall permite o caminho de ida, mas a resposta retorna de forma diferente ou é traduzida incorretamente.

Pontos típicos:

• SNAT ou MASQ ausente.
• DNAT aponta para o host interno errado.
• Uma regra de NAT vinculada foi desativada.
• Rota de retorno ausente.
• SD-WAN ou roteamento estático envia tráfego de resposta por outro caminho.
• Em tráfego VPN, falta uma rota IPsec ou rota de retorno correspondente.

O roteamento assimétrico muitas vezes gera erros difíceis de entender, pois o firewall não pode associar corretamente o estado da conexão. Então, os pacotes podem aparecer como não pertencentes à conexão.

Pacote não pertence a uma conexão conhecida

Mensagens como Could not associate packet to any connection ou avisos semelhantes de Conntrack geralmente significam que o firewall não encontra um objeto de contexto de conexão correspondente.

Possíveis causas:

• Tráfego de retorno segue outro caminho.
• Conexão foi estabelecida em outro nó HA.
• Sessão já expirou.
• Flags TCP não correspondem à conexão esperada.
• Um dispositivo envia respostas sem solicitação anterior.
• Inspeção stateful vê apenas parte do fluxo de dados.

Aqui, Packet Capture é mais importante do que uma única entrada de log. Deve-se ver se ambas as direções passam pelo mesmo firewall e pela mesma zona.

Webfilter, TLS Inspection, Application Control ou IPS bloqueou

Nem todo drop vem da própria regra de firewall. Muitas vezes, o tráfego é permitido, mas depois bloqueado por um módulo de segurança.

Exemplos típicos:

• Web Policy bloqueia uma categoria ou grupo de URL.
• TLS Inspection falha devido a certificado, SNI, cifra ou exceção.
• Application Control detecta uma aplicação indesejada.
• IPS bloqueia um padrão.
• Active Threat Response encontra um IoC.
• Zero-Day Protection retém ou bloqueia um download.

Em casos de IPS, deve-se verificar assinatura, política e contexto da regra antes de definir uma exceção ampla. O procedimento adequado está em Configurar e testar com segurança o IPS no Sophos Firewall.

Em casos de Web e TLS, deve-se também verificar o QUIC. Se os navegadores evitam o UDP 443, as expectativas de Webfilter e TLS nem sempre correspondem. Mais sobre isso: Bloquear corretamente o protocolo QUIC e HTTP/3 no Sophos Firewall.

MTU, MSS ou fragmentação

Em VPN, PPPoE, SD-WAN, celular ou túneis aninhados, um pacote pode ser grande demais para o caminho. Então, nem sempre se vê um drop claro de firewall, mas sim interrupções de conexão, aplicações lentas ou serviços individuais que travam.

Para esses casos, veja Verificar MTU e MSS no Sophos Firewall para problemas de VPN.

Procedimento estruturado

Na prática, esta sequência funciona bem:

1. Anotar caso de teste: Origem, destino, porta, protocolo, horário.
2. Verificar Log Viewer: Filtrar módulo de firewall e módulos de segurança correspondentes.
3. Procurar Rule ID e NAT ID: Verificar qual regra foi realmente acionada.
4. Iniciar Packet Capture: Definir filtro restrito e reproduzir teste.
5. Verificar status: Avaliar Incoming, Forwarded, Consumed, Generated ou Violation.
6. Verificar direção de retorno: A resposta retorna e pelo mesmo caminho?
7. Verificar módulos de segurança: Web, TLS, Application Control, IPS, ATR, WAF.
8. Verificar logs de serviço: Para problemas de serviço, verificar arquivo de log correspondente em /log.
9. Verificar logs centrais: Incluir Central Reporting ou SIEM se os logs locais não forem suficientes.

Os arquivos de serviço e logs apropriados estão resumidos em Resolução de problemas do Sophos Firewall: Serviços e Logs.

Quando nada aparece no Log Viewer

Nenhuma entrada de log não significa automaticamente que o firewall não está envolvido.

Possíveis causas:

• Logging não está ativado na regra de firewall.
• O tipo de log relevante não está ativo em System services > Log settings.
• A conexão não foi encerrada corretamente e, portanto, não foi registrada.
• O tráfego não chega ao firewall.
• O tráfego é processado por um serviço local.
• O filtro no Log Viewer é muito restrito.
• O armazenamento de logs é limitado ou entradas antigas já foram sobrescritas.

Nesses casos, use primeiro o Packet Capture. Se o Packet Capture também não mostrar entrada, o foco é mais no cliente, switch, VLAN, roteamento antes do firewall ou alvo de teste incorreto.

Quando tcpdump ou arquivos de log são necessários

O Packet Capture do WebAdmin é bom para análises rápidas. Para capturas mais longas, arquivos PCAP, filtros muito precisos ou casos de suporte, tcpdump via SSH é frequentemente mais adequado. Isso é especialmente verdade quando um problema ocorre apenas esporadicamente ou quando a captura deve ser analisada posteriormente no Wireshark ou pelo suporte da Sophos.

Para esses casos, deve-se esclarecer antes da captura:

• Quais IPs de origem, IPs de destino e portas devem estar no filtro?
• Quanto tempo a captura pode durar?
• Onde o arquivo PCAP será armazenado?
• Quem pode ver o arquivo?
• Quando o arquivo será excluído após a análise?

O procedimento prático está em Capturar pacotes com tcpdump no Sophos Firewall via CLI. Se, além de pacotes, também forem necessários logs de serviço, veja Salvar logs do Sophos Firewall para suporte e análise.

Definir exceções apenas de forma direcionada

Em drops, a tentação é grande de criar rapidamente uma exceção. Isso pode ajudar a curto prazo, mas muitas vezes piora a segurança ou esconde a causa.

Exceções devem ser definidas apenas quando está claro:

• qual módulo bloqueia
• qual host, domínio ou aplicação é afetado
• por que o tráfego é legítimo
• quão restrita a exceção pode ser
• quando a exceção será revisada ou removida

Exceções amplas para redes inteiras, regras Any ou exceções globais de TLS devem ser evitadas. É melhor uma exceção pequena, documentada, com data de revisão.

Documentar o diagnóstico

Um bom diagnóstico de drop deve ser documentado de forma que outra pessoa possa reproduzir o teste. Isso é importante para revisões internas, documentação de mudanças e casos de suporte.

Registrar pelo menos:

• Data, hora e fuso horário do teste.
• IP de origem, IP de destino, porta, protocolo e usuário.
• Regra de firewall esperada e Rule ID realmente visível.
• Regra de NAT esperada e NAT ID realmente visível.
• Status do Packet Capture: Allowed, Incoming, Forwarded, Consumed, Generated ou Violation.
• Mensagem relevante de Reason ou módulo.
• Alteração feita ou nenhuma alteração intencional.
• Se uma exceção foi definida: proprietário, propósito, validade e data de revisão.

Esta documentação evita que um passo de resolução de problemas temporário se torne uma lacuna de segurança permanente e indefinida.

Lista de verificação

• IP de origem, IP de destino, porta e protocolo conhecidos.
• Hora do teste documentada.
• Log Viewer verificado com módulo e filtro de tempo corretos.
• Rule ID e NAT ID avaliados.
• Em caso de ausência de entrada de drop, verificar se Firewall ID 0 ou a regra padrão está envolvida.
• Regra de firewall e ordem de regras verificadas.
• Regra de NAT e rota de retorno verificadas.
• Packet Capture realizado com filtro restrito.
• Status e Reason no Packet Capture avaliados.
• Direção de ida e volta verificadas.
• Webfilter, TLS Inspection, Application Control, IPS e Active Threat Response verificados.
• Em VPN, MTU, MSS e rota verificados.
• Em DNAT ou WAF, host de destino, endereço hospedado e backend verificados.
• Logs centrais ou Syslog verificados, se os logs locais não forem suficientes.
• Em caso de necessidade de suporte, tcpdump ou arquivo de log preparado de forma direcionada.
• Exceções definidas apenas de forma restrita e documentada.
• Diagnóstico documentado com Rule ID, NAT ID, Status, Reason e alteração.

Perguntas frequentes