Ingeniería inversa del protocolo inform de UniFi

Qué es el protocolo inform de UniFi y por qué importa a los founders tech

Si alguna vez gestionaste infraestructura de red para múltiples clientes desde un solo controlador, sabes que el costo operativo puede escalar rápidamente. El equipo de Tamarack Cloud decidió hacerle ingeniería inversa al protocolo inform de los dispositivos UniFi de Ubiquiti, y lo que encontraron tiene implicaciones directas para cualquier startup que construya soluciones SaaS multi-tenant sobre hardware de red administrado.

El protocolo inform es el mecanismo central de comunicación entre los dispositivos UniFi (access points, switches, gateways) y su controlador. Cada dispositivo envía un HTTP POST a la ruta /inform —típicamente por el puerto 8080 o 6080— con una cadencia de entre 10 y 30 segundos. Este mecanismo de polling es lo que permite al controlador enviar configuraciones, comandos o simplemente un «noop» para confirmar que el dispositivo sigue activo.

Anatomía del paquete: la clave está en la cabecera en texto plano

El paquete inform tiene una estructura binaria bien definida. Lo más revelador es que una parte significativa de la cabecera viaja sin cifrar, incluyendo la dirección MAC del dispositivo. La estructura completa es la siguiente:

4 bytes: Magic number (identificador del protocolo)
4 bytes: Versión del protocolo
6 bytes: Dirección MAC del dispositivo (en texto plano)
2 bytes: Flags de control
16 bytes: Vector de inicialización AES (IV)
4 bytes: Versión del payload
4 bytes: Longitud del payload
N bytes: Payload JSON cifrado con AES-128-CBC (firmwares antiguos) o AES-GCM (firmwares modernos)

La clave de cifrado se establece durante el proceso de adopción del dispositivo. Por defecto, es el MD5 de la cadena «ubnt», que luego se reemplaza por una clave hexadecimal de 16 bits generada por el controlador y enviada vía SSH. Esto significa que, antes de que el dispositivo sea adoptado, la comunicación es especialmente vulnerable a interceptación.

La dirección MAC como eje del enrutamiento multi-tenant

Aquí está el insight clave que hace valioso este análisis para arquitecturas SaaS multi-tenant: dado que la dirección MAC del dispositivo está disponible en la cabecera del paquete sin necesidad de descifrar el payload, es posible construir un proxy de enrutamiento que dirija cada paquete al controlador correcto basándose únicamente en esa información.

Esto tiene un impacto económico directo. En lugar de desplegar un controlador UniFi dedicado por cada cliente (lo que implica más instancias, más infraestructura y más costo), puedes:

Recibir todo el tráfico inform en un único punto de entrada.
Leer la MAC de la cabecera en texto plano.
Enrutar el paquete al controlador correspondiente para ese cliente.
Devolver la respuesta al dispositivo sin haber tocado el payload cifrado.

El resultado es una arquitectura más eficiente, donde un proxy liviano reemplaza múltiples instancias de controlador, reduciendo el costo de infraestructura y simplificando la operación.

Construcción del proxy: consideraciones de arquitectura

Para implementar este tipo de proxy de enrutamiento, los ingenieros de Tamarack Cloud identificaron los siguientes elementos a resolver:

Tabla de enrutamiento por MAC

El proxy debe mantener un mapeo de dirección MAC → endpoint del controlador. Esta tabla puede vivir en una base de datos simple (Redis es una opción popular por su velocidad de lectura) y actualizarse cada vez que se adopta un nuevo dispositivo.

Gestión de puertos y protocolos

Los controladores UniFi utilizan distintos puertos según el tipo de tráfico:

Puerto 8080: Tráfico inform estándar (HTTP).
Puerto 6080: Alternativa común en entornos cloud.
Puerto 8443: Interfaz HTTPS del controlador.
Puerto 10001: Descubrimiento de dispositivos en Layer-2 (UDP, beacons TLV).

El proxy debe manejar correctamente estos puertos y asegurarse de que las respuestas del controlador lleguen de vuelta al dispositivo sin modificaciones.

Seguridad en el proxy

Un punto crítico señalado en la documentación técnica de la comunidad: dado que el protocolo inform no usa TLS por defecto, el tráfico entre el dispositivo y el proxy puede ser interceptado. Investigadores como los del blog jade.wtf han documentado riesgos derivados del cifrado simétrico sin capa de transporte segura. Para entornos de producción, se recomienda:

Establecer un túnel VPN entre los dispositivos y el controlador cloud.
O implementar un reverse proxy con TLS terminado en el edge.

Proceso de adopción Layer-2 vs Layer-3

Otro aspecto relevante del análisis es la diferencia entre la adopción local y remota de dispositivos:

Adopción Layer-2 (red local)

Los dispositivos UniFi envían beacons UDP al puerto 10001 en formato TLV para ser descubiertos automáticamente en la red local. El controlador los adopta mediante SSH usando las credenciales por defecto (ubnt/ubnt), ejecuta el comando set-inform y establece la clave de cifrado.

Adopción Layer-3 (remota/cloud)

Para redes remotas, la URL de inform se configura manualmente vía SSH: set-inform http://controlador-ip:puerto/inform. Esto habilita la adopción a través de redes diferentes sin necesidad de acceso directo Layer-2, lo que es fundamental para arquitecturas multi-site y multi-tenant.

Implicaciones para founders que construyen sobre redes gestionadas

Este análisis es un ejemplo perfecto de cómo la ingeniería inversa de un protocolo propietario puede desbloquear oportunidades de negocio concretas. Para startups y MSPs (Managed Service Providers) que administran redes de múltiples clientes, este patrón de proxy de enrutamiento por MAC puede traducirse en:

Reducción de costos de infraestructura al consolidar controladores.
Mayor escalabilidad sin incremento lineal de instancias por cliente.
Arquitectura más limpia que separa el plano de enrutamiento del plano de control.
Base técnica sólida para construir un producto SaaS de gestión de redes.

Proyectos open source como ubntmfi de mcrute en GitHub y las especificaciones de jeffreykog han documentado partes de este protocolo, lo que facilita construir sobre este conocimiento sin partir de cero.

Conclusión

El protocolo inform de UniFi es un caso de estudio fascinante sobre cómo una decisión de diseño aparentemente menor —dejar la dirección MAC en texto plano dentro de la cabecera— abre la puerta a arquitecturas de enrutamiento multi-tenant eficientes y económicas. Para founders que construyen productos de gestión de infraestructura o MSPs que buscan escalar su operación, este tipo de ingeniería inversa es exactamente el tipo de ventaja técnica que diferencia a un producto maduro de uno que simplemente «funciona».

La lección más amplia es clara: entender a fondo los protocolos sobre los que construyes no es un lujo técnico, es una ventaja competitiva directa que impacta en costos, escalabilidad y arquitectura del producto.

Descubre cómo otros founders implementan estas soluciones técnicas para escalar sus productos SaaS y reducir costos de infraestructura.

Aprender con founders