Puerto espejo, un aliado a veces olvidado.

Como hemos hablado en otras ocasiones, poco a poco se va extendiendo el uso de protocolos industriales basados en tecnología Ethernet en lugar de los tradicionales serie. Esto, si bien permite otra manera de interconexión, también abre nuevas posibilidades en la denominada Industria 4.0. Sin embargo, obliga a tomar cierto tipo de medidas en cuanto a Ciberseguridad se refiere ya que los dispositivos y sistemas que intervienen en los procesos de control y automatización no sólo comienzan a estar más expuestos sino que son susceptibles de sufrir los mismos problemas con ciertos agravantes.

No obstante, aunque se trate de comunicaciones Ethernet, los equipos de networking industrial no sólo conservan funcionalidades tradicionales, sino además otras propias de estos entornos como MRP en contraposición a STP, Spanning Tree Protocol.

Una que puede sernos de mucha utilidad, sin menospreciar a otras tantas, es la de “Port Mirroring” o Puerto Espejo. Esto es, la capacidad de un Switch para poder replicar el tráfico que pasa por dos o más puertos y enviarlo por un tercero. Para entender mejor este concepto haré un repaso sobre cómo funciona un switch. Aunque sea algo bastante obvio para Técnicos de Comunicaciones o Administradores, seguramente no lo sea tanto para otros de Mantenimiento o Ingenieros de Procesos.

Esquema_01

Pongamos un ejemplo con dos equipos llamados “HMI” y “PLC”. Para comunicarse el equipo “HMI” con el “PLC” deberá conocer la IP del de “destino” y, al darse cuenta que está dentro de su misma red, deberá obtener entonces la MAC de éste. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “HMI” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cual se pregunta contestará con un ARP Replydiciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “HMI” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la comunicación no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory) en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

Ahora bien, si por distintas razones necesitásemos conocer el tráfico que pasa en entre “HMI” y “PLC”, no podríamos conseguirlo ya que el switch sólo conmuta el tráfico por los puertos involucrados. Aquí es donde aparece el concepto de “Port Mirroring” o “Puerto Espejo”. Mediante esta funcionalidad lo que conseguimos es que el switch haga una copia de dicho tráfico y lo envíe por un tercer puerto. ¿Con qué finalidad? Por ejemplo, si en este último conectamos un analizador de tráfico, podremos estudiar todo aquello que suceda entre “HMI” y “PLC” y detectar posibles anomalías sin interferir entre el flujo de comunicaciones. Obviamente el switch tiene que tener esta capacidad para hacerlo, sino… no hay nada que hacer.

Si bien las tasas de transferencia en entornos OT son menores que en entornos IT, esto no quita que debamos tener presente algunas consideraciones. Por ejemplo, si las comunicaciones son Full-Duplex (enviar y recibir a la vez) y el enlace es de 100 Mbps, el tráfico que puede llegar a recibir un equipo es de 200 Mbps, 100 Mbps para enviar y otros 100 Mbps para recibir. Si el enlace del puerto espejo es también a 100 Mbps el consumo de ancho de banda entre “HMI” y “PLC” no puede ser superior al 50%, ya que estaríamos superando la capacidad del mismo. O bien, que sea de una velocidad inferior, por ejemplo, a 10 Mbps. En esos casos, el switch descartaría paquetes con lo que el tráfico capturado no se correspondería con la realidad. Aparte, claro está, de la carga computacional que supone para la CPU del propio switch la copia de las tramas. A esto hay que sumar otras limitaciones que cada fabricante pueda considerar en sus productos.

Sin duda es un buen recurso, pero como comento, hay que tener en cuenta algunos aspectos técnicos.

A continuación, pondré ejemplos sobre su implementación en equipos. En la siguiente imagen se muestra una captura de la configuración de un switch Mikrotik RouterBoard 260GS, el cual dispone de 5 puertos RJ-45 10/100/1000 + 1 SFP.

config Mikrotik RouterBoard_01

Según cómo está configurado, estaríamos haciendo una copia del tráfico tanto saliente como entrante del puerto 1 que es dónde en teoría habría conectado un PLC y la enviaríamos por el puerto 2 donde conectaríamos un sniffer que lo recogería para un posterior análisis. Un clásico de este tipo de funciones es el archiconocido Wireshark. También podríamos seleccionar sólo uno de los sentidos, o bien el saliente o entrante según sean nuestras necesidades.

Captura Wireshark_01

Lo cierto es que ese dispositivo resulta de mucha utilidad ya que por su pequeño formato puede ser utilizado en tareas sobre equipos finales como supervisión, diagnóstico, troubleshooting, etc. Aparte, al disponer de un módulo SFP podremos conectarlo a enlaces de fibra o par de cobre.

Ya sobre equipos de red tradicionales, podemos poner un ejemplo con switches Cisco. La funcionalidad la recoge este fabricante como puerto SPAN (Switched Port Analyzer). Aquí las posibilidades, como es lógico, son mayores y pasamos a la interfaz de consola. Podéis encontrar más información en este enlace.

