“DoS Policy” más allá del filtrado tradicional

Como hemos comentado en otras ocasiones la separación y segmentación de los entornos IT y OT es la primera medida técnica que debemos tomar. Es necesario definir los perímetros y qué comunicaciones deben permitirse entre uno y otro lado. Para conseguirlo, empleamos Cortafuegos aunque con características adicionales que han dado lugar a los conocidos NGFW. Sin embargo, también podemos contar con otras adicionales, en este caso, para evitar denegaciones de servicio, DoS.

La primera acción que debemos hacer es identificar el tráfico. Definir qué comunicaciones existen en nuestro entorno de control y automatización. Luego, permitirlas en función del criterio que más se ajuste ya sea por IPs, interfaces, servicios, subredes, aplicaciones, protocolos o cualquier otro. Sin embargo, una vez hecho esto y teniendo que claro “qué si y qué no”, también es importante identificar posibles anomalías dentro del mismo pudiendo afectar al funcionamiento del, o los equipos, destino.

Una de las acciones con las que podríamos afectar a las comunicaciones de este ámbito es introduciendo tráfico adicional. Sea este Broadcast, Multicast o Unicast los efectos podrán ser unos u otros ya que dependerá si la electrónica de red lo replica por todos los puertos o sólo por aquél que está dirigido al destinatario.

Si nos referimos a los equipos de control, sabemos que éstos tienen un ciclo de vida mayor con lo que es muy común encontrarnos con equipos antiguos con una capacidad para gestionar comunicaciones mucho más limitada que los equipos actuales. Ante un exceso de tráfico, aunque esté dirigido a un puerto de destino permitido, éstos podrían dejar de responder perdiendo así visibilidad y control.

Hay que tener presente que una denegación de servicio puede no venir exclusivamente de medidas claramente intencionadas. También puede hacerse por un error o mala parametrización de sistemas. Un caso lo podríamos encontrar en los escáneres de vulnerabilidades. Si no los configuramos correctamente y no los ejecutamos acorde a los equipos finales podríamos llegar a comprobar vulnerabilidades de sistemas operativos Windows, Linux, etc. sobre autómatas o controladores que, lógicamente, no los empleen o podrían no hacerlo. Aparte de que los resultados no tendrían sentido, podría desembocar en posibles bloqueos en módulos de comunicaciones, tiempos de respuesta tardíos, entre otros.

Para emular una situación de esta índole he elaborado una Prueba de Concepto empleando el simulador Snap7 y equipos virtuales. No obstante, la prueba fue realizada sobre dos autómatas Siemens S7-400 y S7-300 y los resultados fueron la pérdida de visibilidad desde el servidor que los gestionaba. Los equipos no eran capaces de manipular tanto tráfico. Por supuesto, en un entorno de laboratorio.

La misma sigue el siguiente esquema:

Desde un equipo con una distribución Kali Linux realizamos una inundación de tráfico por medio de la herramienta hping3, efectuando peticiones TCP SYN contra el puerto TCP 102, que es el empleado por el fabricante Siemens. Dicho equipo tendrá una IP 192.168.100.20, mientras que el PLC virtualizado 192.168.20.10.

root@kali:~# hping3 –flood -p 102 -S 192.168.20.10

Antes de realizar dicha operación podremos comprobar que el consumo de CPU como de memoria es bajo dada la ausencia de sesiones.

Sin embargo, una vez comenzado el envío de paquetes el consumo de recursos va en aumento:

Si en ese momento decidiésemos conectarnos a dicho PLC simulando un servidor, HMI, etc. veríamos que no sería posible y cómo la propia herramienta muestra un mensaje en la parte inferior de la captura “ISO: An error occurred during…”

En este sentido fabricantes como Fortinet introducen una funcionalidad denominada “IPv4 DoS Policy” que nos va a permitir atajar que, algo o alguien, de una manera intencionada, o no, pueda generar un exceso de tráfico que desemboque en una pérdida de visibilidad o control sobre equipos finales.

