Descubrir impresoras y puertos con WMI y SNMP básico

En cualquier red mínimamente seria, descubrir impresoras, servidores y puertos abiertos no es un “extra”, es algo obligatorio si quieres dormir tranquilo. Entre políticas de seguridad, auditorías y usuarios que imprimen a cualquier cosa que tenga tóner, necesitas saber qué hay, dónde está y cómo se está comportando.

La buena noticia es que no tienes que inventar la rueda: WMI en entornos Windows y SNMP en prácticamente cualquier dispositivo de red te dan toda la si sabes cómo aprovecharlos. El truco está en entender qué ofrece cada tecnología, qué puertos intervienen, cómo encaja todo con firewalls y qué implicaciones tiene en rendimiento y seguridad.

Panorama general: agentes, WMI, SNMP y otras formas de monitorizar

Cuando hablamos de monitorizar equipos e impresoras, en realidad hablamos de elegir el “canal” por el que la herramienta de monitorización va a sacar la información del dispositivo. A grandes rasgos, en redes corporativas conviven estas opciones:

1. Agente instalado en el dispositivo
Muchas plataformas de monitorización incluyen su propio agente para Windows, Linux o incluso aplicaciones concretas. Se instala en cada equipo y es el agente el que recopila métricas (CPU, RAM, discos, servicios, etc.) y las envía al servidor de monitorización.

• Ventaja: acceso muy granular a datos del sistema, incluso más allá de lo que ofrecen WMI o SNMP.
• Inconveniente: hay que desplegarlo, mantenerlo, actualizarlo y comprobar que no se convierta en un problema de rendimiento o seguridad.

2. WMI (Windows Management Instrumentation)
En el mundo Windows, WMI es la referencia. Permite obtener información muy detallada sobre hardware, software, procesos, servicios, rendimiento e incluso configurar determinados aspectos del sistema. Todo ello a través de clases WMI accesibles de forma remota.

• Usa por defecto RPC sobre TCP, con el puerto 135/TCP como asignador y luego puertos dinámicos altos (49152-65535) si no se restringe.
• En muchos escenarios se utiliza además sobre WinRM (HTTP 5985 / HTTPS 5986) para evitar lidiar con rangos de puertos RPC abiertos.

3. SNMP (Simple Network Management Protocol)
SNMP es un protocolo de capa de aplicación estándar, definido en varias RFC (1157, 1901-1908, 3411-3418, entre otras), y forma parte de la pila TCP/IP. Es el lenguaje común para routers, switches, firewalls, impresoras, NAS, UPS, appliances de seguridad y también para muchos servidores.

• Las consultas y operaciones de lectura/escritura utilizan normalmente UDP 161.
• Las notificaciones asíncronas (traps e informs) viajan por UDP 162.
• Su potencia está en la combinación de agentes SNMP + MIB + OID.

4. SSH
En sistemas tipo UNIX (Linux, BSD, etc.), muchas herramientas optan por conectarse por SSH (TCP 22) para ejecutar comandos y parsear la salida. Es una alternativa cuando no se dispone de SNMP o se quiere un control más fino sin instalar agentes adicionales.

5. API y servicios web
Cada vez más fabricantes exponen sus métricas a través de APIs REST, SOAP o servicios web. Es la vía habitual para monitorizar aplicaciones modernas, soluciones cloud o appliances muy específicos donde SNMP/WMI no encajan bien o se han quedado cortos.

Recomendación rápida: qué usar para cada tipo de equipo

Una guía que funciona en la mayoría de redes corporativas es la siguiente:

• Equipos Windows: prioriza WMI (o WMI vía WinRM) frente a agentes propios, salvo que necesites monitorización muy avanzada de aplicaciones que solo exponen datos mediante ese agente.
• Servidores y estaciones Linux/UNIX: usa SSH o un agente ligero. SNMP también es posible, pero suele quedarse algo corto para detalles de sistema.
• Electrónica de red (switches, routers, AP, firewalls): SNMP es la opción natural. Oftentimes ni siquiera hay otro método estándar.
• Impresoras y dispositivos “de borde” (NAS, UPS, hardware específico): casi siempre SNMP.
• Aplicaciones y servicios modernos: si el fabricante ofrece API oficial, úsala primero.

Los agentes propietarios déjalos como plan B, cuando no tengas WMI, SSH, SNMP ni API que cubran lo que necesitas. A menudo complican despliegues, mantenimiento y endurecimiento de seguridad.

Cómo funciona SNMP por dentro: gestores, agentes, MIB y OID