Hasta ahora hemos visto switches “tradicionales”, sin embargo otros específicos de entornos OT también poseen esta funcionalidad como los muestra SIEMENS en este enlace y de donde se extraen las siguientes imágenes.

SIEMENS_Port_Mirroring_01

SIEMENS_Port_Mirroring_02

Sin embargo esto no es exclusivo de equipos de networking. Por ejemplo, el fabricante Fortinet la incluye en sus dispositivos. A continuación se muestran capturas sobre un FortiWifi 60D con versión de FortiOS 5.4.5. Como podemos ver la forma de acceder a ella es a través del apartado de “Interfaces”.

Fortigate SPAN_01

En mi caso “HW_SW_01”, y ya en su configuración veremos el campo correspondiente:

Fortigate SPAN_02

Como vemos el criterio es similar, interfaz a monitorizar y a hacia cuál queremos enviar la copia de los paquetes. Haciendo una prueba, he conectado en el puerto “internal1” un servidor Modbus (10.10.10.100) y desde el puerto “internal2” (10.10.10.200) el cliente desde cual hacer las lecturas. Finalmente, un equipo con Wireshark en el puerto “internal3” donde capturar el tráfico.

Wireshark_Modbus_01

Un caso de uso podría ser en un equipo donde se le aplique una estrategia de “Virtual Patching” y necesitemos saber qué es lo que está sucediendo desde, hacia, él. Hace tiempo escribí a este respecto, os dejo los enlaces:

Hasta aquí la entrada de hoy con la que espero hayáis podido descubrir una nueva funcionalidad de vuestros equipos. Puede que escondida, pero seguro de utilidad en un futuro. Las aplicaciones pueden ser varias, espero poder escribir sobre alguna de ellas. Sólo falta tiempo.

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

Edorta

Controlando nuestros Proveedores, Parte II.

Hola de nuevo. Siguiendo con la entrada anterior “Controlando nuestros Proveedores, Parte I” en el día de hoy vamos a ver la manera en cómo trabaja el binomio FortiGate + FortiClient.

Si bien la protección es en tiempo real, al hacer un análisis antivirus vemos la forma en la que detecta malware según la base de firmas del fabricante. Para ver su funcionamiento he dejado en el escritorio un fichero de EICAR.

Escritorio Proveedor_01

No obstante, para que no fuese un típico ejemplo, también tenía una carpeta con el software incluido en el repositorio Pengowin y que desde aquí, dicho sea de paso, recomiendo dicho proyecto.

Aviso de virus_01

Viendo los logs:

Logs de Virus_01

en total fueron 55 detecciones:

Registro de Virus_02

Para terminar la desinfección es posible que se solicite un reinicio del sistema.

Captura_02_Tras Finalizar AV

Como se puede ver, también en el escritorio tenía el simulador del protocolo S7 de SIEMENS, Snap7 del que hablaba en la entrada “Snap7 suite de PLCs y comunicaciones Siemens”. Al ejecutar el cliente para hacer una lectura del supuesto PLC, esto es “clientdemo.exe”, como el protocolo “ICMP” y “S7 Protocol” no están permitidos vemos su bloqueo, al igual que otros relacionados con el sistema operativo.

Aplicaciones Bloqueadas_02

Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.

Cliente SNAP7_01

También disponemos de un “Filtro Web”, funcionalidad que no he utilizado pero también útil si necesitamos tener acceso a una interfaz Web. ¡Ojo! Hablo de equipos locales, no accesos a Internet.

Como decía en el post anterior es compatible con los “Security Profiles” configurables en cada una de las reglas del Firewall, con lo que a nivel de red también podríamos ejercer un control adicional. Configurar los perfiles de qué se puede ejecutar, o no, en un PC puede llegar a ser complejo y laborioso en función de cada proveedor. Con lo que llegado el momento, podríamos llegar a ser más permisivos en este sentido en cuanto a consentir toda la categoría “Industrial” o “Servicios de RED” y denegar “Botnet”, “Game”, “P2P”, etc. y luego apoyarnos en reglas y “Security Profiles” como indicaba en las entradas:

También destacar la visibilidad que podemos tener desde el Fortigate a la hora de monitorizar los FortiClients conectados y de si cumplen, o no, con las políticas establecidas. Para ello deberemos ir a “Monitor – FortiClient Monitor”.

Forticlient Monitor_01

Ya por último comentar que en este caso hemos hecho uso de un Firewall Fortigate para la gestión de los endpoint. Sin embargo, Fortinet dispone de un producto específico para la gestión de este software denominada FortiClientEMS (Enterprise Management Server) con lo que podremos realizar un control centralizado y una gestión más pormenorizada de todos ellos.  Aquí os dejo un video presentación y enlaces con información al respecto.

Integración de Fortigate y FortiClientEMS.

