Configurar e testar NetFlow no Sophos Firewall

Com NetFlow, o Sophos Firewall envia metadados de conexões para um coletor de fluxos externo. Isso permite analisar relações de comunicação, volume de tráfego e conexões incomuns ao longo do tempo. O requisito mais importante é fácil de ignorar: apenas o tráfego de regras de firewall com Log firewall traffic ativado é exportado.

O caminho rápido é:

1. Preparar no coletor um listener NetFlow v5, por exemplo em UDP 2055.
2. Adicionar o coletor em System > Administration > Netflow.
3. Ativar Log firewall traffic na regra de firewall correspondente.
4. Gerar um fluxo de teste claramente documentado.
5. Verificar separadamente o transporte com Packet Capture e o conteúdo no coletor.

Um resultado confiável exige que três elementos coincidam: os campos da versão 5, a regra de firewall realmente aplicada e o caminho de rede até o coletor.

Quando NetFlow é a ferramenta certa

NetFlow é adequado quando um coletor deve armazenar e analisar ao longo do tempo registros de fluxos de conexões processadas por regras com logging. Perguntas típicas são: quais endereços de origem e destino se comunicam, quais portas são usadas e quantos pacotes ou bytes pertencem ao fluxo?

Outras ferramentas respondem a outras perguntas:

• Monitoramento sFlow coleta amostras de tráfego e contadores de interfaces de hardware selecionadas. É especialmente adequado para padrões de tráfego e planejamento de capacidade.
• Syslog para um SIEM transporta eventos de firewall, VPN, IPS e outros logs com campos específicos do produto.
• SNMP Hardware Monitoring monitora hardware, interfaces, temperatura, ventoinhas e fontes de alimentação.
• Central Firewall Reporting oferece relatórios, pesquisa e retenção da Sophos no Sophos Fusion (anteriormente Sophos Central).
• Packet Capture continua mais preciso para um único caminho de pacote, NAT ou problema de conexão.

O NetFlow não substitui essas ferramentas. Muitas vezes, o coletor primeiro mostra um fluxo incomum e, em seguida, o Log Viewer ou o Packet Capture explica qual regra, decisão de NAT ou função de segurança esteve envolvida.

O que NetFlow v5 mostra e o que não mostra

O SFOS 22 e o SFOS 23 documentam NetFlow Version 5 e a capacidade de exportar todos os parâmetros v5. Essa capacidade documentada não confirma que cada campo tenha um valor significativo em todos os fluxos; é preciso verificar os registros realmente recebidos. Um registro v5 pode conter, entre outros, os seguintes valores:

• endereço IPv4 de origem e destino;
• porta de origem e destino e protocolo IP;
• contadores de pacotes e bytes;
• horário de início e fim do fluxo;
• interface de entrada e saída como ifIndex;
• flags TCP, ToS e informações de AS e prefixo.

O NetFlow v5, por outro lado, não contém campos nativos para nome de usuário, Firewall Rule ID, URL, aplicação ou conteúdo do pacote. Um coletor pode correlacionar endereços IP com fontes de dados adicionais, mas essas informações não vêm diretamente do registro v5.

A ajuda da Sophos também descreve o objetivo de identificar protocolos, políticas, interfaces e usuários que consomem muita largura de banda. Protocolos e índices de interfaces podem ser analisados a partir de registros v5; a associação a uma política ou a um usuário exige dados adicionais de logs ou de inventário. A Sophos cita PRTG e Open Source Data Analyzer como exemplos para a análise de relatórios, não como uma lista exaustiva de compatibilidade.

O endereço do coletor pode ser inserido no SFOS como endereço IPv4, endereço IPv6 ou FQDN. Isso não altera o formato de exportação: o firewall continua enviando NetFlow v5. Esse formato não tem campos para endereços IPv6 de origem e destino. Portanto, um endereço IPv6 do coletor afeta apenas o transporte até ele; não permite representar o tráfego útil IPv6 como fluxos IPv6 nativos.

