Clavister NetWall cOS Core 14.00 ignora peticiones SNMPv3 fuera de ventana
El par HA de NetWall 500A descarta silenciosamente los mensajes SNMPv3 fuera del intervalo de tiempo y altera aleatoriamente snmpEngineBoots, dejando obsoleta la caché del gestor.
Clavister NetWall HA, modelo 500A con cOS Core 14.00.19.05, está dejando caer sin respuesta los paquetes SNMPv3 que no cumplen la ventana de tiempo USM, en lugar de devolver el informe usmStatsNotInTimeWindows que especifica el RFC 3414 §3.2 paso 7. Además, el contador snmpEngineBoots varía a valores aparentemente aleatorios, incluso retrocediendo, sin que el dispositivo se reinicie.
El problema se detectó con Zabbix 7.0 LTS (net‑snmp) que consulta cada nodo por su IP de gestión. Cuando el firewall registra el mensaje snmp3_message_not_in_time_window (ID 3100110), la petición del gestor queda sin respuesta y la interfaz de Zabbix muestra “timed out”. Un reinicio del caché SNMP del servidor Zabbix (zabbix_server -R snmp_cache_reload) restablece la comunicación al instante.
Para aislar el comportamiento, se reprodujo el fallo con net‑snmp directamente, forzando valores de boots y time fuera de rango:
snmpget -v3 -u <user> -l authPriv -a SHA -A <authPass> -x AES -X <privPass> -Z 1,1 -t 3 -r 0 1.3.6.1.2.1.1.3.0
La solicitud autenticada con boots=1 y time=1 no obtuvo respuesta, mientras que 33 peticiones válidas con valores correctos fueron respondidas sin problema. La captura mostró que el engineTime no se reinicia al cambiar boots; permanecía alrededor de 2 064 000 s (~24 días), coincidiendo con el tiempo de actividad del dispositivo.
El efecto práctico es que, al cambiar snmpEngineBoots, el gestor mantiene un valor en caché que ya no coincide con el agente. El agente, al no emitir el informe esperado, deja al gestor bloqueado hasta que se limpia la caché manualmente. La causa sospechada son despliegues de configuración desde InControl, aunque aún no se ha confirmado.
Clavister ha abierto un caso de soporte. Mientras tanto, los administradores que dependan de SNMPv3 contra cOS Core deberían considerar:
- Forzar la recarga del caché SNMP del gestor tras cualquier cambio de configuración.
- Monitorizar los valores de snmpEngineBoots y engineTime para detectar saltos inesperados.
- Evaluar la posibilidad de usar versiones anteriores o parches que corrigan el comportamiento.
Queda abierto el debate sobre si el descarte silencioso es una medida deliberada de mitigación contra ataques de reflexión/amplificación o un bug del firmware. La comunidad sigue recopilando pcap sanitizados para un análisis más profundo.
Hilo de Reddit