Como hemos visto nuestros proveedores pueden ser no sólo un punto de entrada sino también el origen de un problema mucho mayor. Los habrá que sean estrictos con el uso de sus equipos sin embargo, esto no es razón para pensar que nada malo pueda suceder. Los entornos industriales no son para nada similares a los de Oficina o IT tradicionales. Los ciclos de vida son mayores con lo que la posibilidad de encontrarnos con Sistemas Operativos y Hardware viejo u obsoleto, es bastante común. Con ello, falta de soporte del fabricante y vulnerabilidades incapaces de corregir, y aun existiendo parches, según actividad de la compañía, desarrollos de software propios, o cierre, hacen que muchas veces sea inviable. A esto hay que sumar la existencia de empresas proveedoras de servicios que necesitan conectarse a nuestras instalaciones para llevar a cabo las tareas para las cuales han sido contratadas, y que no hace posible desplegar su software sobre otro equipo de la organización en el que sí tenemos control y conocimiento de su estado.

Con esta entrega hemos visto cómo con los NGFW FortiGate y endpoint FortiClient podemos llevar a cabo un control y permitir qué equipos de terceros puedan conectarse a nuestra red. De esta manera reducimos los riesgos  de que algo, o alguien, pueda comprometer la disponibilidad de nuestras instalaciones. No pretende ser un manual, ni mucho menos, sino una visión sobre de qué manera podemos ejercer dicho control y supervisión.

Obviamente existen en el mercado otros fabricantes, con otras soluciones que de igual manera puedan satisfacer nuestras necesidades, pero resulta interesante ver esta en concreto por su integración junto con el hardware de red. Como hemos visto, desde hace relativamente poco tiempo, los fabricantes de equipos de control y automatización tipo SIEMENS, Phoenix Contact, entre otros, incluyen ya características relacionadas con la Ciberseguridad, cosa con los equipos más antiguos o bien, o no disponen o son débiles. Por tanto, delegar en la electrónica de red y seguridad perimetral aspectos de la seguridad sigue siendo un hecho que durará por mucho tiempo ya que la renovación de PLCs, Robots, o cualquier otro por motivos puramente de seguridad, no es una razón de peso o prioridad.

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

Edorta

 

Controlando nuestros Proveedores, Parte I.

Hace unos días hablaba acerca de la necesidad de gestionar los proveedores externos e incluirlos en nuestras políticas de seguridad, claro está, orientadas a su actividad. Muy particularmente en grandes corporaciones, éstas se ven obligadas adquirir a terceros equipos, productos y servicios especializados para la actividad de la misma. Luego, cara a garantizar una respuesta o asesoramiento, firman contratos de soporte con el fin de obtener ayuda en caso de ser necesario. Como veíamos en la entrada “Proveedores Externos, posible punto de entrada…” ha de establecerse un procedimiento tanto administrativo como técnico que regule cómo han de conectarse y qué requisitos deben reunir sus equipos antes, durante y después de conectarse a nuestra red de control.

A diferencia del post que citaba anteriormente, hoy hablaré sobre cómo podemos controlar técnicamente dichos equipos. Es un ejemplo, obviamente no dará respuesta a todas las necesidades ni a todas las casuísticas que sin duda serán muy particulares dependiendo de tecnologías, industrias, equipos, actividad, o cualquier otro factor.

El objetivo será llevar a cabo un control sobre el PC de un proveedor que necesariamente ha de conectarse, sí o sí, a nuestra red OT para llevar a cabo tareas de soporte o mantenimiento. Estos PC contendrán el software necesario sin embargo, no tendremos ni su control, ni conocimiento alguno del estado de actualización de sistema operativo, aplicaciones; firmas antivirus (si las hubiera); vulnerabilidades; etc. etc. Habrá quien piense que una alternativa pueda ser instalar las herramientas en PCs de la propia organización sobre los que sí tendríamos aquello que ahora nos falta. No le quito razón, sin embargo, la realidad nos muestra una serie de inconvenientes:

  1. Coste de licenciamiento de Software. ¿Nueva instalación, nueva licencia? ¿reasignación de licencias?
  2. Necesidad de probar aplicaciones en PCs de la organización para garantizar pleno funcionamiento.
  3. Dada el ciclo de vida mayor, probabilidad de uso en Sistemas Operativos con distintas versiones.
  4. Desarrollo de herramientas a medida y bajo condiciones concretas, diferentes a los empleados en la organización.

Por tanto, con todo en contra, lo que sí podríamos hacer es obligar a nuestros proveedores a cumplir nuestras normativas y marcarles las vías de cómo hacerlo. De hecho, es algo que las políticas de seguridad deben contemplar. Me refiero a que una vez implementadas todas las herramientas y medidas, todo nueva sistema, instalación o equipo debe cumplir con aquello especificado para el nuevo “ciberseguro” escenario. Para algo lo hemos hecho, ¿no?

Para ello emplearemos la aplicación endpoint FortiClient de Fortinet con el que podremos identificar y remediar equipos vulnerables, o comprometidos, reduciendo así la superficie de ataque. Luego podremos integrarlo en otras soluciones del mismo fabricante, aspecto que no abordaremos en este post.

Para la Prueba de Concepto he creado el siguiente ejemplo:

Como vemos en la figura, un proveedor ha de conectarse a la red Control para llevar a cabo determinadas tareas. Tiene dedicada una VLAN con un direccionamiento 192.168.254.0/24 a la que deberán conectarse todos los equipos de proveedores. Así pues, todas las comunicaciones deberán pasar por el Firewall (NGFW) que bien podría ser el de Separación o de Segmentación dependiendo de cómo tenga definida la arquitectura la organización. Luego, en función de cómo configuremos el mismo, dejaremos pasar el tráfico necesario hacia la red 192.168.0.0/24, esto es, la de Control.

Para ello emplearé la versión 5.4.4 de FortiClient y un equipo FortiGate 61E con FortiOS 5.4.5.

Lo primero que deberemos hacer será definir una subred, VLAN para nuestros proveedores y que el Gateway, por ejemplo, sea el Fortigate.

En ella deberemos habilitar por un lado la detección de Dispositivos y el control de acceso basado en Forticlient. Ni qué decir que desde la red de proveedores no puede existir la posibilidad de acceso a los Firewalls….

El siguiente paso será definir qué Aplicaciones vamos a dejar permitir ejecutar a los proveedores en sus equipos. Para ello deberemos ir a “Security Profiles – Application Control” y definir uno con los parámetros que creamos convenientes. Os dejo dos entradas que os pueden orientar en las que hablaba de esto mismo:

Con ello listo, iremos a “Security Profiles – FortiClient Profiles” y crearemos el que a posteriori será el que se aplicará sobre los endpoints.

Allí deberemos especificar algunos parámetros como: la red sobre la que se aplicará, en nuestro caso la 192.168.254.0/24, “LAB_RED PROVEEDORES”; acción en caso de no cumplimiento, “Block – Warning – Auto-update”; el tipo de dispositivo, “ALL”; Versión mínima del software FortiClient, “5.4.1”; comportamiento del motor Antivirus, “Realtime Protection, Up-to-date signatures”; y por último el perfil de Firewall de Aplicación, el que hemos definido anteriormente, “LAB_APP-CONTROL_S7”.

Aquí quizás puede llevarnos a confusión el concepto de Control de Aplicación, pero que en este caso se aplica de dos maneras distintas. Una cosa es el Control de Aplicación que se  ejecuta sobre las aplicaciones del PC y que lo regula en el endpoint FortiClient; y otro distinto el que podemos aplicar sobre el tráfico de red en cada una de las reglas configuradas y definidas dentro de la columna “Security Profiles”.

Si en estos instantes alguien quisiera acceder a algún recursos de la red no podría ya que no cumple con los requisitos. Si por ejemplo abriésemos un navegador y pretenderíamos navegar aparecería el siguiente mensaje:

La instalación del endpoint es sencilla. Lo único que tendremos que tener en cuenta es realizar una instalación completa, en lugar de sólo la funcionalidad de VPN. Una vez finalizada se comenzará a descargar los distintos componentes.

Si abrimos el cliente veremos una pantalla con los distintos apartados del endpoint.  Si nos fijamos a “Firewall de Aplicación” veremos los “Overrides” autorizados relacionados con el protocolo S7.

Hasta aquí hemos visto la manera en la que configuramos, de forma resumida, todo lo necesario para comenzar a ejercer el control del que hablábamos. Con todo listo, será en la próxima entrada, cuando comprobemos los resultados y por tanto su eficiencia.

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

Edorta

 

Control de Aplicación en entornos ICS/SCADA, Parte II

Hoy vamos a continuar con lo que adelantábamos en la entrada “Control de Aplicación en entornos ICS/SCADA, Parte I” poniendo algunos ejemplos sobre cómo esta funcionalidad en los NGFW puede ayudar a detectar, o prevenir, cierto tipo de actividades.

En ella proponía el siguiente entorno:

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65/24 accesible desde una Workstation, 192.168.0.100/24, destinada a labores propias del entorno. Por otro lado, la red 10.10.10.0/24 donde existe una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFW he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En “Firewall de Segmentación OT-OT” hemos creado el siguiente perfil “Control de Aplicación” para las comunicaciones entre el servidor SCADA  y la red de Control. Como se puede ver, se bloquearán todas las aplicaciones incluidas dentro de la categoría ”Industrial”. Sin embargo, se hará uso de “Application Overrides” para permitir sólo aquellos protocolos y operaciones propias de nuestras instalaciones. Dicho sea de paso, han tenido que ser identificadas con anterioridad. No obstante, y aunque no es necesario indicarlo explícitamente, se impedirá la parada de PLC, algo reservado sólo a nivel local, no por red.

Fortinet define varios controles sobre el tráfico. Estos son Allow, Monitor, Block y Quarantine. Para conocer las diferencias os dejo el enlace en la página Web del fabricante, pincha aquí.

Ahora bien, en “Firewall  Separación IT-OT”, no habrá excepciones de ningún tipo, absolutamente todo se bloquea. Se entiende que no debe existir ningún software que necesite acceder a la red de control y mucho menos que realice operaciones de lectura o escritura sobre variables, bloques de memoria, funciones, etc.

