Monitorización redes industriales, SCADAGuardian

Cuando abordamos un proyecto para la protección de un entorno de control y automatización, una de las primeras tareas es elaborar un inventario de todos los activos. No podemos tratar de reducir los riesgos de que algo o alguien, de una manera intencionada o no, pueda llevar a cabo una acción que afecte a la actividad de planta, instalaciones o infraestructuras; si saber lo que tenemos.

Es cierto que muchos equipos podrán serán comunes en distintos escenarios, pero dada la heterogeneidad de las actividades industriales cada entorno deberá ser abordado de forma particular. Es cierto que PLC´s, HMI´s y SIS serán un común denominador; no si de lo que hablamos es de atornilladoras, AGVs, sistemas de almacenamiento automático, sistemas de metrología, y un largo etcétera.

Esta tarea puede no ser compleja, pero sí tediosa. Al fin y al cabo, estamos recolectando información. El problema es cómo lo hacemos de una manera lo más sencilla y efectiva posible. Además, por experiencia, se parte con un alto grado de desconocimiento en particular para los profesionales que tienen que liderar proyectos de Ciberseguridad Industrial. Provenientes de entornos IT, donde aparte de desconocer las tecnologías, componentes y tecnologías, comienzan a relacionarse más estrechamente con personal con distintas culturas, puntos de vista, necesidades y sobre todo, prioridades. Hablo de personal de Ingeniería o Mantenimiento.

Por tanto, la base de cualquier proyecto es tener un inventario completo y consolidado que nos permita desarrollar medidas eficientes para proteger nuestros entornos.

Sin embargo, el éste no debe estar ceñido exclusivamente a información sobre tipos de equipos, fabricantes, modelos o versiones de firmware. Debemos conocer las comunicaciones que mantienen con otros sistemas o dispositivos. Esto es, orígenes y destinos, protocolos empleados, direcciones IP y sobre todo qué consignas o valores se envían a través de ellos. Podemos estar autorizando una determinada comunicación, pero ¿qué ocurre si aprovechando una falta de medidas de seguridad nativas somos capaces de cambiar un valor que está fuera de tolerancia?

Por esta y otras razones que iremos descubriendo en sucesivos artículos es que debemos contar con herramientas que nos ayuden a identificar los activos en nuestra organización, sus características y conocer cómo y de qué manera se comunican. A partir de aquí, ya comenzaremos a localizar vulnerabilidades, calcular impactos, priorizar medidas para minimizar riesgos, definir topologías de re red, crear matrices de comunicaciones para configurar reglas en firewalls, etc. etc. etc.

Una de estas ellas es el producto de la firma NOZOMI Networks, SCADAGuardian. Se trata de una herramienta especializada para entornos y tecnologías OT. En formato físico o virtual, entre sus características están

  • Monitorización en tiempo real
  • Identificación de activos de forma automática
  • Detección de comportamiento, amenazas y vulnerabilidades
  • Deep Packet Inspection de protocolos industriales
  • Fácil despliegue
  • Integración con otros sistemas
  • Creación de informes

El modo de operación es por medio bien de un puerto espejo en algunos de los switches de nuestra infraestructura o por medio de dispositivos TAP por lo que no resulta intrusiva ni añade latencias en las comunicaciones establecidas.

Por supuesto, todas estas medidas van acompañadas de una interfaz gráfica a través de la cual podamos visualizar, analizar y explotar toda la información recolectada de una manera intuitiva a través de los menús de navegación.

Adicionalmente se cuenta con una herramienta de gestión centralizada denominada “Central Management Console” con la que podremos desde un único espacio tener visibilidad de todos nuestros SCADAGuardian desplegados en nuestras instalaciones geográficamente o localmente dispersas.

No obstante, esta herramienta no tiene porqué ser empleada exclusivamente por clientes finales. Empresas que provean de servicios de SOC pueden encontrar en CMC una solución para proporcionar otros nuevos sobre entornos industriales como veremos más adelante.

Con todo ello a continuación se muestra una imagen de un despliegue tipo:

