Interpretar corretamente o Live Connections na Sophos Firewall

O Live Connections mostra quais ligações estão atualmente ativas na Sophos Firewall. A vista permite identificar rapidamente que cliente, utilizador ou aplicação gera tráfego, que interfaces estão envolvidas e que regra de firewall ou NAT processa a sessão. Para uma ligação específica, Diagnostics > Connection list fornece ainda mais detalhes técnicos.

Ambas as vistas são instantâneos. Não substituem o Log Viewer para decisões registadas nem o Packet Capture para o fluxo real de pacotes. Quando usadas corretamente em conjunto, poupam muito tempo: primeiro localiza-se a sessão ativa e depois verificam-se os logs e os pacotes, se necessário.

Live Connections em sete passos

1. Definir o fluxo de teste: IP de origem, IP de destino, protocolo, porta de origem se conhecida, porta de destino e hora exata.
2. Gerar uma nova ligação no cliente de teste, por exemplo HTTPS de 192.0.2.25 para 198.51.100.50 em TCP 443.
3. Abrir Current activities > Live connections e agrupar por Source IP address.
4. Filtrar por 192.0.2.25 e abrir as ligações individuais através de Total.
5. Registar Start time, In interface, Out interface, Source, Destination, portas, Firewall Rule ID e NAT Rule ID.
6. Em Diagnostics > Connection list > Display filter, filtrar o mesmo fluxo com a maior precisão possível e comparar Translated source, Translated destination, Gateway ID, Policy IDs e RX/TX.
7. Em caso de diferenças, correlacionar o fluxo no Log Viewer e no Packet Capture antes de alterar regras, NAT ou routing.

Os endereços 192.0.2.25 e 198.51.100.50 pertencem a redes de documentação. Num teste real, devem ser substituídos pelos endereços efetivos do cliente e do destino. TCP 443 só é adequado quando se testa realmente uma ligação HTTPS.

⚠️ As vistas contêm endereços IP internos, nomes de utilizador, aplicações e relações de comunicação. Limitar os filtros e as capturas de ecrã ao necessário e partilhar os dados de suporte apenas com destinatários autorizados.

Distinguir Live Connections de Connection List

As duas vistas usam o estado atual das ligações, mas foram concebidas para perguntas diferentes.

Live Connections para a visão geral

Em Current activities > Live connections, as ligações ativas podem ser agrupadas por:

• Application
• Source IP address
• Username

A vista mostra upload, download, utilização média da largura de banda, propriedades e número de sessões. Isto ajuda a responder a perguntas como: que cliente está a gerar muito tráfego neste momento? Que aplicação está ativa? Que utilizador tem várias ligações abertas?

Os valores de transferência apresentados abrangem o período desde o estabelecimento da ligação. Upstream bandwidth e Downstream bandwidth são calculadas a partir dos bytes transferidos e da duração da ligação até ao momento. Por isso, não constituem um teste da linha segundo a segundo. Para testar o desempenho, é mais adequado utilizar corretamente o iPerf3 com a Sophos Firewall.

No Live Connections, apenas um filtro pode estar ativo de cada vez. O IP de origem é normalmente o ponto de partida mais claro. Username ou Application são úteis quando o cliente já está corretamente autenticado ou a aplicação foi identificada.

Connection List para a sessão individual

Em Diagnostics > Connection list, cada ligação atual aparece numa linha separada. Esta vista é mais técnica e mostra, entre outros dados:

• In interface e Out interface
• Source e Destination com portas
• Protocol e Application
• Rule ID e NAT ID
• User e User group
• Policy IDs de Web, Application, IPS, Traffic Shaping e Remote Access
• Gateway ID
• Translated source e Translated destination
• Expiry, RX/TX bytes e RX/TX packets
• Connection served by

O Display filter pode incluir várias características conhecidas do fluxo de teste. Desta forma, uma lista extensa é reduzida a um pequeno conjunto de sessões correspondentes.

