Archivo de la categoría: Simuladores

Snap7, suite para de PLCs y comunicaciones Siemens.

Posted on por

En lo que a comunicaciones se refiere, si en algo se caracterizan los Sistemas de Control Industrial es por la gran cantidad de protocolos existentes.  Según sean las operaciones a llevar a cabo estos pueden dividirse, principalmente, en dos grades grupos: “Fieldbus” y “Backend”. Dentro de “FieldBus” encontramos aquellos relacionados con tareas vinculadas a operaciones de proceso y control; mientras que en “Backend” los vinculados a funciones de supervisión, como lo son servidores y sistemas SCADA. Algunos ejemplos son:

Fieldbus:

  • Profibus
  • Devicenet
  • Canbus
  • Profinet
  • Ethernet/IP
  • CC-Link
  • SERCOS

Backend:

  • OPC
  • DNP3

En cualquiera de los casos el abanico existente es muy amplio y por si fuera poco a éstos hay que sumar los que cada fabricante desarrolla para sus propios productos. Tal es el caso de S7 de SIEMENS, objeto en día de hoy, aunque como podéis imaginar, no el único.

Fabricante Protocolo
OMRON FINS
HITACHI HI-Protocol
ROCKWELL RS-Logix
SCHNEIDER Unitelway
HONEYWELL UDC

Dicho lo cual, aunque tengamos que hacer una referencia al protocolo en sí, nos vamos a centrar en una suite llamada Snap7 con la que podremos imitar ciertas comunicaciones y comportamientos de igual modo que lo hicimos con Modbus en la entrada “Simulador de Protocolo MODBUS”.

Snap7 es un software multi plataforma para comunicarse de igual manera que lo harían de forma nativa PLCs del fabricante SIEMENS empleando tecnología Ethernet y protocolo S7.

Entre sus características principales destacan:

  • Arquitectura diseñada para 32 y 64 bits.
  • Software Open Source.
  • Soporte para varios sistemas operativos, Windows, Linux, MacOSX, etc.
  • Soporte para varios tipos de CPU.
  • No son necesarios librerías de terceros.
  • No es necesaria su instalación.
  • Modelos de transmisión de información síncrona como asíncrona.
  • Se incluyen algunas demos para su uso directo.

A día de hoy da soporte parcial a CPUs más nuevas como 1200 y 1500 y más antiguas como 200. Dentro de su estructura se definen 3 componentes principales los cuales son “Client”, “Server” y “Partner”.

Como digo, la aplicación está orientada para ser utilizada en comunicaciones Ethernet y  S7, no siendo necesario ningún adaptador especial.

La implementación del protocolo S7, base de las comunicaciones entre dispositivos SIEMENS, se soporta sobre una ampliación del protocolo TCP recogida en la RFC 1006 y titulada como “ISO Transport Service on top of TCP”. Esto es necesario ya que TCP esta orientado al envío de datos  no transmitiendo información sobre la longitud de la información contenida o sobre cuándo empiezan o terminan. Sin embargo, en aplicaciones de automatización, es indispensable operar orientado a mensajes. Esto es, enviar bloques de datos en los que el receptor sea capaz de reconocer, ahora sí, dónde terminan y finalizan cada uno de ellos. Con RFC 1006, se logra esto último ya que se incluye una cabecera que lo define, y por tanto, garantiza el proceso. Resumiendo, RFC 1006 es una aplicación dirigida a mensajes pero basada en TCP que está basado en datos.

Una vez descargada la aplicación, conviene leer el Manual de Referencia para conocer las capacidades, características, usos y otras cuestiones técnicas.

En mi caso voy a utilizar las “Demos” para Sistemas Operativos Windows los cuales encontraremos junto con el resto de versiones en:

snap7-full-1.4.2\rich-demos

snap7-full-1.4.2\rich-demos\x86_64-win64\bin

Allí encontramos tres aplicaciones:

  • clientdemo
  • serverdemo
  • PartnerDemo

Como se puede entender, hacen referencia a los dispositivos “Cliente” (Workstation, HMI o FieldPG), “Servidor” (PLC) y “Partner” (Comunicaciones entre PLCs); donde, los clientes sólo preguntan, los servidores sólo responden y los partner que pueden hablar de forma bidireccional bajo su propia iniciativa. En cualquiera de los casos, desde el punto de vista hardware, no importa cómo se lleven a cabo estas comunicaciones. Es indiferente de si se trata de un puerto de comunicaciones en la propia CPU 3XX-PN o CPU4XX-PN o un módulo tipo CP343 o CP443.

Para este ejemplo iniciaremos el serverdemo y tras configurar la IP (0.0.0.0 si lo corremos en la propia máquina) pincharemos en “Start”. En la parte inferior se puede ver un espacio donde se registran los eventos que a su vez pueden ser habilitados en la la parte superior.