Para descubrir impresoras y puertos con SNMP, hay que entender antes cómo se organiza la información. SNMP se basa en tres pilares: gestor SNMP, dispositivos gestionados (agentes) y MIB/OID.

Gestor SNMP (NMS)
Es la pieza central: la consola o servidor que ejecuta el Network Management System. Es el que envía peticiones (GET, GETNEXT, GETBULK, SET) a los agentes y recibe respuestas, traps e informs.

• Interroga periódicamente a los agentes para recopilar métricas.
• Procesa valores, aplica umbrales, genera alertas y gráficos.
• Puede escribir en ciertos OID (SET) si la seguridad lo permite, aunque en la práctica se recomienda trabajar casi siempre en modo solo lectura (RO).

Dispositivos gestionados y agentes SNMP
Cada router, switch, impresora o servidor que quieras monitorizar ejecuta un agente SNMP. Este agente:

• Recoge de forma local estadísticas de hardware, red, colas de impresión, temperatura, etc.
• Expone esta información según las definiciones contenidas en sus MIB.
• Puede generar traps hacia el NMS cuando ocurre algo (por ejemplo, papel atascado, caída de interfaz, sobretemperatura).
• Incluso puede actuar como proxy para equipos que no tienen SNMP nativo.

MIB (Management Information Base)
La MIB es, por simplificarlo, el “diccionario” que define qué variables se pueden consultar y en qué formato. Es un archivo de texto (normalmente en notación ASN.1) que describe:

• Nombre simbólico del objeto.
• Tipo de dato (INTEGER, OCTET STRING, COUNTER, Gauge, TimeTicks…).
• Acceso (read-only, read-write).
• Descripción funcional.
• Relación jerárquica con otros objetos.

Hay MIB estándar (por ejemplo IF-MIB, IP-MIB, SNMPv2-MIB) y MIB privadas de fabricante (Cisco, HP, Xerox, Synology, etc.). Estas MIB privadas son las que te permiten ir más allá de lo genérico, por ejemplo, ver el nivel de tóner o páginas impresas de un modelo concreto de impresora.

OID (Object Identifier)
Cada objeto definido en una MIB se identifica con un OID, una secuencia numérica separada por puntos, por ejemplo:

• 1.3.6.1.2.1.1.3.0 -> sysUpTime.
• 1.3.6.1.2.1.1.5.0 -> sysName (nombre del dispositivo).
• 1.3.6.1.2.1.1.4.0 -> sysContact.

Los OID se organizan en una estructura de árbol, donde:

• 1.3.6.1.2.1 corresponde a los MIB estándar (mib-2).
• 1.3.6.1.4.1 es la rama de enterprises, es decir, MIB de fabricantes.

Un ejemplo típico de OID propietario para un NAS Synology sería algo así como 1.3.6.1.4.1.6574.5, relacionado con información SMART de discos, mientras que un OID de Cisco podría colgar de 1.3.6.1.4.1.9.

Puertos SNMP, operaciones básicas y versiones del protocolo

Para que la monitorización SNMP funcione, hay que tener bien claros los puertos implicados y el modelo de comunicación. Si no, el firewall se convierte en tu peor enemigo.

Puertos estándar de SNMP

• UDP 161: consultas y operaciones normales (GET, GETNEXT, GETBULK, SET). El NMS envía peticiones al agente en ese puerto.
• UDP 162: traps e informs. En este caso el agente inicia la comunicación hacia el servidor de monitorización.

Aunque se puede usar TCP con SNMP en algunos casos, la implementación clásica y la más extendida es UDP. Esto tiene implicaciones: hay menos sobrecarga, pero también no hay garantía de entrega. Por eso los sistemas de monitorización suelen repetir consultas si no reciben respuesta.

Operaciones SNMP más importantes

• GET: el NMS pide el valor de uno o varios OID concretos.
• GETNEXT: similar a GET, pero solicita el siguiente OID en la jerarquía, muy útil para iterar por tablas.
• GETBULK: introducido en SNMPv2, pensado para descargar bloques grandes de datos (tablas enteras) de forma eficiente.
• SET: el gestor escribe un valor en el agente. Es potente pero peligroso, por eso en casi todas las redes serias se evita exponer SET o se restringe al máximo.
• TRAP: mensaje asíncrono que el agente envía al NMS cuando ocurre un evento (p. ej. impresora sin papel, enlace caído).
• INFORM: parecido al trap, pero con confirmación de recepción por parte del NMS.

