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

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

 

Simulador de protocolo ModBus

Una de las características que presentan los Sistemas de Control Industrial y SCADA es la gran cantidad de protocolos de comunicaciones existentes. Esto es debido a que muchos fabricantes han desarrollado los suyos propios, aparte de los ya estandarizados. Éstos los podemos encontrar bien en formato serie mediante RS-422, RS-485 o Ethernet siendo la tendencia es que sea este último el medio predominante ya que permite la integración en redes tradicionales e implementar servicios bajo TCP/IP. Esto resulta algo indispensable cara al despliegue de tecnologías dentro de la Industria 4.0. la cual requiere, aparte de la funcionalidad conocida de equipos SCADA, recolectar otro tipo de datos para sistemas ERP e BI, herramientas Big Data, Analítica Avanzada o incluso simulación.

La premisa que acompaña a estos protocolos es que han sido diseñados para ser funcionales. No se ha contemplado la seguridad en el inicio, a excepción de algunas variantes de DNP3 u OPC. Sin embargo, el uso de protocolos sin medidas de seguridad nativas es amplísima, lo cual obliga a externalizar en otros equipos la protección de la información que viaja en los paquetes.

Uno de estos protocolos es Modbus. Fue creado a finales de la década de los 70 para comunicaciones serie, y en 1999 para comunicaciones TCP/IP. Bajo el nombre ModbusTCP/IP, presenta una arquitectura Maestro/Esclavo en el que el Maestro representa el cliente y el Esclavo el Servidor. Esta característica propició su consolidación como protocolo de control industrial lo que justifica su presencia en todo tipo de entornos y sectores, incluyendo infraestructuras críticas.

En el día de hoy vamos a ver cómo podremos representar su funcionamiento, lo que nos ayudará a entender mejor cómo puede ser interceptado, manipulado y, por ende, necesariamente protegido.

En esta labor nos apoyaremos de un simulador Modbus. Por un lado Modbus Master (Maestro) y Modbus PAL (Esclavo) siendo este último un fichero para plataformas basadas en Java. En la siguiente imagen podremos ver, en la parte izquierda, “el Master”, y derecha el “Slave”. Como hemos dicho anteriormente maestro equivale a “cliente” y esclavo Servidor”. El maestro, (cliente) es quien controla las comunicaciones con los esclavos (servidores) y por el contrario los esclavos (servidores) se limitan a devolver los datos solicitados o bien, ejecutar la acción indicada por el maestro.

modbus_simulator_01

Por defecto el “Master” aparece configurado para operar en conexiones tipo serie, por lo que deberemos configurarlo para hacerlo bajo TCP. En este modo el puerto por defecto que emplea es el 502. Para ello iremos a “Option” y seleccionaremos “Modbus TCP…”.

modbus_simulator_02

También haremos lo propio en el apartado “Modbus Mode” – “TCP”.

modbus_simulator_04

También definir la IP del Master. Puesto que tanto uno como otro corren en el mismo equipo configuraremos la de Loopback, 127.0.0.1.

modbus_simulator_03

Hecho esto, ahora toca configurar los esclavos. En “Modbus slaves” seleccionamos “Add” y allí definiremos el nuestro, identificado con “1” y con el nombre “Test_Blog”.

modbus_simulator_05

Abriremos el editor (icono con aspecto de ojo) y configuraremos en la pestaña “Coils” del 1 al 8, configurando los 4 primeros con un “1” y los 4 segundos con un “0”.

modbus_simulator_06

Aprovecharemos para configurar también el apartado “Holding registers” esta vez del 1 al 4, y con los siguientes valores.

modbus_simulator_07

Por último, pincharemos en “Run” para iniciar el esclavo. Si abrimos un “cmd” veremos que en nuestro equipo se nos ha abierto un socket en el puerto TCP-502.

modbus_simulator_08

Ahora deberemos ir a nuestro “Master” y conectarnos al “Esclavo” pinchando en el icono marcado.

modbus_simulator_13

Para hacer una lectura o escritura seleccionaremos el icono situado a la derecha del que empleamos para conectarnos, viendo a continuación los resultados. Esto es cuatro “unos” y cuatro “ceros”.

modbus_simulator_09

Que se realice una lectura y escritura dependerá también del “Function Code”. En el caso anterior teníamos “Read Coils (0x01)”, sin embargo si esto lo cambiamos por “Read Holding Registers (0x03)” veremos el otro resultado . Ojo, que en este caso el “Number of Registers” ahora es 4, valor que ha cambiado del “8” del número de “Coils“ configurados.

