Configurar Monitorização sFlow no Sophos Firewall

Com a monitorização sFlow, o Sophos Firewall pode enviar amostras de tráfego para um coletor externo. Assim, é mais fácil identificar picos de volume, fluxos incomuns, destinos inesperados e a distribuição de carga entre interfaces do que em logs individuais em tempo real. A função está disponível no Sophos Firewall v22.

A função é especialmente interessante para resolução de problemas, planejamento de capacidade e monitorização de segurança. No entanto, sFlow não substitui o Log viewer nem o Packet Capture ou uma manutenção adequada de logs através do Central Firewall Reporting ou Syslog. sFlow responde a outras perguntas: não “qual regra foi exatamente aplicada?”, mas “quais fluxos de tráfego passam por esta interface e como se distribuem?”. Para o estado do hardware, temperatura, ventoinhas, fontes de alimentação e PoE, o SNMP Hardware Monitoring é mais adequado.

Se, em vez de amostras de interface, forem necessários registros NetFlow v5 de regras de firewall com logging direcionado, Configurar e testar NetFlow no Sophos Firewall é mais adequado. Se, pelo contrário, um switch tiver de enviar passivamente para a firewall um fluxo de pacotes espelhado, Discover Mode com TAP e SPAN é o modelo adequado e claramente separado.

Quando o sFlow é útil

O sFlow é útil quando existe um coletor externo ou um sistema de monitorização e se pretende tornar visíveis os padrões de tráfego ao longo do tempo.

Casos de uso típicos:

• Identificar picos inesperados de largura de banda em interfaces WAN, LAN ou Core.
• Melhor classificar o tráfego entre VLANs ou locais.
• Apoiar o planejamento de capacidade para firewall, uplink ou comutação central.
• Encontrar fluxos suspeitos como ponto de partida para análise adicional.
• Comparar dados de monitorização com logs de firewall, Central Reporting ou dados SIEM.

Se apenas uma única conexão precisa ser verificada, o sFlow muitas vezes não é a ferramenta certa. Para testes de desempenho direcionados, o iPerf é mais adequado. Para problemas de conexão específicos, o Log Viewer, Policy Test e Packet Capture são geralmente mais rápidos.

Requisitos

Para o sFlow, é necessário:

• Sophos Firewall com SFOS 22.0 ou mais recente.
• Acesso administrativo à Device Console.
• Um coletor sFlow acessível, como um NMS, SIEM ou ferramenta de análise de fluxo.
• Uma rede segura entre o firewall e o coletor.
• Uma decisão clara sobre quais interfaces de hardware devem ser monitorizadas.

A configuração não é feita numa página do WebAdmin. No WebAdmin com SFOS 22, abra o menu do nome de utilizador (por exemplo, admin) no canto superior direito e selecione Console; com SFOS 23, clique nesse local no ícone de conta Account icon e selecione Command line. Em ambas as versões, selecione depois 4. Device Console e execute system sflow. O Advanced Shell não é a consola correta. O artigo Resolução de problemas do Sophos Firewall: serviços e logs explica a diferença.

Se utilizar um cliente SSH, aceda a Administration > Device access > Local service ACL, permita SSH a partir da zona de origem necessária e clique em Apply. Não abra uma zona inteira sem necessidade: uma Local service ACL exception rule é a opção mais restritiva quando apenas hosts de gestão específicos precisam de acesso. Confirme o acesso existente à consola ou por SSH antes de alterar o sFlow, não apenas quando já precisar de reverter.

Fluxo mínimo

A configuração em si é curta. O importante é planear primeiro o caminho de monitorização e só depois ativar o sFlow:

1. Definir o coletor, a porta e o caminho de rede.
2. Selecionar uma interface de hardware para o primeiro piloto.
3. Executar primeiro system sflow show para verificar se já existem collectors antigos ou interfaces de monitorização configurados.
4. Configurar a Sampling Rate e, opcionalmente, o Polling Interval.
5. Usar system sflow show para verificar se o coletor e a interface estão configurados corretamente.
6. Ativar o sFlow com system sflow on.
7. No coletor, confirmar que os dados chegam a partir do IP de agente esperado da firewall.

As secções seguintes explicam os passos individuais e os limites operacionais.

Limites importantes antes da ativação

O sFlow parece inofensivo, mas pode ter impactos na operação e segurança.

sFlow não é criptografado

