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:
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:
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:
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:
Pero uno de los que me resulta especialmente «curioso» es el número #245 el cual nos proporciona información sobre la dirección IP privada del equipo y que difiere de la que nos hemos conectado. Ésta termina en X.X.X.239 mientras que que nos aparece es 192.168.13.11/24. Como podemos comprobar un usuario mal intencionado podría obtener información de manera remota del direccionamiento existente, auqnue éste se produzca a nivel de capa 2 del Modelo de Referencia OSI. Esto sumado a otra información que se obtenga por otros medios se conseguiría una imagen acerca de las redes o dispositivos que existen en la citada subred.
Quizás esto, a priori, puede no tener importancia pero en mi opinión desde luego que la tiene.
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.
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».
Allí si seleccionamos «View Signatures» podremos verlas que en este caso el fabricante ha desarrollado. En el momento de escribir este artículo está en 3020. OJO, no son 3020 protocolos industriales, en realidad son muchos menos ya sobre cada uno de ellos se pueden enviar diferente cantidad de comandos e instrucciones ya sean estos propietarios o estándar como se puede apreciar en la imagen siguiente. Y mas concretamente sobre el protocolo que nos atañe, Ethernet/IP:
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…
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.
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.
Viendo los logs:
en total fueron 55 detecciones:
Para terminar la desinfección es posible que se solicite un reinicio del sistema.
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.
Si actualizásemos el perfil del control de aplicación correspondiente, ya podríamos acceder al mismo, en la IP 192.168.0.1.
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”.
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.
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 .