modbus_simulator_10

Para ello cambiaremos la “Function Code” por “Write Multiple Registers (0x10)” y en campo inferior por valores como 999, 888, 777, 666. Luego a continuación pincharemos sobre “Read/Write” y veremos cómo cambian los valores en el esclavo.

modbus_simulator_12

Aunque no se haya comentado el simulador también permite:

Master

  • Realizar de forma continuada lecturas o escrituras sin necesidad de hacerlo manualmente.
  • Posibilidad de ejecutar tanto Maestro como Esclavo en distintos equipos y poder hacer pruebas adicionales con equipos de red tales como cortafuegos, IDS/IPS, router, etc.
  • Una ayuda e información sobre el protocolo.
  • Almacenar en un fichero de texto los logs generados de la herramienta.
  • Monitor de los paquetes enviados y recibidos.

Slave

  • Guardar el proyecto
  • Grabar la actividad y poder reproducirlo a posteriori.
  • Modificar el puerto a la escucha en lugar del 502 por defecto.

Así pues, este simulador nos puede ayudar a entender no sólo el funcionamiento de Modbus sino la creación de un laboratorio para pruebas y  tomar conciencia de los débiles que pueden llegar a ser los protocolos existentes en entornos de control y automatización presentes en gran cantidad de áreas, sectores e instalaciones.

Espero que os haya gustado, nos vemos en la siguiente.

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

Nmap Scripting Engine para ICS

Muchos sabemos que Nmap es una de las herramientas estrella para identificar host, servicios, redes  y poder llevar a cabo tareas de recolección de información (Information Gathering) dentro de procesos de auditoría o pentesting. Hablando más concretamente de entornos industriales, hemos de tomar ciertas precauciones ya que podremos afectar a la operativa del equipo, algo que en ningún caso puede producirse. Nmap posee además algunas funcionalidades extra de la mano de su motor NSE (Nmap Scripting Engine) que nos permite llevar a cabo tareas más concretas. Éste se basa en un conjunto de scripts que se organizan en distintas categorías dependiendo de la finalidad, como son:

  • auth
  • broadcast
  • brute
  • default
  • discovery
  • dos
  • exploit
  • external
  • fuzzer
  • intrusive
  • malware
  • safe
  • version
  • vuln

Hace un tiempo hablé sobre algunos aspectos de Nmap, tanto de su  motor de Scripting NSE como de sus uso sobre sistemas de control industrial. Por no repetir contenido os dejo los enlaces para que las podáis consultar.

  1. Nmap Scripting Engine
  2. Nmap sobre SCI sí, pero con cuidado…

Sin embargo, en el día de hoy voy a hablar de una serie de Scripts dirigidos específicamente a identificar y enumerar dispositivos y aplicaciones que pueden ser encontrados en entornos de control y automatización. Para ello se basan en protocolos y comandos de la propia aplicación para obtener información del objetivo. Sólo se trata de “recolectar”, no de “explotar”.

El primer conjunto de ellos podemos encontrarlo en el siguiente enlace de Github. Los mismos han sido desarrollados dentro de un proyecto de investigación llamado “Redpoint” de Digital Bond, consultora fundada en 1998 por Dale Peterson especializada en seguridad en entornos industriales.

redpoint_01

Para un mejor uso podemos descargarlos y copiarlos en la carpeta de “Scripts” que emplea nmap y que en la distribución Kali Linux está ubicados en:

/usr/share/nmap/scripts 

Luego es necesario actualizar la base de datos para que podamos verlos por ejemplo con la interfaz gráfica “Zenmap”.

