Usar Packet Capture da Sophos Firewall no WebAdmin
Packet Capture é uma das ferramentas de troubleshooting mais importantes no Sophos Firewall WebAdmin. Mostra se os pacotes chegam a uma interface, se são encaminhados, que regra ou NAT ID está envolvido e se um pacote é descartado.
Log Viewer mostra a decisão da firewall. Packet Capture mostra o fluxo dos pacotes. Em conjunto, são muitas vezes a forma mais rápida de encontrar a causa.
É importante enquadrar: este artigo descreve a versão WebAdmin do Packet Capture. É ideal para uma primeira verificação, porque se vê diretamente no browser se os pacotes chegam, são encaminhados ou são descartados. Para capturas mais longas, filtros muito precisos, exportação PCAP ou casos de suporte, tcpdump por SSH é muitas vezes mais indicado.
Quando Packet Capture é útil
Packet Capture ajuda sobretudo em perguntas como:
- O tráfego chega sequer à firewall?
- O tráfego sai pela interface esperada?
- Uma Firewall Rule faz match?
- Uma NAT Rule faz match?
- Um pacote é descartado por policy, IPS ou routing?
- Chega uma resposta do sistema de destino?
- Está a ser usado outro porto ou protocolo do que o esperado?
Se nada aparece no Log Viewer, Packet Capture é frequentemente o próximo passo. Assim vê-se se o problema está antes da firewall ou se a firewall está a processar o tráfego.
Caminho no menu
A ferramenta encontra-se em:
Diagnostics > Packet capture
Packet Capture abre diretamente no WebAdmin. Dependendo da versão SFOS e da visualização do browser, parece uma janela de diagnóstico própria dentro do WebAdmin.
Log Viewer ou Packet Capture?
Log Viewer e Packet Capture respondem a perguntas diferentes.
| Ferramenta | Mostra sobretudo |
|---|---|
| Log Viewer | Que Firewall Rule, Web Policy, Application Control, IPS ou SSL/TLS inspection tomou a decisão |
| Packet Capture | Se pacotes individuais chegam, são encaminhados, consumidos, gerados ou descartados |
Um bom exemplo é um ping. No Log Viewer vê-se muitas vezes apenas uma entrada ou uma decisão resumida da ligação. No Packet Capture vêem-se os pacotes ICMP individuais: Echo Request para o destino e Echo Reply de volta. O Windows envia por predefinição quatro ICMP Echo Requests com ping. No Packet Capture espera-se, portanto, ver vários pacotes de ida e volta. Se só os requests são visíveis, mas não chegam replies, é um problema diferente de não chegar qualquer request à firewall.
Na prática:
- Log Viewer responde: Que regra ou módulo tomou a decisão?
- Packet Capture responde: Os pacotes chegaram mesmo e que caminho seguem?
- Para problemas de routing, NAT, VLAN, gateway ou caminho de retorno, Packet Capture é muitas vezes mais esclarecedor.
- Para decisões de Web filter, Application Control, IPS ou SSL/TLS inspection, também é necessário o Log Viewer.
Limitar bem antes de começar
Packet Capture não deve ser iniciado sem filtro. Em redes de produção, isso cria rapidamente muitos dados e torna a saída difícil de ler.
Antes, deve-se anotar:
- Source IP
- Destination IP ou FQDN
- Protocolo
- Source port, se relevante
- Destination port
- Interface ou zona
- Hora do teste
- Aplicação afetada
Para um teste web, o enquadramento pode ser:
| Campo | Exemplo |
|---|---|
| Source IP | 172.16.10.25 |
| Destination | 93.184.216.34 |
| Protocol | TCP |
| Destination Port | 443 |
| Direção esperada | LAN para WAN |
Configurar capture filter
Com Configure, define-se um filtro tão estreito quanto possível.
Filtros típicos:
- Source IP do cliente
- Destination IP do servidor
- Destination port
- Protocolo TCP, UDP ou ICMP
- Interface
Se o servidor de destino não for conhecido, pode começar-se por filtrar apenas pela Source IP. Se aparecerem demasiados pacotes, restringe-se mais.
Sophos Firewall usa a sintaxe Berkeley Packet Filter, ou BPF. O capture filter decide que pacotes são escritos no capture buffer. Por isso, deve ser configurado corretamente antes do teste.
Exemplos BPF típicos:
| Objetivo | Exemplo BPF |
|---|---|
| host específico | host 10.10.10.1 |
| Source IP específica | src host 10.10.10.1 |
| Destination IP específica | dst host 10.10.10.1 |
| rede específica | net 10.10.10.0 |
| porto específico | port 443 |
| porto de destino específico | dst port 443 |
| host e porto específicos | host 10.10.10.1 and port 443 |
| ICMP/ping | proto ICMP |
| TCP | proto TCP |
| UDP | proto UDP |
Para um teste web muito direcionado, um filtro pode ser:
host 172.16.10.25 and host 93.184.216.34 and port 443
Para um teste ping, isto costuma ser suficiente:
host 172.16.10.25 and proto ICMP
No WebAdmin, depois de guardar, o BPF string ativo é mostrado acima da lista de pacotes. O primeiro screenshot mostra a configuração do filtro, o segundo a lista de resultados com o filtro ativo.
⚠️ Os dados PCAP podem conter endereços IP, nomes de host, detalhes de protocolo e, dependendo do protocolo, também dados úteis. As capturas só devem ser partilhadas com pessoas ou parceiros autorizados a ver estes dados.
Iniciar a captura e reproduzir o problema
- Definir o filtro.
- Ativar Packet Capture com o interruptor.
- Reproduzir o problema de forma direcionada.
- Parar novamente a captura.
- Analisar os resultados.
- Limpar a captura antes de iniciar um novo teste.
Sophos Firewall mostra o estado e o buffer:
| Indicação | Significado |
|---|---|
Trace On | Packet Capture está em execução |
Trace Off | Packet Capture está desativado |
Buffer size | Tamanho do capture buffer, 2048 KB na documentação Sophos |
Buffer used | buffer atualmente utilizado |
Quando o buffer fica cheio, a captura para automaticamente. Depois é necessário usar Clear antes de uma nova captura fazer sentido. Por isso, um filtro restrito é importante.
Nas definições do filtro, também se pode definir quantos bytes por pacote são capturados. Para muitas primeiras análises, a informação dos cabeçalhos é suficiente. Se forem necessários mais dados de payload, é preciso capturar mais bytes, mantendo em atenção a privacidade e o tamanho do buffer.
Compreender as colunas importantes
Packet Capture mostra muitos campos. Na prática, estes são especialmente importantes:
| Campo | Significado |
|---|---|
| Time | Hora do pacote |
| In interface | Interface em que o pacote entrou |
| Out interface | Interface pela qual o pacote sai |
| Source IP | Endereço de origem |
| Destination IP | Endereço de destino |
| Packet type | Protocolo ou tipo de pacote |
| Ports [src, dst] | Porto de origem e destino |
| NAT ID | Regra NAT correspondente |
| Rule ID | Firewall Rule correspondente |
| Status | Estado do pacote |
| Reason | Razão para drop ou violation |
| Connection status | Estado da ligação |
| Gateway ID | Gateway utilizado |
| Username | Utilizador detetado |
| IPS policy ID | IPS Policy aplicada |
| Application filter ID | Application Control Policy aplicada |
Estes campos são valiosos porque fecham a lacuna entre “a regra parece correta” e “o tráfego flui realmente assim”.
Com Show additional properties ou a vista detalhada, dependendo da versão, vêem-se mais informações, como Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username ou outros policy IDs. Estes detalhes ajudam quando um pacote não é processado apenas por uma Firewall Rule, mas também por Web, Application Control, IPS ou outros módulos.
Interpretar Status corretamente
| Status | Significado |
|---|---|
| Incoming | O pacote foi recebido numa interface |
| Forwarded | O pacote foi encaminhado |
| Consumed | O pacote destina-se à própria firewall |
| Generated | O pacote foi gerado pela firewall |
| Violation | O pacote foi descartado por uma violação de policy |
Se apenas Incoming é visível e não aparece Forwarded, o pacote provavelmente fica preso na firewall. Deve-se verificar Firewall Rule, NAT, routing e security features.
Se Forwarded é visível mas não volta resposta, o problema está muitas vezes no sistema de destino, caminho de retorno, NAT ou num peer remoto.
Num ping bem-sucedido, normalmente vêem-se pacotes nas duas direções. Se o Windows envia quatro pings, vêem-se vários ICMP Echo Requests do cliente para o destino e vários Echo Replies de volta. Se faltam os Replies, deve-se verificar a rota de retorno, o sistema de destino, a firewall local do destino, NAT ou um peer remoto. Se já faltam os Requests, deve-se verificar cliente, gateway, VLAN, porta do switch ou se o tráfego chega sequer à Sophos Firewall.
Usar Display filter
O capture filter limita que pacotes são gravados. O Display filter, por outro lado, filtra a vista já gravada. Isto é útil quando a captura foi iniciada de forma um pouco mais ampla e depois só se quer mostrar determinados pacotes.
No Display filter, pode-se filtrar, entre outros, por:
- Interface name
- Ethernet type, por exemplo IPv4, IPv6 ou ARP
- Packet type
- Source IP e Source port
- Destination IP e Destination port
- Reason
- Status
- Rule ID
- User
- Connection ID
Para troubleshooting, Status, Reason, Rule ID, Source IP, Destination IP e Destination port são especialmente úteis. Se houver muitos pacotes na captura, ajudam a reduzir rapidamente a vista à parte relevante sem reiniciar logo o teste.
Ler NAT no Packet Capture
Com NAT, é preciso ter em conta que um pacote parece diferente antes e depois de NAT. Packet Capture pode mostrar NAT ID, Rule ID e os endereços alterados.
Em problemas de NAT, verificar:
- O pacote é visível com o endereço original?
- O pacote é visível após a tradução?
- O NAT ID esperado é mostrado?
- O pacote sai pelo Out interface esperado?
- Volta uma resposta?
Para DNAT, há ainda outro ponto: a Firewall Rule usa a zona de destino após NAT, mas o Destination IP antes de NAT. À primeira vista, isto parece invulgar.
Mais sobre isto: Compreender NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.
Combinar Packet Capture e Log Viewer
O melhor fluxo é:
- Abrir Log Viewer.
- Iniciar Packet Capture com um filtro restrito.
- Reproduzir o teste.
- No Packet Capture, verificar se os pacotes chegam e saem.
- No Log Viewer, verificar que regra ou módulo tomou a decisão.
- Se necessário, passar para o ficheiro de log correspondente.
Log Viewer mostra, por exemplo, eventos Firewall, Web, SSL/TLS inspection, IPS ou Application Control. Packet Capture mostra o fluxo de pacotes ao nível da interface.
Esta combinação é especialmente importante em ping ou ligações TCP simples. Log Viewer só consegue mostrar que uma ligação foi permitida ou bloqueada. Packet Capture mostra adicionalmente se os pacotes de resposta voltam, se NAT é aplicado, se o Out interface correto é usado e se o caminho de retorno funciona.
Exemplos frequentes
O cliente não chega à Internet: definir capture para Source IP e TCP 443. Se nenhum pacote chega, verificar cliente, VLAN, gateway ou switch. Se o pacote chega mas não sai, verificar Firewall Rule, NAT ou routing.
DNAT não funciona: definir capture para Destination IP pública e porto externo. Se nenhum pacote chega, verificar router do provider, port forwarding, cloud Security Group ou WAN. Se o pacote chega mas não vai para o servidor interno, verificar a regra DNAT e a Firewall Rule.
Tráfego VPN não funciona: definir capture na interface de túnel, XFRM interface ou redes origem/destino relevantes. Verificar também strongswan.log, charon.log ou xfrmi.log.
Web filter bloqueia inesperadamente: No Packet Capture normalmente vê-se apenas o fluxo de pacotes. A decisão real deve ser verificada no Log Viewer em Web, Application Control ou SSL/TLS inspection.
Quando tcpdump é melhor
WebAdmin Packet Capture é ideal para análises rápidas. Para capturas mais longas, filtros muito precisos ou casos de suporte, tcpdump baseado em CLI é muitas vezes melhor.
Mais sobre isto: Recolher logs da Sophos Firewall com TCPDump para análise.