O que nenhuma das vistas comprova

Uma sessão visível comprova que existe uma entrada atual de connection tracking. Não comprova automaticamente:

• que todos os pedidos e respostas foram transferidos na íntegra
• que o servidor de destino processou corretamente a aplicação
• que um erro anterior no mesmo fluxo ainda está disponível no histórico
• que a regra de firewall ou NAT selecionada é funcionalmente a correta
• que uma entrada verde não inclui perda de pacotes, retransmissões ou um problema de MTU

As decisões históricas requerem logs. Ingress, egress, respostas e drops requerem Packet Capture. Para a própria aplicação, os logs do servidor, do cliente ou do serviço SaaS continuam a ser relevantes.

Preparar um fluxo de teste controlado

Um teste útil não começa com uma atualização aleatória do browser. Primeiro define-se o quíntuplo:

• IP de origem
• IP de destino
• protocolo
• porta de origem
• porta de destino

A porta de origem é frequentemente dinâmica nas ligações de cliente. Se ainda não for conhecida, o IP de origem, o IP de destino, o protocolo e a porta de destino são suficientes para o primeiro filtro. Depois de localizar a entrada, é possível obter a porta de origem concreta a partir da sessão.

Também devem ser definidos os valores esperados:

• In interface e Out interface
• Firewall Rule ID e, quando aplicável, NAT Rule ID
• utilizador ou grupo de utilizadores se a regra usar identidade
• Gateway ou caminho SD-WAN
• Source e Destination esperadas depois do NAT
• hora exata do teste com fuso horário

Criar sempre uma nova ligação após alterações

As sessões existentes mantêm o estado estabelecido no momento da criação. Em particular, as decisões de NAT não são reavaliadas para cada pacote seguinte. Depois de alterar uma regra, NAT, routing ou SD-WAN, deve terminar-se a sessão da aplicação e gerar-se um novo fluxo.

Uma atualização do browser pode continuar a usar a mesma ligação TCP, HTTP/2 ou HTTP/3. Uma nova janela privada do browser, um processo de cliente reiniciado ou outro teste controlado que abra garantidamente uma nova ligação ajuda a obter uma validação fiável. O método exato deve ser adequado à aplicação e não deve interromper involuntariamente uma sessão de produção.

Utilizar Live Connections para localizar a primeira entrada

1. Abrir Current activities > Live connections.
2. Selecionar um Automatic refresh interval adequado ao teste ou atualizar manualmente com Refresh.
3. Para um cliente conhecido, selecionar Source IP address.
4. Abrir o filtro, escolher um modificador adequado e introduzir o IP de origem.
5. Verificar Transfer, Bandwidth e Total na linha.
6. Clicar no número em Total para abrir as ligações individuais num novo separador.
7. Identificar o fluxo correspondente através de Start time, interfaces, endereços IP, portas e Protocol.

Um pedido DNS, ICMP ou Web muito curto pode já ter desaparecido antes da atualização da página. Nesse caso, configurar primeiro o filtro, preparar Refresh e acionar o teste exatamente mais uma vez.

Interpretar corretamente Other applications e DNS

Other applications inclui aplicações não identificadas e tráfego gerado pelo sistema, por exemplo downloads de assinaturas, acesso à consola ou pedidos DNS da própria firewall. Não é automaticamente uma categoria de erro.

O DNS exige atenção adicional: o tráfego entre um cliente interno e um servidor DNS externo está sujeito às regras de firewall normais e aparece como DNS. O tráfego DNS gerado pela própria firewall pode, por outro lado, aparecer tanto em DNS como em Other applications.

Se uma aplicação não for identificada e o Security Heartbeat estiver ativo, a Connection List pode permitir a resolução de Application Information para endpoints ligados. Sem um Sophos Endpoint ligado ou sem Heartbeat, No information available continua a ser possível. Por isso, um nome desconhecido não indica automaticamente tráfego malicioso.

