¿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.

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.

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:

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

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:Y el Master recogería estos resultados:

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:

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

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

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) :

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:

Generaríamos el siguiente log en el Firewall.

Y también, hacer una lectura:

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.

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

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”.

Y el correspondiente log en el Firewall:

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

Idem con la lectura:

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

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 .

Separar y Segmentar, primeros pasos para reducir riesgos…

Hace unos meses hablaba del concepto de Defensa en Profundidad en entornos industriales y de las medidas que ello conlleva para reducir el riesgo de sufrir algún incidente de seguridad. Como podemos comprobar no se trata de tomar una única medida, sino que es la suma de un conjunto de ellas aplicadas en distintas capas.

Una que resulta fundamental y deberemos implementar en primera instancia, es Separar y Segmentar nuestras redes. Veremos de qué se trata.

Cuando hablamos de separar nuestras redes, hablamos de establecer una frontera entre la red “Común” donde ubicamos las redes IT tradicionales como un entorno de “Oficinas”; y nuestra de red de automatización o control, llamémosle de “Producción”. La forma cómo lo hacemos es, introduciendo un elemento de seguridad perimetral como un Cortafuegos que permita sólo aquellas comunicaciones que sean estrictamente necesarias. Sin embargo deberemos tener presente aspectos clave en estos tipos de equipos, como que sean Cortafuegos de Próxima generación (NGFW, Next Generation Firewall) con funcionalidades IPS/IDS, Antivirus y Control de Aplicaciones; y que soporten protocolos de ámbito industrial tales como Profinet, Modbus-TCP, OPC, DNP3, ICCP, etc. Es decir no nos vale que sólo hagan DPI (Deep Packet Inspection) sobre FTP, DNS, HTTP, (que también son necesarios) si lo que nos interesa es detectar las amenazas propias de sistemas de control, carentes algunos de ellos de medidas de seguridad inherentes. Ahora bien, no nos podemos olvidad que estos dispositivos introducen latencias y por tanto, dependiendo del ámbito de automatización, estaremos introduciendo retardos, que pueden ser inasumibles.

Dicho lo cual, y por representarlo de forma simple y gráfica, nos quedaría de la siguiente manera:

Como podemos comprobar estamos hablando de una separación física de ambos entornos. Cada una pose uno o varios enlaces a través del dispositivo de Seguridad Perimetral, y cuyo tráfico será sometido a las reglas que configuremos en él. Obviamente estos equipos, dependiendo de fabricante y modelo, podrán tener unas u otras capacidades.

Al mismo tiempo lo idóneo es que la red de control posea todos los recursos necesarios (servidores de almacenamiento, DNS, NTP, etc.) para poder operar de forma totalmente independiente de la red de “Oficinas” pero lamentablemente esto no siempre es así.

Las redes físicas completamente separadas constituyen la mejor de las opciones, ya que pueden utilizarse para conseguir una separación lógica y física total. Ambos entornos se basan en su propia topología y al no tener componentes de red compartidos tales como switches o routers, todas las comunicaciones de entrada y salida entre la red “Común”, y las redes de “Automatización”, se controlan mediante un punto de seguridad como el NGFW definido anteriormente.

A nivel de infraestructura esta solución también aporta la ventaja que cada cual puede desarrollar su actividad de manera diferente. Por tanto, ante cualquier cambio o migración en los entornos, sólo es necesario modificar el elemento de acoplamiento al Firewall para seguir garantizando la comunicación. Esto es especialmente importante considerando los ciclos de vida del equipamiento en entornos OT, mucho mayor en comparación con los de IT.

No nos debemos olvidar que la premisa de los entornos industriales y las Infraestructuras Críticas es garantizar la disponibilidad de las instalaciones, por tanto en caso de producirse algún fallo en la red “IT”, éste no afectará al entorno “OT”.

Separados ambos entornos, el siguiente paso será aplicar el concepto de Segmentación. La  Segmentación consiste en subdividir la red, o redes, del entorno de automatización en lo que denominamos “Zonas de Seguridad”, y la aplicación de un “Punto de aplicación de seguridad”.

Definiremos como “Zona de Seguridad” al conjunto de dispositivos, aplicaciones, servicios y otros activos agrupados según su ubicación, funcionalidad o condición, tanto desde un punto de vista físico como lógico. Un “Punto de aplicación de seguridad” es un elemento o dispositivo, normalmente un Firewall, cuya  misión es la de filtrar todas las comunicaciones hacia, desde o entre, las distintas “Zonas de Seguridad”. La idea es sencilla, agrupar y aislar  un conjunto de activos y controlar todos los flujos de comunicaciones entre ellos. Al hacerlo conseguiremos por un lado, reducir el grado de exposición que tendrá una “Zona de Seguridad”, y por otro, en caso de producirse un evento de seguridad (ataque, escaneo, propagación de malware, etc.) quede confinado a su “Zona”. Esto no sólo reforzará nuestra seguridad sino que además aumentará nuestro grado de resiliencia frente a cualquier fallo producido por algún tipo de actividad hostil, ya que, aunque una “Zona” haya quedado aislada o sus comunicaciones bloqueadas, el resto de “Zonas” podrán seguir estando operativas. No estarán al 100% pero al menos podrán seguir funcionando a un rendimiento menor durante equis tiempo.

Una de las preguntas claves es, qué tamaño debe tener una “Zona de Seguridad” y qué dispositivos hay que incluir en cada una de ellas. Cada arquitectura es única,  no sólo por el tipo de equipamiento en sí, a veces común pero distinto según fabricante, modelo y prestaciones, sino cómo cada sistema está desplegado dentro de su propio entorno y cómo se comunica con otros para formar una única, completa e integrada red de control industrial. No existe una respuesta única de cómo se debe diseñar una arquitectura concreta ya que son muchos son los factores a tener en cuenta propios de cada instalación. Algunos de ellos, que no los únicos, son; tamaño de la empresa, sector, actividad, criticidad de los elementos, capacidad de la electrónica de red, antigüedad de los equipos, vulnerabilidades, perfil de usuarios que acceden a ellos, etc.

