Analisar pacotes descartados no Sophos Firewall

Um pacote descartado não representa automaticamente um erro. O firewall pode bloquear o tráfego conforme previsto, descartar tráfego legítimo inesperadamente ou nem sequer receber o fluxo de dados. O processo seguinte permite identificar rapidamente se a causa está numa regra, no NAT, no caminho de retorno, num módulo de segurança ou num sistema anterior ao firewall.

Identificar pacotes descartados em poucos minutos

1. Registar o caso de teste: anotar o IP de origem, o IP de destino, a porta, o protocolo, a hora e a direção esperada. Em erros esporádicos, registar também o utilizador, a aplicação e a última alteração de configuração.
2. Filtrar o Log Viewer: procurar no módulo Firewall pelo endereço IP, porta e hora. Conforme o caso, abrir também Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection ou VPN.
3. Iniciar o Packet Capture: em Diagnostics > Packet capture, definir um filtro restrito, ativar a captura e realizar exatamente um teste reproduzível.
4. Interpretar o estado do pacote: Incoming, Forwarded, Consumed, Generated ou Violation mostram se o pacote chega, é encaminhado, processado localmente, gerado pelo firewall ou descartado.
5. Associar a decisão: comparar Rule ID, NAT ID e Reason com as regras de firewall e NAT esperadas. Em ocorrências de Web, IPS ou Application, verificar também o respetivo ID da policy.
6. Capturar o sentido inverso: se o tráfego de ida for encaminhado, mas não houver resposta visível, verificar a rota de retorno, o sistema de destino, NAT, SD-WAN e routing assimétrico.
7. Só depois alterar: não criar uma regra Allow abrangente nem uma exceção global antes de identificar o módulo responsável e a causa efetiva.

Para uma explicação aprofundada sobre correspondência de regras e Policy Tester, consulte Testar regras do Sophos Firewall com Log Viewer e Packet Capture.

Interpretar Log Viewer e Packet Capture em conjunto

Log Viewer e Invalid traffic

O Log Viewer abre-se no canto superior direito do WebAdmin. Não mostra apenas decisões do firewall, mas também eventos dos módulos de segurança envolvidos. No tráfego através do Web Proxy, por exemplo, o módulo Firewall pode indicar Allowed enquanto o módulo Web indica Blocked: a regra de firewall permite a ligação ao proxy, mas a Web Policy bloqueia o conteúdo. Por isso, deve-se correlacionar sempre os módulos referentes ao mesmo momento de teste. Os filtros, Detailed view, o momento da sessão e Log occurrence são explicados em Utilizar corretamente o Log Viewer da Sophos Firewall.

Para tráfego de firewall, é necessário verificar separadamente dois requisitos:

• A opção Log firewall traffic está ativada na regra em causa. As regras SSL/TLS possuem a opção própria Log connections.
• Em System services > Log settings, o destino necessário para o Log Viewer está ativado em Local reporting, Sophos Central ou Syslog.

As sessões de firewall surgem geralmente quando o firewall recebe um evento Destroy ao fechar a ligação. Se uma ligação terminar sem esse evento, a entrada esperada pode não aparecer. Para retenção prolongada, podem ser utilizados Central Firewall Reporting ou Syslog para um SIEM.

Invalid traffic significa que o Conntrack não consegue associar um pacote a uma ligação atual. Uma sessão expirada ou pacotes TCP RST e FIN adicionais podem gerar esses eventos e não representam automaticamente um erro. Se ocorrerem problemas de ligação ao mesmo tempo, capturar os dois sentidos e verificar possíveis causas, como uma rota de retorno em falta, um caminho assimétrico ou uma mudança de função no HA. Aumentar o tempo do Conntrack pode apenas reduzir o número de entradas no log; não resolve a causa.

Se o motivo específico do descarte for Invalid TCP reserved bit, a causa pode ser o Accurate ECN, e não uma regra de firewall. Resolver Invalid TCP reserved bit causado pelo Accurate ECN explica como comprovar a causa e avaliar o impacto de segurança do workaround global via CLI.

Status, Rule ID, NAT ID e Reason

O Packet Capture mostra os pacotes que passam por uma interface e complementa essas informações com o processamento efetuado pelo firewall, NAT e módulos de segurança. A ajuda atual do SFOS 22 define os seguintes estados:

• Incoming: o pacote chega a uma interface. Isso ainda não prova que será encaminhado.
• Forwarded: o firewall encaminha o pacote para uma interface de saída. Se não houver resposta, a análise deve prosseguir no sistema de destino e no caminho de retorno.
• Consumed: o pacote destina-se ao próprio firewall, por exemplo, WebAdmin, SSH, DNS ou um portal VPN.
• Generated: o firewall gera o próprio pacote, por exemplo, como resposta ou tráfego do sistema.
• Violation: uma violação de policy faz com que o pacote seja descartado. Rule ID, Reason e o módulo responsável indicam o próximo ponto a verificar.

Também são importantes Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID e Username. Um valor inesperado pode significar que uma regra mais genérica acima está a corresponder, que o NAT altera os endereços visíveis ou que o utilizador não foi reconhecido.

Reason é uma orientação, não um relatório completo da causa raiz. Valores como Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION ou VIRTUAL_HOST podem, conforme a versão, indicar o módulo responsável. Primeiro, interpretar o status e os IDs; depois, abrir a área adequada do Log Viewer. O artigo Sophos Firewall Packet Capture explica a utilização e os filtros.

Firewall ID 0 e logs de descarte em falta

Se nenhuma regra de firewall explícita corresponder, aplica-se no fim da base de regras a regra Drop all integrada, com Policy ID ou Firewall ID 0. Essa regra não cria uma entrada normal no log de tráfego do firewall. Para tornar esses pacotes descartados visíveis no Log Viewer, Central Reporting ou Syslog, deve-se criar no fim da base de regras uma regra própria com Action: Drop e Log firewall traffic ativado.

Selecionar individualmente as Source e Destination zones necessárias, sem utilizar indiscriminadamente Any para as zonas. Assim, os serviços locais permanecem acessíveis conforme previsto. Se a regra final registar muito tráfego legítimo, provavelmente falta uma regra Allow adequada acima ou uma rede foi classificada incorretamente.

Para o SFOS 22.0.1 MR1 Build 490, a Sophos também documenta o Known Issue NC-178387: os Default Drops com ID 0 não aparecem no Dropped Packet Capture nem em drppkt; no Packet Capture normal, pode surgir apenas Incoming, sem a respetiva entrada Violation Firewall. Ainda assim, o tráfego é descartado. A Sophos não indica na lista de Known Issues uma versão de correção claramente confirmada, portanto esse comportamento não deve ser presumido fora do build indicado.

Em caso de suspeita de Default Drop:

1. Verificar a ordem das regras e o Policy Test.
2. Comparar o resultado com um Packet Capture real.
3. Se for necessário logging, criar uma regra final com zonas específicas e uma Rule ID própria.
4. Repetir o teste e confirmar a nova Rule ID no log ou na captura.

O Policy Tester em Diagnostics > Tools não considera rotas SD-WAN e, por isso, nunca constitui prova suficiente por si só. Além disso, no SFOS 22.0 GA, o NC-177587 podia apresentar resultados de regras incorretos; os logs de produção e o Packet Capture continuam a ser decisivos.

Identificar a causa com base nos resultados

Regra, NAT e caminho de retorno

Se a Rule ID não corresponder à regra esperada, verificar Source e Destination zone, objetos de rede, serviço, protocolo, utilizador, horário e ordem das regras. Em DNAT, é essencial confirmar se o teste utiliza o endereço público e qual NAT ID é efetivamente aplicada. Os princípios básicos encontram-se em Compreender as regras de firewall e Publicar um servidor através de DNAT.

Se o Packet Capture indicar Forwarded, mas não mostrar uma resposta, outra regra Allow raramente é a solução. É mais provável faltar SNAT/MASQ ou uma rota de retorno, estar desativada uma regra NAT associada, o sistema de destino bloquear localmente ou o SD-WAN enviar a resposta por outro caminho. O tráfego nos dois sentidos deve atravessar o mesmo firewall stateful.

Sessão, routing assimétrico e HA

Mensagens como Could not associate packet to any connection significam que não foi encontrada uma entrada Conntrack correspondente. Entre as causas possíveis estão uma sessão expirada, flags TCP inesperadas, um caminho de retorno assimétrico ou um fluxo de dados que o firewall vê apenas num sentido. Após uma mudança de função no HA, também pode ser relevante saber em que nó a ligação foi estabelecida.

Um evento RST ou FIN isolado, sem um problema para o utilizador, não exige uma alteração imediata. Interrupções reproduzíveis devem ser verificadas com o mesmo filtro nos dois sentidos; em seguida, analisam-se routing, SD-WAN, caminhos VPN e o estado do HA.