Por otra parte arrancaremos el software cliente, donde deberemos especificar la IP del serverdemo. Puesto que ambas están en el mismo equipo la IP será la de loopback, 127.0.0.1.

ClientDemo_01

Y pinchando en “Connect”…. Voila! Estamos conectados, en teoría, a un PLC de la serie 300.

Luego exploraremos el contenido de las pestañas, como por ejemplo “Security”.

Para comprobar la manera en la que podremos interactuar debemos irnos a la pestaña “Control”. Como podemos ver, actualmente el PLC están “RUN”, pero si presionamos en “Stop” podríamos pararlo.

En el lado del serverdemo:

Y en el clientdemo:

La herramienta contiene otras muchas funcionalidades que viene reflejadas en el Manual de Referencia que podéis encontrar en el mismo paquete, aparte de distintas casuísticas y topologías. Sin duda Snap7 es un excelente recurso con el que aprender el funcionamiento no sólo de los PLCs del fabricante SIEMENS sino la manera en la que se comunican y explorar técnicamente todo lo que nos ofrecen. Muchas veces nos ceñimos a la parte teórica, buscamos información en uno y otro sitio, pero tener la posibilidad de montarnos nuestro propio laboratorio y simular un escenario por muy simple que sea nos permitirá aplicar todo lo leído y ayudarnos a entender mejor los Sistemas de Control. Así pues ahora toca ponerse manos a la obra.

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

Posted on por

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.

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

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

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.

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

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

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

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.

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

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

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.

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.

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 .

Conpot, Honeypot para ICS (Parte II)

Posted on por

Continuando la entrada anterior hoy vamos con esas pruebas que he hecho contra Conpot y de cómo éste se ha comportado.

A continuación veremos lo sucedido cuando he accedido por el puerto 80 desde un navegador.

A partir de aquí los log que revelan nuestro acceso.

Hasta aquí podríamos interpretarlo como algo relativamente común. Pero en el ejemplo que sigue requiere conocimientos técnicos y una buena dosis de premeditación y alevosía. Si desde otro equipo ejecutamos un escáner para detectar servicios sobre la IP ejecutando conpot:

Como podemos comprobar el honeypot recoge información como el tipo de paquete, datos del contenido del mismo, IP de origen, etc.

¿Un equipo enviando un paquete a un Honeypot bajo protocolo S7comm? Esto chirría un poco…

 

Otra de las posibilidades que tenemos es ejecutar alguno de los escáneres disponibles en Metaesploit en auxiliary/scanner/scada

Aquí detectaremos el servicio de Modbus en lugar de S7comm.

Finalmente otras de las pruebas que hice fué sobre SNMP. Desde Metaesploit lancé una enumeración mediante este protocolo.

Y sus respectivos logs.

También podríamos cambiar un OID de SNMP. Por ejemplo la dirección de correo:

Y registro de ello.

Como podemos comprobar Conpot puede ser de gran ayuda para detectar comportamientos anómalos en nuestra red y que vayan dirigidos específicamente a nuestros sistemas de control. Obviamente esta es una Prueba de Concepto y cara a su despliegue en nuestras instalaciones deberemos personalizarla para dar una mayor credibilidad en los resultados.

Con el creciente aumento de las amenazas y publicaciones de vulnerabilidades que afectan a entornos con estos equipos, tener un Honeypot que simule uno de ellos es necesario cara a localizar posibles brechas de seguridad. Obviamente trabajamos para no tenerlas y minimizar los riesgos, pero no estamos exentos de que algo, o alguien, pueda acceder a nuestra red y lleve a cabo algún tipo de acción malintencionada. Para esos casos, aquí tenemos un aliado.

Como es lógico, esta herramienta no nos protege de nuestras vulnerabilidades, pero sí nos avisa. El uso más común será detectar tráfico y comportamientos fuera de lo común en este tipo de redes pero no estaría de más poner uno en la red de oficinas. No sea cosa que el enemigo nos venga por ahí.  También nos puede ayudar cara a la realización de auditorias detectando posibles actividades no conocidas en las instalaciones de nuestros clientes y que puedan poner en peligro la disponibilidad de sus instalaciones.

En mi caso he utilizado una máquina virtual pero hay quién lo ha instalado en una RasperryPi, lo cual ya veis los recursos técnicos y económicos que requiere…

Aquí os dejo un enlace del SANS donde encontraréis una guía sobre cómo diseñar e implementar un Honeypot en un entorno SCADA.

Enlace

En fin, espero que os haya gustado la entrada de hoy. Como siempre, os invito a dejar vuestros comentarios.

Un saludo!