En la imagen siguiente podemos ver los distintos parámetros que podemos definir y parametrizar según sea nuestra necesidad.

 

Deberemos indicar la interfaz de entrada por dónde esperaremos el tráfico en cuestión, ya sea física o lógica; direcciones IP de origen y destino y servicios. A continuación, hemos de identificar las características a nivel de capa 3 y/o 4 que queremos habilitar y los respectivos umbrales de cada uno de ellos. Este es un trabajo que hemos realizar con cautela ya que nos obliga a tener una estimación acerca de los valores tolerables y qué se escapa de un normal comportamiento. No tenemos porqué habilitar todas las opciones, sino aquellas que consideremos que nos pueden ser de utilidad o tengan sentido dependiendo de la ubicación y exposición del cortafuegos. Finalmente, una de las opciones que sí resulta conveniente habilitar es la opción de registro ya que nos va a permitir disponer de información al respecto, como se puede ver en la imagen siguiente.

Cuando hablamos de cortafuegos, generalmente nos viene a la mente la opción de permitir o denegar tráfico y sobre él aplicarle controles adicionales como Antivirus, IDS/IPS, entre otros. Es cierto, ese su principal cometido. Sin embargo, podemos encontrar funcionalidades que, sin penalizar el rendimiento, pueda ayudar a identificar anomalías de aquél que estamos dejando pasar.

La primera tarea es decidir qué debemos autorizar y qué no. Esto nos va obligar a conocer qué comunicaciones establecen nuestros equipos de control y sistemas asociados. A menudo partiremos de un desconocimiento total ya que nos enfrentaremos a entornos conmutados o enrutados donde no se ha documentado dicha información y obviamente no existen elementos de seguridad perimetral. Si queremos filtrarlas deberemos identificarlas, y entender el por qué deben producirse, o no. No todo lo que veamos debe ser permitido. Probablemente ni tan siquiera los propios usuarios de las instalaciones lo sepan. Es una labor que puede complicarse según sean los escenarios, pero que en cualquier caso, ha de realizarse.

Un buen recurso pueden ser los “Puerto Espejo” o dispositivos como el Siemens TAP  104, que nos ayudarán a replicar tráfico de red y que pueda ser colectado y analizado a posteriori.

Hasta aquí la entrada de hoy.

¡Un saludo nos vemos en la próxima!

BACnet, fundamentos de un protocolo para la gestión de edificios

A menudo nos centramos en materia de Ciberseguridad haciendo referencia a aquellos equipos y sistemas que intervienen en los procesos productivos o entornos de control y automatización. Sin embargo, las fábricas no sólo son PLCs, HMIs, Workstations, sensores u actuadores. Dependiendo de la actividad y el tamaño, cuentan con otros elementos que también contribuyen a que se garantice la disponibilidad de la que tanto hemos hablado. Me refiero a sistemas de refrigeración, extinción de fuegos, climatización, montacargas, etc. los cuales pueden ser gestionados por medio del protocolo BACnet.

Habitualmente los vemos referenciados en los denominados “Edificios Inteligentes”, sin embargo, su uso ni es exclusivo de ellos ni es algo relativamente nuevo. La gestión de edificios viene dada por las siglas BMS, Building Management System debiéndose distinguir, entre edificios de viviendas o edificios industriales. En general, los sistemas BMS integran un conjunto de subsistemas encargados de los sistemas de control de iluminación, antincendios, alarmas, elevadores, ventilación, temperatura, etc. Si bien muchos de ellos son comunes a ambos entornos no podemos decir que son similares ya que las aplicaciones y alcance son distintos.

