Configurar la monitorización de hardware por SNMP en Sophos Firewall

Para utilizar la monitorización de hardware por SNMP, se activa el agente en Administration > SNMP, se crea preferiblemente un usuario SNMPv3, se limita el acceso al host de monitorización en Administration > Device access y se descarga la MIB actual. Después se puede probar la conexión desde el sistema de monitorización con snmpget y consultar el árbol de hardware con snmpwalk.

Desde Sophos Firewall v22, la MIB proporciona métricas de hardware adicionales según el modelo de XGS Appliance, como las temperaturas de CPU y NPU, las velocidades de los ventiladores, el estado de las fuentes de alimentación y los valores de PoE. SNMP responde principalmente a preguntas sobre el estado del dispositivo. Para eventos de seguridad individuales resultan más adecuados Central Firewall Reporting o syslog, mientras que sFlow es más apropiado para los patrones de tráfico.

Si se necesita una comprobación inmediata directamente en el appliance en lugar de monitorización continua, comprobar la temperatura y el ventilador de Sophos Firewall por SSH explica cómo leer sensors y xgs-healthmond.log e interpretar correctamente las aparentes alarmas de los sensores brutos.

⚠️ SNMP solo debería ser accesible desde una red de gestión o monitorización de confianza. Permitir un acceso amplio desde zonas de clientes, invitados, IoT o WAN expone innecesariamente información sobre el modelo, las interfaces y el estado operativo.

Configurar SNMP de forma segura

Limitar el acceso al host de monitorización

Si una zona de monitorización dedicada necesita acceder al servicio, se activa SNMP en Administration > Device access solo para esa zona. Si, en cambio, las consultas proceden de un único servidor con dirección IP fija, SNMP permanece desactivado para la zona. En su lugar, una Local service ACL exception rule permite de forma específica el origen, el destino del firewall y el servicio SNMP. La configuración completa se explica en Proteger Device Access en Sophos Firewall.

SNMP es un servicio local del firewall. Una regla LAN a WAN convencional no sustituye a Device Access. SNMP no debería exponerse directamente desde la WAN; para la monitorización externa, una VPN de gestión ofrece una conexión más segura.

Activar el agente

Abrir Administration > SNMP.
Activar Enable SNMP agent.
Introducir el nombre, la ubicación y el contacto, por ejemplo xgs-zrh-01, ZRH-DC1 / Rack 3 y noc@example.net.
Guardar con Apply.
Utilizar Download MIB para descargar la MIB correspondiente a la versión instalada del firewall e importarla en el sistema de monitorización.

Además del árbol de hardware específico de Sophos, SFOS proporciona las MIB estándar SNMPv2-MIB, IF-MIB con Counter32 y Counter64, SNMPv2-SMI, IP-MIB, IP-FORWARD-MIB, TCP-MIB y UDP-MIB. Con ellas se pueden supervisar, por ejemplo, uptime, contadores de interfaces, valores IP y de routing, así como estadísticas TCP/UDP. La MIB actual de Sophos sigue siendo importante porque proporciona los OID específicos del fabricante y su significado para la versión de SFOS instalada.

Las consultas llegan al agente por UDP 161. Los traps se envían al gestor por UDP 162. El enrutamiento y los firewalls locales de los hosts entre ambos sistemas también deben permitir el tráfico en la dirección necesaria.

Configurar SNMPv3

En Administration > SNMP > SNMPv3 users and traps, hacer clic en Add.
Definir un nombre de usuario permanente como monitoring. Utilizar letras sin espacios y configurar el mismo nombre de usuario en el gestor. No se puede cambiar posteriormente.
Activar Accept queries.
Activar Send traps solo si el firewall también debe enviar notificaciones al gestor.
Si Send traps está activado, introducir en Authorized hosts las direcciones IPv4 o IPv6 reales de los receptores de traps previstos antes de guardar el usuario SNMPv3. Aquí deben figurar las direcciones de los receptores del propio entorno, no automáticamente las direcciones IP de los hosts de polling.
Para instalaciones nuevas, utilizar AES y SHA256 o SHA512 siempre que sea posible. Ambas frases de contraseña deben tener al menos doce caracteres.
Guardar la configuración.

SFOS también ofrece DES o None para el cifrado y MD5 para la autenticación. Estas opciones no deben utilizarse en configuraciones nuevas. Si un colector solo admite estos métodos, primero se actualiza o se limita la conexión SNMP a una ruta de gestión aislada y técnicamente justificada; una degradación silenciosa no constituye una prueba de compatibilidad satisfactoria.

Según Sophos, Authorized hosts solo se aplica a los destinos de traps. La lista no limita las consultas SNMPv3. El acceso para las consultas depende de que las credenciales sean correctas, de Accept queries y de Device Access.

