El problema de Modbus del que nadie quiere hablar
Modbus TCP está en todas partes en OT. PLCs, RTUs, gateways SCADA, sistemas de gestión de edificios. Si has trabajado en entornos industriales durante más de un año, lo has usado.
El protocolo fue diseñado en 1979. Asume una red de confianza, aislada físicamente, donde todo el que tiene acceso físico está autorizado. Esa suposición dejó de ser válida hace unos veinte años, pero la mayoría de las plantas siguen ejecutando Modbus completamente abierto en redes planas, sin autenticación, sin cifrado y sin ningún control de acceso.
Este no es un riesgo teórico. Cualquier persona con Wireshark y acceso a la red puede leer todos los valores de registros en texto claro. Cualquier persona con un script de Python puede escribir en bobinas y registros de retención. No hay handshake, no hay token de sesión, nada.
Por qué Modbus TCP es difícil de proteger
Modbus TCP toma el protocolo serie original y lo envuelve en TCP/IP en el puerto 502. Eso es todo. No hay TLS, no hay cabecera de autenticación, no hay concepto de identidad de usuario.
Sin autenticación. Un servidor Modbus TCP acepta comandos de cualquier dirección IP que pueda alcanzarlo. No hay nombre de usuario, no hay contraseña, no hay intercambio de certificados. Si puedes abrir una conexión TCP al puerto 502, tienes acceso.
Sin cifrado. Cada código de función, dirección de registro y valor viaja en texto claro. Un atacante en la red puede ver exactamente qué está leyendo y escribiendo tu HMI. También puede modificar paquetes en tránsito si está posicionado para un ataque de intermediario.
La repetición es trivial. Los paquetes Modbus TCP son suficientemente sin estado como para que el tráfico capturado pueda reproducirse más tarde. Graba un comando "write single coil" y puedes ejecutarlo de nuevo cuando quieras. El PLC no notará la diferencia.
Segmentación de red: empieza aquí
Si no haces nada más, segmenta tu tráfico Modbus del resto de tu red. Este único paso elimina la mayor clase de ataques: alguien en la LAN corporativa (o una estación de trabajo IT comprometida) que accede directamente a tu red de control.
Las VLANs son el mínimo. Coloca tus dispositivos Modbus en su propia VLAN. No te limites a etiquetar el tráfico y dar el trabajo por hecho. Asegúrate de que el enrutamiento entre VLANs esté bloqueado para que solo hosts específicos puedan cruzar el límite.
Los firewalls entre zonas son importantes. Una VLAN sin firewall entre ella y el resto de la red es solo decoración organizativa. Necesitas inspección de paquetes con estado en el límite, con reglas que permitan explícitamente solo los pares origen/destino y puertos que esperas.
Si sigues IEC-62443, esto se corresponde con el modelo de zonas y conductos. En la práctica, significa trazar una línea clara entre tu red de Nivel 2 (control) y Nivel 3 (operaciones del sitio), con un conducto definido para cualquier tráfico que necesite cruzar.
Cifrado del tráfico Modbus
Como Modbus TCP no tiene cifrado nativo, tienes que envolverlo en otra cosa.
Los túneles VPN entre sitios o entre una estación de trabajo de ingeniería y la red de control son el enfoque más común. IPsec o WireGuard funcionan bien. Lo clave es asegurarse de que el túnel termine lo más cerca posible del dispositivo Modbus, no en el borde de una red plana donde el tráfico viaja sin cifrar en el último tramo.
Los wrappers TLS como stunnel pueden cifrar Modbus TCP entre dos endpoints. Esto funciona bien para enlaces punto a punto, como un HMI que habla con un PLC específico. Tiene más sobrecarga de gestión a escala, pero proporciona cifrado por conexión.
Los firewalls con conocimiento del protocolo añaden otra capa. Un firewall que entiende los códigos de función Modbus puede bloquear comandos de escritura de hosts que solo deberían leer, o restringir qué rangos de registros puede acceder un origen determinado. Un proxy en línea que entiende los códigos de función Modbus puede aplicar políticas por dispositivo y por código de función sin requerir cambios en el PLC ni en el HMI.
Control de acceso sin soporte nativo
Modbus no sabe qué es un "usuario". Por eso hay que aplicar el control de acceso en las capas de red y aplicación.
Crea una lista de IPs de origen permitidas en el firewall. Solo el HMI, el historiador y la estación de trabajo de ingeniería deberían poder alcanzar el puerto 502 en tus PLCs. Todo lo demás se descarta. Es un método básico, pero elimina el acceso casual desde máquinas aleatorias en la red.
Usa un gateway o proxy para el control basado en roles. Si necesitas mayor granularidad (solo lectura para operadores, lectura y escritura para ingenieros), necesitas algo delante del dispositivo Modbus que mapee usuarios autenticados a conjuntos de permisos. Un gateway de acceso con conocimiento de Modbus hace esto terminando la conexión Modbus, autenticando al usuario y luego enviando por proxy solo los códigos de función permitidos al dispositivo aguas abajo.
MFA para acceso remoto, siempre. Si alguien se conecta a tu red de control de forma remota, ya sea a través de una VPN, un jump host o un gateway en la nube, necesita autenticación multifactor. Esto no es negociable. Una contraseña robada no debería ser suficiente para alcanzar un PLC.
Monitorización: no puedes proteger lo que no puedes ver
El tráfico Modbus plano es fácil de monitorizar porque está en texto claro y tiene una estructura bien definida. Aprovecha eso.
Ejecuta un IDS que entienda Modbus. Snort y Suricata tienen preprocesadores Modbus. Pueden alertar sobre códigos de función inesperados, escrituras en rangos de registros que no deberían modificarse, o tráfico de direcciones IP que no están en tu lista de permitidos.
Primero establece una línea base de tu tráfico normal. Antes de empezar a escribir reglas de alerta, captura una semana de tráfico Modbus normal y analízalo. ¿Con qué frecuencia hace polling el HMI? ¿Qué registros lee? ¿Alguien escribe en bobinas durante las operaciones normales? Una vez que sabes cómo es lo "normal", las anomalías se vuelven evidentes.
Registra todo en el gateway. Si ejecutas un proxy o gateway Modbus, registra cada conexión y cada código de función. Cuando algo sale mal, tener un registro de auditoría completo de quién escribió qué en qué registro, y cuándo, marca la diferencia entre una investigación de 30 minutos y un ejercicio forense de tres días.
La gestión de parches en OT es diferente
Parchear en OT no es como parchear en IT. No puedes simplemente desplegar actualizaciones un martes por la noche y reiniciar. El tiempo de inactividad cuesta dinero real, y una actualización de firmware defectuosa en un PLC puede detener una línea de producción.
Sabe qué estás ejecutando. Mantén un inventario de cada dispositivo que habla Modbus, su versión de firmware y el estado de parches del fabricante. La mayoría de las plantas no pueden responder a esta pregunta, lo que significa que no pueden parchear aunque quieran.
Prueba los parches en un entorno de staging. Si tienes un PLC de prueba o una configuración de simulación, valida los parches allí antes de desplegarlos en producción. Si no tienes un entorno de prueba, lo necesitas. El coste es insignificante comparado con una actualización fallida en un sistema en producción.
Planifica ventanas de mantenimiento de forma realista. Trabaja con operaciones para encontrar ventanas donde sea posible parchear. Trimestral es un objetivo razonable para la mayoría de los entornos. Anual es demasiado lento. Mensual es aspiracional para OT, pero apunta a ello si puedes.
Estándares que vale la pena seguir
IEC-62443 es el estándar de referencia para la ciberseguridad industrial. Proporciona un marco para zonas, conductos y niveles de seguridad que se corresponde directamente con decisiones reales de arquitectura de red. Empieza por las partes 3-2 (evaluación de riesgos de seguridad) y 3-3 (requisitos de seguridad del sistema).
NIST SP 800-82 es la guía del gobierno de EE. UU. para la seguridad de sistemas de control industrial. Es práctica y está bien redactada. Si estás en un entorno CMMC o NIST 800-171, se alinea con esos requisitos y proporciona orientación específica para OT que el 800-171 por sí solo no cubre.
NIS2 aplica si operas en la UE o vendes a sectores de infraestructura crítica de la UE. Impone obligaciones de notificación de incidentes y requisitos de seguridad que cubren específicamente los entornos OT. Si aún no estás siguiendo el cumplimiento de NIS2, verifica si tu organización está dentro de su ámbito.
Por dónde empezar mañana
Elige el elemento de mayor impacto que aún no hayas abordado. Para la mayoría de las plantas que ejecutan Modbus TCP en una red plana, eso es la segmentación. Coloca tus dispositivos de control detrás de un firewall, restringe qué hosts pueden alcanzar el puerto 502 y registra las conexiones. Solo eso cerrará la mayoría de las brechas. Todo lo demás se construye sobre esa base.
