Mapa completo de servicios MS‑RPC y UUID: unicidad, versiones y mejores prácticas

¿Necesitas saber exactamente qué UUID corresponde a cada interfaz MS‑RPC que corre en tu red —o confirmar que las versiones que despliegas siguen siendo compatibles— sin depender de fuentes incompletas? A continuación encontrarás una guía extensiva que cubre el origen, la unicidad y el versionado de los UUID de MS‑RPC, con un método práctico para generar tu propio catálogo interno y blindar tu política de seguridad.

Índice

Conceptos básicos: MS‑RPC y sus UUID

Microsoft Remote Procedure Call (MS‑RPC) es la implementación, sobre DCE/RPC, empleada por Windows y por múltiples aplicaciones de terceros para exponer APIs locales o remotas. Cada interfaz se identifica mundialmente mediante un Universally Unique Identifier (UUID), un número de 128 bits representado típicamente como 8‑4‑4‑4‑12 caracteres hexadecimales (ej.: 12345678‑1234‑1234‑ABCD‑EF1234567890). Este valor se incrusta en los ficheros .idl, en los binarios y, en tiempo de ejecución, se anuncia al Endpoint Mapper (RPCSS) vía RpcServerRegisterIf*.

Aunque los UUID se generan “pseudo‑aleatoriamente”, el algoritmo definido por RFC 4122 garantiza que la probabilidad de colisión es despreciable: dos equipos pueden generar millones de UUID sin coordinarse y seguir siendo únicos. Por esa razón, Windows no fuerza un registro centralizado —y por ende, tampoco existe una base de datos oficial que los liste todos.

¿Existe una lista pública y exhaustiva?

No. Microsoft publica miles de UUID en la documentación “Windows Protocols” y en los encabezados del SDK, pero el propio ecosistema de Windows es demasiado amplio (aplicaciones instaladas, controladores, plugins, componentes COM expuestos vía RPC, etc.) como para mantener un catálogo global siempre actualizado. Existen, sin embargo, fuentes parciales muy valiosas:

Archivos .idl y cabeceras del Windows SDK. Cada versión del SDK añade o depreca interfaces; basta con buscar “uuid(” en la carpeta Include.
Documentación MS‑DN (p.ej., artículos “Protocol Specifications” o referencias de COM) que incluyen la cláusula interface UUID.
Herramientas de inspección como RpcView o rpcdump, que enumeran los UUID registrados en tiempo real desde el puerto 135.
Listas comunitarias mantenidas por fabricantes de appliances (Juniper, Palo Alto) para sus firmas IPS.

Por qué nunca será “completa”

Cada vez que un desarrollador crea una nueva DLL con una interfaz RPC y ejecuta uuidgen.exe o la API equivalente, nace un UUID que no existía previamente. Ese identificador puede quedar dentro de la red corporativa, incorporarse a un producto comercial o publicarse en un repositorio open‑source; nada obliga al autor a registrarlo ante Microsoft o ante IANA.

Tabla de problemas y conclusiones prácticas

Problema	Solución / Conclusión práctica
Tabla completa de mapeo	Microsoft no publica una lista exhaustiva. La única forma de conocer todo lo que corre en tu entorno es interrogar al Endpoint Mapper (TCP 135) en cada host y, opcionalmente, procesar IDLs y binarios para comparar resultados. Automatiza ambos enfoques y consolida la información en tu CMDB.
Unicidad de los UUID	Un interface UUID es globalmente único y pertenece a una única interfaz RPC. Un servicio (p.ej., “Remote Desktop Services”) puede exponer múltiples interfaces y, por tanto, varios UUID. El escenario inverso —dos servicios distintos compartiendo UUID— no es válido según las reglas de DCE/RPC y provocaría errores en tiempo de ejecución.
UUID “compuesto”	El estándar no contempla UUID agregadores. Si necesitas representar un bloque de funcionalidades conjunto, diseña una nueva interfaz —y genera un nuevo UUID— que defina los métodos comunes. El protocolo exige que cada combinación (UUID, versión) sea única.
Versiones de la misma interfaz	El par `(UUID, VersiónMajor, VersiónMinor)` forma la identidad completa. Un cambio solo en VersiónMinor mantiene la compatibilidad binaria ascendente (“minor es extensiva”); cambiar VersiónMajor equivale, de facto, a una nueva interfaz —aunque algunos equipos optan por crear un UUID distinto para evitar confusiones.

Generar y registrar un UUID paso a paso

Abre un Símbolo del sistema de Visual Studio y ejecuta:
uuidgen > MyInterface.idl
Declara el identificador en tu archivo IDL:
[uuid(12345678-1234-1234-ABCD-EF1234567890), version(1.0)] interface IMyInterface { / métodos / };
Compila el IDL con midl.exe y enlázalo con tu servidor RPC.
En tu código, registra la interfaz:
RpcServerRegisterIf2(IMyInterfacev10sifspec, NULL, NULL, 0, RPCCLISTENMAXCALLS_DEFAULT, 0, NULL);
Comprueba que aparece publicado ejecutando:
rpcdump -p 135 -t tcp <hostname>

Cómo crear tu propio inventario de mapeo

La clave es fusionar descubrimiento dinámico y análisis estático:

Escaneo remoto: un script PowerShell que recorra tu OU de Active Directory, contacte cada host por TCP 135 y vuelque los endpoints en CSV. Ejemplo mínimo:

$hosts = Get-ADComputer -Filter * | Select-Object -Expand DNSHostName

foreach ($h in $hosts) {

    rpcdump.exe -p 135 -t tcp $h | Out-File -Append "rpc_$($h).txt"

}

Descompilación de binarios: utiliza dumpbin /headers o herramientas PE para localizar secciones .rdata que contengan GUIDs; los UUID se reconocen por el patrón de 16 bytes.
Indexación y correlación: importa ambos conjuntos en tu base de datos. La clave de correlación será el UUID; como atributos añade versión, binario origen, host y fecha de descubrimiento.

Consejo de producción

No te limites a escanear solo servidores: estaciones de trabajo con software de respaldo, antivirus, herramientas de gestión de inventario o incluso impresoras suelen exponer interfaces RPC propias.

Profundizando en la unicidad

Internamente, Windows almacena las entradas del Endpoint Mapper en una tabla hash indexada por (UUID, versión). Cuando un cliente llama a RpcBindingFromStringBinding con un UUID que ya existe pero versión incompatible, el marco RPC responde RPCSUNKNOWN_IF. Gracias a esta lógica:

No es posible que dos servicios distintos “coexistan” con el mismo UUID y misma versión en el mismo proceso.
Sí es posible que un proceso aloje múltiples versiones minor del mismo UUID, aportando compatibilidad retroactiva.

Diseño orientado a extensibilidad (“no rompas a tus clientes”)

Al planificar la evolución de una API RPC:

Regla de oro: incrementa VersiónMinor cuando añadas métodos que no alteren los existentes y VersiónMajor cuando cambies la firma de un método o su semántica.

Sin embargo, muchos equipos —sobre todo en comunicación inter‑empresa— escogen directamente un UUID nuevo para cada “versión mayor” porque:

Permite ejecutar en paralelo ambas versiones sin riesgo de choque.
Facilita estrategias side‑by‑side e in‑place upgrade.
Simplifica la auditoría: cada UUID refleja un conjunto cerrado de métodos.

Seguridad: filtrado, alerta y hardening

Mantener un inventario preciso de UUID tiene impacto directo en la superficie de ataque:

Firewalls y NIDS: las reglas de capa 7 para RPC pueden “permitir solo los UUID A, B, C” y bloquear el resto.
Honeypots: publicar un UUID falso atrae escaneos y detecta actividad maliciosa.
Control de cambios: cuando aparece un UUID nuevo en un servidor crítico, dispara una alerta de CI/CD o SOC.
Confianza cero: validación mutua de versiones minor para prevenir downgrade attacks.

FAQ — Preguntas frecuentes

¿Puedo reutilizar parte de un UUID para indicar familia de interfaces? No. La especificación prohíbe cualquier semántica interna; debes documentar la relación mediante metadatos en tu CMDB. ¿Qué ocurre si dos desarrolladores generan casualmente el mismo UUID? La probabilidad es menor a 1 entre 2¹²², virtualmente imposible; la colisión en un único dominio administrativo sería aún menos probable que acertar dos veces seguidas la lotería nacional. ¿Existe un rango “privado” o “reservado” de UUID? No. Todos los UUID versión 4 se crean con la misma probabilidad y sin registro central. ¿Cómo averiguo la versión si solo tengo el UUID? Interroga el endpoint: rpcdump devuelve VersiónMajor.Minor; también puedes consultar RpcMgmtInqIfIds desde un cliente propio. ¿El Endpoint Mapper puede publicar interfaces no RPC (DCOM, EPM v4)? Sí, DCOM usa el mismo transportador; aparecerán UUID de clases COM enlazadas a puertos dinámicos.

Caso práctico: inventario semanal automatizado

En un entorno de 300 servidores Windows Server 2022, ejecutar el script de escaneo descrito arriba genera unos 25 000 endpoints. Al procesarlos con una función HashSet para eliminar duplicados, quedaron 3 872 UUID distintos. Tras comparar con la versión anterior del inventario, solo aparecieron 14 UUID nuevos, de los cuales 12 correspondían a la actualización mensual de Microsoft y 2 a un equipo de desarrollo que desplegó una beta sin pasar por QA: la alerta llegó al CISO antes de que el servicio saliera a producción.

Resumen y conclusiones

Los UUID son la piedra angular de la identificación en MS‑RPC: únicos, inmutables y libres de colisiones. No existe —ni existirá— una tabla pública que cubra la totalidad de ellos, por lo que cada organización debe construir su propio mapa mediante escaneo de endpoints y análisis de código. Entender la relación UUID ↔ versión ↔ servicio permite:

Garantizar compatibilidad binaria durante una migración.
Aplicar políticas de seguridad precisas a nivel de red.
Detectar software no autorizado o mal configurado.
Mantener documentos de arquitectura actualizados y auditables.

Con las técnicas y ejemplos aportados en este artículo podrás crear un proceso continuo —y automatizable— que transforme un tema arcano en una pieza clave de tu estrategia de gobernanza de TI.