Herramienta: EtherNet/IP & CIP Stack Detector, Parte I

Anuncios

Como anunciaba en la entrada «Breve recordatorio de protocolos, industriales» podemos encontrar algunas herramientas o software que nos puede ayudar a obtener información sobre los equipos finales. Esta tarea denominado como «Information Gathering» es vital para poder conocer el equipo, tecnología, o componente sobre el cual queremos llevar a cabo distinto tipo de acciones. Obviamente nosotros lo haremos con fines éticos, pero también conviene tener en cuenta que una persona malintencionada puede emplearla con otra finalidad.

Hoy hablaremos cómo hace esta tarea sobre equipos que utilicen el protocolo Ethernet/IP para las comunicaciones. Ethernet/IP es la implementación de CIP (Common Industrial Protocol) para ser utilizado en redes Ethernet y ofrecer servicios basados en TCP/IP. Además permite la creación de arquitecturas tolerantes a fallos en forma de anillo a través de DLR (Device Level Ring), algo similar a lo que podríamos lograr con PROFINET-MRP. No  quiero extenderme mucho más en este sentido porque no es el objeto, pero os dejo un enlace donde encontraréis muchas más documentación.

ODVA, Document Library

Hoy hablaremos de la herramienta diseñada por el equipo del fabricante de soluciones de seguridad «Claroty». Éste ademas cuenta con un equipo de investigadores denominado «Team82» el cual publica diferentes e interesantes artículos.

Team82, The Claroty Research Team

Pues bien, esta empresa dispone en su cuenta de Github la herramienta «Ethernet/IP & CIP Stack Detector», con la que podremos identificar las características del equipo a partir cómo implemente el citado protocolo. Os dejo el enlace desde dónde os podréis descargar la misma y poderla instalar en un distribución. En mi caso lo he hecho sobre una Kali Linux algo antigua pero que me ahorra tener que adaptar las más nuevas para software más viejo.

Ethernet/IP & CIP Stack Detector, GITHub

Dicho esto, una vez que la ejecutemos podremos obtener la siguiente información y obtendremos los siguientes resultados:

A partir de aquí, podríamos empezar a buscar manuales y conocer sobre los recursos que pueden llegar a disponer así como las posibles vulnerabilidades que pudieran existir y si serían, o no, de aplicación…

Manual 1

Manual 2

Advisory 1

Advisory 2

Advisory 3

Con esto, ya solo toca meter horas revisando y contrastando contenido en los resultados de las búsquedas.

¡Nos vemos en la siguiente!

Gestión de redes y Ciberseguridad

Anuncios

Para que podamos bastionar, configurar, habilitar o deshabilitar servicios, características o funcionalidades de los equipos presentes en los entornos industriales, plantas, talleres, maquinaria, células de automatización, etc. éstos deben de ser capaces de ser administrables. Es decir, poder acceder a ellos bien de forma local o remota, a través de una interfaz gráfica, de texto o cliente software, y así poder llevar a cabo cambios sobre sus prestaciones.

En paralelo, con el creciente aumento de la conectividad los switches juegan un papel fundamental ya que es el primer elemento que permite a los dispositivos a ellos acceder a otros por medio de una red, bien Ethernet o Ethernet Industrial. Sí, una cosa son las comunicaciones en los entornos de oficinas o IT (Ethernet) y otra muy distinta la red de planta, periferia, o buses de campo sobre Ethernet Industrial.

Desafortunadamente, bien por cuestiones económicas o desconocimiento, la existencia de estos equipos no gestionados es muy muy amplia. Así como en entornos IT nadie imagina no poder configurar una VLAN, tener una interfaz de administración, configurar un puerto espejo, etc. en los entornos OT es muy común no disponer de ello.

Esto hace que cualquier equipo va a tener total visibilidad sobre los elementos de su subred por estar en el mismo dominio de Broadcast pudiendo descubrir bien a través de protocolos como LLDP, peticiones ARP, etc. los equipos allí presentes. Si esto lo sumamos a la existencia de redes planas en la que o no hay o todo es la misma VLAN el alcance es mucho mayor.

Menú de configuración switch Phoenix Contact

A esto hay que sumar la posibilidad que terceros, esto son ingenierías o proveedores, puedan conectarse a nuestras redes para llevar a cabo intervenciones programadas o puestas en marcha, lo que sumado a una falta de implementación de controles de acceso podría dar lugar al robo, copia o modificación no autorizada de desarrollos, programaciones, configuraciones o parametrizaciones hechas por cada uno de ellos. Y que dicho sea de paso puedan ser nuestra competencia.

Por ello desde un punto de vista de aplicación de seguridad en redes es vital que debamos desplegar switches que sean gestionables para poder aplicar esos controles y que un switch no gestionable no podrá. Pasamos de comunicar todo con todo, tener plena visibilidad a decir esto sólo debe comunicarse con esto y sólo esto debe verse con aquello.

Esto nos va a permitir aplicar de manera más eficiente estrategias como la microsegmentación o aplicar un control de accesos a más bajo nivel para aquellos escenarios donde tengamos que reducir el nivel de exposición de equipos más críticos. También es cierto que existen cortafuegos que permiten operar en capa 2. Por ejemplo, en modo “Transparent” para productos del fabricante Fortinet, “Virtual Wire” para Palo Alto o SCALANCE de SIEMENS.

En la teoría esto es un gran recurso, pero lamentablemente todo tiene un precio, tanto de adquisición como de mantenimiento. Comprar un NGFW y no renovar las licencias de soporte y actualización, poca protección nos va a ofrecer más allá de la capa 4. Aparte, claro está, que cada uno de ellos va a constituir un único punto de fallo, salvo que los despleguemos en HA (Activo-Pasivo; Activo-Activo) donde su coste será mayor.

