Firewalls Virtuales, por qué no en redes industriales?

Como hemos hablado en otras ocasiones la primera medida técnica para securizar las redes industriales es separar nuestros entornos de Oficinas y de Control mediante un NGFW. Con ello, conseguimos independizarlos y ceñir a cada uno de ellos el tráfico necesario. Luego, ya dentro del segundo es necesario segmentarlo en áreas funcionales más pequeñas de tal modo que si se produjese algún incidente, intencionado o no, no se propague al resto evitando así un daño mayor. Todo esto y más lo comentaba en un artículo de abril de 2016. Os dejo el enlace, pinchar aquí.

En él citaba que las mismas podrían ser física o lógica, utilizándose enlaces dedicados o configuraciones en la electrónica de red como pueden ser las tan conocidas VLAN. Sin embargo, el uso de tecnología “virtual” no es exclusivo de los switches o servidores. También la podemos emplear en Firewalls. Sí, los mismos que nos separan y segmentan dichos entornos.

En mi caso voy a tomar como ejemplo el uso que hace de esta tecnología el fabricante Fortinet.

Fortinet lo denomina como “VDOMs”, Virtual Domains. Con ella podremos crear dos o más Firewalls “lógicos” dentro de uno físico siendo cada uno de ellos totalmente independiente uno del otro. Tendrán sus propias reglas de filtrado, sus propios perfiles de seguridad, sus propios administradores, etc.

Tal es así que, aparte de los que se configuren, se creará otro de forma automática denominado “root”. Cuando todos los VDOMs son deshabilitados en cualquier unidad FortiGate, hay un VDOM que sigue activo, el “root”. Esto es así ya que debe existir un VDOM de administración entre otros aspectos, para la gestión de tráfico. Por ejemplo, cuando habilitamos la funcionalidad de VDOM toda la configuración se conserva en el VDOM “root”. A partir de ahí iremos creando otros en consecuencia. Todas las configuraciones que sean necesarias fuera de los VDOM, se realizan desde el apartado “Global”. Hablamos de las que afectan a la unidad Fortigate como dispositivo físico, esto es, la asignación de interfaces, Alta Disponibilidad, mantenimiento, etc.

Aquí os dejo un video donde se muestra tanto el concepto como una configuración básica:

Como es evidente, cada unidad FortiGate tiene recursos hardware limitados como CPU, memoria y almacenamiento. Cuando no empleamos VDOMs, este límite no supone un problema ya que todas las sesiones, usuarios y otros procesos comparten todos los recursos de forma equitativa. Sin embargo, cuando hacemos uso de ellos, podremos asignar a cada VDOM distinta cantidad, mínima y máxima, según sea necesario. Por defecto, cada VDOM no tendrá límites, con lo que un solo VDOM podría en un momento dado emplear todos los recursos en detrimento de otros VDOM.

Por ello es conveniente definir límites a este respecto. Veamos porqué.

Si bien la electrónica ha mejorado, cada vez que instalamos un equipo de seguridad perimetral introducimos una latencia, que puede aumentar tanto en cuanto se habilitan más características con el fin de mejorar la seguridad en las comunicaciones. Me refiero a servicios antivirus, IDS/IPS, Control de Aplicación, VPNs, etc. Las comunicaciones industriales no requieren unos anchos de banda como las que puede haber en entornos IT, sin embargo, las latencias experimentadas pueden ser inasumibles. Cuando hablamos en comunicaciones en tiempo real como voz o video sobre IP, podemos aceptar tiempos de hasta 150 ms. Sin embargo, en comunicaciones industriales tipo RT (Real Time) podemos hablar de hasta 10 ms o incluso en IRT (Isochronous Real Time) entre 0.25 y 1 ms. A la hora de instalar dispositivos de seguridad perimetral físicos como virtualizados, debemos tener esto presente. Más aún, en el caso de estos últimos donde compartimos recursos hardware. Si no realizamos un correcto dimensionamiento o asignación, podríamos enfrentarnos a que un Firewall virtual del entorno IT donde los anchos de banda sean mayores y exista una mayor cantidad de tráfico, requiera  recursos hardware y penalice al virtualizado en el entorno OT, donde si bien la cantidad de tráfico es menor, las latencias asumibles son mucho menores o críticas.

Como decía dentro de la Ciberseguridad Industrial, nuestro primer paso será la separación de entornos y la segmentación del de Control. Esta tecnología puede sernos de gran utilidad ya  que además de lo anterior es compatible con entornos de Alta Disponibilidad. Dos nodos físicos pueden albergar VDOMs, de tal manera que, si un Firewall cae, el otro podrá dar servicio en los VDOMs alojados en el contrario.