Versiones de SNMP y seguridad
Históricamente SNMP ha pasado por varias versiones, con cambios sobre todo en el plano de seguridad:

• SNMPv1 (RFC1155, 1156, 1157). Modelo muy simple, seguridad basada en “community string”, sin cifrado.
• SNMPv2c. Versión revisada con mejoras de rendimiento (GETBULK, nuevos tipos, etc.), pero manteniendo el mismo esquema de seguridad basado en comunidad. Es la más usada en la práctica.
• SNMPv3. Introduce autenticación y cifrado, con seguridad basada en usuario (USM) y modelos de acceso más robustos. Es mucho más seguro, pero también más complejo de configurar y puede introducir cierta carga extra.

Por comodidad, muchas redes siguen usando SNMPv2c en modo solo lectura (RO) con comunidades no triviales y listas de control de acceso en los dispositivos. Si necesitas cumplir políticas de seguridad estrictas, conviene planificar una migración progresiva a v3.

WMI en profundidad: puertos, RPC y WinRM

En entornos Windows, WMI es la herramienta estrella para extraer información de sistemas sin instalar agentes adicionales. Pero a nivel de red, WMI depende de RPC y eso tiene consecuencias en el firewall.

Puertos implicados en WMI clásico

• TCP 135: puerto del RPC Endpoint Mapper. Es el punto de entrada inicial; a través de él el cliente negocia qué puerto dinámico usará la llamada posterior.
• Puertos dinámicos TCP altos: típicamente 49152-65535 en sistemas modernos. Ahí se establece la sesión real de WMI/DCOM.

Si estás segmentando mucho la red y filtrando puertos, esto supone un problema: abrir un rango completo 49152-65535 entre segmentos no suele ser aceptable desde el punto de vista de seguridad.

Alternativa: WMI a través de WinRM
Para evitar esa riada de puertos dinámicos, Microsoft ofrece la posibilidad de exponer WMI sobre WS-Management a través de WinRM:

• HTTP en el puerto 5985/TCP.
• HTTPS en el puerto 5986/TCP.

De esta forma, puedes limitar la comunicación WMI a puertos bien definidos y más fáciles de controlar en el firewall, además de añadir cifrado cuando tiras de HTTPS. Es la vía preferida para herramientas modernas de monitorización y gestión remota de Windows.

WMI + Active Directory y otros servicios
No hay que olvidar que muchas operaciones de administración remota relacionadas con WMI, PowerShell Remoting o la propia promoción de controladores de dominio también hacen uso de:

• LDAP (389/TCP y UDP), LDAPS (636/TCP).
• SMB (445/TCP) para canalizaciones con nombre.
• Puertos efímeros RPC altos para diferentes servicios dependientes (DFS, replicación de archivos, Netlogon, etc.).

Si estás cerrando a conciencia una red Windows, es fundamental revisar la extensa tabla de puertos de servicios de sistema de Microsoft para no cortar algo crítico (Kerberos, DNS, horario de Windows, replicación de AD, etc.).

Descubrir impresoras y puertos con SNMP: enfoque práctico

Vamos a aterrizar todo esto en el caso que más interesa: localizar impresoras en la red y entender qué puertos tienen activos utilizando SNMP.

1. Activar y configurar SNMP en las impresoras
En la mayoría de impresoras medianamente modernas, SNMP viene habilitado por defecto o se activa desde la interfaz web del dispositivo:

• Define una comunidad SNMP de lectura (no uses “public” en entornos corporativos serios).
• Si es posible, limita el acceso SNMP a la IP o subred de tu servidor de monitorización.
• Rellena los campos de sysLocation y sysContact para poder ordenarlas luego (oficina, sala, planta, correo de soporte, etc.).

2. Comprobar desde el servidor de monitorización con snmpwalk
En un host Linux o similar con las herramientas de Net-SNMP instaladas, puedes tirar de:

snmpwalk -v2c -c TU_COMUNIDAD 192.168.x.x

Si la configuración es correcta, verás desfilar una lista larga de OID y valores: nombre de sistema, ubicación, número de interfaces, estadísticas de red, contadores de páginas, niveles de tóner (si el fabricante lo proporciona en sus MIB privadas), etc.

Para probar solo un OID concreto (por ejemplo, sysName):

snmpwalk -v2c -c TU_COMUNIDAD 192.168.x.x SNMPv2-MIB::sysName.0

3. Identificar puertos y tráfico SNMP “basura”
Un caso muy típico en redes con historial es encontrar un servidor de impresión Windows que sigue intentando hablar SNMP con impresoras que ya no existen o que han cambiado de subred.