Ahora bien, al igual que PLCs, HMIs, y demás dispositivos, estos sistemas han de comunicarse entre sí para su propio funcionamiento y gestión. En este sentido, uno de los protocolos empleados es BACnet, Buiding Automation Control Network. Desarrollado en 1987, ha sido un ANSI e ISO estándar desde 1995 y 2003, respectivamente. Aunque su mantenimiento es continuo, el propósito de BACnet es proporcionar interoperabilidad entre sistemas y dispositivos en aplicaciones de control y automatización de edificios, mediante un protocolo de comunicaciones estándar.

Al igual que muchos otros, cada dispositivo BACNet es una combinación de hardware y software, encontrándolo como norma general en forma de controlador, pasarela o interfaz de usuario. Cada uno de ellos dispone de un identificador o número de instancia único que lo identifica y diferencia de los existentes en la red aparte de otros con información relativa a las entradas y salidas que  monitoriza y controla.

Dentro de BACnet podemos encontrar 3 conceptos claramente diferenciados, Objetos, Propiedades y Servicios.

Toda la información contenida dentro de un dispositivo BACnet es ordenada como objetos, el cual le convierte en un protocolo orientado justamente a esto mismo, a objetos. Cada Objeto” representa un componente del propio dispositivo o un conjunto de información que puede ser solicitada por otro a través de medios como Ethernet, IP, RS-485, etc.

El protocolo define un total de 54 tipos de objetos para los usos más comunes cubriendo así la mayoría de las necesidades. Sin embargo, da la posibilidad de crear otros nuevos para no interferir sobre aquellos usos más concretos o aplicaciones propietarias.

La imagen muestra la arquitectura e interoperabilidad entre los distintos elementos que definen el funcionamiento del protocolo para la gestión y automatización de edificios BACnet.

Arquitectura e inteoperabilidad en BACnet

 

Cada objeto tiene un identificador de 32 bits el cual contiene un código para el tipo de objeto y el número de instancia de dicho objeto.

Con independencia del propósito o función, cada “Objeto” posee un conjunto de “Propiedades”. Cada una de ellas contendrá dos partes, un identificador y un valor. El identificador son números que la definen de forma única en el ámbito del tipo de objeto; y el valor, la magnitud del mismo. Luego, dicha información podrá ser tanto de lectura como de y escritura.

Si unificamos ambos conceptos, podemos decir que cada “Objeto” incluyen “Propiedades” que determinan sus capacidades, operación e información asociada.

Como hemos dicho anteriormente los dispositivos interactúan entre sí para su operación. Cuando un equipo se comunica con otro para llevar a cabo una determinada acción, lo hace a través de los denominados “Servicios”. Los servicios son agrupados en 5 categorías según su funcionalidad:

  1. Object access (lectura, escritura, creación, borrado)
  2. Device management (descubrimiento, sincronización horaria, inicialización, copia de respaldo y restauración)
  3. Alarm and event (alarmas y cambios de estado)
  4. File transfer (Tendencia de datos y cambio de programa)
  5. Virtual terminal (interfaz hombre-máquina por medio de menús o similar)

Cada dispositivo envía las peticiones empleando mensajes convenientemente estructurados tanto en la pregunta como en la respuesta. Los mensajes son codificados en un stream numérico definiendo las funciones que deben llevarse a cabo.

Para que dichos mensajes puedan enviarse y recibirse, se establecen varios medios de transporte, los cuales se citan a continuación:

  1. BACnet/IP
  2. BACnet ISO 802-3 (Ethernet)
  3. BACnet MS/TP (Master-Slave/Token Passing)
  4. BACnet over ARCNET
  5. BACnet Point-to-Point (EIA-232 and Telephone)
  6. BACnet over LonTalk Foreign Frames
  7. BACnet over ZigBee

Cada uno de ellos son una combinación de capas Físicas y Enlace de Datos. Sin embargo, el mensaje BACnet es independiente del medio empleado pudiendo existir a su vez pasarelas referenciadas como “Routers” que puedan combinar cada uno de los medios. No obstante, serán los dos primeros los que reclaman más nuestra atención ya que proporcionan integración con redes tradicionales.

BACnet/IP proporciona conectividad a nivel de capa 3 pudiendo ser los equipos accesibles desde distintas redes IP. Cuando este medio es empleado con múltiples subredes, es necesario el uso de una funcionalidad especial denominada BBMD, Broadcast (Management Devices), equipo empleado para administrar los mensajes broadcast entre subredes. Éste recoge dichos mensajes y los redistribuye a otro BBMD ubicado en otra red mediante mensajes unicast.

Mientras que, BACnet ISO 802.3, similar al anterior, pero limitando las comunicaciones a nivel de capa 2.

Ahora bien, teniendo en cuenta los conceptos acerca de dispositivos, objetos propiedades, servicios y la forma en la que transmitir los mensajes, BACnet proporciona capacidades funcionales las cuales son denominadas como “Interoperability Areas”.  Existen un total de 5:

  1. Data Sharing, intercambio de información entre dispositivos. Lo mensajes pueden ser priorizados en función de su propiedad, además de ser de lectura o lectura/escritura.
  2. Trending, visualización de los valores recogidos y graficados para determinar tendencias.
  3. Scheduling, programación de tareas a ejecutar en momentos o intervalos concretos.
  4. Alarm & Event Management, intercambio de información relativo a alarmas o eventos.
  5. Device & Network Management, permite el descubrimiento de dispositivos, objetos dentro de ellos, establecimiento y reconexión en caso de caída de comunicación, sincronización horaria y reinicio.

Estas áreas están definidas dentro de BACnet como BIBB, “BACnet Interoperability Blocks”.

Puesto que BACnet es un estándar, los distintos fabricantes de equipos deben garantizar que sus productos soportan ciertos requisitos para poder operar unos con otros. Para ello, deben cumplir con lo definido en lo que se denomina “Protocol and Implementation and Conformance Statement”, PICS; una ficha técnica con distinta información y entre ella, los distintos BIBB soportados para que puedan ser comparados y garantizar su funcionamiento.

Es importarte resaltar que los mensajes pueden ser dotados de una “Prioridad” dependiendo el tipo de mensaje y la información que transporta. Se definen un total de 16, siendo las dos primeras relativas a cuestiones de “Safety”, “Manual Life-Safety” y “Automatic Life-Safety”.

Hasta aquí la presentación de los conceptos básicos de BACnet. Un protocolo con unas características específicas para entornos concretos. Como decía, es importante remarcar que su uso puede no estar necesariamente asociado a edificios de viviendas sino también a entornos industriales. Éstos también disponen de sistemas de refrigeración, sensores de humos, montacargas, etc. dependiendo, claro está, del tamaño y la actividad. Podrán almacenar productos químicos que deban ser almacenados bajo unas condiciones de temperatura determinada; entornos donde la calidad del aire deba ser única debiendo accionarse los sistemas de ventilación bajo unas circunstancias concretas; controlar la iluminación de un pabellón en distintas franjas horarias, entre otras muchas. ¿Alguien se imagina los efectos que pudiera tener si algo o alguien, pudiese alterar a las dos de la madrugada la iluminación de parte o toda una nave de producción y los operarios no pudiesen trabajar? Y peor aún, cómo o porqué se genera esa situación si no se puede acotar la causa que lo origina. No estamos hablando de un hecho con unas consecuencias graves, pero sí con impacto sobre la actividad de la propia empresa.

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

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

 

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:

Separacion_01

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.

Escenario_01

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.

Escenario_02

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:

Metaesploit 01

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

Metaesploit 02

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

Metaesploit 03

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

Metaesploit 04

La ejecutamos y comprometemos el objetivo.

Metaesploit 05

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.

Metaesploit 06

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]

Metaesploit 07

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:

Metaesploit 08

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

Metaesploit 09

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

Metaesploit 10

Metaesploit 11

Y los logs generados indicarían el bloqueo:

Metaesploit 12

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!!

Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!