root@kali:/usr/share/nmap/scripts# nmap –script-updatedb
Starting Nmap 7.25BETA2 ( https://nmap.org ) at XXXX-XX-XX 07:00 EST
NSE: Updating rule database.
NSE: Script Database updated successfully.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.37 seconds

Para diferenciarlos los he renombrado como “Redpoint_XXXXXXXX.nse” y así identificarlos más claramente.

zenmap-redpoint-scripts_01

Nmap cuenta de forma nativa con algunos scripts orientados a estos fines como Modbus, OMRON, incluso alguno creado por el propio “DigitalBond” como puede ser para el protocolo “BACnet”. Como ejemplo utilizaré esté último para ver los resultados arrojados y hacernos una idea. Para facilitar la tarea he hecho una primera búsqueda con ZoomEye, del que hablaba en mi último post llamado  “Buscando ICS en la red, ZoomEye”.

En el primero de los ejemplos podemos ver los siguiente:

zenmap-redpoint-scripts_02

Analizando la información podemos seguir buscando y ver las características de los equipos que responden a ese perfil, como puede ser:

nae-55xx_01

Y mira por dónde, yendo un poco más allá localizar vulnerabilidades de ese fabricante:

jhonson-vulnerability_01

Por otro lado, en el siguiente ejemplo podemos observar otro resultado.

zenmap-redpoint-scripts_03

Al igual que el caso anterior localizamos que se trata de un equipo del fabricante Kieback & Peter cuya web es la siguiente:

kieback-peter_01

Y vemos que se trata de un equipo destinado al control de estaciones de ventilación, refrigeración de edificios pequeños y medianos:

kieback-peter-ddc420

El segundo de los repositorios también lo encontramos en GitHub en el siguiente enlace,  haciendo referencia sólo a productos del fabricante SIEMENS. Los mismos han sido desarrollados por la empresa DrainWare, apreciándose que el nombre de la cuenta de GitHub coincide con su fundador “jpalanco”.

github-scripts-drainware_01

El funcionamiento es similar a lo planteado en los casos anteriores, con lo que explicado uno, explicados todos. Sí que es cierto que dependiendo del script que ejecutemos deberemos especificar uno u otros puertos, pudiendo indicar  además ciertos argumentos asociados a HTTP o SMB y así perfeccionar la ejecución.

github-scripts-drainware_02

La idea en el día de hoy es ofrecer cómo ampliar y ajustar las funcionalidades de Nmap para su uso concreto sobre sistemas de control y automatización, mediante la inclusión de Scripts específicos ya desarrollados. Como decía, son especialmente útiles cara a realizar labores de auditoría o pentesting ya que permite, no sólo, la recolección y enumeración de información sino definir la forma y modo de hacerlo mediante la parametrización de la herramienta para que sea más o menos intrusiva.

No obstante, conviene recordar que el uso ha de hacerse teniendo en cuenta el equipo final sobre el que lancemos los scripts ya que podremos afectar a su funcionamiento. Esto es debido a los limitados recursos hardware que poseen con lo que es probable dejarlos “offline”, por lo que resulta necesario, o al menos aconsejable, hacerlo en un entorno controlado o de pruebas. Me refiero por supuesto a equipos de sistema de control y automatización. En cualquiera de los casos mucho, mucho cuidado.

¡Un saludo, nos vemos en la próxima!

 

Reduciendo el tiempo de recuperación

Como he comentado en artículos anteriores, el objetivo primero para entornos OT, es garantizar la disponibilidad de las instalaciones, quedando a un segundo y tercer plano la integridad y confidencialidad de la información manejada. Esto no quiere decir que no sea importante, sino que se establecen prioridades.

Lo que se pretende con la securización de las instalaciones, es reducir los riesgos de sufrir un incidente y que se vea afectado el funcionamiento de las Infraestructuras de automatización y Control, ya sean Críticas o Industriales. Sin embargo conviene recordar, que no es menos importante garantizar la seguridad de tipo “Safety”. Me refiero a las funcionalidades de protección a personas, esas que vienen de la mano de accionadores de emergencia, barreras infrarrojas, detectores de presencia, y demás dispositivos que evitan que un técnico de mantenimiento, operario, etc. sufra un accidente que ponga en riesgo su vida o integridad física.

De todos es sabido que las amenazas, vulnerabilidades, riesgos y negligencias están ahí, y que la seguridad al 100% no existe. Lo que hoy puede tener unos niveles aceptables, mañana con la aparición de un nuevo bug, exploit, etc. puede no tenerlo.  Aparte, considerando la idiosincrasia de estos entornos con funcionamientos en muchos casos 24 X 7 X 365, la puesta en marcha de parches, actualizaciones, mejoras y nuevas soluciones, puede retrasarse a períodos de tiempo realmente largos. Eso teniendo en cuenta que puedan ser aplicados sobre las mismas plataformas, ya que no siempre es así.

Por tanto, teniendo en cuenta que a pesar de haber desplegado un plan de seguridad para nuestro entorno OT, ¿es suficiente para garantizar la disponibilidad? ¿qué ocurre durante el este período de tiempo en el que estamos expuestos por no poder aplicar medidas correctoras? ¿qué va a pasar si en ese intervalo sufrimos un incidente?

Pues bien, garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible. Para alcanzar este propósito es necesario implementar, junto con el resto, un Plan de Contingencia que permita restaurar dispositivos y sistemas a un estado nuevamente operativo.

Por ejemplo, si un HMI queda infectado o por alguna razón su hardware sufre un daño, y esto desemboca en una sustitución del equipo, mientras dure dicha operación nuestra instalación puede quedar fuera de servicio. O bien, un operario realiza un cambio incorrecto en un autómata y debe cargarse el programa a una versión anterior.

Ejemplos se pueden poner muchos, pero lo cierto es que resulta indispensable la inclusión de un proceso de generación de copias de respaldo para cubrir estos supuestos. Cuando hablo de un proceso me refiero a un método. Aquí hay que considerar muchos puntos. Uno de ellos es el tipo de equipo. No es lo mismo un PC, que un servidor SCADA, que un PLC o RTU. Así cómo en los dos primeros podremos instalar un agente que nos haga una copia del sistema operativo, ficheros, aplicaciones, etc. en el segundo y tercero su naturaleza puede que no nos lo permita y debamos elegir otra solución o vía.

Un aspecto clave es establecer la forma en que se hacen de estas copias. Todo cambio debe de estar documentado y programado, salvo que se trate de un incidente obviamente. Por ello debe seguirse una nomenclatura que permita la identificación inequívoca de los ficheros, catalogar si es software, sistema operativo, versiones, fecha en la que se hizo, control de accesos a los mismos por parte de las personas responsables, control de integridad, etc. Además, dependiendo del número dispositivos puede justificarse la instalación de herramientas centralizadas que permitan automatizar este proceso.

La generación de copias lleva aparejado necesariamente un espacio de almacenamiento adicional. Nuevamente dependiendo del número, puede necesitar de una inversión en nuevo hardware o sistemas. Aquí la estrategia marcará la manera de llevarse a cabo. Me refiero a que éstas sean accesibles bien de forma local o por red, esto es, que en caso de recuperación pueda descargarse la copia desde un servidor o desde un disco duro externo conectado via USB.

Aplicaciones en el mercado hay varias. En mi ejemplo utilizaré una del fabricante Acronis en concreto del producto Backup Advanced 11.7. Con él podremos realizar imágenes de disco de nuestros equipos y, como comentaba,  para recuperarlos en caso de fallo, rotura de hardware, o cualquier otra incidencia que afecte a su funcionamiento.

Esta solución consiste en un servidor central de administración y un agente software que se debe instalar en los equipos sobre los que se quiere hacer los backups. Para administrarlo, necesitamos de un software cliente (consola) con el que conectaremos al servidor y desde ahí llevar a cabo todas las operaciones necesarias como pueden ser:

  1. Dar de alta equipos.
  2. Organizar lugares de almacenamientos de las copias (Bóvedas).
  3. Control de acceso y permisos de usuarios.
  4. Programación de copias.
  5. Definición de nodos de almacenamiento.

En lo referente al servidor de gestión, a la hora de instalar nos preguntará sobre cómo va a utilizarse el equipo para a partir de ello instalar más o menos componentes.

acronis-01_editada

acronis-03_editada

En el Escritorio del servidor se habrá generado un acceso directo del software con el que nos conectaremos (consola) , en este caso a nosotros mismos contra la IP 127.0.0.1.

acronis-03_02_editada

Por la parte del cliente, ha de instalarse dos tipos de software. Uno denominado “AcronisAgentCore” y “AcronisAgentWindows”. La instalación es sencilla, un ejecutable más.

acronis-05_editada

Luego, desde el servidor, deberemos dar de alta los equipos para poder dar las órdenes de la generación de las copias. Lo haremos proporcionando el nombre o IP además de las credenciales definidas en el proceso de instalación.

acronis-06_editada acronis-07_editada

En el apartado “Equipos con agentes – Todos los equipos con agentes” veremos el equipo ya registrado, para este ejemplo, el “HMI-EST-01”.

acronis-08_editada

Allí encontraremos varios parámetros de configuración. Dadas las características de los entornos industriales me centraré en concreto en dos de ellas. La primera es la compresión. La imagen guardada podrá ser comprimida para ahorrar espacio, sin embargo esto podrá afectar no sólo en la generación de la copia sino también la recuperación de la imagen. Esto habrá de tenerse en cuenta ya que aumentará el tiempo en el que el equipo podrá estar disponible de nuevo.

acronis-09_editada

La segunda corresponde la prioridad que tendrá el agente de Acronis con respecto al resto de procesos que corran sobre el equipo final. La generación de la copia consume una serie de recursos, los cuales no podrán afectar al resto aplicaciones control que corre en ese mismo instante. Las copias deberemos programarlas, de ser posible, para su ejecución fuera del horario de funcionamiento pero en el supuesto de que no sea así deberemos dar prioridad al resto en lugar a la de Acronis.

acronis-10_editada

Finalmente, lanzaremos la tarea teniendo una duración variable en función de todos los parámetros configurados y el rendimiento de nuestra red.

acronis-12_editada

Si bien los valores pueden variar bastante, para hacernos idea, una máquina virtual de 60,5 GB de disco duro se quedó en 44 GB y tuvo una duración del entorno a media hora.

acronis-13_editada

Para poder recuperar un equipo, deberemos crear un dispositivo de arranque, esto es un Live CD o USB. Para ello tendremos que instalar la aplicación “Acronis Media Builder” y definir alguno de ellos.

acronis-14_editada

Con anterioridad deberemos tener cambiados los parámetros en la BIOS del sistema para arrancar desde la unidad de CD o medios extraíbles. A partir de aquí el asistente de Acronis nos guiará durante el proceso, teniendo que asignar una IP e indicar el lugar donde se almacena la copia que queremos recuperar.

acronis-15

El mensaje de hoy no es tanto ver la manera de “protegerse” sino de “recuperarse”. O dicho de otra manera no tanto a la seguridad sino  minimizar el tiempo de recuperación en el caso de que tengamos una brecha. Las estadísticas dicen que las vulnerabilidades descubiertas van en aumento y que los ataques cada vez son más diversificados. Que exista un parche, no quiere decir que se pueda implementar nada más publicarse y por tanto, mientras esta situación se mantenga, los equipos son vulnerables. He puesto el ejemplo de un HMI ya que están a la cabeza de ser el objetivo estrella, para desde ahí llevar a cabo distintas acciones sobre la red de control. Estos HMI están basados principalmente sobre sistemas operativos Microsoft Windows, de ahí que en este caso haya puesto como ejemplo una solución como la de Acronis Backup Advanced, y aplicación sobre equipos con esas características.

Espero que haya sido interesante, lo dicho “garantizar la disponibilidad no es sólo poner en marcha aquellas medidas que reduzcan los riesgos, sino que, si sufrimos un incidente, tengamos la capacidad de recuperarnos en el menor tiempo posible”. 

Saludos!

 

Identificando tráfico en redes ICS, Grassmarlin.

Son muchos los motivos que nos pueden llevar a realizar un análisis de tráfico, desde una auditoría, documentación de tráfico, hasta una labor de troubleshooting, etc. En concreto esto cobra mayor importancia en los entornos industriales con la evolución de los protocolos de comunicaciones hacia estándares Ethernet y TCP/IP permitiendo la integración con otros sistemas y tecnologías dando lugar a la llamada Industria 4.0 e IIoT.

Pero esta integración también tiene sus riesgos, ya que el grado de exposición dentro de la red aumenta con lo que resulta necesario implementar estrategias de seguridad que reduzcan los riesgos de sufrir un incidente.

Dentro de un proceso de securización, en concreto, de un entorno industrial, una de las primeras zonas donde intervenir es a nivel de infraestructura de red. Aquí surgen dos conceptos importantes como son “Separación” y “Segmentación”. Por separación entendemos dividir las redes de entornos IT tradicionales como por ejemplo “Oficinas”; y las redes de automatización OT como pueden ser las de producción en una empresa manufacturera. Entre cada una de ellas es necesario instalar un elemento de seguridad que filtre todas aquellas comunicaciones entre ambos entornos, siendo el más común un NGFW que además de las funciones tradicionales de un cortafuegos añada una capa más de seguridad con motores Antivirus, IDS/IPS, Control de Aplicación, DPI, etc.

Separacion_01

Hecho esto, la siguiente fase es segmentar nuestro entorno OT. Esto es, fraccionar en áreas, zonas, celdas, más pequeñas nuestra red o conjunto de redes, de tal manera que en caso de incidente en una de ellas, éste no se propague al resto y ponga en peligro la totalidad de las instalaciones. Recordemos que la regla número uno es garantizar la “Disponibilidad”. Esto requiere que todo el tráfico de cada una de estas áreas, celdas, etc. pase nuevamente por un dispositivo tipo NGFW y quede condicionado a unas políticas de seguridad preestablecidas.

Escenario_01

Ahora bien, para que todo esto funcione deberemos en primer lugar identificar el tráfico y realizar el análisis del que hablaba al principio.

El primero de los pasos será capturarlo para posteriormente realizar el análisis para extraer de él la información que necesitemos. Para llevar cabo esta tarea contamos con la aplicación Grassmarlin.

GrassMarlin es una herramienta destinada a entornos industriales y sistemas SCADA con la que podremos llevar a cabo:

  1. Identificación de tráfico
  2. Descubrimiento de dispositivos.
  3. Representación lógica y física.
  4. Gráfico de segmentos o arquitecturas.
  5. Exportar información a formato .CSV.

Todo ello lo realiza de forma pasiva sin interceder en la operativo normal de la operación de los equipos. Para ello permite dos opciones:

  1. Interpretar la información contenida en un fichero PCAP
  2. Captura de tráfico con la propio Grassmarlin.

Para conseguir esta información sin interceder en la operativa, la forma de hacerlo es la configuración de un puerto en modo “port-mirroring” (puerto espejo) de tal manera que recibamos una copia de todo el tráfico hacia/desde otros que sean de nuestro interés. Os dejo dos enlaces ejemplo sobre cómo hacerlo sobre dispositivos de distintos fabricantes.

Siemens

Cisco

Es posible descargarla desde aquí, estando disponible para sistemas operativos Microsoft Windows y Linux. Su última versión es la 3.

Para el presente artículo voy a partir de una captura que importaré a Grassmarlin.

captura_01

En la zona de “Network Tree Map” podremos ver tanto las redes y los nodos existentes; mientras que en la parte derecha la “Logical View” la forma gráfica de la misma con los enlaces entre uno y otro.

Si sobre uno de los nodos hacemos “botón derecho”, “Show all connections” podremos ver todas aquellas relacionadas con éste, junto con un gráfico representativo del tamaño del paquete en función del tiempo.

captura_02

Si sobre uno ellos hacemos nuevamente “botón derecho” podremos ver dicha captura en Wireshark. Esta aplicación se instala por defecto, pero en una versión antigua. Si disponemos una más reciente, podremos configurarlo en “Option – Preferences – Wireshark Executable Path” y abrirlo con ésta. Luego, en la esquina inferior derecha tendremos la opción de exportar el contenido a un fichero con formato CSV y a partir de ahí formatear y explotar la información para uno u otro propósito.

captura_03

La aplicación incluye por defecto algunos identificadores como pueden ser los primeros 24 bits que hacen referencia a los fabricantes en las direcciones MAC. No obstante, si no localizamos alguna podremos dar de alta nuevas en función de nuestras necesidades.

captura_04

Lo mismo ocurre con los protocolos.

captura_05

Allí encontraremos un buen número de ellos, pero si en el caso de que queramos bien editar uno existente o crear el nuestro propio, tendremos la capacidad de hacerlo. Aquí os dejo una muestra de modbus.

captura_06

Finalmente comentar que Grassmarlin dispone de una vista física. Esto es una representación de los equipos. Según he visto en distintas webs, la versión 3 sólo dispone de compatibilidad con dispositivos Cisco. La información que deberemos contener en un fichero de configuración para su importación es el resultado de los siguientes comandos:

  1. “show running-config”
  2. “show ip arp” (OU) “show mac address-table”
  3. “show interfaces”

Como podemos comprobar Grassmarlin puede sernos de mucha utilidad. En el proceso de trasformación de la industria y de la inclusión de políticas de ciberseguridad, identificar el tráfico resulta vital. Es muy común que los responsables o personas involucradas en procesos de fabricación, ingeniería, mantenimiento, etc. no estén familiarizados con todos estos términos y ni conozcan cómo y de qué manera se comunican sus equipos. Como mucho te puedan decir, si tal o cual equipos lo hace con tal o cual servidor o dispositivo, pero hasta ahí. Esta herramienta nos podrá facilitar mucho esta tarea y sobre todo poder comenzar a documentar todo aquello que sea necesario y evitar así esta situación.

Espero que os haya gustado, nos vemos en la siguiente.

Edorta