¿Qué es un servidor SCADA de doble NIC?
Un servidor SCADA a menudo necesita vivir en dos mundos a la vez: debe hablar con los dispositivos de campo en una red de control aislada, y también debe alimentar datos hacia la red de negocio o una DMZ donde viven los reportes y las conexiones a la nube. Un servidor de doble NIC, o multihomed, hace esto con dos interfaces de red - una conectada a cada red - para que la máquina alcance ambas sin fusionarlas en una sola. Bien hecho, mantiene separados los planos de control y de negocio mientras aún puentea los datos que una operación necesita. Mal hecho, se vuelve la ruta accidental que un atacante usa para llegar a la red de control. Esta guía explica el diseño, las reglas de ruteo y de puerta de enlace que mantienen los dos planos aparte, el teaming de NIC para un camino de control redundante y las trampas de puenteo por evitar.
Servidor SCADA de doble NIC en una línea: Un servidor SCADA de doble NIC es una máquina multihomed con dos tarjetas de interfaz de red, una conectada a la red de control o de dispositivos aislada y la otra a la red de negocio o DMZ. El diseño deja que un servidor participe en ambas redes sin unirlas, pero depende de un ruteo cuidadoso y de la configuración de la puerta de enlace por defecto para que el tráfico no pueda fluir por el servidor desde el lado del negocio hacia la red de control.
Dos interfaces, dos redes, un servidor
Una tarjeta de interfaz de red, o NIC, es el puerto por el cual un servidor se conecta a una red. Un servidor de una sola NIC se ubica en una red y solo puede alcanzar lo que esa red alcanza. Un servidor de doble NIC tiene dos de esos puertos, cada uno cableado a una red distinta, y el término para una máquina con pies en más de una red es multihomed. Para SCADA, las dos redes suelen ser la red de control o de dispositivos, donde viven los PLC, las RTU y los dispositivos de campo detrás de una frontera de aislamiento, y la red de negocio o DMZ, donde se ubican las herramientas de reporte de los operadores, los historiadores empresariales y la conectividad a la nube.
La razón para hacer multihomed un servidor SCADA en vez de rutear entre las redes es mantener aislado el lado hacia el campo mientras aún se deja que el servidor jale datos de los dispositivos y los empuje hacia la capa de negocio. La NIC del lado de control habla los protocolos industriales directo a los dispositivos en una red deliberadamente amurallada del LAN corporativo y de internet. La NIC del lado de negocio lleva los resultados hacia afuera - a reportes, a un historiador empresarial o a una plataforma en la nube - sin exponer la red de dispositivos a lo que alcance el lado de negocio.
El valor de este arreglo es que no existe ningún camino de red directo entre los dos lados salvo a través de la propia lógica de aplicación del servidor. Los dispositivos nunca aparecen en la red de negocio, y los hosts de negocio nunca obtienen una ruta a los dispositivos de control, porque no hay ruteador que una las dos subredes, solo un servidor que resulta ser alcanzable en ambas. Esa separación solo se sostiene, sin embargo, si el servidor se configura para que él mismo no se convierta en un puente, que es donde importan las reglas de ruteo.
Ruteo, puertas de enlace por defecto y cómo mantener separados los planos
La regla más importante para un servidor SCADA multihomed es que debe tener una sola puerta de enlace por defecto, y debe estar del lado de negocio, no del lado de control. La puerta de enlace por defecto es donde una máquina envía el tráfico destinado a redes para las que no tiene una ruta específica. Si a un servidor de doble NIC se le dieran dos puertas de enlace por defecto, su comportamiento para el tráfico fuera de subred se vuelve ambiguo y puede empezar a rutear entre las dos redes de maneras que nadie pretendió. Una sola puerta de enlace por defecto elimina esa ambigüedad y define exactamente una dirección para el tráfico saliente general.
La NIC del lado de control no debe tener ninguna puerta de enlace por defecto, solo una conexión directa a la subred de dispositivos que sirve. Como los dispositivos de campo están todos en la misma subred local que la NIC de control, el servidor los alcanza directamente sin necesitar una puerta de enlace, y negarle una a esa NIC asegura que el servidor nunca intente rutear tráfico arbitrario hacia afuera por la red de control. Donde el servidor deba alcanzar dispositivos en otras subredes de control, se agregan rutas estáticas explícitas solo para esas redes específicas, para que la alcanzabilidad sea quirúrgica en lugar de una ruta general que pudiera abusarse.
Igual de importante es que el sistema operativo no debe reenviar paquetes entre sus dos NIC. Un servidor puede, si se configura para ello, actuar como ruteador y pasar tráfico que llega por una interfaz hacia afuera por la otra, que es justo lo que no se quiere aquí: convertiría la frontera de aislamiento en una puerta. El reenvío de IP entre las interfaces debe estar deshabilitado para que el servidor participe en ambas redes pero nunca retransmita tráfico de una a la otra. Con una sola puerta de enlace por defecto, ninguna puerta en la NIC de control, rutas estáticas puntuales y el reenvío apagado, los dos planos se mantienen genuinamente separados mientras el servidor hace su trabajo en ambos.
Teaming de NIC para redundancia y la trampa del puenteo
El diseño de doble NIC sirve a la separación, pero una técnica relacionada, el teaming de NIC, sirve a la redundancia, y las dos no deben confundirse. El teaming enlaza dos NIC físicas que se conectan a la misma red en una sola interfaz lógica, así que si falla un cable, un puerto o un switch, la otra lleva el tráfico sin que el servidor pierda conectividad. Para un camino de control que no debe quedar a oscuras, el teaming de dos NIC en un enlace redundante a la red de dispositivos protege contra una falla de un solo cable o puerto de switch. La distinción clave es que el teaming une dos puertos a una red para resiliencia, mientras que el multihoming pone un puerto en cada una de dos redes distintas para separación.
La trampa peligrosa en cualquier arreglo de doble NIC es el puenteo accidental: crear sin querer un camino de red entre las redes de control y de negocio a través del servidor. Esto puede pasar si se deja encendido el reenvío de IP, si alguien puentea las dos interfaces a nivel del sistema operativo, si una segunda puerta de enlace por defecto se cuela en la configuración, o si se agrega una ruta estática amplia que expone sin querer la red de control. Cualquiera de estas convierte la red de dispositivos cuidadosamente aislada en algo alcanzable desde el lado de negocio, deshaciendo toda la razón del diseño y entregándole a un atacante en el LAN corporativo una ruta hacia los dispositivos de campo.
Protegerse contra el puenteo es sobre todo disciplina: una sola puerta de enlace por defecto, ninguna puerta en la NIC de control, el reenvío deshabilitado y solo las rutas estáticas más estrechas necesarias, todo revisado cada vez que se toca el ruteo del servidor. Muchas arquitecturas maduras evitan por completo poner el servidor de control directamente en la red de negocio, y en su lugar usan un intermediario endurecido y empujan los datos hacia afuera a través de él. El SCADA en la nube encaja en ese patrón limpiamente: una plataforma como Merobix recibe los datos de campo por un camino saliente controlado en lugar de exigir que la red de control sea alcanzable desde afuera, así que el tablero del operador en el navegador se alimenta sin ninguna ruta entrante hacia la red de dispositivos que una segunda NIC mal configurada pudiera crear.
Preguntas frecuentes
¿Por qué un servidor SCADA de doble NIC debe tener una sola puerta de enlace por defecto?
Porque dos puertas de enlace por defecto vuelven ambiguo el ruteo del servidor para el tráfico fuera de subred y pueden hacer que rutee sin querer entre las redes de control y de negocio. Una sola puerta de enlace por defecto, ubicada del lado de negocio, define exactamente un camino para el tráfico saliente general. La NIC del lado de control no recibe ninguna puerta, solo su subred local más las rutas estáticas estrechas necesarias para redes de dispositivos específicas, lo que evita que los dos planos se fusionen.
¿Un servidor de doble NIC es lo mismo que el teaming de NIC?
No. Un servidor de doble NIC, multihomed, pone una interfaz en cada una de dos redes distintas para separación. El teaming de NIC enlaza dos interfaces que se conectan a la misma red en un solo enlace lógico para redundancia, para que un cable o puerto de switch caído no tire la conexión. Resuelven problemas distintos, y un servidor puede incluso hacer ambos: enlazar un par para el camino de control mientras permanece multihomed entre las redes de control y de negocio.
¿Cuál es el riesgo del puenteo accidental en un servidor SCADA multihomed?
El puenteo accidental crea un camino de red no pretendido entre la red de control aislada y la red de negocio a través del servidor, lo que anula el aislamiento que el diseño existe para dar. Suele ocurrir cuando se deja habilitado el reenvío de IP, las dos interfaces se puentean a nivel del sistema operativo, o se agrega una segunda puerta de enlace por defecto o una ruta demasiado amplia. El resultado puede entregarle a un atacante en la red de negocio una ruta hacia los dispositivos de campo, así que el reenvío debe quedar apagado y el ruteo al mínimo.
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.