En la imagen que se muestra a continuación se puede ver cómo a partir de un equipo físico se han definido 3 VDOMs. Uno denominado “VDOM IT” donde tendremos nuestro Firewall Virtual encargado del filtrado de las comunicaciones entre todos los segmentos del entorno de “Oficinas”. El puerto “WAN 1”, red de servidores y del 1 al 3, subredes de clientes. Luego, el “VDOM OT”, y de forma homónima, “WAN 2”, servidores SCADA, Historians, etc. y del 4 al 6 los equipos finales como PLCs, Robots, SIS, etc. Finalmente, el “VDOM Root” el que emplearemos para la administración del equipo.

Al igual que ocurre con los Firewalls físicos podremos necesitar permitir cierto tráfico de un entorno a otro. Puesto que los Firewalls virtuales son independientes, es necesario establecer los denominados “VDOM Links”, que no son otra cosa que interfaces virtuales que comunican VDOMs. Cada “VDOM Link” posee su propio direccionamiento punto a punto, debiendo cada extremo ser asociado a uno de los VDOMs. Estas interfaces virtuales son más rápidas que las físicas, aunque dependerá tanto de la CPU como de la carga que ésta tenga fruto de las funcionalidades, perfiles, sesiones, funciones criptográficas, análisis de tráfico, etc.

En la siguiente guía podréis encontrar más información al respecto.

La idea mostrada aquí es que, si necesitamos aislar y segmentar ambos entornos, no tenemos por qué hacerlo necesariamente con equipos físicos como muestran muchos modelos y recomendaciones. No tiene por qué ser así. De igual manera que lo hacemos de forma lógica en switches con la definición de VLANs, lo podemos hacer con los Firewall, si éstos lo soportan; obviamente. Haciendo uso de esta capacidad podremos no sólo cumplir con nuestras necesidades y estrategias sino también, optimizar recursos hardware, reducir el número de equipos físicos, minimizar el espacio en nuestras instalaciones, escalabilidad, etc. Tal vez requiera de una planificación mayor, no sólo en cuanto a configuración en sí sino la administración futura.

Nuevamente las tecnologías nos ofrecen alternativas y soluciones más apropiadas, sólo tenemos que ver cuál se ajusta mejor a las necesidades de nuestros clientes para reducir los riesgos y garantizar la disponibilidad de las instalaciones. Eso si, previo estudio y planificación.

Un saludo, nos vemos en la próxima.

Edorta

 

¿Por qué es necesario NGFW en entornos ICS/SCADA?

Como he hablado en otras ocasiones el primer paso para securizar un entorno de control y automatización es separarlo del de IT mediante un dispositivo de seguridad perimetral. Luego, ya dentro del propio entorno OT, es necesario segmentar la misma en áreas más pequeñas con el fin de que si se produce un anomalía o incidente, éste no se propague al resto y ponga en peligro la disponibilidad total, o parcial, de las instalaciones.

separacion_01

El dispositivo estrella para este tipo de tareas es el firewall. Los cortafuegos tradicionales (L2, L3, L4) han quedado ineficaces ante el creciente y diversificado aumento de amenazas, vulnerabilidades y vectores de ataque. Surgen entonces los NGFW (Next Generation Firewall) que además de las características típicas incorporan otras como motores Antivirus, IDS/IPS, Control de Aplicación, Filtrado Web y DPI (Deep Packet Inspection).

A continuación, indico algunos enlaces de artículos relacionados a este respecto.

  1. Defensa en Profundidad, breve repaso.
  2. Defensa en profundidad OT
  3. Separar y Segmentar, primeros pasos para reducir riesgos…
  4. Virtual Patching en funcionamiento (Parte I)
  5. Virtual Patching en funcionamiento (Parte II)
  6. Virtual Patching en funcionamiento (Parte III)

En la entrada de hoy vamos a ver la necesidad de este tipo de dispositivos NGFW en detrimento de los tradicionales. Para ello me voy a basar en el software utilizado en la entrada “Simulador de protocolo ModBus”, creado el siguiente entorno.

arquitectura