Nota sobre a API: A referência Configure Netflow do SFOS 23 documenta para NetflowServer os tipos de dados IPADDRESS e DOMAIN e um máximo de 255 caracteres. A referência do SFOS 22 também lista STRING e não especifica um comprimento máximo para esse campo. Essa é uma diferença nos metadados documentados da API, não uma prova de aceitação ilimitada no SFOS 22 nem de valores que passaram a ser rejeitados no SFOS 23. Não permite deduzir uma validação no WebAdmin nem um comportamento verificado por testes durante a execução.

Preparar o coletor e o caminho de rede

Antes de configurar o firewall, o coletor precisa de um listener NetFlow v5 ativo. A Sophos usa UDP 2055 por padrão; é possível usar outra porta UDP válida quando firewall e coletor estão configurados de forma idêntica. É possível cadastrar até cinco servidores NetFlow.

Este exemplo usa:

• Nome do coletor: flow-collector-primary
• Endereço do coletor: 192.0.2.50
• Transporte: UDP
• Porta do coletor: 2055
• Regra de teste: LAN_Test_to_WAN_HTTPS

192.0.2.50 é um endereço reservado para documentação e não pode ser usado como coletor real. No exemplo, ele apenas mostra qual campo deve ser preenchido. Deve-se inserir o endereço IP real ou o FQDN do coletor em que o listener v5 está ativo e que o firewall alcança pelo caminho de rede planejado. Antes disso, os seguintes pontos precisam estar claros:

• O coletor suporta NetFlow v5 e realmente escuta em UDP 2055.
• O firewall tem uma rota para o coletor; ao usar FQDN, o DNS também funciona.
• Os componentes intermediários e o firewall do host do coletor permitem a porta UDP.
• O coletor associa o endereço de origem realmente utilizado ao firewall correto.
• A finalidade, os direitos de acesso e o período de retenção dos dados de fluxo estão definidos.

A exportação NetFlow é tráfego de sistema gerado pelo firewall. Uma regra de firewall de clientes não controla essa exportação. São relevantes o caminho do tráfego de sistema, o roteamento, o DNS ao usar FQDN e os filtros entre o firewall e o coletor.

⚠️ As referências de NetFlow analisadas não descrevem configurações de TLS ou autenticação e não constituem um inventário completo das opções disponíveis. Os dados de fluxo podem expor endereços internos, parceiros de comunicação, portas, horários e volumes. Por isso, o coletor deveria ser acessível por uma rede de gerenciamento confiável ou por um caminho VPN protegido.

Exemplo: preparar o PRTG como coletor

No PRTG, quem recebe os fluxos é a Probe, não automaticamente o servidor web central. O exemplo a seguir pressupõe uma Probe local ou remota já existente. O sensor NetFlow v5 não suporta uma Probe de cluster; no PRTG Hosted Monitor, é necessária uma Probe remota para essa finalidade.

1. Adicionar um sensor NetFlow v5 na Probe que será utilizada.
2. Em Receive Packets on UDP Port, inserir 2055.
3. Em Receive Packets on IP Address, selecionar o endereço real da Probe que será cadastrado no SFOS como destino do coletor.
4. Em Sender IP Address, inserir o endereço de origem da exportação realmente observado no firewall. Um campo vazio aceita dados de qualquer remetente nessa porta e, portanto, não é uma alternativa permanente adequada à associação correta.
5. Para o primeiro teste, deixar Include Filter e Exclude Filter vazios, para que nenhum filtro do coletor oculte o fluxo de referência. Permitir a recepção no host da Probe apenas para os exportadores necessários.

Após o teste de exportação, comparar Top Talkers, Top Connections e Top Protocols com os valores de teste anotados. Se os pacotes UDP chegarem ao host da Probe, mas não houver resultados de análise, verificar primeiro o endereço de recepção, o filtro de remetente e os filtros Include/Exclude. O status Unknown pode ocorrer após o término de Active Flow Timeout (Minutes) sem novos dados de fluxo. Esse status, por si só, não comprova um erro no firewall; aqui não se especifica um timeout de exportação não confirmado para o SFOS.