Respecto a las reglas de Firewall, para este laboratorio he sido bastante “laxo”. Puesto que la intención es destacar el uso de esta funcionalidad, he permitido las comunicaciones entre todas las redes y puertos, siendo el “Control de Aplicación” el único que autoriza o deniega el paso de paquetes. Como todos sabemos, no debiera ser así en un entorno real.

Como hemos dicho anteriormente una de las tareas que no pueden llevarse a cabo desde el servidor es ejecutar la orden de paro de los PLCs. Si lo haríamos, esto sería lo que ocurriría.

Como vemos se genera un log donde se refleja la aplicación identificada y la acción tomada.

Pero siguiendo con el esquema, veremos ahora lo que sucede si alguien desde el entorno de oficinas quisiera obtener alguna información. Los ejemplos siguientes se han hecho con una distribución Kali Linux y aplicaciones Plcscan y script S7-info para Nmap. 

El ambas, el resultado sería el siguiente, siendo el de Plcscan el realizado a las 19:23:34 mientas que Nmap a las 19:25:12 en adelante.

Así pues, el resultado por parte del supuesto atacante quedaría:

Como vemos los escaneos no arrojan ninguna información.  En cambio, si aplicásemos el mismo sensor de “Application Control” para las comunicaciones entre el servidor SCADA y el PLC el resultado sería bien distinto:

Como podemos ver, aquí sí se muestra información ya que las las operaciones que realizan ambas aplicaciones concuerdan con los protocolos y operaciones permitidas, al igual que el servidor SCADA. De esta manera, se podrían extraer datos sobre los equipos para luego seguir con fases más avanzadas o dirigir, somo es lógico, el ataque sobre el fabricante en cuestión.

El “Control de Aplicaciones” puede ser de gran utilidad, sino necesario. Obviamente su configuración y parametrización requiere de una labor que puede resultar costosa en tiempo ya que hay que definir claramente el tráfico que atraviesa por nuestra red. No sólo en lo que se refiere a IPs y puertos, sino también a aquellas aplicaciones que generan el tráfico de Operación, Control y Monitorización. No obstante, no debiera ser la única. Para ser más completos, además habría de acompañarlo de otras como IPS y Antivirus, funcionalidades que ya disponemos. Algo que también resultaría interesante según entornos y necesidades es la consolidación de logs en servidores, tanto para su almacenamiento (Syslog Server) como correlación (SIEM).

Ya por último un factor que no podemos olvidar es que todas estas medidas pueden introducir una latencia en las comunicaciones debido a la carga computacional que requiere el análisis en tiempo real. Según fabricantes, dispositivos y modelos puede variar con lo que dependiendo de nuestra arquitectura, comunicaciones (TCP/IP, RT o IRT), sistemas, etc. es algo que debemos tener presente en cualquiera de los casos.

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

Edorta.

Control de Aplicación en entornos ICS/SCADA, Parte I

Hace poco más de dos meses hablaba de la necesidad de utilizar NGFW (Next Generation Firewall) para securizar nuestros entornos industriales. En ese ejemplo empleaba Modbus como protocolo y el uso de la funcionalidad IPS (Intrusion Protection System) para frenar posibles ataques. El artículo lo podéis encontrar a continuación:

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

Si bien los fabricantes están incorporando características de seguridad en sus productos, la presencia de equipos que no disponen de ellas es, y seguirá siendo, muy amplia. Esto es debido a que el ciclo de vida de los mismos es mayor si lo comparamos contra entornos IT tradicionales. Esto da pie a que exista equipamiento “antiguo”, totalmente funcional, pero con vulnerabilidades susceptibles de ser explotadas. Esto es comprensible ya que en el momento de su diseño, la seguridad no era una necesidad. Sí, la funcionalidad y robustez, algo que se mantiene en la actualidad. A veces es posible corregirlas mediante actualizaciones, pero no siempre es así ya que el hardware puede ser parcial o totalmente incompatible según el modelo en cuestión. Entonces, bien sea porque no es necesario su reemplazo o técnicamente posible su actualización, la securización pasa por elementos o medidas externas. Y como no, los NGFW son una de ellas.

Otras de las funcionalidades que poseen los NGFW es el denominado “Control de Aplicación”. Esta permite identificar el software que circula por la red, interpretar la información contenida en los paquetes mediante “Deep Packet Inspection” y a partir de aquí, permitir, bloquear, monitorizar o poner en cuarentena el mismo. Esto facilita reconocer herramientas en entornos donde, en principio, no debiera darse esas comunicaciones y por tanto alertarnos de que algo anormal está sucediendo o, aún peor, una actividad hostil.