La idea es representar dos supuestos entornos; uno IT (de Oficinas) y uno OT (de automatización). En este último he simulado un equipo cliente ModBus el cual será el “objetivo” de las acciones a realizar. Por otro lado, en parte de IT/OT, situaré el posible “atacante” (Kali Linux) junto con un equipo legítimo (Maestro Modbus). He decidido especificar IT/OT para cubrir dos supuestos. Cuando me refiero a “IT”, represento el concepto de “Separación” y con “OT” el de “Segmentación”. De esta manera cubrimos las posibles acciones llevadas a cabo desde la propia red de Control como desde otra ajena a éstas como puede ser la de “Oficinas” o Internet si consideramos equipos accesibles remotamente. En cualquiera de los casos, ambos están separados por un equipo Fortinet FortiWifi60D con una versión de FortiOS 5.2.8. Habrá que piense que esta versión ya tiene un tiempo y que las hay más nuevas. Tiene razón, pero hay una explicación. Las actualizaciones en equipos industriales, se producen en intervalos de tiempo superiores si lo comparamos contra entornos IT con lo que es muy común encontrarse no con las últimas. Además de esto, no debemos olvidar el uso de equipamiento acorde a la actividad que vamos a realizar. Lo correcto sería emplear, por ejemplo uno de la serie Fortinet Fortigate Rugged.

Así pues, el esclavo queda configurado como sigue:

esclavo_01

Por otro lado, el firewall permite el tráfico según la siguiente regla.

config_forti_01

Como se puede apreciar sólo se deja pasar el protocolo “ModBus” (TCP-502), entre la red 172.30.123.0/24 y el destino “Esclavo_MODBUS” (172.20.123.200). Lo suyo sería dejar pasar sólo aquellos equipos que lo necesiten. Aparte de ser un entorno de laboratorio, en la vida real, es probable que alguien se pueda configurar manualmente la IP de un equipo legítimo, la infección de uno de ellos o las conexiones vengan de redes configuradas con DHCP con lo que se abra a todo su rango. No es descabellado. Lo dicho, cobra especial importancia la correcta configuración de las reglas del firewall.

Según lo anterior el resultado de una conexión legítima al esclavo sería la siguiente:log_forti_01Y el Master recogería estos resultados:

master_01

Considerando las características de ModBus que no posee ninguna medida de seguridad nativa, un atacante podría con alguna herramienta poder leer o escribir datos. Para este caso he utilizado mbtget, la cual podéis encontrar aquí.

Así pues leeremos los siguientes registros:

kali_01O escribir, por ejemplo, “12345” en la primera entrada.

kali_02

Y… oh sorpresa! el usuario legítimo lo vería….

master_02

Con ello vemos que los Firewall tradicionales no son del todo efectivos para este tipo de entornos y protocolos. Vamos a proceder a configurar el “Perfil de Seguridad”, término que emplea Fortinet para definir las características de seguridad adicionales y que son definidos en cada una de las reglas. Estos perfiles pueden ser ajustados según necesidades. En el siguiente ejemplo optamos por activar en “Modo Monitor” de la característica “IPS” con lo que operaría como un IDS (Intrusion Detection System) en lugar de un IPS (Intrusion Prevention System) :

config_forti_02

Aún podríamos llevar a cabo una escritura con el valor “55555” en el esclavo desde el equipo atacante, ya que sólo detectaríamos tal acción:

kali_03

Generaríamos el siguiente log en el Firewall.

kali_07

Y también, hacer una lectura:

kali_04

Como vemos en los logs del Firewall, en la columna “Action” vemos como figura “detected”. El tráfico se ha detectado pero no se ha cortado.

log_forti_04

Sin embargo, si cambiamos el perfil IPS y esta vez lo reconfiguramos como “Block”

ips_02

config_forti_03

El atacante se encontrará que no podrá llevar a cabo la escritura. Por ejemplo modificando el primer campo con el valor “8888”. Se produce un “timeout”.

kali_05

Y el correspondiente log en el Firewall:

log_forti_05

Aquí ya vemos cómo en la columna “Action” ya consta como “Dropped”.

Idem con la lectura:

kali_06

log_forti_06

Mientras tanto el cliente legítimo sigue funcionando con total normalidad.

master_03

En el día de hoy hemos comprobado la funcionalidad IDS/IPS para este equipo del fabricante Fortinet, sin embargo, no es la única que debemos aplicar. Hay que apoyarse en otras como Antivirus, Control de Aplicación y filtrado Web. Esto debe mantenerse bajo cualquier circunstancia, también cuando estos firewalls se empleen para establecer VPN y acceder a éstos de forma remota.

Adicionalmente, conviene que los logs generados, se consoliden en un servidor para poder ser almacenados y analizados bien para llevar a cabo una monitorización del estado de la seguridad por medio de un SIEM, como para realizar labores de forénsica en caso de ser necesario. Fortinet cuenta con algunos productos específicos como FortiAnalyzer o FortiManager, que aunque sea este último una herramienta de gestión incorpora algunas funcionalidades de gestión de logs. Este tipo de soluciones deben de contemplarse desde el inicio de los proyectos. Hemos de tener una visión más allá del despliegue inicial ya que todo lo que instalemos luego hay que administrarlo por lo que a la hora de elegir tal o cual producto, esto también ha de considerarse.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .