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

 

LLDP, pros y contras de la difusión de información en redes PROFINET

Como hemos dicho en anteriores ocasiones, la evolución de las comunicaciones industriales tiende a basarse sobre tecnología Ethernet en detrimento, en muchos casos no en todos, de las comunicaciones serie. Esto va a traer consigo muchas ventajas, pero también algunos inconvenientes. Por ejemplo, será necesario el despliegue de distintas medidas que reduzcan el riesgo de que algo, o alguien, pueda atentar de manera voluntaria o involuntaria contra la disponibilidad de las instalaciones. Y es que, a mayor interconexión, mayor grado de exposición.

El estándar en estos casos es PROFINET, evolución del extendido PROFIBUS. Según sea su implementación encontraremos distintas funciones PROFISAFE, PROFIENERGY, PROFINET-MRP, etc. Sin embargo, este protocolo no viene solo, sino que también hace uso de otros para su funcionamiento, entre ellos LLDP. Si, parece que no, pero sí.

LLDP, Link Layer Discovery Protocol, es un protocolo empleado por dispositivos de red para anunciar información propia a otros equipos y dispositivos. Viene definido por el IEE 802.1AB. Su funcionamiento es muy similar al propietario de Cisco CDP, Cisco Discovery Protocol. Todos los dispositivos PROFINET lo soportan y es empleado para identificar, comprobar y mantener la topología de una red PROFINET, aparte de obtener información de diagnóstico si algo cambia. Otro de los usos es facilitar la puesta en marcha, tanto en un funcionamiento normal como en caso de fallo de algún equipo siendo necesario su sustitución. Las operaciones a este respecto se realizan de forma automática y sin necesidad de herramientas tipo software, lo cual simplifica y agiliza la forma en la que un equipo es reemplazado, minimizando la pérdida de disponibilidad.

Para ello los dispostivos PROFINET envían de forma cíclica esta información. Sin embargo  desde el punto de vista de la seguridad…

Haciendo un uso legítimo,  todo son facilidades. Sin embargo, cara a la realización de una auditoría o pentesting en entornos industriales que empleen PROFINET, LLDP se convierte en una fuente de información muy, muy buena.  Las tramas LLDP son enviadas a la dirección multicast 01:80:c200:00e. Los switches, por defecto, inundarán estas tramas por todos los puertos con lo que si conectamos nuestro Wireshark en alguna boca que encontremos libre… Seremos capaces de obtener toda esta información que se anuncia.

Empecemos por lo sencillo, aquí va una captura de un switch del fabricante HP…

LLDP_01

Como podemos comprobar podemos ver el nombre, boca del switch a la que estoy conectado, versión del Firmware, Hardware, etc. etc.

¿Ahora bien que pasa con equipos industriales? ¿Qué información podemos extraer? Veamos algunos ejemplos.

En la siguiente imagen podemos ver la que anuncia un switch SIEMENS. Allí podemos ver que estamos conectados al puerto 1, modelo X208, funciones MRP, IP de administración, etc.

LLDP_02

En la siguiente captura veremos el tráfico referente a un autómata S7-300 a lque nos hemos conectado a una de sus interfaces disponibles en su CPU.

LLDP_03

Como podemos ver aquí ya la información disponible es algo distinta, aunque se mantienen algunos campos como Chassis Subtype, Time to Live, etc. Sin embargo, algunos de los que no están por ejemplo el referente a MRP, protocolo utilizado en  switches para detectar bucles en topologías en anillo. Aprovecho para dejaros el link a una entrada que escribí hace un tiempo. Pincha aquí.

Como último ejemplo pondremos la trama esta vez de un módulo de comunicaciones CP del mismo PLC S7-300 que citaba anteriormente.

LLDP_04

Sin duda la información que vemo en cuanto a cantidad y calidad es muy importante. Si vemos habla de CP 343, propia de estos PLCs, con lo que ya sabemos el modelo que se trata. Como información extra podríamos ver de qué modelo de Firmware 3.2.23.

A partir de aquí habría que investigar si existe alguna vulnerabilidad conocida. En este caso no afecta, pero si la versión hubiera sido algo inferior, desde luego que sí. Un ejemplo de ellas, las podemos encontrar aquí:

Vulnerabilidad en módulos de comunicaciones SIEMENS.

Múltiples vulnerabilidades en módulos SIMATIC CP 343-1/CP 443-1 y CPU SIMATIC S7-300/S7-400 de Siemens

Como podemos comprobar LLDP puede ser un gran aliado en tareas de mantenimiento, puesta a punto o reducción del tiempo en caso de avería ya que simplifica todas las tareas asociadas para restaurar la operatividad. Sin embargo, surge el problema de qué hacer al publicitarse tanta información que luego, pueda hacerse un mal uso de ella. Se me ocurren varios usos, pero mejor no dar ideas.

