Brokers MQTT expuestos en internet: los riesgos del puerto 1883 abierto

Los brokers MQTT expuestos son servidores que aceptan conexiones desde cualquier lugar de internet, a menudo en el puerto 1883 sin cifrar y sin autenticación. Este artículo explica qué puede ver y hacer en un broker así un atacante o un desconocido curioso, cómo comprobar si alguno de tus brokers está expuesto y cómo solucionarlo. Terminarás con una breve lista de comprobación para auditorías y una regla clara sobre dónde deben ir los datos de prueba y los de producción.

Por qué siguen apareciendo brokers MQTT expuestos

MQTT se diseñó para ser sencillo. Una instalación de broker por defecto suele escuchar en el puerto TCP 1883, y algunas configuraciones antiguas u orientadas al desarrollo permiten conexiones anónimas de serie. Eso es perfecto en un portátil y peligroso en una VM en la nube con una IP pública.

Los investigadores de seguridad y los buscadores que indexan servicios conectados a internet han informado en repetidas ocasiones de un gran número de brokers que responden en el puerto 1883 y aceptan una conexión sin credenciales. El patrón que hay detrás suele ser el mismo:

• Un desarrollador arranca Mosquitto u otro broker en una VM para que funcione un prototipo.
• El firewall o grupo de seguridad de la nube se abre "temporalmente" para el 1883 para que los dispositivos de campo puedan llegar a él.
• El acceso anónimo sigue activado porque nunca se dieron credenciales a los dispositivos.
• El prototipo se convierte silenciosamente en producción.

Ninguno de estos pasos parece arriesgado por sí solo. Juntos crean un bus de mensajes que cualquiera puede leer y escribir.

Qué expone un broker abierto

Para entender el riesgo, recuerda qué hace un broker MQTT: enruta cada mensaje publicado a todos los suscriptores que coincidan. Si cualquiera puede conectarse, cualquiera puede convertirse en suscriptor, y el comodín multinivel # coincide con todos los topics que gestiona el broker.

El lado de la escritura suele subestimarse. Si un relé inteligente se suscribe a home/garage/door/set y el broker acepta publicadores anónimos, la puerta la controla quien encuentre el broker. En entornos industriales, el mismo patrón afecta a consignas y comandos de máquinas. Por eso la seguridad de MQTT tiene tanto que ver con la autorización como con el cifrado.

Filtraciones de información sin ningún ataque

No hace falta mala intención para que haya daños. Un árbol de topics como acme/plant2/line4/press7/fault informa a un competidor sobre la distribución de tu planta. Los mensajes retenidos pueden incluir versiones de firmware, lo que ayuda a cualquiera que busque dispositivos con fallos conocidos. Los topics de depuración suelen llevar trazas de pila, direcciones IP o volcados completos de configuración. Lo prudente es suponer que todo lo publicado en un broker abierto es público.

Cómo comprobar si tu propio broker está expuesto

Prueba solo brokers que te pertenezcan o que tengas autorización explícita para probar. El objetivo es confirmar tu propia configuración desde fuera, tal como la vería un escáner de internet.

Ejecuta estas comprobaciones desde una red ajena a tu red corporativa o cloud, como un punto de acceso móvil:

# 1. ¿Es accesible desde internet el puerto MQTT sin cifrar?
nc -vz your-broker.example.com 1883

# 2. ¿Acepta una conexión anónima? (solo en tu propio broker)
mosquitto_sub -h your-broker.example.com -p 1883 -i audit-anon-check -t 'audit/probe' -W 5 -v

# 3. ¿Presenta el puerto TLS un certificado válido?
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null | head -20

Interpreta los resultados así:

1. Si nc indica que el puerto está abierto y no pretendías ofrecer MQTT sin cifrar públicamente, ciérralo en el firewall.
2. Si mosquitto_sub se conecta y espera en lugar de fallar con "not authorised", el acceso anónimo está activado. Desactívalo.
3. Si el certificado es autofirmado, ha caducado o no coincide con el nombre de host, los clientes fallarán o, peor aún, se habrán configurado para omitir la verificación.

Revisa también directamente la configuración del broker. En Mosquitto 2.x, por ejemplo, un listener sin allow_anonymous false y sin un archivo de contraseñas o plugin de autenticación es una señal de alarma. Comprueba todos los listeners, incluidos los de WebSocket en puertos como 8083 y 9001, que se olvidan con frecuencia.

Cómo corregir un broker MQTT expuesto

Sigue estos pasos en orden. Los tres primeros eliminan la mayor parte del riesgo en una tarde.

1. Exige autenticación en todos los listeners. Emite un nombre de usuario y una contraseña únicos, o un certificado de cliente, por dispositivo o por servicio. Las credenciales compartidas hacen imposible la revocación. La guía de autenticación MQTT con usuario y contraseña cubre la configuración práctica.
2. Cierra el puerto 1883 a internet. Mantén MQTT sin cifrar para localhost o una red privada, y expón solo TLS en 8883 (y WebSockets seguros si los navegadores necesitan acceso).
3. Activa TLS con un certificado de una CA de confianza. Los clientes deben verificar el certificado del servidor y el nombre de host. Consulta la configuración de TLS en MQTT para los ajustes de cliente y broker.
4. Restringe lo que cada identidad puede publicar y suscribir. En un broker autoalojado, usa ACL para que un sensor de temperatura no pueda suscribirse a # ni publicar comandos. La guía de ACL en MQTT muestra patrones habituales.
5. Elimina los datos sensibles de los payloads y topics retenidos. Borra los mensajes retenidos que ya no necesites publicando un mensaje retenido vacío en el topic.
6. Aplica límites. Limita las conexiones, el tamaño de los mensajes y la tasa de mensajes para que un solo cliente no pueda agotar el broker.
7. Actualiza y supervisa. Mantén la versión del broker al día y vigila los inicios de sesión fallidos repetidos.