Utilizar SNMPv1 o SNMPv2c solo cuando sea necesario

Si el sistema de monitorización no admite correctamente SNMPv3, hacer clic en Add en Administration > SNMP > SNMPv1/v2c y crear una entrada de comunidad. Los campos necesarios son el nombre, el Community String, IPv4 o IPv6, la IP del gestor y Accept queries. Send traps permanece desactivado si no se utilizan traps. A continuación, guardar la entrada con Save.

El Community String funciona como una contraseña, pero se transmite sin cifrar con v1/v2c. No debe aparecer en capturas de pantalla ni en tickets y solo debería utilizarse dentro de una red de gestión estrictamente limitada.

Después de actualizar a SFOS 22, conviene revisar las entradas v1/v2c existentes. El firewall copia el nombre anterior en el Community String y crea un nombre con el prefijo snmp para los objetos migrados. Esto también permite eliminar variantes IPv4 o IPv6 innecesarias y orígenes de monitorización que ya no se utilizan.

Activar los traps de forma selectiva

SFOS 23 – actualizaciones de seguridad mediante hotfix: Estas actualizaciones no disponen de notificaciones SNMP. En lugar de esperar un trap, configurar el correo para Firmware > Security updates con el interruptor global de correo y SMTP funcional, y verificar las actualizaciones aplicadas. Esta excepción no se aplica de forma general a todos los hotfixes ni a todos los eventos de firmware.

Para los traps, el usuario SNMP o la entrada de comunidad no son suficientes por sí solos. En System services > Notification list se deben activar SNMP traps y los tipos de alerta que realmente sean necesarios.

La recepción se debe probar con un evento seleccionado que ocurra realmente. Los informs de SNMPv3 requieren confirmación; según Sophos, el firewall no intenta reenviar un inform si no recibe la confirmación. Por tanto, los traps y los informs no sustituyen la supervisión del propio proceso de consulta.

Guardar o transferir la configuración SNMP

SFOS 22 puede exportar e importar como archivo TAR la configuración del agente SNMP, las comunidades y los usuarios SNMPv3 en Backup and firmware > Import export. Esto resulta útil para una sustitución controlada de hardware o antes de cambios importantes. El archivo contiene configuración de monitorización relevante para la seguridad y debe guardarse en un almacenamiento protegido. El procedimiento general está descrito en Exportar e importar la configuración de Sophos Firewall.

Una importación correcta no demuestra que la monitorización funcione. Después hay que volver a comprobar el estado del agente, Device Access o la ACL exception, las credenciales, las consultas y el destino de los traps mediante una prueba real de polling y eventos. El sistema de monitorización también debe disponer de la MIB actual correspondiente a la versión de destino.

Revertir una configuración de prueba

Antes de un piloto, se anota si el agente y SNMP ya estaban activados para la zona afectada, qué usuarios, comunidades y ACL exceptions existen y qué opciones SNMP están habilitadas en System services > Notification list. Así se pueden revertir solo los cambios del piloto sin desconectar otro sistema de monitorización.

Para volver atrás, primero se desactivan la tarea de polling y cualquier tratamiento de traps específico del piloto en el sistema de monitorización, pero no un receptor de traps compartido. Después se eliminan el usuario SNMPv3 o la comunidad recién creados y la Local Service ACL exception correspondiente. Enable SNMP agent solo se desactiva y se confirma con Apply si el agente estaba apagado antes del piloto y ningún otro gestor lo utiliza. Si se activó SNMP para una zona completa, también se restaura el ajuste anterior en Administration > Device access. También se devuelve al estado anotado cualquier opción de traps o alertas habilitada exclusivamente para el piloto en System services > Notification list. Por último, la consulta desde el host piloto debe agotar el tiempo de espera, mientras que los gestores existentes deben seguir recibiendo respuestas y los traps esperados.

Métricas de hardware y limitaciones por modelo

SFOS 22 proporciona los nuevos valores de hardware para XGS Appliances:

CPU temperature: todos los modelos de XGS Appliance.
NPU temperature: todos los modelos de XGS Appliance excepto 88/88w, 108/108w, 118/118w y 128/128w.
Fan speed: todos los modelos de XGS Appliance excepto 88/88w y 108/108w.
Power supply status: XGS 2100 y superiores.
PoE measurements: modelos de XGS Appliance con PoE excepto XGS 116/116w.

Sophos documenta estos sensores para XGS Appliances. En appliances virtuales, cloud o software no se deben esperar sensores físicos del host procedentes de la MIB de SFOS. Incluso en una XGS Appliance, que falte una métrica no indica automáticamente un error; primero hay que comprobar si el modelo la admite.