Ahora bien, hasta ahora nos hemos ceñido a la identificación de activos y características asociadas, para poder así elaborar un inventario acorde a nuestras necesidades. La herramienta nos permitirá exportar la información generada en formatos como Excel o CSV para un tratamiento posterior. Entre ellas estará la relativa a los equipos, sus enlaces y sesiones de comunicaciones pudiendo tener documentado los valores identificados dentro de cada protocolo.

Hasta ahora hemos hablado de esa primera fase de recolección de información para tener una visión de cómo y por quién está compuesta nuestra red OT. Sin embargo, las capacidades de esta herramienta van más allá pudiendo ser capaz de detectar vulnerabilidades con mayor o menor precisión según sea el caso.

Adicionalmente a SCADAGuardian, disponemos de SCADAGuardian Advanced. Como hemos dicho, la solución recolecta información de forma pasiva no interfiriendo en el tráfico legítimo. Esto proporciona a SCADAGuardian la capacidad de identificar vulnerabilidades por medio del citado análisis. Sin embargo, SCADAGuardian Advanced incorpora una funcionalidad que permite confirmar dichas vulnerabilidades por medio de consultas inteligentes sin interferir en el correcto funcionamiento.

A continuación, se establece una comparativa entre ambas:

Como bien sabemos existe un creciente aumento de vulnerabilidades y amenazas que afectan a sistemas de control y entornos industriales. En este sentido NOZOMI Networks cuenta con un servicio de suscripción denominado “OT Threat Feed” para recibir las últimas descubiertas y que nuestros SCADAGuardian o SCADAGuadian Advanced tengan la capacidad de detectarlas. Detrás de ello, se encuentra con un equipo de investigadores propio que trabajan continuamente para la mejora del producto siendo un ejemplo de ello las publicadas en fuentes como el ICS-CERT.

Con todo ello hemos de tener presente una funcionalidad clave en este tipo de soluciones y es la de notificar de alertas cada vez que tenga lugar un evento o anomalía. Para ello podremos personalizar y establecer canales para su notificación que van desde productos comerciales hasta mensajes de correo electrónico, Syslog o Traps de SNMP. SCADAGuardian establece 4 tipos de alertas principales en función del motor (funcionalidad) que la origine, “Protocol Validation”, “Learned Behavior”, “Built-in Checks” y “Custom Checks”.

En el momento del despliegue, SCADAGuardian necesita de un proceso de aprendizaje acerca del comportamiento de la red y de los elementos que la componen. En función de ese aprendizaje, la herramienta generará una nueva alerta por cada anomalía detectada. Más tarde, debreemos indicar si se trata de un incidente o si por el contrario se trata de un cambio o evento controlado. Por ejemplo, imaginemos una tarea de mantenimiento programado en la que conectamos un nuevo equipo que hasta la fecha no había sido conectado a la red.

Hasta aquí la entrada del día de hoy donde hemos hecho un repaso a la herramienta de monitorización líder del mercado no sólo por el crecimiento que NOZOMI Networks sino por sus capacidades de integración como es el caso de los equipos SIEMENS RUGGEDCOM APE proporcionando así una solución embebida en productos de terceros evitando así el despliegue de nuevo equipamiento.

Sin embargo no es la única. A continuación os dejo un video con la que se puede obtener con equipamiento de la firma Fortinet, dela que ya hemos hablado en otras entradas como su integración con switches.

Un saludo, nos vemos en la próxima!

Edorta

 

Reproduciendo PCAPs, TCPreplay

El uso de protocolos de comunicaciones basados en Ethernet en entornos industriales aparte de ser clara, resulta necesaria para la integración de tecnologías y sistemas que ayudan a mejorar procesos. Aunque, también es cierto, que la existencia de buses de campo basados en comunicaciones serie seguirá estando presente hasta que puedan ser reemplazados por aquéllos. Ethernet ofrece una flexibilidad, escalabilidad y capacidades de integración evidentes.

Sin embargo, esas ventajas traen consigo nuevos riesgos. Los componentes, sistemas y equipos comienzan a estar más expuestos y por tanto con un mayor riesgo frente a amenazas de distinta índole.

Desde el punto de vista de la ciberseguridad en muchas ocasiones deberemos de analizar distintos patrones de tráfico con el fin de identificar activos, anomalías o extraer algún tipo de información que resulte de interés. Para ello deberemos recurrir a capturar tráfico de una manera pasiva o, no intrusiva, para no introducir latencias o variaciones de éstas que puedan afectar los procesos. Algo crítico, como ya sabemos.

Los recursos más empleados son los puertos espejo en switches o dispositivos TAP de los que ya hablaba en las siguientes entradas.

Puerto espejo, un aliado a veces olvidado

TAP devices, Siemens TAP 104

Sin embargo, no son los únicos. Cortafuegos también disponen de estas características como podemos observar en los del Fabricante Fortinet como se muestra en la imagen siguiente. Una funcionalidad a tener presente tanto en los encargados de «Separar y Segmentar» o de proteger una celda, célula o un conjunto menor de equipos siguiendo una estrategia de Virtual Patching

Las capturas que realizaremos están muy bien desde el punto de vista de recolección de información para su análisis posterior, tanto de forma manual o por medio de alguna herramienta que nos facilite la tarea.

Ahora bien, puede darse el caso en el que queramos por ejemplo reproducir ese tráfico en un entorno controlado tal y como se ha producido en nuestra red OT. Algo que como es lógico no podremos realizar en el original

Para esos casos podremos emplear herramientas como la que nos atañe en el día de hoy, tcpreplay. Con tcpreplay podremos reproducir las capturas previamente recogidas e inyectarlas de nuevo en la red y así ver efectos, comprobar configuración de cortafuegos, NIDS, entre otras. Para ello he generado el siguiente escenario:

Desde la estación con una distribución “Kali Linux” reproduciremos las capturas previamente recolectadas para poder visualizarlas en un equipo Windows 10 con el analizador Wireshark.

Para el caso más sencillo, deberemos indicar la interfaz por dónde se inyectará el tráfico y la captura en sí. En nuestro caso “eth0” y “omron.pcap” respectivamente.

Como podemos comprobar las direcciones IP de la captura son distintas a configuradas en los equipos ya que pertenecen al entorno original.

No obstante, dispondremos de otras opciones, dependiendo de nuestras necesidades y objetivos. Por ejemplo.

Establecer la frecuencia con la que emitiremos los paquetes, es este caso 1 segundo:

Como podremos comprobar en la columna “Time” vemos la sucesión de tiempos según lo indicado en el paso anterior.

En otros escenarios podrá interesarnos la opción de enviar los paquetes tan rápido como sea posible con el parámetro “-t”. En este caso podremos comparar los resultados con el ejemplo anterior y ver, una duración de 244 segundos frente a 0,012045. Algo que puede ser útil para comprobar comportamientos, respuestas, etc.

Otras opciones que tendremos será la de poder indicar la cantidad de paquetes a enviar. Por ejemplo, 1 paquete por segundo durante un tiempo de 15 segundos.

Mientras que con el siguiente la emisión de 15 paquetes pero sin la limitación de tiempo.

Hasta ahora hemos visto la posibilidad de definir una serie de parámetros y realizar los envíos. Sin embargo, podremos hacerlo de forma controlada interactuando con la herramienta. Esto puede ser interesante en momentos en lo que debamos analizar, por ejemplo, alguna acción y detectar los paquetes a través de los cuales se ha realizado. Por ejemplo, en un entorno de laboratorio si detectamos la parada de un PLC poder ir paquete a paquete hasta detectar el cambio de estado de la CPU del controlador.

Según la imagen siguiente habremos enviado un total de 100 paquetes. Primero habremos mandado 10, luego 20, luego 5, 50, 10, 3, y 1. En paralelo habremos observado el comportamiento en el entorno que hubiéramos deseado.

La tendencia hacia las comunicaciones Ethernet en entornos industriales en detrimento de las serie es clara, aunque éstas seguirán vigentes durante mucho tiempo ya que la migración requiere de recursos humanos, técnicos y económicos importantes. Algo que puede no ser asumible por las organizaciones.

Pero sobre aquellas que así lo sean, buses de campo como supervisión, es probable que tengamos la necesidad de capturar esas comunicaciones y realizar un análisis posterior en un entorno de laboratorio y con otro tipo de herramientas, como puede ser también Grassmarlin. En el caso de tener la necesidad de querer reproducir tales capturas para observar el comportamiento en un medio o entorno similar al original, tcpreplay es una herramienta a tener muy presente. Ahora queda explorar el resto de opciones.

