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

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

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

1. En Administration > SNMP > SNMPv3 users and traps, hacer clic en Add.
2. Definir un nombre de usuario permanente como monitoring. No se puede cambiar posteriormente.
3. Activar Accept queries.
4. Activar Send traps solo si el firewall también debe enviar notificaciones al gestor.
5. Para instalaciones nuevas, utilizar AES y SHA256 o SHA512 siempre que sea posible. Ambas frases de contraseña deben tener al menos doce caracteres.
6. Guardar la configuración.

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, se crea una entrada de comunidad en Administration > SNMP > SNMPv1/v2c. 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.

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

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.

Métricas de hardware y limitaciones por modelo

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

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

Sophos documenta estos sensores para hardware XGS. En appliances virtuales, cloud o software no se deben esperar sensores físicos del host procedentes de la MIB de SFOS. Incluso en XGS, 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 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 presupuesto disponible.
• 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 importan ambos appliances. Consultar únicamente la dirección del clúster no muestra necesariamente el ventilador, la fuente de alimentación o el puerto del appliance pasivo. Si el diseño de red y la plataforma permiten accesos de gestión separados, Primary y Auxiliary deberían identificarse individualmente. La accesibilidad real por SNMP y la asignación de los valores se deben verificar después de configurar HA y de nuevo tras un failover. 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

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.