Si bien resulta necesario frenar cualquier actividad no autorizada o perjudicial para nuestras infraestructuras, mejor aún es poder identificarlas o frenarlas antes de que se produzcan. Situándonos en el papel de un atacante, antes de llevar a cabo cualquier acción han de darse fases como reconocimiento, identificación de equipos, redes, servicios, vulnerabilidades, etc. debiendo emplear herramientas con las que, de forma activa o pasiva, poder obtener dicha información. Por tanto, si somos capaces de detectarlas, no sólo estaremos previniendo una actividad inusual sino además, que algo o alguien pueda estar dando los primeros pasos antes de llevar a cabo una acción mayor. Y como no, si esto se produce, identificar qué es lo que ha fallado o es necesario corregir.

Por poner un ejemplo, propongo el siguiente escenario:

Arquitectura_APP_CONTROL_01

Escribir una leyenda

En la red 192.168.0.0/24 tendremos un PLC (en este caso un Siemens S7-300 emulado con la aplicación Snap7) con IP 192.168.0.65 el cual es accesible desde una Workstation 192.168.0.100/24 destinada a labores propias del entorno. Por otro lado, tenemos una red 10.10.10.0/24 donde ubicamos una DMZ, y en ella, un servidor SCADA con IP 10.10.10.101/24. Por último, la Red de Oficinas bajo un direccionamiento 192.168.1.0/24, donde a priori no debiera haber ningún tipo de software de Control.

Como NGFWs he empleado un Fortinet FortiWifi 60D, el cual tiene instalada una versión FortiOS 5.4.2. Cabe recordar que en esta versión hay que habilitar las firmas “Industrial” ya que por defecto no vienen activadas.

En la siguiente imagen vemos una captura del Software Step7 de Siemens desde la Workstation que citaba anteriormente.

Step7_01_EDITADA

Para el “Firewall Separación IT-OT” de los entornos de Oficinas y de Control, hemos creado el siguiente perfil de “Application Control”. Aquí bloqueamos todo tipo de aplicaciones, no debe darse ninguna comunicación desde un lado a otro.

APP_CONTROL_IT-OT_001

Sin embargo, ya dentro del entorno OT, en “Firewall Segmentación OT-OT”, sí que permiten las aplicaciones “Industrial” y “Network Services”. Esto es:

APP_CONTROL_OT-OT_001

Si queremos ser más estrictos podríamos bloquear una categoría completa y permitir a su vez que aplicaciones incluidas dentro de ésta, se ejecuten. Esto es, monitorizar la actividad de estos dos últimos y sin embargo denegar una acción concreta. Esto se consigue mediante la opción “Application Overrides”, cuya configuración prevalecerá sobre la definida de un modo más global.  En la imagen siguiente podemos ver que aunque monitoricemos el tráfico, vamos a impedir especificamente la acción de Bloquear la CPU del PLC mediante el protocolo S7 de Siemens.

APP_CONTROL_OT-OT_002

También podríamos hacer lo propio definiendo un filtro, “Filter Overrides”. Por ejemplo todas las comunicaciones “Cliente-Servidor bloquearlas independientemente de qué categoría estén.

APP_CONTROL_OT-OT_003

A partir de aquí será configurar las reglas en el Firewall según sean nuestros direccionamientos, interfaces y servicios de igual manera que lo sería en un Firewall tradicional. Es decir, podemos definir que desde un origen a un destino y bajo un mismo puerto sólo se puedan llevar a cabo tareas específicas de ese protocolo.

Hasta aquí una presentación de los que es y para qué se utiliza el “Control de Aplicaciones” dentro de un NGFW del fabricante Fortinet. En la próxima veremos algunos ejemplos y la funcionalidad de esta característica.

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

Un saludo.

Edorta.

MRP, Media Redundancy Protocol

Como avanzaba en la entrada “Redundancia en entornos ICS/SCADA” hoy comenzaremos a hablar de aquellos mecanismos que dotan a nuestras redes industriales de una resiliencia mayor. La tendencia de los protocolos empleados en este tipo de entornos es evolucionar hacia tecnología Ethernet en lugar de la tradicional serie. Sin embargo, su propia naturaleza, no permite la creación de bucles en la red ya que el tráfico “Broadcast” podría no sólo ralentizar las comunicaciones, sino bloquearlas. Ante la necesidad de entornos que requieren alta disponibilidad, hemos configurar protocolos que “rompan” esos bucles dejando un solo camino posible para la comunicación entre equipos. En caso de producirse un fallo, dicho protocolo será capaz de detectarlo y desencadenar las medidas necesarias para que todo el tráfico comience a ir por una vía alternativa. En entornos IT, el más conocido es Spanning Tree Protocol (STP) así como sus respectivas versiones RSTP, MSTP o PVSTP. Sin embargo, los tiempos que maneja para poder restaurar las comunicaciones son muy altos para los requerimientos de los sistemas de control y automatización, siendo necesario emplear otros que iremos viendo en esta y entradas sucesivas.