Un saludo, ¡nos vemos en la siguiente!

IX Congreso Internacional de Ciberseguridad Industrial. Fortinet & Nozomi Networks.

Los pasados 4 y 5 de octubre se celebró en Madrid el IX Congreso Internacional de Ciberseguridad Industrial organizado por el Centro de Ciberseguridad Industrial. En él, un año más, se dieron cita profesionales, expertos e instituciones con el fin de compartir dos jornadas cargadas de puntos de vista, investigaciones, nuevas líneas de productos, casos de éxito, mesas redondas y momentos para el networking empresarial donde intercambiar y hacer nuevos contactos.

A diferencia de las dos ediciones anteriores, este año acudía no sólo como espectador sino, además, como ponente. Allá por el mes de mayo tuve la oportunidad de participar en “La voz de la Industria”, pero esta vez tocaba hacerlo con proyección internacional.

Dicha ponencia se hizo en conjunto con miembros del equipo de profesionales de  GrupoCMC,  Fortinet y Nozomi Networks siendo cada uno de ellos Jose Luis Laguna, Director Técnico de Fortinet Iberia; Antonio Navarrete, Ingeniero Pre-venta; y Edgar Capdevielle, como CEO de ésta última y un servidor como GrupoCMC.

El tema de nuestra presentación era “Demostración práctica de protección de un escenario de automatización industrial” donde simulamos el funcionamiento de una presa hidroeléctrica empleando para securizarla con equipos específicos como Fortinet Fortigate Rugged 90D y solución SCADAGuardian. Ahora bien, ¿cuál fue nuestro discurso para ver la necesidad de ambos? Comencemos.

Bajo mi punto de vista y basándome en lecciones aprendidas (prácticas, no teóricas) en proyectos planteamos que la actualización de equipamiento porque sea más seguros no es una prioridad. Las empresas no los cambian porque incorporen tal o cual medida de seguridad, lo hacen porque la función que realicen lo requiera. Además, puede no es fácil llevarlas a cabo ya que la implementación de unas u otras tecnologías puede necesitar ventanas de tiempo amplias. Por ejemplo, pensemos una migración de una arquitectura RS-485 a una Ethernet. En otro orden, por muy planificados que estén los trabajos, cualquier intervención no deja de introducir un riesgo que desemboque en un impacto en la actividad siendo éste inasumible.

Es por ello que la Seguridad Perimetral sigue siendo la primera medida. ¿Por qué? Porque permite reducir los riesgos en una primera instancia sin la necesidad de actuar sobre esos equipos finales desactualizados, sin soporte en algunos casos, sin compatibilidad con soluciones de seguridad, con largos ciclos de vida, que por su criticidad sea inviable actuar sobre ellos para aplicar parches, con desarrollo de aplicaciones propias, y un largo etcétera. Además, permite atajar la propagación de amenazas o incidentes a través de filtrado de tráfico junto con funciones avanzadas como Control de Aplicación, Antivirus, Filtrado Web o IDS/IPS. Sí filtrado web. Hay equipos que permiten ciertas funcionalidades a través de servidores web embebidos a los que les pueden afectar las mismas vulnerabilidades con la dificulta que, o no pueden ser corregidas, o supone la actualización completa de firmware o software.

Por supuesto, esto último respaldado con un buen diseño y arquitectura de red ya que de nada nos sirve incorporar un equipo último modelo, si luego tenemos una red plana o enrutada…

Aparte de lo anterior, otra de las necesidades que veíamos era la inclusión de medidas en materia de visualización y monitorización. No me refiero a solucione SCADA, sino a nivel de red. De tráfico.

La Industria 4.0 trae consigo una buena cantidad de beneficios no sólo por los avances tecnológicos como fabricación aditiva, robótica colaborativa, simulación, etc. sino la inclusión de las Tecnologías de Información para mejorar los procesos convirtiendo las fábricas en más productivas, competitivas, eficientes energéticamente, etc. Esto requiere tener una visión de lo que ocurre en nuestras instalaciones, consiguiéndose mediante la recolección de información tanto en tiempo real como en cortos espacios de tiempo y a partir de ahí corregir desviaciones o tomar otro tipo de medidas. Ahora bien, para alcanzar ese propósito los equipos deben de estar interconectados y en el momento que esto se produce, todos comienzan a estar expuestos. Y como bien sabemos, una medida para reducir los riesgos es reducir justamente el grado de exposición.