Configurar o coletor NetFlow

1. No WebAdmin, abrir System > Administration > Netflow.
2. Clicar em Add.
3. Em Server name, inserir flow-collector-primary.
4. Em Netflow server IP/domain, inserir 192.0.2.50.
5. Em Netflow server port, inserir 2055.
6. Salvar com Save.

As entradas de servidores NetFlow existentes também podem ser atualizadas. Após uma alteração, repetir o teste controlado de exportação descrito abaixo: verificar separadamente a correspondência da regra, o transporte UDP e a descodificação v5.

Não há um teste de conexão documentado nessa tela. Portanto, uma entrada salva confirma apenas a configuração, não o transporte nem a decodificação no coletor.

Ativar Rule Logging como fonte de dados

O NetFlow exporta apenas conexões de regras de firewall em que Log firewall traffic está ativado. A configuração é verificada na regra correspondente em Rules and policies > Firewall rules.

Para o primeiro teste, deve-se usar uma regra claramente delimitada. No exemplo, LAN_Test_to_WAN_HTTPS processa um teste HTTPS de um cliente conhecido para um destino permitido. O nome de exemplo não é o mais importante; é essencial identificar sem dúvida no Log Viewer qual regra realmente processa o fluxo.

A criação e o logging corretos de uma regra são explicados em Configurar regras do Sophos Firewall com segurança. Em caso de dúvida sobre o match, ajuda testar a regra com Log Viewer, Policy tester e Packet Capture.

Testar a exportação de forma controlada

O teste separa três perguntas: a regra correta foi aplicada, um pacote UDP sai do firewall e o coletor consegue interpretar o conteúdo como NetFlow v5?

Antes de começar, definir uma janela de observação finita adequada ao ambiente local e anotar seu horário de término. As fontes analisadas não especificam um cronograma de exportação do SFOS; a exportação pode ser observada com atraso após o fim da conexão. Durante a janela, monitorar o estado da captura, o uso do buffer e o processamento no coletor. A captura do WebAdmin tem um buffer de 2048 KB e para automaticamente quando ele fica cheio, a menos que Wrap capture buffer once full esteja ativado. Essa opção mantém a captura em execução, mas sobrescreve os pacotes anteriores. Salvar as evidências necessárias antes de perdê-las e não considerar uma captura interrompida antes do término ou sobrescrita como observação contínua.

1. No coletor, verificar se o listener v5 está ativo em UDP 2055.
2. Anotar horário, cliente de teste, endereço de destino, porta de destino e regra de firewall esperada.
3. Em Diagnostics > Packet capture, clicar em Configure, inserir dst host 192.0.2.50 and dst port 2055 em Enter BPF string, clicar em Save e iniciar a captura com Trace On.
4. Gerar um único fluxo de teste identificável e limitado a partir do cliente, por exemplo uma solicitação HTTPS permitida, e encerrar a conexão quando possível. Anotar o horário de término.
5. No Log Viewer, verificar se LAN_Test_to_WAN_HTTPS ou a Rule ID esperada foi aplicada.
6. Continuar observando até o término definido da janela e procurar pacotes UDP destinados ao coletor; depois interromper a captura com Trace Off.
7. Durante a mesma janela, verificar se aparece no coletor um registro v5 com os valores de origem e destino esperados e anotar o resultado. A ausência de dados em uma janela curta não é conclusiva sem conhecer os tempos de exportação; por si só, não comprova uma falha de exportação.

Para uma verificação adicional somente de leitura, pode-se executar uma captura curta na Device Console:

tcpdump 'host 192.0.2.50 and port 2055'

192.0.2.50 e 2055 devem ser substituídos pelo coletor e pela porta reais. A captura é encerrada com Ctrl+C. Pacotes UDP visíveis confirmam o transporte até a interface observada, mas ainda não confirmam que o coletor decodifica os registros como versão 5.

Um teste só está completo quando o match da regra, o transporte UDP e a decodificação v5 estão corretos. Assim também fica claro em que ponto ocorre um erro.