Por ello resulta necesario que todo cuanto pueda aplicarse desde la electrónica de red, necesaria para el funcionamiento debe aplicarse. Así podrán llevarse a cabo una reducción del grado de exposición y delimitar los tráficos antes de que otro elemento como puede ser un de ser un cortafuegos, pueda llevar un filtrado sobre los paquetes o tramas.

Interfaz de gestión de Switch SIEMENS XC 208

Pero esto no es lo único que deberemos tener presente. Los equipos gestionables al poseer una interfaz para el acceso, bien gráfica o CLI a la que también debe aplicarse medidas de control, des habilitar funcionalidades no utilizadas, emplear protocolos que ofrezcan medidas para garantizar la confidencialidad por ejemplo de credenciales, etc.

Si un usuario no autorizado ganase acceso podría en un momento dado cambiar parámetros que pudieran generar inestabilidad en las comunicaciones, impedir acceso legítimo, creación de nuevos usuarios, entre otras muchas opciones. Por ejemplo, según la siguiente imagen des habilitar la redundancia para una topología en anillo.

Configuración de topología en anillo en switch SIEMENS XC208

Hasta aquí la entrada de hoy. Nos vemos en las siguiente donde trataremos más aspectos de sobre la protección de redes industriales.

Identificando tráfico con cortafuegos, Parte II

Anuncios

Hablábamos en la entrada “Más que IPs y puertos para proteger entornos industriales” la necesidad de identificar los protocolos e instrucciones para limitar aquellas acciones que pueden realizar sobre Sistemas de Control Industrial. Para llevar a cabo esta acción, podemos emplear soluciones como Nozomi SCADAGuardian la cual, entre otras funciones, permite realizar Deep Packet Inspection (DPI) y extraer la información que necesitamos.

Sin embargo, los  mismos cortafuegos que nos ayudan a “Separar y Segmentar” podrán ayudarnos en esta tarea. En “Identificando tráfico con cortafuegos, Parte I” veíamos como podríamos hacerlo con equipamiento del fabricante Fortinet. En el día de hoy abordaremos la misma tarea, pero con aquellos del fabricante Palo Alto.

El mismo, dispone del equipo PA-220R para proteger este tipo de entornos teniendo la capacidad para realizar DPI sobre protocolos de esta índole. Además, es apto para instalaciones de entornos tales como subestaciones o plantas generadoras de energía ya que dispone de compatibilidad con estándares como IEC 61850-3 e IEEE 1613. Sus características físicas le permiten operar en rangos de temperatura y humedad de -40-70º C y 10-90%; respectivamente, pudiendo evitar daños físicos en entornos hostiles y polvo en suspensión ya que carece de piezas móviles para su refrigeración. Igualmente dispone de doble alimentación proporcionando así redundancia en lo que suministro eléctrico se refiere.

Dicho lo cual, veremos que las interfaces pueden ser configuradas de distintos modos, entre ellas el “TAP” con el que podremos monitorizar y analizar el tráfico que le llega.

Más tarde, definiremos una “Zona” en la cual incluir la interfaz que recibirá el tráfico que replicaremos desde el puerto espejo del switch o un dispositivo TAP. La denominaremos “Analisis_Trafico_ICS” y le asignaremos la interfaz “ethernet1/8”.

Luego, habrá que crear una política en la que deberemos indicar como origen y destino la Zona configurada en los puntos anteriores e indicar qué aplicaciones queremos detectar.  En nuestro caso seleccionaremos “Any” para poder hacerlo sobre todas aquellas que recojan las firmas que hayan sido desarrolladas hasta el momento.

Adicionalmente podremos habilitar otros controles para la detección de amenazas tales como antivirus, vulnerabilidades, filtrado URL, etc. Esto nos permitirá identificar la presencia de actividades o tráfico malicioso ya presente en nuestra red. Como se puede apreciar hemos creado un “Security Profile Group” con alguno de ellos.

Hecho esto, el siguiente paso será comenzar a procesar tráfico. De igual modo que hicimos en la entrada “Identificando tráfico con cortafuegos, Parte I”, reproduciremos tráfico con la herramienta TCPReplay previamente capturado a partir de distintas fuentes. En este nos hemos decantado por IEC 60870-5-104 y BACnet.

A partir de aquí, en la pestaña “Monitor” podremos ver los logs generados según distintos resultados de ese análisis. Por ejemplo, continuación se muestra el contenido relativo al tráfico en sí mismo, esto es, IPs de origen destino, puertos, Aplicación, etc.

Pero como hemos dicho, también nos interesa analizar en busca de amenazas como intentos de intrusión, malware, etc. Esta información la localizamos en el subapartado “Threat”. En este caso vemos cómo de entre las capturas reproducidas identificamos la presencia del archiconocido “Wannacry”, algunas anomalías relativas a Siemens S7 o DNP3.

Con la interoperabilidad entre entornos IT y OT, es imprescindible conocer las comunicaciones que se realizan hacia/desde los equipos. Un activo no sólo se compone de los datos de fabricante, modelo, instalación, etc. también han de incluirse sus comunicaciones dentro del modelo de gestión de activos. Un firewall y sus funcionalidades extras serán tan eficientes como estrictos seamos con su configuración y mantenimiento.

Pero, para conseguirlo, hemos hacer la tarea previa de identificarlas y estructurarlas y para ello los mismos cortafuegos también pueden ayudarnos.

Un saludo, ¡nos vemos en la siguiente!