Nuevamente,  un aspecto clave  son los tiempos. No nos podemos olvidar que en los entornos industriales ha de garantizarse, en primer lugar la disponibilidad de las instalaciones. Por ello en la decisión qué y cuántos componentes se pueden combinar dentro de un área de seguridad deberemos estudiar cuánta cantidad de tiempo es asumible y cuánta no, en el supuesto que algún suceso deje inoperativos, total o parcialmente, nuestros equipos.

Otro de los elementos que deberemos contemplar es la creación de una DMZ. Sí, aquí, en los entornos industriales también debe haberlas. El concepto de esta DMZ es muy similar al que se ha hecho en los entornos IT tradicionales. En esta Zona ubicaremos aquellos recursos compartidos que pudiera haber entre ambas zonas como servidores Antivirus; gestor de parches; otros específicos de la red de automatización como Bases de Datos, ficheros, NTP, DNS, pasarelas VPN, Escritorio Remoto, etc.

Como vemos poco a poco a medida que nos adentramos van apareciendo más componentes y más aspectos a tener en cuenta. Esto es sólo la “punta del Iceberg”. Seguramente muchos de los que lean el presente verán que faltan muchas cosas, ¡VAYA QUE SI FALTAN! Esto es sólo un esquema genérico, luego hay que profundizar sobre cada uno de los aspectos. Por ejemplo, deberíamos hablar de las ACLs que nos servirán de apoyo para discriminar cierto tipo de tráfico a nivel de la electrónica de red; cómo configurar los equipos en Alta Disponibilidad; ¿enrutamiento estático o dinámico?; diseño de VLANs; cifrado de comunicaciones; y un largo etcétera.

Resumiendo, mucho se podría hablar y escribir sobre cómo diseñar, o ajustar, la arquitectura de red. Podremos establecer parámetros, líneas de trabajo o estrategias genéricas, pero luego cada proyecto es totalmente distinto.

Con esto damos por concluida la entrada de hoy que al igual que las anteriores espero sea de vuestro agrado. Os invito a que dejéis vuestros comentarios.

Un saludo, nos vemos en la próxima.

Virtual Patching en funcionamiento (Parte III)

Bueno, aquí seguimos com el tema del Virtual Patching. Antes de seguir los dejo los enlaces de las 3 entradas anteriores para estar al tanto del tema que nos concierne.

1.- Parches y Virtual Patching

2.- Virtual Patching en funcionamiento (ParteI)

3.- Virtual Patching en funcionamiento (Parte II)

Siguiendo con la última entrada, si no contásemos con el dispositivo Fortigate, un atacante podría haber localizado nuestra vulnerabilidad y lanzar un “exploit” para poder aprovecharse de ella. Esto puede llevarse a cabo con el framework “Metaesploit” destinado a ese fin y con la ayuda de la GUI “Armitage” para un entorno más amigable.

Arrancaríamos la aplicación “Armitage” desde nuestra distribución Kali y seguiríamos los siguientes pasos:

Dar de alta al equipo con su dirección IP que ya la conoceríamos de los pasos anteriores:

Se realiza un escaneo para detectar puertos abiertos y posterior detección del Sistema Operativo:

Ahora se trata de localizar posibles ataques en función de los resultados obtenidos con anterioridad.

A partir de ahí se localiza la vulnerabilidad descubierta con el escáner “Nessus”.

La ejecutamos y comprometemos el objetivo.

Y una vez hecho esto, ya tendríamos nuestro equipo bajo control. Como vemos en la figura siguiente el icono del XP ha cambiado tornándose de color rojo y unos rayos.

Con el equipo comprometido, podríamos hacernos con el control del Windows XP mediante un visor VNC aún sin tenerlo instalado. El exploit genera un proceso en nuestro equipo Kali, al cual nos conectamos ejecutando el comando:

#vncviewer 127.0.0.1:[identificador]

Esto resulta especialmente grave ya que la tener acceso a la interfaz gráfica podríamos realizar alguna serie de cambios y modificaciones sobre las aplicaciones que estarían corriendo en esos instantes.

También, si lo deseásemos, podríamos hacernos con una consola remota tal y como aparece en la parte inferior y otras muchas acciones:

Sin embargo, si configurásemos el motor IDS/IPS para que bloquee en lugar de monitorizar. Esto es:

Y lanzamos de nuevo el ataque veríamos que éste no tiene éxito:

Y los logs generados indicarían el bloqueo:

Así pues queda claro la importancia de no sólo parchear nuestros equipos, sino además en el supuesto de que por distintas razones no podríamos llevarlo a cabo, la obligación de tener que tomar las medidas necesarias.

En entornos industriales podemos ver el esta situación de una forma más habitual que en entornos IT tradicionales ya que por un lado los ciclos de vida de los PCs industriales son mayores y por otro, dada la criticidad de las instalaciones gobernadas por éstos muchas veces no sea aconsejable instalar algún tipo de software tipo “Endpoint” que los bastione con funcionalidades Host IPS, Antivirus y Firewall.

Espero que el ejemplo haya sido de utilidad para tomar conciencia de esta situación y de las medidas que debemos tomar para securizar nuestros equipos.

Así pues nos vemos en la siguiente entrada, no sin antes invitaros a dejar vuestros comentarios. Desde ya muchas gracias.

Un saludo!!