Si esa lista te parece más un trabajo continuo que un arreglo puntual, es porque lo es. Es uno de los principales motivos por los que los equipos pasan a un broker MQTT gestionado en lugar de operar por su cuenta un servidor expuesto a internet.

Brokers públicos de pruebas frente a brokers privados

Hay una diferencia importante entre un broker expuesto por accidente y uno público a propósito. Un broker público de pruebas está diseñado para ser abierto: cualquiera puede conectarse, cualquiera puede suscribirse y todo el mundo entiende que los datos son visibles. Es una herramienta para aprender y hacer experimentos rápidos.

ConnectMQ gestiona uno en broker.connectmq.com. Acepta clientes anónimos con cualquier client ID único no vacío y aplica límites conservadores por cliente, como 64 KB por mensaje, 10 mensajes por segundo y 10 suscripciones. Eso lo hace ideal para probar código:

mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-7f3a -t 'connectmq/demo/7f3a/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-7f3a -t 'connectmq/demo/7f3a/hello' -m 'test message'

La regla es sencilla: el servidor MQTT público gratuito es solo para datos de prueba y prototipos, nunca para producción. Nunca publiques datos reales de clientes, credenciales, ubicaciones ni comandos de control de equipos reales en ningún broker público. Usa un prefijo de topic único como connectmq/demo/<random-id>/ para que tus experimentos no choquen con los de otros.

Cuando tu proyecto va más allá de los experimentos, necesita un broker privado con autenticación y TLS. En ConnectMQ, al crear uno obtienes credenciales generadas, y los client IDs están vinculados a esas credenciales, así que un client ID filtrado no basta por sí solo para conectarse.

Qué cambia con un broker gestionado

Pasar a un broker MQTT gestionado no te hace seguro automáticamente, pero elimina las causas más comunes de exposición. En un broker privado de ConnectMQ:

• Las conexiones requieren el nombre de usuario y la contraseña generados en el portal.
• TLS está disponible en el puerto 8883 y los WebSockets seguros en el 8084, con un certificado de Let's Encrypt, para que los clientes puedan verificar el servidor sin archivos de CA personalizados.
• Los tenants están aislados entre sí en el clúster multi-tenant.
• Las cuotas por plan, la protección contra inundaciones y el bloqueo de IP tras inicios de sesión fallidos repetidos limitan los abusos.

Tu parte sigue siendo tuya: protege las credenciales en los dispositivos, usa TLS en producción y diseña los topics para que no filtren información. Para una visión completa de las opciones, la guía del broker MQTT en la nube compara los modelos de despliegue, y el artículo de buenas prácticas de seguridad MQTT trata en profundidad el lado del cliente.

Lista de comprobación rápida para auditorías

Usa esta lista en cada broker que operes:

1. Ningún listener acepta conexiones anónimas salvo que sea público a propósito.
2. El puerto 1883 no es accesible desde internet; TLS es obligatorio en los endpoints públicos.
3. Cada dispositivo o servicio tiene sus propias credenciales, y sabes cómo revocarlas.
4. Los clientes verifican el certificado del servidor y el nombre de host.
5. No se publican secretos, datos personales ni topics de control en brokers públicos de pruebas.
6. Los mensajes retenidos no contienen nada que no quisieras que leyera un desconocido.
7. Hay límites configurados de conexiones, tamaño y tasa.
8. Los inicios de sesión fallidos son visibles y los fallos repetidos se bloquean.

Empieza con un broker privado de ConnectMQ

Si tu prototipo funciona hoy en un broker abierto, la solución más rápida es moverlo a uno privado. Crea un broker en el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, copia las credenciales generadas y cambia tus clientes a mqtts:// en el puerto 8883. Tu código de pruebas sigue funcionando en broker.connectmq.com mientras los datos de producción permanecen privados.

Preguntas frecuentes

¿El puerto 1883 es siempre inseguro?

El puerto 1883 transporta MQTT sin cifrar, así que las credenciales y los payloads viajan en texto claro. Es aceptable en localhost o en una red aislada, pero los endpoints expuestos a internet deben usar TLS en el 8883.

¿Cómo sé si hay desconocidos leyendo mi broker?

Sin autenticación no puedes saberlo con certeza, porque cualquier cliente puede suscribirse a # en silencio. Trata un broker anónimo expuesto a internet como ya comprometido y rota cualquier secreto que haya transportado.

¿Es seguro usar broker.connectmq.com para mi proyecto?

Es seguro para aprender y hacer pruebas con datos no sensibles. Como es público por diseño, todo lo que se publique allí puede ser leído por otros, así que los sistemas de producción deben usar un broker privado con credenciales.

¿Desactivar el acceso anónimo detiene todos los ataques?

No, pero elimina el más fácil. Combina la autenticación con TLS, autorización por cliente, límites y actualizaciones para obtener una protección real.