Saltar para o conteudo
Avanet

Configurar monitoramento de hardware via SNMP no Sophos Firewall

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 XGS. 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

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

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

  1. Em Administration > SNMP > SNMPv3 users and traps, clique em Add.
  2. Defina um nome de usuário permanente, como monitoring. Ele não poderá ser alterado posteriormente.
  3. Habilite Accept queries.
  4. Habilite Send traps somente se o firewall também precisar enviar notificações ao manager.
  5. Em novas configurações, escolha AES e SHA256 ou SHA512 sempre que possível. Ambas as passphrases devem ter pelo menos doze caracteres.
  6. Salve.

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, crie uma comunidade em Administration > SNMP > SNMPv1/v2c. 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.

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

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.

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

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

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

A Sophos documenta esses sensores para o hardware XGS. Em appliances virtuais, em nuvem ou de software, não se deve esperar sensores físicos do host na MIB do SFOS. Mesmo no XGS, 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 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 se aproxima do orçamento de energia.
  • 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.

Em um cluster HA, ambos os appliances são relevantes. Uma consulta somente ao endereço do cluster não mostra necessariamente a ventoinha, a fonte de alimentação ou a porta do appliance passivo. Se a arquitetura da rede e a plataforma permitirem acessos de gerenciamento separados, Primary e Auxiliary devem ser identificados individualmente. A conectividade SNMP real e a atribuição devem ser verificadas após a configuração do HA e após um failover. 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

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.