Junto con ello los flujos de tráficos deben ser un reflejo del proceso. Nada que no forme parte de la actividad propia, debe existir. Sólo lo estrictamente necesario.

La contextualización de la información también debe estar presente. Tenemos que tener una visión amplia de lo que sucede. Si hablamos de una fábrica de producción en serie, el fallo en un equipo instalado en una línea a priori no debería afectar a otra. Pero si ese problema no se resuelve dentro de los tiempos máximos podría dejar de suministrar piezas o material a esta última provocando unas consecuencias mayores.

Finalmente, conviene diferenciar entre información e inteligencia sobre amenazas. Debemos pararnos a pensar que no toda la información que obtenemos con esta monitorización puede ser del todo útil. Por ello cara a recolectar datos debemos analizar la calidad de la información; su origen; cantidad; relevancia para la organización, sistemas y entorno; capacidad para recolectar, correlar o analizar; y finalmente, cómo la aplico. Es decir, si no hago nada con ella, ¿para qué conseguirla?

Si sumamos ambos aspectos, por un lado, la seguridad perimetral y por otro la necesidad de monitorización, es que encontramos el beneficio de contar ambos productos destacando entre otros aspectos:

Fortinet Fortigate:

  • Gama productos específicos para entornos industriales.
  • Diseño rugerizado capaz de soportar entornos hostiles con polvo, humedad y temperatura muy superiores a entorno IT tradicional.
  • Electrónica de alto rendimiento.
  • Integración con soluciones de gestión centralizada.
  • Deep Packet Inspection sobre protocolos industriales.
  • Montaje sobre carril DIN y alimentación por fuentes de alimentación externas.

Nozomi SCADAguardian:

  • Solución diseñada para entornos industriales.
  • Identificación de activos y protocolos
  • Detección de anomalías en flujos y tipos de tráficos.
  • Instalación pasiva no introduciendo latencias adicionales.
  • Evaluación de vulnerabilidades a partir de información recolectada.
  • Detección de amenazas, riesgos e incidentes.
  • Variedad de paneles de control y generación de informes para análisis y labores forenses.

Sin embargo, el mayor de los beneficios está por anunciar. Y es que a pesar de los beneficios de ambos por separado, tanto Fortinet  como Nozomi Networks han alcanzado un grado de integración tal que, en caso de SCADAguardian detecte una anomalía a partir del análisis de tráfico, puede interactuar de forma automática con los equipos Fortigate configurando una regla en los firewalls que deniegue el tráfico anómalo identificado.

Esto introduce un grado adicional de protección ya que permite atajar cualquier incidente en el mismo instante que se produce reduciendo así el tiempo transcurrido desde que una amenaza es detectada, interpretada, valorado el alcance, puesta en marcha su mitigación, resolución y extraídas las conclusiones. Sin embargo, esto no es fácil ya que lleva aparejado una importante labor desde el punto de vista que debemos conocer qué activos y protocolos tenemos en nuestra organización para saber cuáles son legítimos o cuales no; definir tendencias y patrones; sopesar de qué forma SCADAguardian va interactuar con los Firewalls, esto es, bloquear IPs, cerrar sesiones, y un largo etcétera.

Como decía anteriormente para demostrar este valor añadido, ideamos una réplica de lo que podría ser una presa hidroeléctrica. En la imagen siguiente se ve el esquema de la simulación en la que aparece un taque donde se acumula el agua. Luego, se abre una electroválvula que, al abrirse, deja pasar el agua haciendo mover una turbina que es la que genera electricidad para  ser almacenada en el tanque inferior. Finalmente, se acciona una bomba que impulsa de nuevo el agua al tanque superior, para volver a repetir el proceso.

La lógica está gestionada por un equipo TRIDIUM JACE el cual cuenta con una interfaz web para labores de administración. Tanto la electroválvula como la bomba están conectadas al equipo TRIDIUM SEDONA el cual recibe las órdenes de abrir/cerrar y paro/arranque del JACE por medio del protocolo ModbusTCP.

