¿Es seguro MQTT? El protocolo en sí solo proporciona los puntos de anclaje para la seguridad, un campo de usuario y contraseña y la posibilidad de funcionar sobre TLS, y es exactamente tan seguro como el despliegue que lo rodea. Este artículo explica qué protege y qué no protege MQTT, qué amenazas afectan realmente a los sistemas, los mitos que causan problemas y las capas que convierten una instalación MQTT en una instalación segura.
Qué ofrece MQTT por sí mismo
MQTT se diseñó como un protocolo de mensajería ligero, y su especificación deja deliberadamente la mayor parte de la seguridad a otras capas. De serie obtienes:
- Un campo de usuario y contraseña en el paquete CONNECT, enviado como bytes sin procesar.
- Puntos de anclaje para la autenticación mejorada de MQTT 5 (un método de autenticación y paquetes AUTH) para esquemas de desafío-respuesta que implementa el broker.
- Códigos de motivo que permiten al broker indicar "credenciales incorrectas" o "no autorizado".
- Independencia del transporte, de modo que MQTT puede funcionar sobre TLS o WebSockets seguros.
Lo que el protocolo no ofrece por sí solo:
- Ningún cifrado. Sin TLS, todos los topics, payloads y contraseñas son legibles en la red.
- Ningún modelo de autorización. Qué cliente puede usar qué topic depende del broker.
- Ninguna integridad ni firma del payload. Un mensaje no lleva ninguna prueba de quién lo creó más allá de la conexión por la que llegó.
- Ninguna limitación de tasa ni protección contra abusos. Eso es una funcionalidad del broker.
La especificación OASIS de MQTT incluso tiene un capítulo de seguridad que presenta estos aspectos como responsabilidades de la implementación. Así que la respuesta honesta a "¿es seguro MQTT?" es: MQTT se puede asegurar, y la seguridad es una propiedad del broker, de los clientes y del diseño de la red.
Las amenazas que realmente importan
| Amenaza | Cómo ocurre | Protección principal |
|---|---|---|
| Escucha clandestina | Tráfico en el puerto 1883 capturado en Wi-Fi, en el ISP o en la red cloud | TLS en 8883 / 8084 |
| Robo de credenciales en tránsito | Contraseña leída de un CONNECT sin cifrar | TLS con verificación de certificado |
| Brokers abiertos | Broker expuesto a internet con acceso anónimo | Autenticación, sin acceso anónimo en producción |
| Extracción de credenciales de dispositivos | Contraseña incrustada en el firmware o guardada en flash sin cifrar | Credenciales por dispositivo, almacenamiento cifrado |
| Suplantación | Un atacante se conecta con un client ID robado o compartido | Client IDs vinculados a credenciales |
| Acceso entre tenants | Aislamiento débil en un broker compartido | Aislamiento de tenants |
| Comandos maliciosos | Cualquiera puede publicar en un topic de comandos | Autorización, validación de comandos en el dispositivo |
| Denegación de servicio | Inundaciones de conexiones o mensajes, inicios de sesión por fuerza bruta | Cuotas, protección contra inundaciones, bloqueo de IP |
Los escaneos de brokers expuestos encuentran con regularidad sistemas en el puerto 1883 con acceso anónimo, que filtran datos de sensores y a veces aceptan comandos. Son fallos de configuración, no vulnerabilidades del protocolo, y por eso la mayor parte del trabajo real es operativo. Consulta brokers MQTT expuestos para ver cómo se detectan y se cierran.
Mitos habituales sobre la seguridad de MQTT
"MQTT es inseguro porque envía las contraseñas en texto claro."
Las envía en texto claro dentro de la capa MQTT, igual que la autenticación HTTP Basic. Sobre TLS toda la conexión está cifrada, incluido el paquete CONNECT. El problema es usar MQTT sin TLS, no MQTT en sí.
"El puerto 1883 no es un problema dentro de nuestra red."
Las redes internas se ven comprometidas, el Wi-Fi se intercepta y las redirecciones de puertos "temporales" se vuelven permanentes. Trata todas las redes como no confiables y usa TLS siempre que puedas. Reserva el 1883 sin cifrar para datos públicos de prueba que no te importaría ver en cualquier parte, como el tráfico de demostración del servidor MQTT público gratuito.
"Un client ID largo y aleatorio es un secreto."
Los client IDs aparecen en logs, dashboards y rutas de topics. Identifican a un cliente; no lo autentican. La seguridad procede de la credencial a la que está vinculado el client ID.
"TLS hace que los payloads sean seguros de extremo a extremo."
TLS protege cada salto entre un cliente y el broker. El broker ve el payload sin cifrar. Si necesitas confidencialidad de extremo a extremo desde el dispositivo hasta la aplicación, añade cifrado del payload MQTT por encima.
"Nadie se molestaría en atacar mis sensores."
A los escáneres automatizados no les importa qué miden tus sensores. Buscan puertos abiertos y credenciales por defecto, y un broker expuesto puede usarse como punto de entrada o como relé gratuito.
Las capas que hacen seguro MQTT
- Cifrado del transporte. TLS 1.2 o superior en el puerto 8883, o WebSockets seguros en el 8084 para navegadores, con la verificación de certificado activada en todos los clientes.
- Autenticación. Ningún acceso anónimo a datos de producción. Credenciales únicas por dispositivo y servicio.
- Vinculación de identidad. Client IDs ligados a credenciales para que un cliente no pueda suplantar a otro.
- Aislamiento y autorización. Tenants y entornos separados; restringe los topics cuando tu broker lo permita y diseña árboles de topics con la identidad y la dirección visibles. La guía de ACL en MQTT cubre ambos enfoques.
- Protección contra abusos. Cuotas de conexiones y mensajes, protección contra inundaciones y bloqueo de intentos de inicio de sesión por fuerza bruta.
- Bastionado del dispositivo. Almacenamiento cifrado de credenciales, Secure Boot, puertos de depuración desactivados y actualizaciones de firmware firmadas.
- Operaciones. Rotación de credenciales, supervisión del estado de conexión y de anomalías, y un plan para revocar un dispositivo comprometido.
Cómo cierra las brechas un broker MQTT gestionado
Varias de esas capas dependen del broker, y son precisamente las partes que los despliegues autoalojados configuran mal con más frecuencia: los certificados caducan, el acceso anónimo queda activado tras una prueba, todos los dispositivos comparten un mismo archivo de contraseñas. Un broker MQTT gestionado asume esas responsabilidades.
Así se corresponde ConnectMQ con las capas anteriores:
| Capa | ConnectMQ |
|---|---|
| Cifrado del transporte | TLS en 8883 y WebSocket seguro en 8084 (ruta /mqtt) con un certificado de Let's Encrypt |
| Autenticación | Usuario y contraseña generados por cada conjunto de credenciales del broker |
| Vinculación de identidad | Client IDs vinculados a las credenciales emitidas |
| Aislamiento | Aislamiento multi-tenant entre clientes; plan Dedicated para un clúster aislado; BYOC en tu propia cuenta cloud |
| Protección contra abusos | Cuotas por plan, protección contra inundaciones, bloqueo de IP tras inicios de sesión fallidos repetidos |
| Visibilidad | Dashboard, explorador de topics en vivo y $SYS/broker/connection/{clientId}/state para el estado de conexión de cada cliente |
ConnectMQ no aplica ACL por topic, así que su frontera de seguridad es el tenant y el broker: si dos grupos de clientes no deben ver los datos del otro, dales brokers separados, y mantén a los usuarios no confiables detrás de tu propio backend en lugar de entregarles credenciales del broker. El bastionado de los dispositivos y la rotación de credenciales siguen siendo responsabilidad tuya, como con cualquier broker; las guías sobre cómo proteger las credenciales MQTT en los dispositivos y las buenas prácticas de seguridad MQTT los tratan en detalle.
Autoevaluación rápida
Responde a estas preguntas sobre tu despliegue actual:
- ¿Algún cliente de producción se conecta por el puerto 1883?
- ¿Algún cliente desactiva la verificación de certificado?
- ¿Comparten dos o más dispositivos una misma credencial?
- ¿Hay alguna credencial incrustada en una imagen de firmware o en un repositorio público?
- ¿Puedes revocar un único dispositivo en minutos sin afectar a los demás?
- ¿Te darías cuenta si un dispositivo empezara a conectarse desde un lugar inesperado o a publicar diez veces más de lo normal?
Un "sí" en cualquiera de las cuatro primeras o un "no" en alguna de las dos últimas marca por dónde empezar.
Empieza con ConnectMQ
Obtén TLS, autenticación, vinculación de identidad, aislamiento de tenants y protección contra abusos desde el primer día con un broker MQTT en la nube gestionado por nosotros. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta tu primer dispositivo por el puerto 8883 en minutos.
Preguntas frecuentes
¿Es seguro MQTT sin TLS?
No. Sin TLS, los nombres de usuario, contraseñas, topics y payloads pueden ser leídos por cualquiera que capture el tráfico. Usa el puerto 8883 o WebSockets seguros para todo lo que no sean datos públicos de prueba.
¿Es MQTT más o menos seguro que HTTP?
Son comparables. Ambos dependen de TLS para el cifrado y del servidor para la autenticación y la autorización; ninguno es seguro en texto claro.
¿Mejora MQTT 5 la seguridad?
MQTT 5 añade autenticación mejorada, reautenticación y códigos de motivo más detallados, lo que facilita construir y depurar diseños seguros. No añade cifrado por sí mismo.
¿Es seguro usar un broker MQTT público?
Para aprender y hacer demostraciones con datos no sensibles, sí. Los brokers públicos son legibles por todo el mundo, así que los datos de producción deben ir en un broker privado con credenciales y TLS.