El primero de ellos es MRP (Media Redundancy Protocol). Este protocolo está descrito en el estándar IEC 62439-2, el cual es ampliamente utilizado en redes industriales para entornos de alta disponibilidad. MRP opera en Capa 2 y es específico para redes en anillo con hasta 50 equipos, garantizando un comportamiento determinístico en caso necesidad de cambio de un estado a otro. Para ello, define una serie de tiempos máximos para recuperar las comunicaciones según sea la configuración elegida. Éstos pueden ser 500 ms, 200 ms, 30 ms y 10 ms. Como hemos dicho estos son valores máximos, por lo que los tiempos reales oscilan entre la mitad y un cuarto de los mismos. Esto es, si configuramos nuestros equipos con un valor de 200 ms, el tiempo aproximado del cambio entre una ruta a otra de los paquetes podrá rondar entre 50 y 60 ms, aproximadamente.

Como vemos en la imagen anterior, MRP necesita que cada nodo disponga de dos enlaces en el anillo. Dentro de la topología, uno de ellos será elegido MRM (Media Redundancy Manager), el cual   monitoriza y controla,  reaccionando en caso de fallo. Esto lo consigue enviando tramas de control desde cada uno de los puertos, recibiéndolas en el otro extremo.  A pesar de que uno de ellos permanezca “Bloqueado”.

El resto de elementos del anillo reciben el nombre de MRC (Media Redundancy Client). Cada MRC retransmite las tramas de control enviadas por el MRM de un puerto a otro de tal manera que éste pueda detectar el fallo y activar el puerto en “Bloqueado”.

MRP define 3 tipos de tramas de control:

  1. Para monitorizar el estado de anillo. MRM envía regularmente tramas de prueba en ambos puertos que le conectan al anillo.
  2. Cuando el MRM detecta un fallo o recuperación de los enlaces, envía tramas de cambio de topología (“TopoChange”) en ambos puertos de lanillo.
  3. Cuando un MRC detecta un fallo o recuperación en un puerto, local envía tramas de cambio de enlace (“LinkChange”) al MRM. Éstas se consideran como un subtipo de otras denominadas “Linkdown y “Linkup”.

En un funcionamiento normal, “Anillo Cerrado”, el MRM bloqueará todo el tráfico a excepción de estas tramas, por lo que a efectos prácticos el anillo se comporta como si fuera un único enlace. Esto es, no existe ningún bucle.

Anillo Cerrado MRP

                        Anillo Cerrado MRP

Cuando el MRM deja de recibir dichas tramas en el otro extremo, interpreta que el enlace se ha roto en algún punto,  “Anillo Abierto”, por lo que ese puerto que estaba en “Bloqueado”, ahora comienza a enviar tramas de forma normal.

Topología en anillo abierto MRP

                      Anillo Abierto MRP

A esto hay que sumar que los MRC son capaces de informar de cambios de estado en alguno de los enlaces. Si esto se produjese, el MRC envía una trama de control al MRM informando de ello. Si éste la recibe antes de detectar que se ha producido un cambio en el anillo, toma la información contenida en ella para activar el enlace “Bloqueado” y así recuperar la conectividad en el menor tiempo posible. De ahí que, aunque se fijen tiempos máximos, siempre cabe la posibilidad de que el anillo pueda seguir enviando tráfico por debajo de estos umbrales.

Tanto el MRM como el MRC definen una serie de “estados” para sus puertos dentro de la topología.

  1. Disabled, los puertos descartan todas las tramas recibidas.
  1. Blocked, los puertos descartan todas las tramas excepto las tramas de control MRP y algunas otras de protocolos como LLDP.
  1. Forwarding, los puertos reenvían todas las tramas recibidas.
  1. Not Connected, el enlace está físicamente caído o desconectado.

En otro orden, en el caso concreto de PROFINET, MRP puede ser implementado sobre los dispositivos finales sin necesidad de equipos adicionales gracias a la definición de una aplicación concreta como es PROFINET/MRP.

Por último conviene citar las funcionalidades que cada fabricante otorga a sus productos dependiendo de modelos y licenciamiento. Algunos de ellos pueden ser; posibilidad de integración con software de gestión como Siemens Total Integrated Automation (TIA); definición de varios anillos MRP por una misma VLAN; interperabilidad con Spanning Tree Protocol; etc.

No debemos olvidar tampoco de las limitaciones y recomendaciones que cada uno hace a la hora de configurar los equipos. Por ejemplo, Cisco nos habla de que los puertos MRP no pueden ser configurados como puertos SPAN, Private VLAN o Tunnel y, si además la implementación es sobre Profinet, como Trunk; ser configurado en puertos Etherchannel; etc.

Lo dicho, hablar de resiliencia no es sólo hablar de la securización, es tener además la capacidad de recuperarse del elemento que provoca una determinada perturbación. Hoy en día con la cantidad de amenazas que acechan a los Sistemas de Control  Industrial resulta necesario no sólo desplegar medidas técnicas sino además definir arquitecturas que hagan frente a cambios o anomalías inesperadas. Los accidentes ocurren, una fibra óptica rota; un SFP, defectuoso; una configuración accidental de un puerto, o cualquier otra razón,  bien puede desencadenar una alteración en las comunicaciones y por tanto un impacto en el proceso. Esto no quita que debamos hablar de otros riesgos como el “Sabotaje”, “Inyección de tráfico”, “Intrusión”, y que obligen implementar otras medidas como el “Hardening de Sistemas”, “Monitorización”, “Control de Accesos”, entre otras paliando así estas amenazas.

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