O tráfego sFlow do firewall para o coletor não é criptografado. Portanto, o coletor deve ser acessível através de uma rede de gestão confiável, uma rede de monitorização interna ou um caminho protegido de outra forma.

⚠️ O sFlow não deve ser enviado sem proteção através de redes inseguras. Os dados de fluxo podem tornar visíveis endereços IP internos, relações de comunicação e sistemas de destino.

FastPath é desativado na interface monitorizada

Quando o sFlow está ativo em uma interface, o Fast Path é desativado nessa interface. Isso é especialmente importante em interfaces WAN, LAN ou Core altamente carregadas.

Antes da ativação, deve-se verificar:

• Qual é a carga da interface?
• Transporta tráfego de produção com débito elevado?
• Existe uma janela de manutenção para o primeiro teste?
• É possível comparar o desempenho antes e depois da ativação?

Para uma compreensão básica do desempenho do firewall, o artigo Compreender corretamente os dados de desempenho do Sophos Firewall é adequado.

Cluster HA: sFlow só funciona no Primary

Em um cluster HA, o agente sFlow funciona apenas no Primary. Isso deve ser considerado em avaliações e testes de failover. Após uma troca de função, deve-se verificar se o coletor continua a receber dados e se o IP do agente permanece conforme esperado.

Para o planejamento de operação e monitorização em HA, consulte Configurar Alta Disponibilidade no Sophos Firewall.

Planejar Interface e Coletor

O sFlow é configurado em interfaces de hardware. Interfaces dependentes, como aliases e VLANs da interface de hardware escolhida, também podem ser visíveis nas amostras. A seleção da interface deve, portanto, sempre corresponder ao caminho de tráfego real, não apenas ao nome da VLAN ou à avaliação desejada no coletor.

No SFOS 22, o agente utiliza o endereço IP de uma interface de hardware. No SFOS 23, esta é a seleção automática quando não existe um IP de agente configurado com agent-ip. No entanto, a ajuda do SFOS 22 não especifica qual endereço é escolhido quando existem várias interfaces adequadas. Não deduza um IP de agente específico apenas a partir do encaminhamento ou do nome da interface. Após a ativação, identifique e documente o IP que realmente chega ao coletor; qualquer lista de permissões do coletor deve refletir essa observação.

Isso é prático, mas pode levar a interpretações erradas:

• Se Port1 for monitorizado, interfaces VLAN ou alias associadas também podem ser visíveis na amostragem.
• Se apenas uma VLAN específica for de interesse, deve-se filtrar corretamente no coletor.
• Se existirem várias portas Core ou WAN, não se deve ativar todas as interfaces imediatamente.
• Em designs LAG, Bridge ou VLAN, deve-se saber previamente onde o tráfego relevante realmente flui.

A base limpa para isso é um planejamento compreensível de interfaces e zonas. O artigo Configurar Zonas e Interfaces no Sophos Firewall ajuda na classificação de interfaces físicas, VLANs, Bridges, LAGs e RED.

Planejar Piloto, Privacidade e Caminho de Retorno

Antes da primeira ativação, o sFlow deve ser tratado como uma alteração de monitorização produtiva. A função gera dados adicionais, altera o FastPath na interface monitorizada e envia informações de fluxo para outro sistema. Portanto, não basta apenas inserir o IP do coletor e a taxa de amostragem.

Antes do piloto, estes pontos devem estar claros:

• Qual problema específico o sFlow deve resolver: planejamento de capacidade, picos de largura de banda, monitorização de segurança ou resolução de problemas?
• Quem opera o coletor e quem pode ver os dados de fluxo?
• Por quanto tempo os dados de fluxo serão armazenados?
• Por qual caminho de rede os pacotes sFlow chegam ao coletor?
• Qual interface será testada primeiro?
• Quais métricas são consideradas como linha de base antes da ativação?
• Quando o sFlow será desativado ou movido para outra interface?

Os dados de fluxo podem tornar visíveis endereços IP internos, relações de comunicação, sistemas de destino, portas e volume de tráfego. Esses dados são menos detalhados do que uma captura de pacotes completa, mas ainda assim relevantes para operações e segurança. Se o coletor estiver conectado a um SIEM ou plataforma de monitorização central, a responsabilidade deve ser tão claramente definida quanto em Enviar Syslog do Sophos Firewall para SIEM.

Antes de qualquer alteração, guardar, com system sflow show, os coletores, as interfaces monitorizadas com as respetivas taxas de amostragem exatas, o intervalo de polling, o estado de ativação/desativação e a identidade do agente. Documentar também, como referência, a receção efetiva nos coletores e a associação à firewall. Para o piloto, escolher apenas uma interface que comprovadamente ainda não esteja a ser monitorizada; os monitores existentes permanecem inalterados.

Para o primeiro teste, um piloto limitado é sensato:

1. Documentar o estado inicial: carga da interface, carga da CPU, serviços afetados, dados de monitorização existentes.
2. Selecionar uma única interface que não esteja maximamente carregada.
3. Definir a taxa de amostragem de forma conservadora.
4. Verificar a recepção do coletor e a quantidade de dados.
5. Observar o desempenho, latência e throughput após a ativação.
6. Testar o caminho de retorno: system sflow off ou remover a interface de monitorização.

O caminho de retorno deve estar claro antes da ativação. Se o desempenho de uma interface de produção piorar, não altere simultaneamente a taxa de amostragem, o coletor, o encaminhamento e as regras de firewall. Primeiro desative o sFlow ou remova a interface afetada da monitorização e depois meça novamente.

A desativação global ou a remoção de uma interface só constitui uma forma de reversão no piloto inicial com um monitor recém-criado, ou uma medida de emergência expressamente autorizada. Numa configuração de monitorização existente, isto pode interromper a monitorização anterior e não restaura nem um monitor existente nem a respetiva taxa de amostragem guardada. Após uma medida de emergência, restaurar o estado de ativação guardado e verificar a restauração completa conforme indicado abaixo.

Para um primeiro piloto com os valores do exemplo sem alterar a identidade do agente, a reversão é a seguinte. Este bloco não repõe uma identidade configurada com agent-ip; a limitação do passo opcional do SFOS 23 continua a aplicar-se:

system sflow off
system sflow monitor delete interface-name Port1
system sflow collector delete ip-address 192.0.2.10 port 6343
system sflow polling-interval 60
system sflow show

Isto remove apenas as entradas criadas no exemplo e repõe o Polling Interval no valor predefinido documentado de 60 segundos. Se o sFlow já estava configurado, este bloco não é uma reversão geral. Remova apenas as suas adições, restaure o Polling Interval e o estado de ativação anteriormente registados com system sflow show e execute novamente o comando para verificar o estado final. Se o SSH tiver sido permitido apenas para este piloto, reponha também a Local service ACL ou a regra de exceção anteriormente documentada sem remover outros acessos de administração.

Numa configuração existente, os coletores e monitores herdados, bem como a identidade do agente, são preservados. Cada taxa de amostragem alterada tem de ser reposta no valor exato guardado, utilizando o procedimento previamente confirmado para o build instalado. Remover apenas as novas entradas criadas no âmbito desta intervenção e restaurar o intervalo de polling e o estado de ativação/desativação guardados. Com system sflow show, comparar o estado final completo com a configuração de referência; no coletor, verificar a associação efetiva e a receção de acordo com o estado de ativação guardado, bem como o tráfego e o desempenho afetados. A desativação global ou a eliminação de monitores, por si só, não constitui uma reversão completa.

Adicionar Coletor sFlow

Primeiro, o coletor é definido. Se nenhuma outra porta estiver planeada, o sFlow usa normalmente 6343. A Sophos permite valores de porta de 1 a 65535; o default documentado é 6343. Em ambientes produtivos, a porta deve ainda corresponder ao coletor utilizado e às regras de firewall no caminho.

Exemplo:

system sflow collector add ip-address 192.0.2.10 port 6343

A Sophos suporta até cinco coletores. Cada coletor é adicionado separadamente.

O status atual pode ser verificado em seguida:

system sflow show

Se um coletor precisar ser removido:

system sflow collector delete ip-address 192.0.2.10 port 6343

Opcional: definir a identidade do agente no SFOS 23

Este passo aplica-se apenas ao SFOS 23; o procedimento existente do SFOS 22 permanece inalterado. Com agent-ip, pode definir um IP unicast válido como identidade sFlow da firewall no coletor. Só é permitido um IP de agente configurado por firewall. Não é o endereço de destino do coletor. Sem uma identidade configurada, o SFOS 23 utiliza automaticamente um IP de interface de hardware.

⚠️ Antes de alterar qualquer coisa, guarde a configuração inicial com system sflow show, incluindo qualquer IP de agente existente. Uma identidade diferente pode alterar a atribuição e os filtros de identidade no coletor. Não substitua uma identidade existente às cegas; confirme primeiro o procedimento para a versão instalada. A descrição do SFOS 23 contradiz-se quanto à eliminação: o resumo da sintaxe exige um endereço IP, mas a descrição detalhada e o exemplo omitem-no. Por isso, não se fornece aqui um comando de eliminação nem uma reversão completa para uma identidade recém-configurada. Se precisar de regressar de forma fiável à identidade automática, omita este passo opcional até a sintaxe de eliminação ser esclarecida por uma fonte autorizada para a versão instalada. system sflow off para a exportação, mas não demonstra que a identidade anterior tenha sido restaurada.

Só após estas verificações prévias e sem uma identidade configurada existente pode adaptar este exemplo na Device Console:

system sflow show
system sflow agent-ip add 192.0.2.20
system sflow show

192.0.2.20 é um valor de documentação: substitua-o por um IP unicast válido destinado a identificar inequivocamente a sua firewall no coletor. 192.0.2.10 continua a ser o destino separado do coletor no exemplo. A identidade do agente não garante o endereço de origem UDP, o encaminhamento, a atribuição de interface nem o comportamento das ACL de transporte; verifique o caminho de rede separadamente.

Verifique a configuração após a alteração e, depois da ativação, compare o IP de agente que o coletor realmente descodifica dos dados sFlow com o valor planeado. Ajuste os filtros de identidade apenas com base nessa observação. Se houver uma diferença, verifique primeiro a configuração e a descodificação do coletor, em vez de adivinhar novas alterações de identidade. Volte a verificar a receção e a atribuição após um failover HA; não se garante uma identidade estável numa mudança de função.

Configurar Interface e Taxa de Amostragem

Em seguida, é definido qual interface será monitorizada e com qual taxa de amostragem os pacotes serão selecionados. No SFOS 22, o agente sFlow usa um IP de interface de hardware; no SFOS 23, isto só se aplica sem uma agent-ip configurada. No coletor pode, portanto, aparecer um IP de interface de hardware, mesmo que a análise real diga respeito a uma VLAN ou alias abaixo dessa porta.

Exemplo:

Antes do exemplo de monitor add que se segue, verificar a configuração guardada: Port1 tem de ser uma interface de hardware que ainda não tenha sido monitorizada. Se, em vez disso, for necessário alterar a taxa de amostragem de um monitor existente, confirmar primeiro, de forma inequívoca, tanto o procedimento de alteração suportado pelo build instalado como o procedimento de restauração da taxa exata guardada. Sem procedimentos de alteração e de reversão confirmados, parar. Não assumir que add atualiza um monitor existente de forma segura, nem deduzir um comando de reposição a partir da sintaxe Add/Delete.

system sflow monitor add interface-name Port1 sampling-rate 1000

A taxa de amostragem decide com que frequência os pacotes são selecionados como amostras. Um número menor gera mais amostras e, portanto, mais detalhes, mas também mais carga e mais dados no coletor. Um número maior reduz a quantidade de dados, mas pode tornar fluxos curtos ou menores menos visíveis.

Os limites relevantes são:

Para começar, um valor conservador é sensato, por exemplo, 1000 ou superior. Depois, deve-se verificar no coletor se a quantidade de dados, nível de detalhe e desempenho correspondem ao objetivo.

O comando de eliminação que se segue destina-se apenas à remoção do monitor recém-criado neste piloto. Não eliminar um monitor herdado como forma normal de reversão; a respetiva taxa alterada deve ser restaurada através do procedimento previamente confirmado.

Uma interface de monitorização pode ser removida novamente:

system sflow monitor delete interface-name Port1

Definir Intervalo de Polling

Além da amostragem de pacotes, o sFlow também pode consultar estatísticas e contadores de interface em um intervalo. A Sophos permite um intervalo de polling entre 30 e 300 segundos; o default é 60 segundos. Com 0, o polling é desativado.

Exemplo:

system sflow polling-interval 80

Desativar polling:

system sflow polling-interval 0

Para a maioria dos ambientes, um intervalo médio é sensato. Intervalos muito curtos geram mais dados e não são automaticamente mais úteis.

Ativar sFlow

Quando o coletor, interface e polling estão planejados, o sFlow é ativado. Por predefinição, o sFlow está desativado:

system sflow on

Verificar o status:

system sflow show

A desativação global que se segue também termina a monitorização sFlow existente. Como forma de reversão, destina-se apenas ao piloto inicial ou a uma medida de emergência expressamente autorizada, e não à restauração de uma configuração existente. Em seguida, restaurar e verificar o estado de ativação guardado e os restantes elementos da configuração de referência.

