Información sobre las conexiones sin agente para los equipos de red
Cyberwatch escanea los equipos de red (routers, conmutadores, cortafuegos, appliances…) en conexión sin agente, por SNMP en el puerto UDP 161. El escaneo consulta el agente SNMP del equipo, sin instalar ni modificar nada en él, y reporta:
- el sistema y su versión (firmware), a partir de los cuales se deducen las vulnerabilidades;
- el nombre de host y las direcciones IP;
- metadatos: ubicación, número de serie, modelo, rol de alta disponibilidad, vencimientos de licencia…;
- los puertos en escucha;
- fallos de seguridad de la configuración SNMP.
La matriz de flujos figura en los requisitos previos de las conexiones sin agente, y los equipos compatibles en la lista de sistemas soportados.
Versiones y credenciales SNMP
Cyberwatch es compatible con SNMP v1, v2c y v3:
- en v1 y v2c, la credencial es una comunidad;
- en v3, el usuario debe tener autenticación y cifrado (nivel de seguridad
authPriv). Los nivelesnoAuthNoPrivyauthNoPrivno son compatibles.
Los protocolos de autenticación disponibles son SHA, SHA-256, SHA-512 y MD5, y los protocolos de cifrado AES, AES-256 y DES.
Recomendamos SNMPv3 con SHA-256 o SHA-512 y AES. Un escaneo en v1 o v2c, o con un usuario SNMPv3 en MD5 o en DES, produce un fallo de seguridad en el activo.
Vistas MIB que se deben autorizar
Cyberwatch solo necesita un acceso de lectura. La vista SNMP del usuario o de la comunidad utilizada debe incluir las ramas siguientes:
| MIB | Raíz de OID | Datos leídos | Si la vista la excluye |
|---|---|---|---|
| SNMPv2-MIB, grupo system | 1.3.6.1.2.1.1 | Descripción, identificador de objeto (sysObjectID), tiempo de funcionamiento, nombre, ubicación y contacto | El escaneo falla. |
| Rama del fabricante | 1.3.6.1.4.1.<número> | Sistema, versión y características propias del fabricante | La detección falla, ver En caso de fallo de la detección. |
| HOST-RESOURCES-MIB | 1.3.6.1.2.1.25 | Tiempo de funcionamiento del equipo; software instalado, que proporciona la versión de algunos equipos | El tiempo de funcionamiento es el del agente SNMP. La versión de estos equipos no se detecta, y la detección falla para Cisco ISE, Ucopia, y Juniper cuando la descripción no proporciona la versión. |
| IP-MIB, OSPF-MIB | 1.3.6.1.2.1.4, 1.3.6.1.2.1.14 | Direcciones IP | Faltan las direcciones IP. |
| ENTITY-MIB | 1.3.6.1.2.1.47 | Fabricante, modelo, número de serie y revisión de hardware del chasis | El modelo y el número de serie se leen en la rama del fabricante, cuando esta los proporciona. La detección de Arista, que lee allí su versión, falla. |
| TCP-MIB, UDP-MIB | 1.3.6.1.2.1.6, 1.3.6.1.2.1.7 | Puertos en escucha | Faltan los puertos. |
| SNMP-USER-BASED-SM-MIB, SNMP-VIEW-BASED-ACM-MIB, SNMP-COMMUNITY-MIB | 1.3.6.1.6.3.15, 1.3.6.1.6.3.16, 1.3.6.1.6.3.18 | Usuarios SNMPv3, accesos v1/v2c y comunidades configurados en el equipo | Solo se notifican los fallos de seguridad de la credencial utilizada. |
<número> es el número de empresa IANA del fabricante, con el que empieza el identificador de objeto del equipo: 1.3.6.1.4.1.9.1.… para un equipo Cisco, por ejemplo. Un equipo basado en el agente net-snmp lee también las ramas de net-snmp (1.3.6.1.4.1.8072 y 1.3.6.1.4.1.2021), y la de su editor. Por tanto, una vista que incluye 1.3.6.1.2.1 y 1.3.6.1.4.1 cubre todas las ramas necesarias.
Las tres tablas de 1.3.6.1.6.3 describen la configuración SNMP del equipo. Abrirlas a Cyberwatch es opcional. Cyberwatch solo reporta a partir de ellas fallos de seguridad: nunca reporta una comunidad que no figure en la lista de comunidades débiles, ni el nombre de un usuario sin autenticación.
Fuera del grupo system y de la rama del fabricante, una tabla ausente, excluida de la vista o que no responde no hace fallar el escaneo: simplemente falta la información correspondiente.
Metadatos
El escaneo reporta metadatos, que se muestran en la pestaña «Metadatos» del activo. Se actualizan en cada escaneo correcto: un metadato que el escaneo ya no lee desaparece. Los valores vacíos y los valores por defecto de los agentes SNMP (Unknown, root@localhost…) se ignoran, y un valor se trunca a 255 caracteres.
Metadatos comunes
Estos metadatos se leen en las MIB estándar, sea cual sea el fabricante:
| Clave | Fuente | Descripción |
|---|---|---|
snmp-location | sysLocation (SNMPv2-MIB) | Ubicación declarada en la configuración SNMP |
snmp-contact | sysContact (SNMPv2-MIB) | Contacto declarado en la configuración SNMP |
system-manufacturer | entPhysicalMfgName (ENTITY-MIB) | Fabricante del chasis |
system-product-name | entPhysicalModelName (ENTITY-MIB), si no, rama del fabricante | Modelo del chasis |
system-serial-number | entPhysicalSerialNum (ENTITY-MIB), si no, rama del fabricante | Número de serie del chasis |
system-version | entPhysicalHardwareRev (ENTITY-MIB) | Revisión de hardware del chasis, y no versión del firmware |
snmp-agent-version | versionTag (UCD-SNMP-MIB) | Versión del agente net-snmp |
Las columnas de ENTITY-MIB se leen en la primera entidad de clase chasis. Cuando ENTITY-MIB no proporciona ni modelo ni número de serie, estos se leen en la rama del fabricante, para la mayoría de los fabricantes compatibles.
Las claves system-* son las que reporta el escaneo de los activos Linux. Por tanto, un mismo filtro, por ejemplo meta:system-serial-number:FCW2140, encuentra tanto un servidor como un equipo de red.
Metadatos propios de determinados equipos
| Clave | Equipos | Valor |
|---|---|---|
ha-state | Check Point, Cisco ASA, F5 BIG-IP, FortiGate, Juniper | Estado de alta disponibilidad, standalone fuera de clúster para Cisco ASA, Check Point, F5 BIG-IP y FortiGate. En clúster, Cisco ASA, Check Point y F5 BIG-IP proporcionan el rol del equipo (active, standby, offline para F5, active-attention para Check Point…). FortiGate proporciona el modo del clúster (active-active, active-passive), el mismo en cada miembro. Juniper: virtual-chassis para un Virtual Chassis, ningún valor para un equipo independiente. |
virtual-chassis-member | Juniper | Un miembro del Virtual Chassis por valor: identificador, rol, número de serie, modelo y versión, por ejemplo 9 master LX0213388389 ex4550-32f 15.1R7-S10 |
config-unsaved | Cisco (IOS, IOS XE, IOS XR, NX-OS, ASA…) | true si la configuración en ejecución se ha modificado desde que se guardó por última vez, si no false |
boot-image | Extreme Networks EXOS | Imagen arrancada: primary o secondary |
firmware-pending-version | Extreme Networks EXOS | Versión de la imagen elegida para el próximo arranque, cuando difiere de la versión en ejecución |
routerboot-pending-version | MikroTik | Versión de RouterBOOT proporcionada por RouterOS, cuando difiere de la instalada: la actualización de RouterBOOT está pendiente |
firmware-update-available | Synology | true si DSM indica que hay una actualización disponible, false si no indica ninguna. Ningún valor cuando DSM no ha podido comprobarlo. |
av-signature-version, av-signature-date | FortiGate | Versión y fecha de la base de firmas antivirus |
ips-signature-version, ips-signature-date | FortiGate, Sophos (solo versión) | Versión y fecha de la base de firmas IPS |
license-expiration | Cisco AsyncOS, Sophos, WALLIX Bastion | Vencimiento de licencia más próximo |
support-expiration | Check Point, Sophos | Vencimiento de soporte más próximo |
Las fechas tienen el formato AAAA-MM-DD.
Utilizar los metadatos
- En el inventario, filtrar los activos con el filtro Metadato, o introduciendo
meta:clave[:valor]en la barra de búsqueda. La clave y el valor se buscan por prefijo (ver el anclaje de las búsquedas). Por ejemplo:meta:ha-state:standby: equipos en espera en un clúster;meta:config-unsaved:true: equipos Cisco cuya configuración no está guardada;meta:license-expiration:2026: equipos con una licencia que vence en 2026.
- Mostrar un metadato como columna del inventario, como se describe en Añadir una columna de metadatos. Una clave con varios valores, como
virtual-chassis-member, muestra sus valores separados por comas. - Estos filtros también sirven para las reglas de activos, las alertas y las exportaciones. La API v3 devuelve los metadatos en el detalle de un activo, y filtra la lista de activos por
metadata_keyymetadata_value.
Puertos en escucha
El escaneo reporta los puertos en escucha del equipo en la pestaña «Puertos» del activo. Lee:
- para TCP, la tabla
tcpListenerTable, o en su defecto las conexiones en escucha detcpConnTable(TCP-MIB); - para UDP, la tabla
udpEndpointTable, o en su defectoudpTable(UDP-MIB).
Los puertos de las direcciones de bucle invertido se ignoran, al igual que los sockets UDP conectados. Un puerto que escucha en todas las direcciones se reporta sin dirección. SNMP no proporciona ni el servicio ni el producto de un puerto: estas columnas quedan vacías.
La lectura se limita a 500 líneas por tabla y a 60 segundos para el conjunto de las tablas. Más allá de ese límite, o si el equipo deja de responder, Cyberwatch conserva los puertos ya leídos y lo indica en el resultado bruto del escaneo con una línea # Listening ports from <tabla>: <motivo>.
Como para los demás activos, un puerto TCP 21, 23 u 873 en escucha produce los fallos de seguridad FTP-port, Telnet-port o rsync-port.
Fallos de seguridad SNMP
El escaneo notifica los fallos de seguridad siguientes en la pestaña «Fallos de seguridad» del activo:
| Identificador | Severidad | Título | Notificado cuando | Detalle |
|---|---|---|---|---|
SNMP_weak_community_string | Alta | SNMP weak community string | El equipo acepta una comunidad de la lista de comunidades débiles, o esta figura en su tabla de comunidades (snmpCommunityTable) | Community string: <comunidad> |
SNMP_v1_v2c_enabled | Media | SNMP v1/v2c enabled or configured | El escaneo se realiza en v1 o v2c, o la configuración de acceso del equipo (vacmSecurityToGroupTable) contiene una entrada v1 o v2c | SNMPv1 o SNMPv2c |
SNMP_no_authentication | Media | SNMPv3 user without authentication | Un usuario SNMPv3 del equipo (usmUserTable) no tiene autenticación | User: initial, si no User without authentication |
SNMP_weak_authentication_protocol | Baja | SNMPv3 MD5 authentication | El usuario del escaneo, o un usuario del equipo, se autentica en MD5 | User: <usuario> (MD5) |
SNMP_weak_privacy_protocol | Media | SNMPv3 weak or no encryption | El usuario del escaneo, o un usuario del equipo, cifra en DES o no cifra | User: <usuario> (DES) o User: <usuario> (no encryption) |
Estos fallos se deducen de la credencial utilizada y de las tablas que la vista hace legibles. El escaneo sigue siendo no intrusivo: nunca intenta autenticarse de otro modo que con la credencial de la conexión, salvo para la prueba de las comunidades débiles. Esta prueba solo se realiza en un escaneo en v1 o v2c. Prueba, en solo lectura, las comunidades de la lista del script Nmap snmp-brute: public, private, snmpd, mngt, cisco, admin, PUBLIC, PRIVATE, rmonmgmtuicommunity, secret, cascade, ANYCOM, ILMI, volition, TENmanUFactOryPOWER, MiniAP y snmp-Trap.
El nombre de un usuario sin autenticación basta para consultar el equipo: no se muestra, salvo si es público, como initial.
Cada usuario, versión o comunidad da lugar a una ocurrencia distinta del fallo de seguridad. Una ocurrencia que ya no se detecta en un escaneo correcto se considera corregida, y una ocurrencia ignorada sigue ignorada. El ciclo de vida de los fallos de seguridad se describe en Usar los problemas de seguridad.
En caso de fallo de la detección
Si el escaneo falla, el activo conserva su último estado conocido: firmware, vulnerabilidades, metadatos, puertos y fallos de seguridad no se borran. El fallo se indica:
- en el script de análisis del activo, que pasa a «Fallo de comunicación» con el mensaje de error;
- en la conexión sin agente, en la columna «Último error de conexión» del menú Conexiones sin agente.
Si los fallos se repiten, el activo acaba pasando a pérdida de conectividad.
Cada solicitud SNMP espera su respuesta 3 segundos y se reintenta 2 veces. Un escaneo dura como máximo 5 minutos. El mensaje de error lleva como prefijo el número de empresa del fabricante, cuando se conoce (PEN 9: …). Los mensajes más habituales son:
| Mensaje | Causa probable | Resolución |
|---|---|---|
Timeout after 3 seconds | El equipo no responde: flujo UDP 161 bloqueado, agente SNMP detenido, o comunidad desconocida para el equipo (v1, v2c) | Verificar la matriz de flujos, la configuración SNMP del equipo y la credencial. |
Unknown user name | El usuario SNMPv3 de la credencial no existe en el equipo | Verificar el nombre de usuario de la credencial y la configuración SNMP del equipo. |
Authentication failure (…) | Contraseña o protocolo de autenticación SNMPv3 erróneos | Verificar la contraseña y el protocolo de autenticación de la credencial. |
Decryption error | Contraseña o protocolo de cifrado SNMPv3 erróneos | Verificar la contraseña y el protocolo de cifrado de la credencial. |
Unsupported security level | El usuario SNMPv3 del equipo no tiene a la vez autenticación y cifrado | Configurarlo en el nivel authPriv, ver Versiones y credenciales SNMP. |
Could not retrieve the version of <producto> | El equipo no proporciona su versión donde Cyberwatch la lee | Verificar que la vista incluye la rama del fabricante y, después, contactar con el soporte. |
No Such Instance currently exists at this OID (<OID>), No such name (…) | Un OID necesario para la detección está ausente o excluido de la vista | Verificar que la vista incluye el OID indicado y, después, contactar con el soporte. |
Time limit of 300 s exceeded | El equipo responde demasiado lentamente para terminar el escaneo en 5 minutos | Verificar la carga del equipo y la latencia de la red. |
Si el equipo no se reconoce, o si su detección sigue fallando, escribir a support@cyberwatch.com con el mensaje de error y un SNMPWalk completo del equipo (snmpwalk -On <equipo> 1.3.6.1).