Configurar Monitorização de Hardware SNMP no Sophos Firewall
Com o Monitorização de Hardware SNMP, pode-se integrar melhor o estado de um Sophos Firewall num sistema de monitorização existente. Além dos valores clássicos de acessibilidade e interface, desde o Sophos Firewall v22 estão disponíveis métricas de hardware adicionais através da MIB. Estas incluem, dependendo do modelo, temperatura da CPU, temperatura da NPU, ventoinhas, estado da fonte de alimentação e valores de PoE.
Isto é particularmente interessante para instalações XGS produtivas. Um firewall pode ainda ser acessível no WebAdmin, mas mesmo assim mostrar sinais de problemas térmicos, ventoinhas defeituosas, uma fonte de alimentação avariada ou carga PoE inesperada. Tais condições não devem ser notadas apenas no próximo login manual.
Quando o SNMP na firewall é útil
O SNMP é útil quando já existe um sistema de monitorização em operação e a firewall deve ser monitorizada como um componente de infraestrutura.
Casos de uso típicos:
- Monitorizar o estado de hardware de appliances XGS.
- Observar a temperatura da CPU e NPU ao longo do tempo.
- Incluir o estado das ventoinhas e fontes de alimentação num NOC ou monitorização MSP.
- Controlar a carga PoE em modelos XGS com portas PoE.
- Comparar valores de interface com a monitorização de switches, routers e provedores.
- Correlacionar alarmes de firewall, switch, UPS e temperatura ambiente.
O SNMP não substitui a análise de logs. Para questões de tráfego e segurança, o Log viewer, Central Firewall Reporting, Syslog ou um SIEM continuam a ser mais importantes. Para padrões de tráfego em interfaces, o sFlow Monitoring no Sophos Firewall é mais adequado. O SNMP responde principalmente a questões de estado: o dispositivo está acessível, as interfaces estão operacionais, os valores de hardware são normais e os valores mudam ao longo do tempo?
Pré-requisitos
Antes de configurar, deve-se esclarecer os seguintes pontos:
- Existe um sistema de monitorização com suporte SNMP.
- A firewall é acessível através de uma rede de gestão ou monitorização.
- O acesso SNMP é permitido sob Device Access apenas para o sistema de monitorização.
- A MIB apropriada do Sophos Firewall está importada no sistema de monitorização.
- Está claro quais modelos de firewall serão monitorizados e quais valores de hardware esses modelos fornecem.
- As regras de alarme são planeadas para relatar problemas reais de operação e não apenas gerar ruído.
⚠️ O SNMP não deve ser amplamente acessível a partir de zonas de cliente, convidado, IoT ou WAN. Os dados de monitorização podem tornar visíveis o modelo, interfaces, valores de status e condições de operação. O acesso deve ser feito a partir de uma rede de gestão ou monitorização confiável.
Separar claramente SNMP, sFlow e Reporting
SNMP, sFlow e Reporting fornecem respostas diferentes.
| Ferramenta | Boa pergunta | Não ideal para |
|---|---|---|
| SNMP | A firewall está acessível, como estão os valores de hardware e interface? | Regras de firewall individuais, bloqueio de URL ou erro de VPN |
| sFlow | Que fluxos de tráfego passam por uma interface? | Análise exata de pacotes ou regras |
| Log Viewer / Syslog / Central Reporting | Que regra, módulo ou utilizador esteve envolvido? | Estado de hardware e valores de polling de interface a longo prazo |
| Packet Capture | O que é realmente visível na interface? | Monitorização contínua |
Na prática, estas ferramentas são combinadas. O SNMP relata, por exemplo, alta temperatura ou erros de interface. Depois, verifica-se o Log Viewer, Packet Capture, porta do switch, temperatura ambiente ou o segmento de rede afetado.
Quais valores de hardware o SFOS 22 fornece
As notas de lançamento do SFOS 22 documentam métricas de hardware SNMP adicionais. A disponibilidade depende do modelo de firewall.
| Métrica | Disponível segundo a Sophos para |
|---|---|
| Temperatura da CPU | todos os modelos XGS |
| Temperatura da NPU | Modelos XGS exceto XGS 88/88w, 108/108w, 118/118w, 128/128w |
| Velocidade da ventoinha | Modelos XGS exceto XGS 88/88w e 108/108w |
| Estado da fonte de alimentação | XGS 2100 e superiores |
| Medições PoE | Modelos XGS com PoE, exceto XGS 116/116w |
Esta tabela é importante para as expectativas. Se um pequeno modelo de desktop não fornecer valores de ventoinha ou temperatura da NPU, isso não é automaticamente um erro de monitorização. Primeiro, deve-se verificar se o modelo suporta a métrica em questão.
Proteger o acesso SNMP
A primeira verificação de segurança não ocorre no sistema de monitorização, mas na própria firewall.
Em Administration > Device access, o SNMP deve ser acessível apenas a partir da rede onde o servidor de monitorização está localizado. Se o sistema de monitorização tiver um único endereço IP fixo, uma Local service ACL exception rule é geralmente melhor do que uma autorização ampla de zona.
Regras básicas sensatas:
- Não permitir SNMP a partir de
WAN. - Não liberar SNMP para zonas completas de clientes ou servidores se apenas um host de monitorização estiver a fazer polling.
- Definir o servidor de monitorização como um objeto de host próprio ou rede de gestão.
- Verificar o acesso após alterações com Packet Capture ou teste de monitorização.
- Remover regras SNMP não utilizadas e fontes de monitorização antigas.
O Device Access controla o tráfego para a própria firewall. Uma regra de firewall normal para tráfego LAN-para-WAN não substitui esta configuração.
Escolher conscientemente a versão SNMP
Sempre que possível, deve-se usar SNMPv3, pois permite autenticação e, com a configuração AuthPriv adequada, também criptografia. SNMPv1 e SNMPv2c trabalham com Community Strings. Estas Community Strings não são contas de utilizador, mas segredos partilhados e devem ser protegidas adequadamente.
Para SNMPv1/v2c, a Sophos no SFOS 22 menciona uma alteração: pode-se adicionar o Community String e escolher se a configuração se aplica a IPv4 ou IPv6. Durante a atualização, a firewall adota nomes existentes como Community String e gera nomes de objetos migrados com o prefixo snmp.
Após uma atualização, deve-se verificar:
- Existem Community Strings SNMPv1/v2c antigas?
- Os objetos
snmpmigrados automaticamente estão nomeados de forma compreensível? - IPv4, IPv6 ou ambos são realmente necessários?
- Podem ser removidas fontes de monitorização antigas?
- É possível usar SNMPv3 ou o v2c permanece necessário por razões de compatibilidade?
⚠️ Community Strings não devem ser tratadas como etiquetas inofensivas. Esses strings pertencem a um conceito de senhas ou segredos, não devem ser copiados em tickets e não devem ser visíveis em capturas de tela.
Importar MIB e verificar OIDs
Para que um sistema de monitorização reconheça os valores Sophos de forma útil, precisa do ficheiro MIB apropriado. A MIB descreve quais OIDs estão disponíveis para valores de firewall, interface e hardware.
Procedimento prático:
- Obter o ficheiro MIB atual do Sophos Firewall ou da documentação Sophos apropriada.
- Importar a MIB no sistema de monitorização.
- Adicionar a firewall com SNMPv3 ou uma configuração v1/v2c escolhida conscientemente.
- Deixar o modelo, versão de firmware e OIDs acessíveis serem reconhecidos.
- Verificar métricas de hardware contra o modelo específico.
- Realizar um polling manual e validar os valores.
- Só depois ativar regras de alarme.
Após atualizações de firmware, a página MIB deve ser verificada novamente. Novas versões do SFOS podem adicionar OIDs ou alterar áreas existentes. Se um sistema de monitorização não resolver mais valores corretamente após uma atualização, não se deve suspeitar primeiro da firewall, mas verificar a versão MIB, descoberta e atribuição de OID.
Alarmes sensatos
A monitorização SNMP só é útil se os alarmes forem definidos de forma sensata. Limiares muito apertados geram ruído, limiares muito amplos relatam problemas tarde demais.
Áreas de alarme típicas:
| Área | Verificação sensata |
|---|---|
| Acessibilidade | A firewall não responde mais por SNMP ou Ping |
| Temperatura da CPU | A temperatura sobe permanentemente acima da faixa normal |
| Temperatura da NPU | Tendência de temperatura notável ou permanentemente mais alta que valores de comparação |
| Velocidade da ventoinha | Valor da ventoinha ausente, é zero ou significativamente fora da faixa normal |
| Fonte de alimentação | Fonte de alimentação redundante ausente ou relatando erro |
| PoE | Carga PoE aproxima-se do orçamento disponível |
| Interfaces | Porta inativa, contador de erros, largura de banda incomum |
Para valores de temperatura, uma linha de base é importante. Uma pequena firewall de desktop num armário técnico quente comporta-se de forma diferente de um appliance em rack numa sala climatizada. Portanto, deve-se primeiro observar alguns dias de operação normal e só depois definir limiares produtivos.
Definir Runbook de Alarme e Responsabilidade
Um alarme SNMP só é útil se depois for claro quem reage e qual é o procedimento. Os valores de hardware são frequentemente indicadores precoces: uma temperatura crescente, um valor de ventoinha ausente ou um alarme de fonte de alimentação não significa automaticamente que o appliance deve ser substituído imediatamente. Mas significa que o estado deve ser avaliado e documentado.
Para firewalls produtivas, deve existir uma entrada curta no Runbook:
| Alarme | Primeira verificação |
|---|---|
| Firewall não acessível por SNMP | Verificar rede de gestão, Device Access, roteamento, servidor de monitorização e acessibilidade do appliance |
| Temperatura sobe permanentemente | Comparar temperatura ambiente, ventilação, posição do rack, poeira, carga e tendência |
| Valor da ventoinha ausente ou notável | Verificar limite do modelo, valor do sensor, ruído, tendência de temperatura e relevância para suporte |
| Fonte de alimentação relata erro | Verificar alimentação elétrica, UPS, cabos, fonte de alimentação redundante e risco de HA |
| Carga PoE é alta | Verificar dispositivos conectados, orçamento PoE e reservas planeadas |
| Erros de interface aumentam | Verificar cabos, porta do switch, duplex/velocidade, módulo SFP e entrega do provedor |
A ordem é importante: primeiro verificar visibilidade e plausibilidade, depois avaliar risco, depois preparar processo de suporte ou substituição. Em caso de suspeita de defeito de hardware, deve-se documentar adicionalmente o número de série, modelo, versão de firmware, momento, métrica afetada, tendência e captura de tela ou extrato de monitorização. Questões de garantia e RMA no final não dependem apenas do alarme, mas do dispositivo específico, status de suporte e imagem do erro.
Para questões de SSD, o SNMP não é o caminho principal correto. Se o estado do disco ou carga de escrita estiver em foco, Verificar saúde do SSD do Sophos Firewall via SMART é mais adequado.
HA-Cluster e múltiplas firewalls
Em ambientes HA, deve-se definir claramente como ambos os dispositivos serão monitorizados. Nem sempre é suficiente observar apenas o endereço do cluster. Para valores de hardware, muitas vezes ambos os appliances são relevantes, pois uma ventoinha, fonte de alimentação ou porta no appliance passivo também pode falhar.
Perguntas importantes:
- O Primary e o Auxiliary são reconhecidos separadamente?
- Ambos os dispositivos têm endereços IP de gestão próprios para monitorização?
- O número de série, nome do host ou modelo são exibidos de forma clara no monitorização?
- Os alarmes permanecem compreensíveis após um failover?
- Um erro de fonte de alimentação no appliance passivo também é relatado?
Para a operação HA em si, Configurar Alta Disponibilidade no Sophos Firewall é adequado. O SNMP não deve ser planeado isoladamente, mas em conjunto com atualizações de firmware, testes de failover, conceito de backup e documentação operacional.
Validação após a configuração
Após a configuração do SNMP, não se deve apenas verificar se a monitorização está verde. É importante saber se os dados corretos vêm da fonte correta.
Lista de verificação:
- O acesso SNMP é possível apenas a partir da rede de monitorização.
- A firewall é reconhecida com o nome do host, modelo e versão de firmware corretos.
- A MIB Sophos está importada e os valores de hardware são nomeados corretamente.
- Métricas não suportadas são documentadas como limites de modelo, não como erros.
- Valores de temperatura, ventoinhas, fontes de alimentação e PoE são plausíveis.
- Um alarme de teste é acionado e chega ao destinatário correto.
- Em clusters HA, ambos os dispositivos ou a lógica de cluster desejada são verificados.
- Após uma atualização de firmware, a descoberta é testada novamente.
Para questões de desempenho e throughput, não se deve sobreinterpretar os valores SNMP. A interpretação dos dados de desempenho da Sophos é descrita no artigo Compreender corretamente os dados de desempenho do Sophos Firewall.
Resolução de problemas
Firewall não responde ao SNMP
Primeiro, verificar se o sistema de monitorização vem da zona esperada e se o SNMP está permitido em Administration > Device access. Depois, verificar endereço IP, roteamento, regras ACL locais, versão SNMP, Community String ou credenciais SNMPv3.
Se não estiver claro se os pacotes estão a chegar à firewall, o Packet Capture na interface afetada pode ajudar. Uma regra de firewall normal não resolve este problema se o tráfego for para a própria firewall.
MIB é importada, mas faltam valores
Primeiro, verificar se a métrica ausente está disponível para o modelo utilizado. Pequenos modelos XGS não fornecem todos os valores de hardware. Depois, comparar versão MIB, atribuição de OID e versão de firmware.
Após a atualização, os objetos SNMP têm nomes diferentes
Com SNMPv1/v2c, o SFOS 22 pode gerar objetos migrados com o prefixo snmp. Após uma atualização, deve-se verificar Community Strings, nomes de objetos e descoberta de monitorização. Se a monitorização trabalhar com nomes em vez de OIDs estáveis, pode ser necessário ajustar modelos.
Monitorização relata muitos alarmes de temperatura
Então, provavelmente os limiares estão muito apertados ou definidos sem uma linha de base. Primeiro, capturar valores normais ao longo de vários dias. Depois, definir limiares com base no modelo, localização e temperatura ambiente. Picos curtos individuais são diferentes de uma tendência de temperatura permanentemente crescente.
HA-Cluster mostra apenas um dispositivo
Então, deve-se verificar se a monitorização está a consultar apenas o endereço do cluster ou se ambos os appliances são acessíveis separadamente. Para o estado de hardware, o appliance passivo também é relevante. Em clusters produtivos, deve-se documentar qual endereço IP representa qual dispositivo e qual função.
Lista de verificação operacional
- Permitir SNMP apenas a partir de redes de gestão ou monitorização.
- Preferir SNMPv3, se o sistema de monitorização o suportar corretamente.
- Tratar Community Strings SNMPv1/v2c como segredos.
- Importar a MIB Sophos e verificar após atualizações de firmware.
- Documentar limites de modelo para valores de hardware.
- Definir limiares de temperatura e PoE com base em linhas de base reais.
- Nomear e avaliar separadamente dispositivos HA de forma clara.
- Documentar Runbook de alarme com primeira verificação, escalonamento e responsabilidade.
- Em caso de suspeita de hardware, proteger modelo, número de série, versão de firmware e tendência.
- Testar alarmes regularmente e esclarecer responsabilidade.
- Combinar dados SNMP com logs, sFlow, Packet Capture e Central Reporting.