Identificando tráfico con cortafuegos, Parte I

Comentábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de realizar un análisis del tráfico de red para identificar las comunicaciones existentes dentro de nuestro entorno OT. Con los activos y servicios localizados, podremos empezar a configurar las reglas necesarias en nuestros cortafuegos dentro de las acciones de “Separación y Segmentación” necesarias para limitar accesos o propagación de acciones que puedan afectar a la operatividad de nuestras instalaciones.

Sin embrago, debemos ir un paso más allá y conocer aquellos protocolos y comandos que permiten interactuar entre sistemas de control. Sin embargo, uno de los problemas más comunes es el alto grado de desconocimiento ya que, muy a menudo, nos enfrentamos a redes conmutadas o enrutadas donde todo comunica sin filtro alguno.

Esto cobra especial importancia, a nivel de célula de automatización, instalación o conjunto de equipos en planta; base de la actividad de las empresas. Sistemas superiores deben comunicar con controladores y éstos a su vez con elementos de periferia, como sensores, actuadores o cabeceras dentro de arquitecturas de periferia distribuida. Esto da lugar a en muchas ocasiones a que PLCs dispongan de dobles en laces de red. Por ejemplo, un módulo de comunicaciones para su integración “aguas arriba” con la red corporativa y otra “aguas abajo” de la propia CPU para entradas, salidas y módulos de conexión de dentro arquitecturas descentralizadas.

Como bien sabemos las latencias en este tipo de entornos son un aspecto crítico ya que las comunicaciones deben de hacer frente al carácter determinístico de éstas. Por tanto, debamos donde debamos identificar el tráfico no podemos introducir tiempos adicionales que puedan interferir en la operación.

Port Mirroring Siemens X208

Por tanto, surgen pues dos necesidades, documentar nuestras comunicaciones independientemente del segmento; y el despliegue de nuevos elementos de seguridad perimetral para separar y segmentar nuestras redes IT y OT.

Gracias a las funcionalidades de los productos de algunos fabricantes podremos apoyarnos en alguna de ellas para hacer esto último.

Por ejemplo, el fabricante Fortinet nos permite la configuración de alguna de las interfaces físicas en un modo denominado “One-arm-Sniffer”. Este modo, a diferencia de las habituales para permitir o denegar el flujo de comunicaciones, permitirá analizar mediante los motores IPS y Control de Aplicación el tráfico enviado desde un puerto espejo un dispositivo TAP. En caso de coincidencia con alguna de las firmas, se genera el correspondiente log y registro, descartándose el tráfico recibido.

De esta manera podremos utilizar nuestro equipo Fortinet Fortigate como un IDS o detectar qué tráfico a nivel de capa 7 que como hablamos en la entrada “Más que IPs y Puertos para proteger entornos industriales”. 

En primer lugar, deberemos configurar la interfaz en el modo anteriormente indicado, a partir de lo cual nos aparecerán las distintas opciones como los motores de filtrado contra los cuales queremos analizar el tráfico recibido. Como vemos en la imagen siguiente en nuestro caso hemos elegido la interfaz número 4.Fortigate One Arm Sniffer

Edit y Sniffer Profile Fortinet Fortigate One Arm Sniffer

Luego dentro de “Edit Sniffer Profile” podremos configurar cada uno de los motores y por tanto y ajustarlo en función de nuestras necesidades. En nuestro caso, puesto que planteamos el escenario de identificación de las comunicaciones y los protocolos industriales nos centraremos en éstos.

Application Control Industrial Category

Para la presente entrada he empleado la herramienta TCPreplay para la reproducción de capturas PCAP.

De esta manera, el Firewall nos ha identificado no sólo un buen conjunto de ellos sino además los comandos que a través de ellos se envían. Como podemos ver en la imagen siguiente dentro de Modbus encontramos “Modbus_Function.Reserved.Code” y “Modbus_Read_Coils” entre otras como “S7.Protocol_CPU-Function.Read.SZL” o “DNP3_Response”.

Logs One Arm Sniffer

Dependiendo de la arquitectura que tenga en nuestras instalaciones de planta las opciones podrán ser diversas, aparte de dónde radique el interés o necesidad por identificar ese tráfico. Es decir, podremos desplegar su uso a nivel de célula para conocer cómo un HMI, un PLC o periferia intercambian información; o bien, cómo desde servidores SCADA o MES envían o reciben consultas sobre equipos de planta para labores de control de producción, monitorización, telemetría entre otras.

En cualquiera de los casos, la idea es explotar otra funcionalidad de los cortafuegos que vayamos a desplegar y en la que nos podremos apoyar para la identificación de comunicaciones. Quizás no tengamos herramientas como “Nozomi SCADAGuardian” pero alternativas, las tenemos.

No obstante Fortinet no es el único. Próximamente presentaremos una funcionalidad similar, pero de otro fabricante.

¡Un saludo, nos vemos en la próxima!

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 .