Configurar monitoramento de hardware via SNMP no Sophos Firewall

Para configurar o monitoramento de hardware via SNMP, habilite o agente em Administration > SNMP, configure preferencialmente um usuário SNMPv3, limite o acesso ao host de monitoramento em Administration > Device access e baixe a MIB atual. Depois, o sistema de monitoramento pode testar a conexão com snmpget e consultar a árvore de hardware com snmpwalk.

Desde o Sophos Firewall v22, a MIB também fornece temperatura da CPU e da NPU, velocidade das ventoinhas, status das fontes de alimentação e valores de PoE, dependendo do modelo de XGS Appliance. Assim, o SNMP responde principalmente a perguntas de status. Para eventos de segurança individuais, Central Firewall Reporting ou Syslog são mais adequados; para padrões de tráfego, use sFlow.

Quando não se pretende uma monitorização permanente, mas uma verificação imediata diretamente na appliance, Verificar temperatura e ventoinha do Sophos Firewall via SSH mostra como ler sensors e xgs-healthmond.log e interpretar corretamente aparentes alarmes dos sensores brutos.

⚠️ O SNMP deve ser acessível somente por uma rede confiável de gerenciamento ou monitoramento. Uma liberação ampla a partir de zonas de clientes, convidados, IoT ou WAN expõe desnecessariamente informações sobre modelo, interfaces e estado operacional.

Configurar o SNMP com segurança

Limitar o acesso ao host de monitoramento

Se uma zona de monitoramento dedicada precisar de acesso, habilite SNMP em Administration > Device access somente para essa zona. Se, por outro lado, apenas um servidor com endereço IP fixo fizer o polling, mantenha o SNMP desabilitado para a zona. Em vez disso, uma Local service ACL exception rule permite especificamente a origem, o destino no firewall e o serviço SNMP. A configuração completa está em Proteger o Device Access no Sophos Firewall.

O SNMP é um serviço local do firewall. Uma regra LAN-to-WAN normal não substitui o Device Access. O SNMP não deve ser exposto diretamente pela WAN; para monitoramento externo, uma VPN de gerenciamento é a conexão mais segura.

Habilitar o agente

Abra Administration > SNMP.
Habilite Enable SNMP agent.
Informe nome, local e contato, por exemplo, xgs-zrh-01, ZRH-DC1 / Rack 3 e noc@example.net.
Salve com Apply.
Use Download MIB para baixar a MIB correspondente à versão do firewall e importá-la no sistema de monitoramento.

Além da árvore de hardware específica da Sophos, o SFOS disponibiliza as MIB padrão SNMPv2-MIB, IF-MIB com Counter32 e Counter64, SNMPv2-SMI, IP-MIB, IP-FORWARD-MIB, TCP-MIB e UDP-MIB. Com elas, é possível monitorizar, por exemplo, uptime, contadores de interfaces, valores de IP e routing, bem como estatísticas TCP/UDP. A MIB atual da Sophos continua a ser importante, porque fornece os OID específicos do fabricante e o respetivo significado para a versão SFOS instalada.

As consultas chegam ao agente pela porta UDP 161. Os traps são enviados ao manager pela porta UDP 162. O roteamento e os firewalls locais dos hosts entre os dois sistemas também devem permitir essa direção.

Configurar o SNMPv3

Em Administration > SNMP > SNMPv3 users and traps, clique em Add.
Defina um nome de usuário permanente, como monitoring. Use letras sem espaços e configure o mesmo nome de usuário no manager. Ele não poderá ser alterado posteriormente.
Habilite Accept queries.
Habilite Send traps somente se o firewall também precisar enviar notificações ao manager.
Se Send traps estiver habilitado, informe em Authorized hosts os endereços IPv4 ou IPv6 reais dos receptores de traps previstos antes de salvar o usuário SNMPv3. Nesse campo devem constar os endereços dos receptores do seu próprio ambiente, não automaticamente os endereços IP dos hosts de polling.
Em novas configurações, escolha AES e SHA256 ou SHA512 sempre que possível. Ambas as passphrases devem ter pelo menos doze caracteres.
Salve.

O SFOS também oferece DES ou None para criptografia e MD5 para autenticação. Essas opções não devem ser usadas em novas configurações. Se um coletor oferecer suporte apenas a esses métodos, ele deve ser atualizado primeiro ou a conexão SNMP deve ser limitada a um caminho de gerenciamento isolado e tecnicamente justificado; um downgrade silencioso não é um teste de compatibilidade bem-sucedido.

Segundo a Sophos, Authorized hosts se aplica somente aos destinos de traps. A lista não limita as consultas SNMPv3. Para elas, são determinantes as credenciais corretas, Accept queries e Device Access.