Y todo ello en la realidad quedó en….

Así pues, lo que se hizo en vivo y en directo fue llevar a cabo un ataque sobre el TRIDIUM Sedona enviando paquetes específicos ModbusTCP desde un PC que provocada el paro de la bomba o el cierre de la electroválvula. Esto es posible debido a la falta de medidas de seguridad nativas de dicho protocolo.

Más tarde, para ver la efectividad de ambas soluciones trabajando conjuntamente se incorporó el equipo SCADAguardian el cual recibía el tráfico desde un puerto espejo de un FortiSwitch. Luego tras la integración de Fortigate Rugged 90D en aquél, se repitió nuevamente el ataque no teniendo éxito ya que al considerarse que provenía de un equipo no legítimo, SCADAguardian lo consideraba como “malicioso” enviando la orden al Firewall de la generación de una regla que lo cortase. Impedía así que llegase el paquete al TRIDIUM Sedona y por tanto evitando el cierre o paro de los dispositivos.

Obviamente este fue una prueba de concepto, sin embargo en un entorno real esta tarea llevaría más tiempo. Sería necesario dejar aprender durante unos días o semanas el comportamiento de la red para poder establecer qué tráficos son buenos y cuáles no. También la manera en la que queremos que se comporte el Cortafuegos, esto es, cortar sesiones, bloquear IP, etc. etc.

A continuación os dejo un video elaborado por Fortinet donde se explica todo ello. ¡Excelente!

Quedamos muy satisfechos con la exposición ya que aparte de lo original, práctico y puesta en escena todo salió muy bien. No quería pasar por alto agradecer a mis compañeros de GrupoCMC que diseñaron la interfaz gráfica y metieron horas para que todo saliese en esta línea. Sin ellos, su conocimiento, experiencia y sobre todo su actitud; esto no hubiera sido posible. Como no, a Jose Luis, Antonio y Edgar por los esfuerzos, trabajo e iniciativa; a Jose Valiente, Miguel García-Menéndez y Susana Asensio por la organización de este congreso de referencia; y finalmente a los asistentes que esperamos fuese de su agrado esta exposición en la que se invirtió tanto tiempo como ganas de haber proporcionado una forma automática, rápida y eficiente de proteger nuestros entornos de control y automatización industrial sea cual sea su naturaleza o criticidad.

Un abrazo!!

ICSSPLOIT, PROFINET-DCP

No hace mucho hablábamos de ICSSPLOIT como herramienta para ayudarnos en labores de auditoría y pentesting en entornos industriales. En concreto veíamos la posibilidad de parar y arrancar tanto la CPU como un módulo de comunicaciones CP de un autómata SIEMENS S7-300.

Además del módulo de «exploits» y «creds», disponemos de un tercero denominado “scanners” destinado como podéis imaginar a la obtención de información. Sin embargo, en esta ocasión, se emplea  para ello el estándar de comunicaciones basado en tecnología Ethernet, PROFINET.

A continuación citaremos algunos de los aspectos más relevantes de dicho estándar:

En lo que respecta a las comunicaciones, se consideran 3 tipos dependiendo de las necesidades del entorno y precisión de proceso. Hablamos de:

  1. Standard TCP/IP, emplea para tareas en las que la latencia de 100 ms puede ser aceptable como pueden ser la comunicaciones con sistemas IT.
  1. RT (Real Time), son aquellas en las que los tiempos de latencia pueden oscilar hasta 10 ms o son de carácter determinista.
  1. IRT (Isochronous Real Time), comunicaciones en los que los tiempos son inferiores a 1 ms.

Para lograr la identificación de los dispositivos, al estar basado en Ethernet, el direccionamiento dentro de viene dado por la dirección MAC, IP y nombre del dispositivo.

Por otro lado, ya  dentro del estándar, encontramos varios tipos de protocolos según sea el uso y contexto sobre el que valla a utilizarse. Podremos hablar de:

PROFINET-IO, destinado a comunicaciones entre dispositivos de campo, entradas y salidas.

PROFINETMRP, para su uso en entornos de alta disponibilidad en topologías en anillo. A continuación se muestra una captura de un switch Siemens X208 en el que se reflejan dichos parámetros.

PROFINET-RT, transferencia de datos en tiempo real.