OID y unidades de la MIB de SFOS 22

El árbol de hardware comienza en .1.3.6.1.4.1.2604.5.1.9. Las áreas más importantes son:

Temperatura de la NPU: .1.3.6.1.4.1.2604.5.1.9.1.0
Temperatura de la CPU: .1.3.6.1.4.1.2604.5.1.9.2.0
Velocidad del ventilador: .1.3.6.1.4.1.2604.5.1.9.3.1.2
Estado de la fuente de alimentación: .1.3.6.1.4.1.2604.5.1.9.4.1.2
Tabla PoE: .1.3.6.1.4.1.2604.5.1.9.5

Las temperaturas se devuelven en décimas de grado Celsius: 420 equivale a 42,0 °C. Los valores de los ventiladores se expresan en RPM. La potencia PoE se indica en milivatios, la tensión en milivoltios y la corriente en miliamperios. Para una fuente de alimentación, up(1) significa operativa y down(2) significa averiada.

Para cada puerto, la tabla PoE también devuelve la etiqueta, el estado, el límite de potencia configurado y el consumo actual. enabled(1) indica que la alimentación PoE está activa y disabled(2) que está desactivada. Por tanto, disabled(2) no demuestra por sí solo un fallo de hardware. Para las alertas, se compara el consumo con el límite del mismo puerto y se vuelven a detectar la etiqueta y el índice, en lugar de asignar ciegamente las filas de la tabla a una plantilla antigua. La tabla no indica el presupuesto PoE total del appliance; una alerta sobre el consumo agregado también necesita un presupuesto PoE específico del modelo y verificado por separado.

Para obtener valores de hardware que puedan evaluarse numéricamente, debería estar instalado como mínimo SFOS 22.0 GA Build 411. Este build corrige NC-169564, que hacía que los valores de los sensores se devolvieran como strings en lugar de integers, además de otros problemas de MIB y OID.

Después de una actualización del firmware, se debe volver a descargar la MIB actual, importarla en el sistema de monitorización y repetir la detección. Las plantillas de monitorización no deben depender únicamente de los nombres mostrados.

Probar la conexión y los valores de hardware

Los siguientes comandos Bash se ejecutan en un host de monitorización Linux o macOS con Net-SNMP, no en Sophos Firewall. En macOS se debe iniciar primero bash, ya que read -p tiene un significado diferente en la shell zsh predeterminada. Los ejemplos se han comprobado con la sintaxis documentada de Net-SNMP y la MIB oficial de SFOS 22, pero no se han ejecutado contra el firewall de un cliente.

SHA-256 y SHA-512 suelen requerir Net-SNMP 5.8 o posterior. Con snmpwalk -h se puede comprobar qué algoritmos acepta el cliente instalado. Las versiones antiguas de macOS pueden admitir únicamente MD5 y SHA.

⚠️ Net-SNMP transmite el Community String y las frases de contraseña como argumentos del proceso. Introducirlos mediante read evita que queden en el historial de la shell, pero no impide que aparezcan brevemente en la lista de procesos. Estas pruebas solo deben realizarse en un host de monitorización de confianza.

Probar SNMPv3 con AuthPriv

Adaptar la dirección IP y el usuario, introducir las frases de contraseña y consultar primero el OID estándar e inofensivo sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Contraseña de autenticación SNMPv3: " SNMP_AUTH
printf '\n'
read -r -s -p "Contraseña de cifrado 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

Una primera consulta correcta devuelve sysUpTime.0 como Timeticks. El walk posterior solo muestra los sensores compatibles con el modelo concreto.

Utilizar SNMPv2c como prueba de compatibilidad

Para un gestor v2c configurado de forma deliberada:

FIREWALL_IP="192.0.2.1"

read -r -s -p "Comunidad 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

Una prueba de uptime correcta demuestra que hay conectividad y que las credenciales coinciden, pero todavía no confirma que todos los valores de los sensores sean plausibles. Después hay que comparar el hostname, el modelo, el firmware, la versión de la MIB y los valores con WebAdmin, el appliance y el funcionamiento normal. Antes de activar alertas de temperatura y PoE, se debe establecer una línea base durante varios días.

Alertas y HA

Las alertas útiles notifican una desviación operativa, no solo una medición individual:

Falla la accesibilidad por SNMP o una interfaz esperada.
La temperatura de CPU o NPU permanece por encima de su línea base.
Un ventilador instalado indica 0 RPM o no devuelve ningún valor.
Una fuente de alimentación redundante cambia a down(2).
El consumo PoE se acerca al límite configurado de un puerto.
Los errores o drops de una interfaz aumentan de forma anómala.

Los umbrales de temperatura universales y fijos resultarían engañosos. El modelo, el rack, la temperatura ambiente y la carga determinan el rango normal. Un runbook de alertas debería comprobar primero el valor, su evolución y la limitación del modelo, y después evaluar la refrigeración, la alimentación eléctrica, el cableado, el puerto del switch o los dispositivos PoE.

Las alertas deberían distinguir como mínimo entre Advertencia y Crítico. Para cada nivel, el runbook debe definir el responsable, la primera comprobación y la vía de escalado.

Si se confirma un fallo de hardware, se documentan el modelo, el número de serie, el firmware, la hora y la evolución. El proceso de garantía y sustitución se describe en Preparar una RMA y la sustitución de hardware Sophos. Para las unidades de almacenamiento, Comprobar el estado de la SSD con SMART es más apropiado que SNMP.

En un clúster HA, cada appliance tiene sus propios sensores. Sophos documenta una dirección de administración del peer para acceder al WebAdmin del appliance Auxiliary, pero no que sus valores de hardware SNMP puedan consultarse por separado a través de esa dirección. Por tanto, una consulta a la dirección del clúster no debe considerarse una prueba del estado del hardware de ambos appliances. Después de configurar HA y tras un failover, hay que comprobar si el gestor puede asignar cada medición sin ambigüedad a un appliance; de lo contrario, se necesita otro método documentado para comprobar el appliance Auxiliary. Los fundamentos se explican en Configurar High Availability en Sophos Firewall.

Los valores SNMP no deberían utilizarse como única prueba del rendimiento. Interpretar correctamente los datos de rendimiento de Sophos Firewall explica cómo evaluar el throughput y la utilización.

Solución de problemas

Timeout o ausencia de respuesta

Primero se comprueban la IP de monitorización, el enrutamiento, Device Access, Local Service ACL, Accept queries, la versión de SNMP y las credenciales. En WebAdmin, en Diagnostics > Packet capture, se puede utilizar el filtro host 192.0.2.50 and port 161; Packet Capture en WebAdmin explica su uso.

Como alternativa, en la opción 4, Device Console, se puede comprobar si la consulta llega al firewall:

tcpdump 'host 192.0.2.50 and port 161'

La prueba se detiene con Ctrl+C. Si no llega ningún paquete, la causa se encuentra antes del agente SNMP. Si la consulta llega pero no sale ninguna respuesta, las siguientes comprobaciones son Device Access, la IP del gestor, las credenciales y la configuración del agente.

Falla la autenticación o el algoritmo

El nombre de usuario, el nivel de seguridad authPriv y los algoritmos de autenticación y cifrado deben coincidir exactamente con la configuración del firewall. Si el cliente no acepta SHA-256 o SHA-512, se comprueban los algoritmos compatibles con snmpwalk -h y se actualiza Net-SNMP. No se debe recurrir de forma silenciosa a MD5 ni a SNMP sin cifrar.

En caso de errores de consulta, no hay que centrarse en Authorized hosts: en SNMPv3, esta lista solo se aplica a los destinos de traps.

Faltan valores de hardware o parecen incorrectos

Se comprueban la limitación del modelo, el firmware y la versión de la MIB. En SFOS 22.0 GA Build 365, los valores de hardware pueden aparecer como strings en lugar de integers debido a NC-169564; Build 411 corrige el problema. Después de actualizar, se renuevan la MIB y la detección del sistema de monitorización.

Los mensajes más recientes se pueden consultar en Device Console:

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

snmpd.log pertenece al agente SNMP. xgs-healthmond.log ayuda a investigar la temperatura de la CPU y el estado de los ventiladores. En Logs de servicio de Sophos Firewall se muestran otras correspondencias.

No llegan los traps

Comprobar primero el tipo de evento: en SFOS 23, la ausencia de un trap para una actualización de seguridad mediante hotfix es normal. No demuestra un fallo de enrutamiento, UDP 162 ni de confirmación de un inform SNMPv3, y no indica si la actualización se ha aplicado correctamente. Para este evento, utilizar la ruta de correo y verificación de actualizaciones descrita arriba en lugar de cambiar el transporte SNMP. Las comprobaciones siguientes se aplican a eventos que admiten traps.

Se comprueban Send traps, Authorized hosts, UDP 162 y los eventos seleccionados en System services > Notification list. En Device Console, una captura limitada permite comprobar si el firewall envía tráfico al gestor:

tcpdump 'host 192.0.2.50 and port 162'

Si los paquetes salen del firewall pero no llegan, se comprueban el enrutamiento, los firewalls intermedios y el receptor de traps. Para los informs de SNMPv3, también se verifica la confirmación del gestor.