Usar SNMPv1 ou SNMPv2c somente quando necessário

Se o sistema de monitoramento não oferecer suporte adequado ao SNMPv3, clique em Add em Administration > SNMP > SNMPv1/v2c e crie uma entrada de comunidade. São necessários nome, Community String, IPv4 ou IPv6, o IP do manager e Accept queries. Mantenha Send traps desabilitado se nenhum trap for usado. Em seguida, salve a entrada com Save.

O Community String funciona como uma senha, mas é transmitido sem criptografia no v1/v2c. Ele não deve aparecer em capturas de tela ou tickets e deve ser usado somente em uma rede de gerenciamento estritamente limitada.

Após uma atualização para o SFOS 22, verifique as entradas v1/v2c existentes: o firewall adota o nome anterior como Community String e gera um nome com o prefixo snmp para os objetos migrados. Nesse processo, variantes IPv4/IPv6 desnecessárias e origens de monitoramento que não são mais usadas podem ser removidas.

Habilitar traps de forma direcionada

SFOS 23 – atualizações de segurança por hotfix: Não existem notificações SNMP para estas atualizações. Em vez de esperar um trap, configurar o email para Firmware > Security updates com o interruptor global de email e SMTP funcional, e verificar as atualizações aplicadas. Esta exceção não se aplica indiscriminadamente a todos os hotfixes ou eventos de firmware.

Para traps, apenas o usuário SNMP ou a entrada de comunidade não são suficientes. Em System services > Notification list, habilite SNMP traps e os tipos de alerta realmente necessários.

O recebimento deve ser verificado quando um dos eventos selecionados ocorrer de fato. Os informs SNMPv3 são confirmados; se o firewall não receber a confirmação, segundo a Sophos, ele não tentará reenviar. Portanto, traps e informs não substituem o monitoramento do polling.

Guardar ou transferir a configuração SNMP

O SFOS 22 pode exportar e importar como ficheiro TAR a configuração do agente SNMP, das comunidades e dos utilizadores SNMPv3 em Backup and firmware > Import export. Isto é útil numa substituição controlada de hardware ou antes de alterações maiores. O arquivo contém configuração de monitorização relevante para a segurança e deve, por isso, ser guardado num local protegido. O procedimento geral está descrito em Exportar e importar a configuração do Sophos Firewall.

Uma importação bem-sucedida ainda não prova que a monitorização funciona. Depois, é necessário voltar a verificar o estado do agente, Device Access ou a ACL exception, as credenciais, as consultas e o destino dos traps com um teste real de polling e eventos. O sistema de monitorização também deve ter a MIB atual correspondente à versão de destino.

Reverter uma configuração de teste

Antes de um piloto, registe se o agente e o SNMP já estavam ativos para a zona em questão, que utilizadores, comunidades e ACL exceptions existem e que opções SNMP estão ativadas em System services > Notification list. Assim, é possível reverter apenas as alterações do piloto sem desligar outro sistema de monitorização.

Para reverter, desative primeiro a tarefa de polling e qualquer processamento de traps específico do piloto no sistema de monitorização, sem parar um recetor de traps partilhado. Em seguida, elimine o utilizador SNMPv3 ou a comunidade recém-criados e remova a respetiva Local Service ACL exception. Desative Enable SNMP agent e confirme com Apply apenas se o agente estava desativado antes do piloto e nenhum outro manager o utiliza. Se o SNMP tiver sido ativado para uma zona inteira, restaure também a definição anterior em Administration > Device access. Restaure ainda o estado registado das opções de traps e alertas ativadas exclusivamente para o piloto em System services > Notification list. Por fim, a consulta do host piloto deve terminar em timeout, enquanto os managers existentes devem continuar a receber respostas e os traps esperados.

Métricas de hardware e limitações dos modelos

O SFOS 22 disponibiliza os novos valores de hardware para XGS Appliances:

CPU temperature: todos os modelos de XGS Appliance.
NPU temperature: todos os modelos de XGS Appliance, exceto 88/88w, 108/108w, 118/118w e 128/128w.
Fan speed: todos os modelos de XGS Appliance, exceto 88/88w e 108/108w.
Power supply status: XGS 2100 e modelos superiores.
PoE measurements: modelos de XGS Appliance com PoE, exceto XGS 116/116w.

A Sophos documenta esses sensores para XGS Appliances. Em appliances virtuais, em nuvem ou de software, não se deve esperar sensores físicos do host na MIB do SFOS. Mesmo numa XGS Appliance, a ausência de uma métrica não indica automaticamente um erro; primeiro, verifique a limitação do modelo.

OIDs e unidades da MIB do SFOS 22

A árvore de hardware começa em .1.3.6.1.4.1.2604.5.1.9. As principais áreas são:

Temperatura da NPU: .1.3.6.1.4.1.2604.5.1.9.1.0
Temperatura da CPU: .1.3.6.1.4.1.2604.5.1.9.2.0
Velocidade da ventoinha: .1.3.6.1.4.1.2604.5.1.9.3.1.2
Status da fonte de alimentação: .1.3.6.1.4.1.2604.5.1.9.4.1.2
Tabela PoE: .1.3.6.1.4.1.2604.5.1.9.5

As temperaturas são fornecidas em décimos de grau Celsius: 420 corresponde a 42,0 °C. Os valores das ventoinhas são apresentados em RPM. A potência PoE é expressa em miliwatts, a tensão em milivolts e a corrente em miliamperes. Na fonte de alimentação, up(1) significa operacional e down(2) significa com falha.

Para cada porta, a tabela PoE também devolve a etiqueta, o estado, o limite de potência configurado e o consumo atual. enabled(1) indica que a alimentação PoE está ativa e disabled(2) que está desativada. Portanto, disabled(2) por si só não representa uma falha de hardware. Para alertas, compare o consumo com o limite da mesma porta e volte a detetar a etiqueta e o índice, em vez de associar cegamente as linhas da tabela a um modelo de monitorização antigo. A tabela não indica o orçamento PoE total do appliance; um alerta sobre o consumo agregado também requer um orçamento PoE específico do modelo e verificado separadamente.

Para obter valores de hardware que possam ser processados numericamente, é necessário executar no mínimo o SFOS 22.0 GA Build 411. Essa build corrige, entre outros, o problema NC-169564, no qual os valores dos sensores eram fornecidos como strings em vez de números inteiros, além de outros problemas de MIB e OID.

Após uma atualização de firmware, baixe novamente a MIB atual, importe-a no sistema de monitoramento e verifique a discovery. Os templates de monitoramento não devem depender exclusivamente dos nomes exibidos.

Testar a conexão e os valores de hardware

Os comandos Bash a seguir são executados em um host de monitoramento Linux ou macOS com Net-SNMP, não no Sophos Firewall. No macOS, inicie primeiro o bash, pois read -p tem outro significado no shell zsh padrão. Os exemplos foram verificados com a sintaxe documentada do Net-SNMP e a MIB oficial do SFOS 22, mas não foram executados em um firewall de cliente.

SHA-256 e SHA-512 normalmente exigem Net-SNMP 5.8 ou mais recente. Com snmpwalk -h, é possível verificar quais algoritmos o cliente instalado aceita. Versões antigas do macOS podem oferecer suporte apenas a MD5 e SHA.

⚠️ O Net-SNMP passa Community String e passphrases como argumentos de processo. A entrada via read evita que elas sejam salvas no histórico do shell, mas não impede que fiquem visíveis por pouco tempo na lista de processos. Execute esses testes somente em um host de monitoramento confiável.

Testar o SNMPv3 com AuthPriv

Ajuste o endereço IP e o usuário, informe as passphrases e consulte primeiro o OID padrão inofensivo sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Senha de autenticação SNMPv3: " SNMP_AUTH
printf '\n'
read -r -s -p "Senha de criptografia SNMPv3: " SNMP_PRIV
printf '\n'

snmpget -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_AUTH SNMP_PRIV

Uma primeira consulta bem-sucedida retorna sysUpTime.0 como Timeticks. O walk seguinte mostra somente os sensores compatíveis com o modelo específico.

Testar o SNMPv2c para compatibilidade

Para um manager v2c configurado de forma consciente:

FIREWALL_IP="192.0.2.1"

read -r -s -p "Comunidade SNMP: " SNMP_COMMUNITY
printf '\n'

snmpget -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_COMMUNITY

Um teste de uptime bem-sucedido comprova a conectividade e a validade das credenciais, mas ainda não a plausibilidade de todos os valores dos sensores. Em seguida, compare nome do host, modelo, firmware, versão da MIB e valores com o WebAdmin, o appliance e a operação normal. Para alertas de temperatura e PoE, primeiro crie uma baseline durante vários dias.

Alertas e HA

Alertas úteis não relatam apenas um valor medido isolado, mas um desvio operacional:

A conectividade SNMP ou uma interface esperada fica indisponível.
A temperatura da CPU ou da NPU permanece acima da própria baseline.
Uma ventoinha existente informa 0 RPM ou nenhum valor.
Uma fonte de alimentação redundante muda para down(2).
O consumo de PoE aproxima-se do limite de potência configurado de uma porta.
Erros ou drops de interface aumentam de forma anormal.

