Configurar flujos MQTT

Asegura MQTT en una red OT con Access Gate, denegación por defecto en el puerto 1883, enclaves con alcance de identidad, control a nivel de topic y TLS para un broker que no incluye autenticación ni cifrado.

MQTT es un protocolo ligero de publicación/suscripción utilizado en entornos IoT y OT para telemetría y comandos: los clientes publican mensajes en tópicos de un broker, y otros clientes se suscriben a esos tópicos. Su simplicidad y eficiencia son también su problema de seguridad. Un broker con configuración predeterminada suele funcionar sin autenticación, sin cifrado y sin control de acceso a tópicos, por lo que cualquier dispositivo que pueda alcanzarlo puede leer todos los tópicos o publicar un comando no autorizado en un tópico de control. Access Gate coloca identidad, política y cifrado delante del broker para que solo los clientes autorizados intercambien mensajes MQTT.

Qué se obtiene

Denegación predeterminada en el puerto 1883. Nada llega al puerto MQTT del broker a menos que una regla de ACL explícita lo permita. Esto por sí solo elimina la exposición de "cualquier host en la red puede conectarse y publicar".
Acceso limitado por identidad. Los flujos MQTT suelen ser máquina a máquina: un publicador envía telemetría y un broker la distribuye. Los permisos se definen entre activos, de modo que solo el cliente autorizado llega al broker y ningún otro.
TLS para un protocolo que no lo tiene. MQTT en el puerto 1883 es texto plano. El gate envuelve la sesión en TLS entre el cliente y sí mismo, y luego reenvía al broker a través del segmento protegido, de modo que el tráfico viaja cifrado en tránsito sin necesidad de cambios criptográficos en el lado del broker.

Por qué el broker predeterminado queda expuesto

En este ejemplo, el broker es Eclipse Mosquitto 2.0.18 en Linux, con una configuración mínima de laboratorio:

# /etc/mosquitto/conf.d/lab.conf
listener 1883 0.0.0.0   # MQTT on the standard port 1883, bound to all interfaces
allow_anonymous true    # no authentication: any client can connect, publish, and subscribe

Con esta configuración, el broker presenta varios riesgos:

Sin autenticación. Con allow_anonymous true, cualquier persona en la red puede conectarse, publicar y suscribirse sin nombre de usuario ni contraseña.
Sin TLS. El tráfico en el puerto 1883 es texto plano, por lo que las credenciales y la telemetría son interceptables y la sesión puede ser manipulada en tránsito (MITM).
Sin ACL de tópicos. Cualquier cliente puede suscribirse a todo o publicar en un tópico de control, por ejemplo para falsificar un valor de consigna de un PLC.
Inyección y repetición de mensajes. Los comandos falsificados o repetidos hacia actuadores tienen impacto en el mundo físico en entornos OT.
Denegación de servicio. La inundación de mensajes retenidos y el agotamiento de conexiones pueden derribar el broker.
Exposición del broker. Con el puerto 1883 vinculado a 0.0.0.0, el broker es accesible fuera del segmento cuando la red no está estrictamente aislada.

Configuración

Registre el broker como un activo y establezca su protocolo en MQTT.

Registro del broker MQTT como activo
Agregue el broker a un enclave (consulte Proteger un activo con enclaves) y luego añada una regla allow para el protocolo mqtt limitada al cliente específico que debe acceder a él. Esto envuelve un enclave alrededor de los flujos MQTT.

Un enclave delimitado alrededor de los flujos MQTT

En este punto, el broker ya no está completamente abierto: el gate verifica la identidad del cliente y aplica las reglas de control de acceso sobre el flujo.

Ejemplo práctico: proteger un flujo cliente-broker

Las imágenes a continuación muestran un mensaje publicado desde un cliente hacia el broker a través del Access Gate. El enclave está configurado para que solo ese cliente pueda alcanzar el broker; ningún otro dispositivo en la red puede hacerlo.

Primer nivel de seguridad: agregar autenticación y control de acceso

Desde el cliente, publicamos un mensaje en el tópico. El gate permite el paso del cliente autorizado y el broker lo recibe.

El broker recibiendo el mensaje publicado

Segundo nivel de seguridad: agregar cifrado TLS

Acceda al enclave, active TLS e instale el certificado en el dispositivo cliente. El gate mantiene ahora un túnel TLS entre el cliente y el broker, de modo que el mismo flujo viaja cifrado.

Publicación de un mensaje cifrado en el broker

Cómo se establece la sesión cifrada

Resulta útil ver la publicación cifrada como tres capas, establecidas en orden:

Socket (TCP). El cliente abre una conexión TCP hacia el gate en el puerto 1883. Es simplemente un canal de bytes confiable: transporta lo que se coloque en él.
TLS. Inmediatamente después de abrir el socket, se ejecuta un handshake TLS dentro de él. El proxy presenta su cadena de certificados, el cliente la verifica contra su propio certificado (el de Access Gate en este caso) y comprueba que el nombre de host coincida con el SAN del certificado (mqtt-broker.bluelab.secure). Ambos lados derivan claves y todo lo que sigue queda cifrado.
Mensaje (MQTT). Solo una vez que TLS está activo, MQTT se ejecuta a través del canal cifrado: CONNECT, el broker responde CONNACK (0) (aceptado), luego PUBLISH con el payload al tópico plant/line1/cmd, y finalmente DISCONNECT. El código de salida 0 indica que las tres capas se completaron correctamente.

TCP es el canal, TLS es el sobre cifrado alrededor del canal, y MQTT es la conversación real que se lleva dentro del sobre. La función del proxy es rechazar todo lo que no esté envuelto en el sobre TLS.

Notas y consideraciones

No interrumpa el flujo. Antes de aplicar restricciones, observe el tráfico MQTT real para identificar qué clientes publican o se suscriben de forma legítima.
Los tópicos son la verdadera superficie de ataque. La accesibilidad es el primer control, pero el daño en MQTT ocurre a nivel de tópico. Limite los permisos a los clientes específicos que son propietarios de un tópico de control para que un sensor comprometido no pueda publicar en él.
Guarde el certificado. Mantenga el certificado del cliente en el almacén de certificados del dispositivo en lugar de pasar --cafile en cada comando, de modo que el flujo cifrado sea la ruta predeterminada.
Otros protocolos OT. El mismo modelo de denegación predeterminada, acceso limitado por identidad y envoltorio TLS se aplica a los demás protocolos industriales de la red; MQTT es un punto de partida habitual, no el único.

Resumen

Registró el broker como un activo MQTT, envolvió un enclave alrededor de los flujos MQTT con una regla de denegación predeterminada limitada al cliente autorizado, y activó TLS para que un protocolo de texto plano viaje cifrado sin modificar el broker. El cliente se autentica y cifra contra el gate, que aplica la política y reenvía al broker a través del segmento protegido.

Use este enfoque para proteger un broker MQTT que no incluye autenticación, cifrado ni control de acceso a tópicos, donde la accesibilidad equivale a autorización y una sola publicación no autorizada puede mover un proceso físico.