Consumed e serviços locais do firewall

Consumed não é um descarte normal de tráfego de passagem. O destino é o próprio firewall, por exemplo, WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN ou SNMP. Para essas ligações, os elementos responsáveis são geralmente Administration > Device access e Local service ACL, não uma regra de firewall normal. A configuração segura é explicada em Proteger o Device Access do Sophos Firewall.

Módulos de segurança, VPN e MTU

Uma regra de firewall pode permitir tráfego que depois é bloqueado por outro módulo. Por isso, perante IDs ou Reasons relevantes, verificar também Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response e WAF. Em ocorrências de IPS, avaliar a assinatura e o contexto da regra antes de criar uma exceção; o processo é descrito em Testar o IPS do Sophos Firewall com segurança.

Em problemas Web e TLS, o QUIC através de UDP 443 pode alterar o processamento esperado. O artigo Bloquear QUIC e HTTP/3 apresenta a configuração adequada.

Em VPN, PPPoE, SD-WAN ou túneis encapsulados, MTU, MSS e fragmentação provocam mais frequentemente bloqueios ou interrupções parciais do que um descarte inequívoco. Para esses casos, consulte os artigos sobre MTU e MSS e Troubleshooting de IPsec VPN.

Quando a verificação padrão não é suficiente

Nenhuma entrada no Log Viewer ou Packet Capture

Se não houver uma entrada no log, verificar primeiro o logging da regra, Log settings, o filtro de tempo e o módulo responsável. Se o Packet Capture também não mostrar qualquer pacote, antes de iniciar o diagnóstico da rede deve-se confirmar que:

• O Packet Capture está efetivamente ativo e o teste só foi realizado depois da ativação.
• O filtro contém os endereços, portas, sentido e interface corretos; para testar, pode ser ligeiramente ampliado.
• O buffer de 2048 KB não está cheio. Quando o buffer fica cheio, a captura para automaticamente e deve ser reiniciada depois de selecionar Clear.
• Em System services > Services, o serviço Packet capture and Live connections está em execução; se houver um problema ao iniciar, reiniciar esse serviço de forma controlada.

Só quando um teste reproduzível com uma captura funcional não mostrar qualquer pacote de entrada deve a análise passar para os elementos anteriores ao firewall: cliente, VLAN, switch, gateway, router anterior ou destino de teste incorreto.

tcpdump, Drop Capture e arquivos de logs

Para capturas mais longas, ficheiros PCAP ou filtros BPF precisos, iniciar sessão por SSH e selecionar Option 4: Device Console. Um exemplo restrito para dois hosts e HTTPS é:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Para pacotes descartados por regras de firewall, o mesmo filtro pode ser utilizado com drop-packet-capture:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture não ajuda em problemas da camada de aplicação. Para criar um ficheiro PCAP, o tcpdump suporta a opção filedump; o ficheiro fica temporariamente em /tmp. A captura deve ser tão curta e restrita quanto possível, porque os pacotes podem conter dados confidenciais, e o ficheiro deve ser eliminado após a análise. Há mais exemplos em tcpdump no Sophos Firewall.

Se o suporte também precisar de logs de serviços, identificar primeiro o log responsável e guardar apenas o período necessário. Para isso, consulte Serviços e logs do Sophos Firewall e Guardar logs para suporte e análise.

Corrigir e documentar com segurança

Uma exceção só faz sentido quando o módulo, a finalidade legítima e o âmbito mais restrito estiverem definidos. Não criar uma exceção TLS global, uma regra Allow com Any nem autorizar redes inteiras apenas porque o serviço volta a funcionar. É preferível utilizar hosts, serviços e utilizadores específicos, além de uma data de revisão ou expiração.

Antes de concluir, documentar:

• Source, Destination, porta, protocolo, hora e utilizador.
• A Rule ID e a NAT ID esperadas e efetivamente observadas.
• Status, Reason e o módulo de segurança envolvido.
• O sentido de ida e de retorno ou o ponto onde o fluxo termina.
• Alteração, owner, ticket e data de revisão; registar também quando não foi feita qualquer alteração de forma intencional.

Depois, repetir o mesmo teste. A ligação autorizada deve funcionar e uma origem de comparação não autorizada deve continuar bloqueada. Assim, uma correção rápida não se transforma numa vulnerabilidade permanente.

Perguntas frequentes