Limites universais e fixos de temperatura seriam enganosos. O modelo, o rack, a temperatura ambiente e a carga determinam a faixa normal. Um runbook de alertas deve primeiro verificar o valor medido, a tendência e a limitação do modelo e, em seguida, avaliar refrigeração, alimentação elétrica, cabeamento, porta do switch ou dispositivos PoE.

Os alertas devem diferenciar, no mínimo, Aviso e Crítico; para cada nível, o runbook deve definir responsável, primeira etapa de verificação e caminho de escalonamento.

Quando há suspeita confirmada de falha de hardware, documente modelo, número de série, firmware, horário e evolução. O processo de garantia e substituição está descrito em Falha de hardware Sophos: preparar RMA e substituição. Para unidades de armazenamento, Verificar a integridade do SSD via SMART é mais adequado do que SNMP.

Num cluster HA, cada appliance tem os seus próprios sensores. A Sophos documenta um endereço de administração do peer para acesso ao WebAdmin do appliance Auxiliary, mas não que os respetivos valores de hardware SNMP possam ser consultados separadamente através desse endereço. Por isso, uma consulta ao endereço do cluster não deve ser considerada prova do estado do hardware de ambos os appliances. Depois de configurar o HA e após um failover, verifique se o manager consegue associar inequivocamente as medições a um appliance; caso contrário, use outro método documentado para verificar o appliance Auxiliary. Os conceitos básicos estão em Configurar High Availability no Sophos Firewall.

Os valores SNMP não devem ser usados como única prova de desempenho. A interpretação de throughput e utilização está descrita em Interpretar corretamente os dados de desempenho do Sophos Firewall.

Solução de problemas

Timeout ou nenhuma resposta

Primeiro, verifique o IP de monitoramento, o roteamento, Device Access, Local Service ACL, Accept queries, a versão do SNMP e as credenciais. No WebAdmin, em Diagnostics > Packet capture, é possível usar o filtro host 192.0.2.50 and port 161; o procedimento está descrito em Packet Capture no WebAdmin.

Como alternativa, na opção 4 Device Console, verifique se a consulta chega ao firewall:

tcpdump 'host 192.0.2.50 and port 161'

Encerre o teste com Ctrl+C. Se nenhum pacote chegar, a causa está antes do agente SNMP. Se a solicitação chegar, mas nenhuma resposta voltar, verifique em seguida Device Access, IP do manager, credenciais e configuração do agente.

Falha na autenticação ou no algoritmo

O nome de usuário, o Security Level authPriv e os algoritmos de autenticação e criptografia devem corresponder exatamente à configuração do firewall. Se o cliente não aceitar SHA-256 ou SHA-512, verifique os métodos compatíveis com snmpwalk -h e atualize o Net-SNMP. Não faça downgrade silencioso para MD5 ou SNMP sem criptografia.

Em caso de erro de consulta, não insista em Authorized hosts: no SNMPv3, essa lista se aplica somente aos destinos de traps.

Valores de hardware ausentes ou incorretos

Verifique a limitação do modelo, o firmware e a versão da MIB. No SFOS 22.0 GA Build 365, os valores de hardware podem aparecer como strings em vez de números inteiros devido ao NC-169564; a Build 411 corrige o problema. Após a atualização, renove a MIB e a discovery do monitoramento.

As mensagens mais recentes podem ser lidas no Device Console:

show logs snmpd.log lines 100
show logs xgs-healthmond.log lines 100

snmpd.log pertence ao agente SNMP. xgs-healthmond.log ajuda a verificar a temperatura da CPU e o status das ventoinhas. Outras associações estão em Logs de serviço do Sophos Firewall.

Traps não chegam

Verificar primeiro o tipo de evento: no SFOS 23, é esperado que não exista um trap para uma atualização de segurança por hotfix. Esta ausência não comprova uma falha de encaminhamento, UDP 162 ou confirmação de informs SNMPv3, nem indica se a atualização foi bem-sucedida. Para este evento, utilizar o caminho de email e verificação de atualizações descrito acima em vez de alterar o transporte SNMP. As verificações seguintes aplicam-se a eventos que suportam traps.

Verifique Send traps, Authorized hosts, UDP 162 e os eventos selecionados em System services > Notification list. No Device Console, uma captura restrita mostra se o firewall envia dados ao manager:

tcpdump 'host 192.0.2.50 and port 162'

Se os pacotes saírem do firewall, mas não chegarem ao destino, verifique o roteamento, os firewalls intermediários e o receptor de traps. Para informs SNMPv3, verifique também a confirmação do manager.