Esta semana abordamos un tema muy interesante desde el punto de vista de la conectividad a partir del incremento del uso de los protocolos industriales basado en Ethernet Industrial. Tradicionalmente se emplean switches no gestionables, ahora bien ¿es este enfoque correcto desde el punto de vista de la ciberseguridad? la respuesta, en el vídeo.
Archivo de la categoría: Infraestructura de red
Herramienta: EtherNet/IP Explorer, Parte I
Continuando con el tema de Ethernet/IP y de las herramientas que pueden ser utilizadas para obtener información de nuestros equipos tal y como hablábamos en las entradas:
Herramienta: EtherNet/IP & CIP Stack Detector, Parte I
Herramienta: EtherNet/IP & CIP Stack Detector, Parte II
Hoy vamos a hablar de otra como es «Ethernet/IP Explorer». En mi caso esta herramienta la voy a utilizar sobre sistemas operativos Microsoft Windows aunque lo podremos hacer sobre Linux y descargarla desde el repositorio Sourceforge en el siguiente enlace:
Ethernet/IP Explorer & C## Stack
Con ella podremos encontrar dispositivos en la red local que empleen este protocolo y además mostrar, no sólo sus características, sino también información relativa a Clases, Instancias y Atributos de los diferentes objetos. Para tener un poco más de contexto recomiendo leer el siguiente documento:
Ethernet/IP; quick Start guide for vendors Handbook
Dicho esto un vez que la arrancamos procedemos a seleccionar la interfaz desde donde realizaremos la consultas y la IP del equipo de destino.
A continuación podemos ver algunas características como número de serie, producto y obtener el fabricante…
Hasta ahí todo más o menos igual con respecto a la anterior, pero una de las características para seguir obteniendo información sobre el equipo la podemos conseguir añadiendo «Clases» donde cada una de ellas nos dará más datos.
Entre ellos:
¡Nos vemos en la siguiente!
Herramienta: EtherNet/IP; CIP Stack Detector, Parte II
En la primera parte de esta entrada hablábamos de la herramienta «EtherNet/IP; CIP Stack Detector» y de cómo podemos obtener información de equipos que emplean este protocolo. Luego, a partir de los resultados obtenidos, podríamos ir un poco más allá y ver si alguno de ellos presenta alguna vulnerabilidad que pueda ser explotable.
Ahora bien, conocedores de la labor que realiza la herramienta, ahora vamos a ver cómo detectar su presencia y tomar medidas al respecto. Al utilizar el protocolo Ethernet/IP, y éste operar en Capa 7 del Modelo de Referencia OSI, necesitaremos de equipos que sean capaces de operar en ella. Si sólo nos quedamos en Capa 4, como mucho veremos el puerto de destino. Bueno, aunque lo tengamos y no lo tenemos configurado, estamos en las mismas.
El contar con equipos que implementen estas capacidades podemos tener VISIBILIDAD acerca de los flujos de datos, y por ende, nos ayuda a determinar anomalías de diferente índole. Insisto, VISIBILIDAD. Pues bien de eso es de lo que vamos a hablar hoy con respecto a la herramienta que hemos presentado en la parte I.
Control de Aplicación en entornos ICS/SCADA, Parte I
Control de Aplicación en entornos ICS/SCADA, Parte II
Para ello cuento con un equipo cortafuegos Fortinet Fortigate con las licencias capaces de detectar no sólo los protocolos sino también los comandos, instrucciones, órdenes que son capaces de mandarse a través de ellos. En este fabricante lo encontramos en la parte de «Security Profiles – Application Control – Operational Technologies».
Habiendo definido un perfil y aplicarlo en la regla que filtrará el tráfico, estaremos en disposición de empezar a tener la visibilidad a la que hacíamos referencia. Y «voilá» una vez que lanzamos de nuevo la herramienta…
SE NOS GENERAN TODOS ESTOS LOGS!!!!!!
Quizás podríamos pensar que es un comportamiento «normal» si es que disponemos de equipamiento que emplee Ethernet/IP, pero si vemos que esa dirección IP no es la de un equipo que deba iniciar comunicaciones contra los PLCs… algo falla… O bien, si yo tengo NO TENGO EQUIPOS QUE COMUNIQUEN O INTERCAMBIEN DATOS POR ETHERNET/IP sino por S7; FINS; Modbus; OPC-UA, OPC-AE; OPC-DA; BACNet; u otro de los tantos que nos podemos encontrar; ¿qué diablos hace ese tráfico ahí?
En mi opinión..
LAS COMUNICACIONES QUE SE PRODUCEN EN PLANTA DEBEN SER UN REFLEJO DE LOS PROCESOS.
Sin embargo, ahora viene otra cuestión, y es que esto es de mucha utilidad siempre y cuando sepamos interpretar lo que el cortafuegos nos indica. Si no contamos con personas capaces de entender los logs que nos llegan, sean administradores, analistas de seguridad, de nada nos va a servir. Por eso creo que es vital importancia contar con unos mínimos conocimientos de cómo funcionan los sistemas de control y automatización. Pero bueno, esa es otra historia…
Nos vemos en la siguiente!!