Hasta pronto!

Redundancia en entornos ICS/SCADA

Como hemos hablado en anteriores ocasiones, y no nos cansaremos de repetirlo, la prioridad número uno en entornos industriales es garantizar la disponibilidad. Luego vendrá la integridad y la confidencialidad, pero lo primero es la disponibilidad. Para alcanzarlo, se ha de aplicar una estrategia de Defensa en Profundidad para reducir los riesgos de sufrir un incidente de seguridad y prevenir que algo, o alguien, atente total o parcialmente contra nuestras instalaciones. Dada la limitación y naturaleza de los equipos, así como las debilidades que ofrecen en lo que a materia de seguridad se refiere, muchos de ellos deben delegar en la infraestructura de red la seguridad que por sí mismos no pueden ofrecer. Para ello, ha de comenzarse por la separación de los entornos IT y OT; y más tarde en la segmentación de este último definiendo zonas más pequeñas con el fin de que si una se ve afectada, la amenaza no se propage al resto.

Sin embargo, esto no es lo único que debemos considerar. Si queremos que nuestra red sea resiliente, no sólo debe evitar,  y ser capaz,  de mitigar un ataque sino que debe ser tolerante a fallos, ya sean éstos intencionados o no.

Los enlaces redundantes suponen una medida para evitar puntos únicos de fallo que puedan dejar fuera de servicio toda una instalación. Duplicando las vías de comunicación conseguimos que, en caso de producirse uno, los sistemas comunicarán por caminos alternativos. Así podemos establecer dos posibles propósitos:

  1. Tolerancia a fallos

Aumento de las vías de comunicación que permitan reconducir el tráfico por alguna de las restantes.

  1. Balanceo de carga

Disponiendo de dos o más enlaces entre equipos podemos no sólo lograr el punto anterior sino también un envío alternativo de paquetes por canales distintos de tal manera que consigamos descongestionarlos en caso de saturación de alguno de ellos.

Aunque el punto uno en realidad también está incluido dentro del segundo, el uso de enlaces redundantes en entornos industriales esta usualmente dirigido a éste ya que es más importante garantizar la disponibilidad que el rendimiento. Esto último además se refuerza con que las necesidades de anchos de banda en entornos OT son más pequeñas que en IT.

La tendencia de las comunicaciones industriales es que se basen en tecnologías Ethernet y servicios TCP/IP dejando atrás, o reduciendo el uso,  protocolos basados en buses tipo RS-485 o serie. Sin embargo, el tráfico broadcast propio de la tecnología Ethernet no permite el uso de enlaces redundantes por lo que hemos de implementar protocolos que resuelvan este problema. El más extendido es Spanning Tree Protocol o algunas de sus versiones como RSTP, MSTP o PVSTP, el cual permite disponer de varias rutas físicas, pero bloqueando los puertos de los elementos de la red de tal manera que sólo exista una activa. El resto, permanece en “Standby” hasta que, como digo,  se produzca una caída de alguno de los enlaces que permanecen activos obligando a recalcular una segunda ruta que reestablezca las comunicaciones,  activando alguno de esos enlaces que permanecían en “Standby”. Hasta que esto ocurre transcurre un tiempo que puede ir de uno a varias decenas de segundos según sea el protocolo elegido.

Topología en anillo_01

Esto en entornos IT puede no suponer un problema, donde el retraso en décimas de segundo puede pasar inadvertido mientras se manda un correo o se accede a un fichero en una unidad de red. Aparte, claro está, que existan tecnologías más modernas que permitan la supresión de bucles en Capa 2 y por ende, estos protocolos. Pero insisto, aunque estén implementados, los tiempos pueden ser más amplios, algo que resulta inaceptable para entornos OT. Para hacernos una idea, en comunicaciones tipo RT (Real Time) o IRT (Isochronous Real Time) hablamos de latencias por debajo de 10 ms y 1 ms, respectivamente. Es por ello que las medidas de entornos IT no son aplicables, una vez más, a entornos de automatización, por lo que se han de aplicar otras. En resumen, el método para conmutar de un enlace a otro debe ser predecible para determinar el límite tolerable de latencia, y por tanto, conocer de antemano cómo puede afectar a las comunicaciones según sea su naturaleza. El objetivo debe ser que la convergencia sea tan rápida que resulte transparente para las aplicaciones en uso sin sobrepasar los límites tolerables.

Es por esto que en entornos OT no hablamos de Spanning Tree, ni como decía, ninguna de sus variantes. No tienen cabida. Han de emplearse otros. En las próximas entradas veremos estos protocolos y cómo, una vez más, disponer de una arquitectura de red nos proporcionará,  junto con las medidas de seguridad paralelas,  una resiliencia mayor para hacer frente al creciente número de amenazas y riesgos a los que se enfrentan nuestras infraestructuras.

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

Un saludo!