Desativar sFlow:

system sflow off

Após a ativação, deve-se verificar não apenas o firewall, mas também o coletor. Lá, os dados do IP do agente do firewall devem chegar e ser resolvidos de forma significativa.

Validação após a Ativação

Após a ativação, deve-se verificar os seguintes pontos:

1. system sflow show mostra o coletor, interface, taxa de amostragem e status corretamente.
2. O coletor recebe dados sFlow do IP do firewall esperado.
3. O tempo no firewall e no coletor está correto.
4. Os nomes das interfaces e a direção do fluxo são compreensíveis no coletor.
5. A carga no firewall e no coletor permanece não crítica.
6. A quantidade de dados corresponde ao armazenamento e processamento planejados.
7. O caminho de retorno definido foi testado uma vez ou pelo menos documentado como um comando concreto.
8. Em clusters HA, após um failover, verifica-se se os dados continuam a chegar.

Se as regras de firewall, NAT, VPN ou TLS Inspection forem analisadas em paralelo, o sFlow não deve ser considerado isoladamente. Para decisões de conexão específicas, o Log Viewer e o Packet Capture continuam a ser decisivos. Para uma avaliação a longo prazo, deve-se verificar se é necessário Syslog ou Central Reporting adicionalmente.

Resolução de Problemas

Nenhum Tráfego no Coletor

Primeiro, verifique system sflow show e depois o IP do coletor, a porta e o caminho de rede. No coletor, confirme se os pacotes sFlow recebidos estão a ser descartados ou filtrados por um IP de agente incorreto. Se o firewall tiver vários endereços IP em interfaces de hardware, não presuma antecipadamente qual será o IP do agente.

Apenas Parte do Tráfego é Visível

O sFlow trabalha com amostragem. É normal que nem todos os pacotes individuais sejam visíveis. Se fluxos importantes estiverem faltando, a taxa de amostragem pode ser ajustada ou outra interface escolhida. Em VLANs e aliases, deve-se verificar se a interface de hardware correta está a ser monitorizada.

Também durante a resolução de problemas se aplica a seguinte regra a um monitor existente: alterar a taxa de amostragem apenas se os procedimentos de alteração e de restauração suportados pelo build para o valor inicial exato guardado tiverem sido previamente confirmados; caso contrário, parar.

Desempenho Muda Após Ativação

Se uma interface muito utilizada estiver a ser monitorizada, a desativação do FastPath pode ser relevante. Nesse caso, o sFlow deve ser desativado para teste e o desempenho comparado. Em interfaces Core ou WAN produtivas, um teste planejado é melhor do que uma ativação espontânea.

Uma desativação deste tipo numa configuração de monitorização existente exige autorização expressa como medida de emergência; não constitui uma reversão completa. Após a medição, restaurar o estado de ativação guardado e verificar a configuração, a receção nos coletores e a associação, bem como o tráfego e o desempenho afetados, comparando-os com os dados de referência.

Dados HA Parecem Incompletos

Em ambientes HA, o agente sFlow funciona no Primary. Após um failover, deve-se verificar qual firewall é atualmente o Primary, qual IP é usado como IP do agente e se o coletor continua a atribuir os dados corretamente.

Lista de Verificação Operacional

• Colocar o coletor em uma rede segura.
• Documentar proprietário, propósito, acesso e armazenamento dos dados de fluxo.
• Verificar porta UDP e roteamento para o coletor.
• Começar com uma ou poucas interfaces.
• Capturar linha de base antes e depois para carga de interface, CPU, latência e throughput.
• Escolher a taxa de amostragem de forma conservadora e ajustar depois.
• Considerar o impacto do FastPath em interfaces críticas.
• Planear a reversão com base na configuração guardada: preservar os monitores herdados e restaurar as taxas de amostragem alteradas nos valores exatos através do procedimento previamente confirmado para o build. system sflow off ou a remoção do novo monitor destinam-se apenas à limpeza do piloto inicial ou a uma medida de emergência expressamente autorizada; em seguida, restaurar e verificar o estado de ativação guardado e todos os elementos de referência.
• Testar failover HA se o sFlow for usado no cluster.
• Comparar dados de fluxo com Log Viewer, Packet Capture e Reporting.
• Verificar regularmente se os dados ainda estão a ser analisados ou apenas coletados sem uso.

FAQ