• Los puertos TCP/IP de impresora en Windows pueden tener SNMP habilitado por defecto.
• Si ese servidor intenta hacer consultas SNMP a IP antiguas cada pocos segundos, verás montones de paquetes bloqueados en tu firewall (por ejemplo, un FortiGate), todos dirigidos a UDP 161 de direcciones que ya no pertenecen a la red.

La solución es tan simple como desactivar SNMP en esos puertos de impresión o limpiar los puertos que ya no se usan. Antes de eliminar nada, conviene validar que realmente no hay trabajos asociados y que la impresora correspondiente ya no forma parte de la infraestructura.

4. Uso de MIB de fabricante para datos avanzados
Si quieres ir más allá del “está encendida o apagada” y monitorizar realmente el estado de las impresoras (colas, atascos, tóner, bandejas de papel), tendrás que:

• Descargar las MIB específicas del fabricante (Xerox, HP, Canon, etc.), a menudo disponibles en su portal de soporte.
• Cargarlas en tu herramienta SNMP o navegador de MIB.
• Localizar los OID relativos a cada métrica (por ejemplo, número de páginas impresas, vida útil de consumibles, códigos de error).

Con eso podrás construir gráficas y alertas que avisen cuando una impresora se queda sin papel, cuando el tóner está al 5 % o cuando un contador se dispara anormalmente, evitando sorpresas a los usuarios.

SNMP, seguridad y buenas prácticas de configuración

SNMP es potentísimo, pero si se deja abierto sin control es un coladero. Algunos puntos clave para no darte un tiro en el pie:

• Usa siempre comunidades personalizadas, nunca “public”/“private”.
• Restrínge el acceso a IPs o subredes concretas usando ACL en routers, switches o en el propio demonio SNMP (Linux, Windows, ESXi, etc.).
• Siempre que sea posible mantente en modo lectura (RO); evita SET en producción salvo casos muy controlados.
• Si tu entorno lo exige, plantea usar SNMPv3 con autenticación y cifrado, al menos para equipos críticos.
• Documenta qué MIB y OID utilizas y qué significan, para que otros admins puedan darles mantenimiento.

En Windows Server, recuerda que el servicio SNMP:

• No viene instalado por defecto; hay que añadir la característica (vía GUI, PowerShell o capacidades opcionales).
• Se configura principalmente desde las pestañas Seguridad y Agente del servicio: comunidades aceptadas, hosts de los que se permiten paquetes, contacto, ubicación y servicios supervisados.

En Linux, el archivo clave suele ser /etc/snmp/snmpd.conf, donde puedes definir vistas, comunidades y direcciones de escucha, por ejemplo permitiendo solo una comunidad definida y restringiendo la vista a .1 (todo el árbol) o a subconjuntos concretos.

Coordinando WMI, SNMP y firewalls en redes segmentadas

En empresas con varias VLAN, DMZ y zonas muy filtradas, el reto no es solo monitorizar, sino hacerlo sin abrir medio universo de puertos. Aquí es donde hay que combinar bien WMI, SNMP y reglas del firewall.

Algunos principios que funcionan bien:

• Para Windows internos: habilita WinRM (5985/5986) y limita WMI clásico por RPC solo a segmentos muy controlados.
• Para equipos de red e impresoras: abre únicamente UDP 161/162 desde y hacia las IP de tus servidores de monitorización.
• Centraliza la monitorización en unos pocos NMS bien protegidos en lugar de tener múltiples orígenes de consultas dispersos.
• Revisa la tabla de puertos de servicios de Windows Server para asegurarte de que AD, DNS, Kerberos, DFS, Netlogon, etc. siguen pudiendo hablar entre sí tras cualquier endurecimiento.

Si ya tienes un firewall registrando tráfico denegado, es buena idea analizar los logs en busca de patrones de SNMP bloqueado (o WMI vía RPC) que correspondan a equipos mal configurados, impresoras desaparecidas o servidores que aún creen que hay subredes antiguas. Limpiar eso reduce ruido de fondo y te evita reglas innecesarias.

Al final, combinar bien WMI en Windows y SNMP para todo lo demás, con una política clara de puertos y comunidades, te da una visión muy afinada de impresoras, servidores, switches y aplicaciones, sin tener que llenar la red de agentes pesados ni abrir el firewall de par en par. Es la forma más razonable de tener bajo control quién imprime, desde dónde y a través de qué puertos, sin volverte loco cada vez que llega una auditoría o toca revisar la seguridad de la infraestructura.