Sin duda, desde un punto de auditoría o pentesting, LLDP será un gran recurso para una fase inicial de “Information Gathering”, pero como digo, en malas manos…

El problema aquí es que el propio protocolo PROFINET necesita de LLDP por lo que su uso debe ser permitido ya que se requiere bien para el funcionamiento como para reducir el tiempo de indisponibilidad por fallo. Cisco en alguno de sus recomendaciones deshabilitar CDP o LLDP para los equipos finales. Obviamente éstos no lo necesitar para su funcionamiento, pero en Controladores sí.

Puesto que debemos convivir con él, una de la alternativa es el bloqueo de puertos, bien de forma física como lógica.

Phisical Block Switch Port Siemens

No quiero decir con esto que gracias a LLDP nuestras redes PROFINET van a estar en peligro (que también), sino que existen protocolos que para su uso requieren de la difusión de información que aunque no queramos publicarla, debemos de hacerlo para aprovecharnos de las ventajas que éstos ofrecen en el mantenimiento, operación y garantía de disponibilidad.

¡Un saludo, nos vemos en la siguiente!

Edorta

 

Publicaciones CERTSI e INCIBE sobre Ciberseguridad Industrial, actualizado 29/10/17.

Tanto INCIBE (Instituto Nacional de Ciberseguridad de España) como CERTSI (CERT de Seguridad e Industria) publican a menudo en sus respectivas Webs noticias, guías y artículos sobre distintas temáticas teniendo como telón de fondo la seguridad. Para esta ocasión he ordenado las referentes a Ciberseguriad Industrial, que recopilan un buen número de investigaciones, incidentes, análisis, e informes, sobre distintas temáticas.  Sin duda constituye un conjunto de referencias para el aprendizaje de todo profesional que esté o quiera desempeñarse en securización de estos entornos. Espero que os guste y sobre todo os resulte útil.

Un saludo!

Guías:

  1. Despliegue de un IDS/IPS y gestión centralizada de alertas.
  2. Protocolos y Seguridad en SCI.
  3. Identificación y reporte de incidentes de seguridad para operadores estratégicos: Guía básica de protección de Infraestructuras Críticas.
  4. El Puesto del Operador: Guía básica de protección de Infraestructuras Críticas.
  5. Guía de Seguridad de Protocolos Industriales – Smart Grid

 Artículos:

  1. Los conocimientos del personal de seguridad industrial.
  2. Ciberseguridad en las comunicaciones inalámbricas en Entornos Industriales
  3. SNMP, ¿es tan simple como el nombre indica?
  4. Cortafuegos transparentes, ladrillos de cristal.
  5. PRP y HSR: Protocolos redundantes.
  6. Robots y drones en la Industria 4.0.
  7. Hardware Hacking en Sistemas de Control Industrial.
  8. CrashOverride: El malware para SCI ataca de nuevo.
  9. Analizando la seguridad sin riesgos: laboratorios de pruebas.
  10. Asegurando la virtualización de tus sistema de control.
  11. Gestión de credenciales en sistemas de control.
  12. Prevención de intrusos y gestión de eventos para sistemas de control.
  13. Insider, las dos caras del empleado.
  14. Amenazas emergentes en entornos industriales.
  15. Honeypots Industriales.
  16. Gestionar el riesgo de los proveedores como propio.
  17. Seguridad en protocolos industriales – Smart Grid
  18. Criptografía para reforzar la ciberseguridad en entornos industriales.
  19. Características y seguridad en PROFINET.
  20. Analizadores de red en Sistemas de Control.
  21. Seguridad Industrial 2016 en cifras.
  22. ¿Nuevo ciberataque a la red eléctrica de Ucrania?
  23. Inventario de activos y gestión de la seguridad SCI.
  24. Líneas de actuación del Esquema Nacional de Seguridad Industrial.
  25. Protocolos Industriales: Herramientas de Seguridad.
  26. ¿Tu empresa es segura? Medir es el primer paso para conseguirlo.
  27. Atrapando sombras en la industria.
  28. Cyber Kill Chain en Sistemas de Control Industrial.
  29. DDOS de actualidad: IoT y los DNS de Dyn.
  30. Seguridad en BlueTooth: Fortalezas y debilidades.
  31. ZigBee en el laboratorio.
  32. Thinking in Big (Data) y la seguridad industrial.
  33. Seguridad desde abajo: dispositivos finales a escena.
  34. Familia de malware en la industria.
  35. Protegiéndose de BlackEnergy: Detectando anomalías.
  36. Seguridad en Comunicaciones ZigBee.
  37. BlackEnergy y los Sistemas Críticos.
  38. Desmontando Modbus.
  39. Safety y security: juntos pero no revueltos.
  40. BMS: Edificios inteligentes, ¿y seguros?
  41. Seguridad industrial 2015 en cifras.
  42. Un SCADA en la ciudad.
  43. Aplicando seguridad en WirelessHart.
  44. Sistemas de control de software libre.
  45. Arquitecturas de seguridad en la nube para la industria.
  46. Las aplicaciones de control se hacen mayores.
  47. Mi SCADA en las nubes.
  48. Evolucionando la comunicación en la industria.
  49. La Ciberseguridad en la Industria 4.0.
  50. Divide y vencerás: Segmentación al rescate.
  51. Monitorización de amenazas en SCADA.
  52. Evolucionando la infraestructura de red en SCI.
  53. Bug Bounties en SCI: Vulnerabilidades en busca y captura.
  54. El consumo eléctrico bajo control.
  55. Buenas prácticas de configuración en la red inteligente.
  56. Disciplina militar en Control Industrial: OPSEC.
  57. Auditorias en sistemas de control.
  58. Amenazas en los Sistemas de Control Industrial.
  59. Certificaciones de seguridad en sistemas de control.
  60. La evolución de los dispositivos en los sistemas de control industrial.
  61. Estándares de ciberseguridad en las redes inteligentes.
  62. BYOD en entornos industriales.
  63. IEC 62443: Evolución de la ISA 99.
  64. La seguridad de los coches inteligentes a examen.
  65. La ciberseguridad en las subestaciones y el estándar IEC 61850.
  66. Herramientas TI que evolucionan para TO.
  67. La evolución del software en los sistemas de control industrial.
  68. Diferencias entre TI y TO.
  69. Normativas de seguridad en sistemas de control.
  70. Identificación de sistemas de control industrial.
  71. Problemática de los antivirus en entornos industriales.
  72. Seguridad en Protocolos de Sistemas de Control Industrial.
  73. Del Air Gap a la Segmentación en ICS.
  74. Guía de seguridad de Sistemas de Control Industrial.
  75. La problemática de la ciberseguridad para los profesionales de los sistemas de control industrial.
  76. Protegiendo Infraestructuras Críticas: no es suficiente con medidas IT.
  77. Hacia una evaluación eficaz de la seguridad en ICS.

