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 Fusion (anteriormente 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.

Definir um filtro de captura preciso

Em Diagnostics > Packet capture > Configure, Enter BPF string limita a gravação e Number of bytes to capture (per packet) define o comprimento capturado. Wrap capture buffer once full substitui os dados mais antigos em vez de parar. Após Save, Display filter filtra por Interface name, Ethernet type, Packet type, Source IP/port, Destination IP/port, Reason, Status, Rule ID, User ou Connection ID. Um filtro BPF restrito preserva o buffer de 2048 KB e recolhe menos dados confidenciais.

Firewall ID 0 e logs de descarte em falta

Se nenhuma regra explícita corresponder, aplica-se Drop all com Policy ou Firewall ID 0, sem log normal. Para registar descartes, criar no fim em Rules and policies > Firewall rules > Add firewall rule > New firewall rule uma regra com Rule name, Action: Drop, Source zones and networks, Destination zones and networks, Services e Log firewall traffic. Restringir os valores para um teste. Para reproduzir integralmente a regra final integrada, a Sophos recomenda uma regra Drop any-any; avaliar antes o volume de logs e regras finais existentes.

No SFOS 22.0.1 MR1 Build 490, o NC-178387 faz com que o ID 0 não apareça em Dropped Packet Capture nem drppkt; Packet Capture mostra apenas Incoming sem Violation Firewall. O tráfego continua descartado. Não existe atualmente uma versão corrigida confirmada para o NC-178387, portanto MR2 por si só não prova a correção. Antes de escolher outra build, incluir esta verificação no plano de atualização de firmware.

1. Verificar ordem e Policy Test.
2. Comparar com Packet Capture.
3. Se necessário, criar a regra final com logging e confirmar a Rule ID.
4. Se temporária, desativar ou eliminar e confirmar que ID 0 continua a descartar; só desaparece o log adicional.

O Policy tester, em Diagnostics > Tools na área Pop-out tools, não considera rotas SD-WAN. O NC-177587 afetava o SFOS 22.0 GA Build 411 e foi corrigido no MR1 Build 490; para outras builds, verificar o estado atual do NC-177587 como parte do plano de atualização de firmware. Logs reais e Packet Capture continuam 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.

Utilizar Connection List para sessões ativas

Em Diagnostics > Connection list, a lista mostra as ligações ativas. Display filter filtra por In interface, Out interface, User, Network protocol, Source IP, Destination IP, Packet type, Source port, Destination port e Rule ID. Colunas como NAT ID, Protocol, Application name, Connection status, Connection ID, Gateway ID e IDs de policies ajudam a associar o fluxo. Connection ID mostra sessões relacionadas de proxy, FTP, SIP e ligações semelhantes, quando existem.

Uma sessão ativa com Rule ID e NAT ID esperadas confirma os valores do fluxo atual. A ausência não prova um descarte: a lista é um instantâneo e ligações descartadas ou terminadas podem faltar. Consultar durante o teste e correlacionar com Log Viewer e Packet Capture.

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. Sem Wrap capture buffer once full, a captura para quando o buffer fica cheio e deve ser reiniciada depois de Clear; com a opção ativada, os dados mais antigos são substituídos.
• 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. Os exemplos seguem a sintaxe Device Console documentada para o SFOS 22; não foram executados num firewall para este artigo. 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