¿Qué es el filtrado de comandos por DPI para Modbus y DNP3?
El filtrado de comandos por DPI usa la inspección profunda de paquetes para imponer reglas sobre los comandos reales dentro del tráfico industrial, no solo sobre las conexiones que los llevan. Como un firewall consciente del protocolo puede leer el código de función Modbus o la función de control DNP3 en un paquete, puede tomar una decisión que ningún firewall ordinario puede: permitir que pase una lectura mientras bloquea una escritura, deteniendo un comando de control no autorizado a mitad de flujo aunque comparta una conexión con tráfico de monitoreo legítimo. Esto convierte un control grueso de permitir-o-denegar-la-conexión en un control fino de permitir-lecturas-pero-no-escrituras. Esta página explica cómo funciona el filtrado de comandos, qué puede imponer, y por qué es una herramienta poderosa para proteger una red de control sin cortar la visibilidad que los operadores necesitan.
Filtrado de comandos por DPI en una línea: El filtrado de comandos por DPI es una técnica de firewall que inspecciona la carga útil del tráfico de protocolo industrial y permite o bloquea comandos individuales según su función, en lugar de permitir o denegar una conexión entera. Para Modbus y DNP3 esto típicamente significa permitir que pasen los códigos de función de lectura mientras se bloquean los códigos de función de escritura y control, para que un dispositivo pueda monitorearse pero no comandarse. Como el firewall analiza el código de función de cada paquete y descarta los comandos no permitidos a mitad de flujo, impone una política de solo lectura en un enlace de control vivo que un firewall basado en puertos no puede expresar.
Del filtrado de conexión al filtrado de comandos
Un firewall tradicional decide a nivel de la conexión. Puede permitir o denegar el tráfico entre dos hosts en un puerto dado, así que su control más fino sobre un enlace Modbus es permitir toda la conversación o bloquearla por completo. Eso es demasiado tosco para una red de control, porque la misma conexión lleva tanto las lecturas inofensivas de las que depende un sistema de monitoreo como las escrituras que podrían cambiar el proceso físico. Bloquear la conexión mata la visibilidad, mientras que permitirla permite cada comando, incluidos los peligrosos.
El filtrado de comandos por DPI rompe esa elección de todo-o-nada. Como la inspección profunda de paquetes permite al firewall leer el código de función dentro de cada paquete, puede aplicar una regla al comando específico en lugar de a la conexión. La política clásica es una lista de permitidos de códigos de función: permitir las funciones de lectura, como leer registros de retención o registros de entrada en Modbus, y denegar las funciones de escritura, como escribir un registro o forzar una bobina. La conexión se mantiene arriba y el monitoreo sigue funcionando, pero cualquier paquete que lleve un comando no permitido se descarta antes de que llegue al dispositivo.
El efecto es un punto de imposición de solo lectura que aún deja fluir los datos. Un sistema supervisor o un monitor de seguridad del lado equivocado del firewall puede seguir sondeando un controlador por sus valores, mientras que cualquier intento de comandar ese controlador, sea de un atacante, un host comprometido, o una herramienta mal configurada, se detiene en el firewall. Este es exactamente el control que un operador quiere en torno a un dispositivo sensible: visibilidad completa de lo que está haciendo, sin capacidad de que el lado monitoreado meta la mano y lo cambie.
Qué impone el filtrado de comandos para Modbus y DNP3
En Modbus el filtro trabaja sobre los códigos de función. Las operaciones de lectura y las de escritura llevan códigos de función distintos, así que una política puede permitir las lecturas mientras descarta las escrituras, y puede ir aún más fino, permitiendo escrituras a algunos rangos de registros pero no a otros, o bloqueando el forzado de bobinas mientras permite las lecturas de registros. Esto permite a una planta expresar una regla como permitir a este host de monitoreo leer cualquier cosa en este PLC pero nunca escribirle, impuesta paquete por paquete, que un firewall basado en puertos nunca podría articular porque cada paquete Modbus le luce igual.
DNP3 lleva su propia semántica de control, y el filtrado de comandos lee la función de nivel de aplicación de DNP3 para imponerla. Puede permitir las funciones de lectura y reporte que componen la telemetría normal mientras bloquea las funciones de operar directo y control que realmente accionan un punto, y puede ser consciente de la secuencia de seleccionar-antes-de-operar que DNP3 usa para resguardar el control. Como DNP3 se usa para control remoto real de infraestructura eléctrica y de agua, poder permitir la telemetría mientras se deniegan los comandos de control a nivel de protocolo es una protección significativa para activos donde un operar no autorizado podría tener consecuencias físicas.
La imposición es en tiempo real y en línea, lo que la distingue del monitoreo pasivo. Un sensor pasivo que observa una copia del tráfico puede detectar un comando malo después de que ya ocurrió, pero un filtro de comandos se sienta en la ruta y descarta el paquete no permitido antes de que llegue al dispositivo, así que el comando nunca se ejecuta del todo. Esa posición en línea es lo que le da al filtrado de comandos su fuerza, y es también lo que exige cuidado, porque un dispositivo que falla en la ruta de tráfico debe diseñarse de modo que una falla no corte un enlace de control que el proceso realmente necesita.
Encajar el filtrado de comandos en la arquitectura SCADA
El filtrado de comandos brilla en fronteras dentro de una arquitectura SCADA donde un lado debe observar pero no controlar. Una colocación común es en torno a un segmento de controladores especialmente sensibles, dejando que una red SCADA o de historiador más amplia lea sus valores para monitoreo y reporte mientras se le deniega cualquier capacidad de comandarlos, de modo que los dispositivos sensibles solo sean comandados por sus propios controladores locales y nadie más. Otra es en un enlace a una zona menos confiable, donde se quiere exponer telemetría hacia afuera pero nunca aceptar control hacia adentro.
La técnica se empareja de forma natural con una postura de monitoreo de solo lectura. Donde una organización quiere que un sistema remoto o centralizado vea todo lo que una red de control está haciendo mientras garantiza que ese sistema no pueda cambiar nada, un filtro de comandos que impone solo-lecturas en la frontera provee esa garantía a nivel de protocolo en lugar de confiar en que el sistema remoto se comporte. Esta es una garantía más fuerte que una política o una configuración, porque el filtro descarta físicamente cualquier escritura sin importar lo que el sistema aguas arriba pretenda o sea engañado para enviar.
Para el monitoreo conectado a la nube y centralizado esto importa porque permite a un operador exponer de forma segura los datos de la red de control a sistemas fuera de la planta. Un SCADA en la nube o una plataforma de seguridad como Merobix puede recibir una vista rica y de solo lectura de la telemetría Modbus y DNP3 de un sitio a través de una frontera que permite las lecturas y bloquea cada escritura, de modo que la plataforma remota gane visibilidad completa mientras el filtro de comandos garantiza que nunca pueda meter la mano y accionar nada en el campo. Filtrar sobre el comando en lugar de la conexión es lo que permite separar limpiamente la visibilidad y el control, dando al monitoreo remoto su alcance sin darle su riesgo.
Preguntas frecuentes
¿Cómo permite el filtrado de comandos las lecturas pero bloquea las escrituras en la misma conexión?
Inspecciona la carga útil de cada paquete con inspección profunda de paquetes y lee el código de función del protocolo, que dice de forma explícita si el paquete es una lectura o una escritura. El firewall luego aplica una regla a ese comando específico en lugar de a toda la conexión, dejando pasar los paquetes cuyo código de función está en la lista de permitidos y descartando los que no. Como las lecturas y las escrituras llevan códigos de función distintos, una política de solo lectura puede dejar pasar cada lectura mientras descarta cada escritura, todo en la misma conexión viva.
¿El filtrado de comandos por DPI es lo mismo que el monitoreo pasivo?
No, son opuestos en un aspecto clave. El monitoreo pasivo observa una copia del tráfico y solo puede detectar un comando malo después de que ya llegó al dispositivo, sin enviar nada él mismo. El filtrado de comandos se sienta en línea en la ruta de tráfico y descarta activamente un comando no permitido antes de que llegue al dispositivo, así que el comando nunca se ejecuta. El filtrado por tanto previene en lugar de solo detectar, pero como está en línea debe diseñarse de modo que una falla no corte un enlace de control del que el proceso depende.
¿Puede el filtrado de comandos bloquear una escritura de registro Modbus específica mientras permite otras?
Sí, si el filtro soporta reglas a nivel de dirección. La inspección profunda de paquetes lee no solo el código de función Modbus sino también la dirección de registro o bobina y la cantidad involucrada, así que una política puede escribirse para permitir escrituras a algunos rangos de dirección mientras bloquea otros, o para bloquear el forzado de bobinas mientras permite las lecturas de registros. Esto permite a una planta expresar reglas finas como permitir una escritura de consigna dentro de un rango seguro mientras se deniegan escrituras a direcciones protegidas, todo impuesto paquete por paquete.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.