PROFINET-IRT, transferencia de datos en tiempo real isócrono.

PROFINET-PTCP, sincronización de señales temporales como reloj y tiempo entre dispositivos.

PROFISAFE, aplicación de PROFINET a funcionalidades relativas a la protección de personas bajo el término “Safety”.

Y aqui es donde llegamos al punto que nos interesa para la entrada de hoy…

PROFINET-DCP, esto es PROFINET Discovery and Configuration Protocol, PN-DCP. Se trata de un protocolo basado en la Capa de Enlace, L2, empleado para descubrir dispositivos, identificar información relativa a éstos y configurar parámetros como nombres y direcciones IP dentro de una red PROFINET.

Dentro de su funcionalidad, ofrece varios servicios y métodos de comunicación segúyn sea la aplicación como “Identify All (multicast service/ Group)”,  “Identify (multicast service)”, “Set (unicast service)”, “Set / Reset to Factory (unicast service)”, “Set / Flash (unicast service)”, “Get (unicast service)” y “Hello (multicast service)”.

¿Ahora bien, cómo encaja ICSSPLOIT en todo esto? Como decía al principio, el framework en cuestión trae consigo una herramienta dentro del módulo “Scanners” que permite obtener el nombre, valores de direccionamiento IP y modelo del equipo por medio de PROFINET-DCP. En el video que se muestra a continuación veremos el resultado.

Y por último en la captura siguiente se puede apreciar cómo desde una máquina virtual se solicita información de un equipo «Siemens» cuya dirección MAC aparece sombreada.

Una vez procesada, dicha estación PROFINET responde con los valores que aparecen en el video, esto es, dispositivo (S7-300); nombre, (pn-io) y direccionaminto IP (192.168.0.1; 255.255.255.0; 192.168.0.1)

Con la entrada de hoy hemos visto la manera de recolectar información empleando tanto ICSSPLOIT como PROFINET-DCP, eso sí dentro de la misma subred.

Muchas gracias, nos vemos en la próxima.

Un saludo.

Edorta

ICSSPLOIT, paro de PLCs S7-300 y S7-400

Hola de nuevo. Siguiendo en la línea de herramientas orientadas a redes industriales, hoy le toca turno a ICSSPLOIT.

ICSSPLOIT es un framework dirigido a sistemas y protocolos de control industrial que puede sernos de utilidad en tareas como auditorías y labores de pentesting. Escrito en Python, presenta un aspecto similar al Metasploit, conservando la interfaz y la forma de interacción. Se trata de un software Open Source pudiéndolo descargar desde su sitio en Github. Allí podremos ver el conjunto de scanners, exploits, protocolos y clientes que soporta, y que esperemos vaya creciendo con el tiempo. Veamos un resumen.

La herramienta viene preparada para Kali Linux incluyendo lo necesario para su funcionamiento. Sin embargo, si algo nos faltase, podríamos mirar su fichero “requirements” y llevar a cabo la instalación de los paquetes mediante:

pip install -r requirements

Así pues qué mejor manera que verla en acción con un ejemplo. En otras entradas he trabajado con simuladores pero en esta ocasión lo haré con un PLC Siemens S7-300 real. Por supuesto, en un entorno de laboratorio. Por si fuera poco, además lo haré en formato vídeo. Una novedad que he querido introducir gracias al creciente número de visitas que ha ido teniendo el blog. Así pues, a continuación, veremos cómo llevar a “STOP” tanto la CPU como el una tarjeta CP del autómata para luego revertir el proceso. Todo de forma remota. Ahí va!

Como decía, también es válido para los S7-400. A continuación muestro la captura con Wireshark sobre los paquetes enviados y recibidos. Comentar que el PLC tiene IP 192.168.0.1 y el PC 192.168.0.100 .

Y su arranque:

Hasta aquí la entrada de hoy. Corta, pero que con el vídeo espero haya sido ilustrativa y hayamos descubierto esta nueva herramienta que sin duda va a ser de mucha utilidad para los profesionales de la seguridad. En sucesivas entradas iremos descubriendo nuevas funcionalidad, poco a poco.

¡Un saludo, nos vemos en la siguiente!

Edorta

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.

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.

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.

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.

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

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

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.

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