Otras Guías de interés:

  1. Guía de Pentest: Recolección de información (Information Gathering).
  2. Guía sobre análisis de tráfico con Wireshark.
  3. Guia de Seguridad en servicios DNS
  4. Ciber-Resiliencia: Aproximación a un marco de medición.
  5. Detección de APTs.

 

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.

CCI_01

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.

Escenario lógico

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.

Escenario lógico_01

Y todo ello en la realidad quedó en….

CCI_03

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.

CCI_02

Un abrazo!!

ICSSPLOIT, PROFINET-DCP

No hace mucho hablábamos de ICSSPLOIT como herramienta 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 en un autómata SIEMENS S7-300. Ver entrada.

Además del módulo de “exploits” y “creds”, disponemos de un tercero denominado “scanners” cuyo nombre ya delata su objetivo no haciendo falta decir mucho mas sobre él. Hasta la fecha disponemos de un total de 3:

profinet_dcp_scan

s7comm_scan

vxworks_6_scan

Para esta ocasión fijaremos nuestra atención en el primero de ellos. El mismo, emplea el estándar de comunicaciones PROFINET para la recolección de información de  aquellos dispositivos que lo utilicen.

Conviene recordar en lo que respecta a entornos industriales, se marcan 3 tipos de comunicaciones cuyo uso dependerá de las necesidades del entorno y precisión de procesos. Estos son:

  1. Standard TCP/IP, empleado para tareas en las que latencias  de hasta 100 ms pueden ser aceptables como ocurre en entornos 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 entender mejor dicho estándar, a continuación citaremos algunos de los aspectos más relevantes del mismo.

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

También encontraremos varios tipos de protocolos y funciones según sea el uso y contexto. 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.

Config HA Switch_01

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.

TRama Profinet-PTCP_01

PROFISAFE, aplicación de PROFINET en 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 o 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 su funcionalidad, ofrece varios servicios y métodos de comunicación según 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 nos permitirá obtener el nombre, valores de direccionamiento IP y modelo del equipo por medio de PROFINET-DCP. Eso sí, dentro de la misma subred. En el vídeo que se muestra a continuación vemos el resultado.

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.

PROFINET-DCP_03

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)

PROFINET-DCP_04

Con la entrada de hoy hemos visto la manera de recolectar información empleando ICSSPLOIT a través de PROFINET-DCP. Otra forma, esta vez, fuera de los protocolos habituales.

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.

Funcionalidades ICSSPLOIT_01

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 .

PLC A STOP_01

Y su arranque:

PLC A START_01

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.

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