Firewall Rule ID 0 depende do contexto

O tráfego gerado pelo sistema tem Firewall Rule ID 0 no Live Connections, porque as regras de firewall normais não controlam esse tráfego. O acesso aos serviços locais da firewall é controlado, entre outros mecanismos, por Administration > Device access e pela Local Service ACL. Device Access e Local Service ACL explica a configuração segura.

Este 0 não deve ser interpretado fora do contexto como uma regra implícita de drop. Rule #0 num log de firewall ou no Packet Capture pode ter outro significado de diagnóstico. São decisivos a vista, Status, Reason e a distinção entre tráfego do sistema e tráfego de cliente encaminhado.

Limitar Connection List a um único fluxo

1. Abrir Diagnostics > Connection list.
2. Selecionar Display filter.
3. Definir Network protocol como IPv4 ou IPv6 de acordo com o teste.
4. Introduzir o IP de origem e o IP de destino.
5. Adicionar Packet type e a porta de origem ou de destino, se conhecidas.
6. Introduzir a Rule ID esperada quando se procuram especificamente as sessões ativas dessa regra.
7. Aplicar o filtro com OK e comparar os resultados com a hora do teste.

Um resultado vazio não comprova que a firewall está a bloquear o tráfego. A sessão pode já ter terminado, o cliente pode usar outro endereço de destino obtido através de DNS ou CDN, o NAT pode alterar o endereço visível ou o teste pode ter sido processado pelo outro nó HA. Verificar primeiro o fluxo de teste e a direção de observação, em vez de alargar a regra de firewall.

Ler em conjunto os campos mais importantes

• Time: hora de início da ligação. Deve corresponder ao teste controlado.
• In interface / Out interface: mostram o caminho de entrada e saída usado pela sessão.
• Source / Destination / Ports: definem o fluxo visível antes da interpretação detalhada.
• Rule ID: mostra a regra de firewall que permite a sessão.
• NAT ID: mostra a regra NAT envolvida.
• Translated source / Translated destination: tornam visíveis SNAT, MASQ, DNAT ou PAT.
• Gateway ID: associa a sessão a um gateway e é particularmente importante em questões de WAN ou SD-WAN.
• Username / User group: mostram se o contexto de utilizador esperado está associado à sessão.
• Policy IDs: mostram a policy Web, Application, IPS, Traffic Shaping ou Remote Access atribuída.
• Expiry: mostra após quantos segundos uma sessão inativa expira.
• RX/TX bytes e packets: ajudam a identificar se apenas uma direção transporta dados ou se ambas estão ativas.
• Connection served by: mostra que firewall processa a ligação num ambiente HA.

Rule ID e NAT ID devem ser sempre lidas em conjunto com interfaces, endereços e portas. Uma Rule ID esperada com uma NAT ID inesperada indica um problema de correspondência NAT. Se ambas as IDs estiverem corretas, mas Out interface ou Gateway não, a próxima verificação deve ser o routing ou SD-WAN. NAT na Sophos Firewall explica os fundamentos.

Não sobrevalorizar Related Connections

Ao clicar na Connection ID, podem aparecer ligações dependentes, por exemplo em Web Proxy, FTP, SIP ou outros protocolos com sessões relacionadas. Se não existir um fluxo dependente, a vista permanece vazia. Uma vista Related Connections vazia não constitui, portanto, prova de erro.

Correlacionar a sessão ativa, o Log Viewer e o Packet Capture

As três ferramentas respondem sucessivamente a três perguntas diferentes:

1. Live Connections ou Connection List: que sessão existe atualmente e que IDs, interfaces, endereços, policies e associações de gateway contém?
2. Log Viewer: que decisão de firewall, NAT ou segurança foi registada?
3. Packet Capture: os pacotes chegam, são encaminhados e as respostas regressam?

Para uma comparação fiável:

1. Registar a hora do teste e o quíntuplo.
2. Registar a sessão ativa e a Connection ID.
3. Documentar Rule ID, NAT ID, In/Out interface, Gateway e endereços traduzidos.
4. Filtrar o Log Viewer por origem, destino, porta e hora.
5. Se faltar a resposta ou o caminho não for claro, iniciar o Packet Capture com um filtro BPF restrito.
6. Documentar o resultado antes de alterar a configuração.

Se o Live Connections mostrar uma sessão, mas não existir um evento de firewall correspondente no Log Viewer, verificar primeiro Log firewall traffic, Local reporting e os filtros. O procedimento está em Log Viewer não mostra novos logs.

A Device Console também oferece system diagnostics utilities connections. A ajuda pública atual documenta a ferramenta, mas não todas as opções dependentes do build. Antes de usar, verificar a sintaxe disponível com ? e utilizar a saída apenas para leitura. Troubleshooting CLI da Sophos Firewall explica o limite seguro.

Sintomas típicos

A sessão esperada não aparece

Verificar primeiro se o fluxo ainda está ativo e se a origem, o destino e a versão IP estão corretos. Com DNS, CDN, proxy, NAT ou IPv6, o endereço de destino real pode diferir do esperado. Gerar um novo teste e iniciar o Packet Capture em paralelo se não for claro se a firewall recebe pacotes.

É visível a Rule ID ou NAT ID errada

Uma regra mais geral pode ter prioridade numa posição superior. Comparar a ordem das regras de firewall e NAT, zonas, origem, destino, serviço, utilizador e horário. Não mover várias regras ao mesmo tempo. O procedimento guiado encontra-se em Testar corretamente uma regra da Sophos Firewall.

Apenas uma direção incrementa RX ou TX

Isto pode indicar um caminho de retorno em falta, uma tradução NAT incorreta, um problema no sistema de destino ou a firewall local do servidor. Verificar interfaces, endereços traduzidos e gateway e, em seguida, procurar ambas as direções no Packet Capture. Um contador isolado não comprova a causa.

Os valores não mudam após uma alteração de configuração

Provavelmente ainda está a ser observada a sessão existente. Terminar corretamente a ligação do cliente, gerar um novo fluxo e verificar novamente Start time e Connection ID. Não utilizar um flush global de sessões nem o reinício de um serviço como primeiro teste normal.

Em HA falta a sessão ou a entrada de log correspondente

Registar Connection served by e considerar o nó que processou o tráfego no momento do evento. Os logs são armazenados localmente em cada nó HA e não são totalmente sincronizados entre os nós. Não deduzir uma continuação sem interrupções da sessão a partir de uma Connection List visível. Configurar HA na Sophos Firewall explica os limites.

Other applications é invulgarmente grande

Primeiro, agrupar por IP de origem e abrir as sessões individuais. Aplicações não identificadas, tráfego do sistema e várias causas diferentes podem estar reunidos neste grupo. Verificar Rule ID, destinos, portas, utilizador e contexto da aplicação antes de concluir que existe um incidente de segurança.

Lista de verificação

• Origem, destino, protocolo, portas e hora do teste são conhecidos.
• Foi gerada uma nova ligação para o teste.
• O Live Connections foi agrupado de forma adequada por IP de origem, utilizador ou aplicação.
• Start time, In/Out interface, Rule ID e NAT ID correspondem ao esperado.
• Translated source/destination e Gateway ID correspondem ao caminho planeado.
• User e Policy IDs só foram esperados quando o reconhecimento correspondente estava ativo.
• Rule ID 0 foi interpretada no contexto correto de tráfego do sistema.
• Em HA, Connection served by foi documentado.
• O Log Viewer e, quando necessário, o Packet Capture confirmam a sessão.
• Não foi efetuado um flush global de sessões nem reiniciado um serviço como primeira tentativa de diagnóstico.

Perguntas frequentes