Isolar fluxos ausentes ou incompletos

Nenhum pacote UDP para o endereço do coletor

Verificar o endereço e a porta do coletor em System > Administration > Netflow. Em seguida, conferir o DNS ao usar FQDN, a rota, a interface de saída e os filtros nos componentes intermediários. O firewall do host do coletor também precisa permitir UDP 2055.

Se outras regras ou caminhos de roteamento forem alterados ao mesmo tempo, o resultado dificilmente poderá ser atribuído a uma causa. Por isso, deve-se começar com uma regra conhecida com logging e um único fluxo de teste.

Os pacotes UDP chegam, mas o coletor não mostra nada

O listener precisa processar explicitamente NetFlow v5. Uma entrada configurada somente para NetFlow v9, IPFIX ou sFlow pode receber os pacotes UDP e ainda assim não mostrar fluxos utilizáveis. Verificar os logs do coletor, o parser e o endereço de origem esperado.

Nesse caso, o Packet Capture comprova apenas o transporte. A decodificação bem-sucedida deve estar visível no próprio coletor.

Apenas parte das conexões está visível

Primeiro, verificar qual regra de firewall realmente processa o tráfego ausente e se Log firewall traffic está ativado nela. Outra regra pode corresponder antes por estar mais acima. A perda de pacotes UDP também pode causar lacunas.

O NetFlow v5 tem limitações técnicas. A ausência de nomes de usuário, Rule IDs, URLs ou nomes de aplicações não é um erro de exportação. O formato também não pode representar tráfego útil IPv6 com endereços IPv6 de origem e destino nativos; um endereço IPv6 do coletor não altera essa limitação.

O endereço de origem é inesperado

As referências de NetFlow analisadas não descrevem uma configuração específica para o endereço de origem da exportação. Uma Packet Capture limitada no tempo mostra o endereço realmente utilizado quando pacotes de exportação são observados. Compará-lo com a associação e os filtros de entrada do coletor; se for diferente do esperado, verificar em seguida a rota e a interface de saída.

Failover de HA ou troca de firmware

As referências analisadas não estabelecem garantias de exportação NetFlow sem interrupções ou duplicatas durante um failover de HA. Realizar o failover apenas como exercício operacional planejado e autorizado. Antes, durante a operação normal, e depois, usar o mesmo teste limitado para verificar a recepção dos registros, lacunas ou duplicatas, o endereço de origem e a associação ao firewall correto. Essas são instruções de verificação, não um relato de um teste de HA realizado.

Após alterações de firmware, roteamento, DNS, coletor ou regras, o mesmo teste documentado é repetido. Um curto fluxo de referência é mais confiável do que presumir que uma entrada NetFlow salva continua funcionando.

Operação e privacidade

Os dados NetFlow, assim como os logs de firewall, precisam de um responsável e de um período de retenção definido. A operação deve cobrir pelo menos estes pontos:

• monitorar a recepção no coletor por firewall e alertar sobre falhas;
• documentar endereços de origem, associação de interfaces e sincronização de horário;
• limitar o acesso a metadados internos de comunicação;
• definir retenção e exclusão no coletor;
• testar novamente após alterações de roteamento, HA, firmware ou Rule Logging;
• verificar fluxos incomuns com Log Viewer ou Packet Capture.

O NetFlow mostra relações ao longo do tempo, mas não comprova a causa de uma conexão bloqueada ou lenta. Para uma sessão específica, Rule ID, NAT ID, caminho de pacotes e funções de segurança envolvidas continuam decisivos.

Reverter a alteração

Para interromper a exportação, excluir o servidor correspondente em System > Administration > Netflow. Em seguida, usar o mesmo filtro restrito do Packet Capture para confirmar que nenhum pacote UDP é mais enviado a esse coletor. Log firewall traffic só deve voltar ao estado anterior: desativá-lo não apenas interrompe o NetFlow para essa regra, mas também impede novas entradas no log do firewall.

Perguntas frequentes