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

Fortinet Packe Capture

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.

tcpreplay capture 01

tcpreplay wireshark

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:

tecpreplay

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

wireshark

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.

tcpreplay

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.

tcpreplay

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

tcpreplay

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.

tcpreplay

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!

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.

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.

PROFINET-PTCP

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.

ICSSPLOIT PROFINET-DCP

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)

ICSSPLOIT PROFINET-DCP

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.

ICSSPLOIT

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 .

ICSSPLOIT Stop S7-300

Y su arranque:

ICSSPLOIT Start S7-300

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.

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

Viendo los logs:

Control de Proveedores en entornos industriales OT

en total fueron 55 detecciones:

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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

Snap7

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

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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:

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

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.

Control de Proveedores en entornos industriales OT

Control de Proveedores en entornos industriales OT

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 .