Puerto espejo, un aliado a veces olvidado.

Como hemos hablado en otras ocasiones, poco a poco se va extendiendo el uso de protocolos industriales basados en tecnología Ethernet en lugar de los tradicionales serie. Esto, si bien permite otra manera de interconexión, también abre nuevas posibilidades en la denominada Industria 4.0. Sin embargo, obliga a tomar cierto tipo de medidas en cuanto a Ciberseguridad se refiere ya que los dispositivos y sistemas que intervienen en los procesos de control y automatización no sólo comienzan a estar más expuestos sino que son susceptibles de sufrir los mismos problemas con ciertos agravantes.

No obstante, aunque se trate de comunicaciones Ethernet, los equipos de networking industrial no sólo conservan funcionalidades tradicionales, sino además otras propias de estos entornos como MRP en contraposición a STP, Spanning Tree Protocol.

Una que puede sernos de mucha utilidad, sin menospreciar a otras tantas, es la de “Port Mirroring” o Puerto Espejo. Esto es, la capacidad de un Switch para poder replicar el tráfico que pasa por dos o más puertos y enviarlo por un tercero. Para entender mejor este concepto haré un repaso sobre cómo funciona un switch. Aunque sea algo bastante obvio para Técnicos de Comunicaciones o Administradores, seguramente no lo sea tanto para otros de Mantenimiento o Ingenieros de Procesos.

Esquema_01

Pongamos un ejemplo con dos equipos llamados “HMI” y “PLC”. Para comunicarse el equipo “HMI” con el “PLC” deberá conocer la IP del de “destino” y, al darse cuenta que está dentro de su misma red, deberá obtener entonces la MAC de éste. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “HMI” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cual se pregunta contestará con un ARP Replydiciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “HMI” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la comunicación no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory) en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

Ahora bien, si por distintas razones necesitásemos conocer el tráfico que pasa en entre “HMI” y “PLC”, no podríamos conseguirlo ya que el switch sólo conmuta el tráfico por los puertos involucrados. Aquí es donde aparece el concepto de “Port Mirroring” o “Puerto Espejo”. Mediante esta funcionalidad lo que conseguimos es que el switch haga una copia de dicho tráfico y lo envíe por un tercer puerto. ¿Con qué finalidad? Por ejemplo, si en este último conectamos un analizador de tráfico, podremos estudiar todo aquello que suceda entre “HMI” y “PLC” y detectar posibles anomalías sin interferir entre el flujo de comunicaciones. Obviamente el switch tiene que tener esta capacidad para hacerlo, sino… no hay nada que hacer.

Si bien las tasas de transferencia en entornos OT son menores que en entornos IT, esto no quita que debamos tener presente algunas consideraciones. Por ejemplo, si las comunicaciones son Full-Duplex (enviar y recibir a la vez) y el enlace es de 100 Mbps, el tráfico que puede llegar a recibir un equipo es de 200 Mbps, 100 Mbps para enviar y otros 100 Mbps para recibir. Si el enlace del puerto espejo es también a 100 Mbps el consumo de ancho de banda entre “HMI” y “PLC” no puede ser superior al 50%, ya que estaríamos superando la capacidad del mismo. O bien, que sea de una velocidad inferior, por ejemplo, a 10 Mbps. En esos casos, el switch descartaría paquetes con lo que el tráfico capturado no se correspondería con la realidad. Aparte, claro está, de la carga computacional que supone para la CPU del propio switch la copia de las tramas. A esto hay que sumar otras limitaciones que cada fabricante pueda considerar en sus productos.

Sin duda es un buen recurso, pero como comento, hay que tener en cuenta algunos aspectos técnicos.

A continuación, pondré ejemplos sobre su implementación en equipos. En la siguiente imagen se muestra una captura de la configuración de un switch Mikrotik RouterBoard 260GS, el cual dispone de 5 puertos RJ-45 10/100/1000 + 1 SFP.

Port Mirroring SPAN Puerto Espejo

Según cómo está configurado, estaríamos haciendo una copia del tráfico tanto saliente como entrante del puerto 1 que es dónde en teoría habría conectado un PLC y la enviaríamos por el puerto 2 donde conectaríamos un sniffer que lo recogería para un posterior análisis. Un clásico de este tipo de funciones es el archiconocido Wireshark. También podríamos seleccionar sólo uno de los sentidos, o bien el saliente o entrante según sean nuestras necesidades.

Port Mirroring SPAN Puerto Espejo

Lo cierto es que ese dispositivo resulta de mucha utilidad ya que por su pequeño formato puede ser utilizado en tareas sobre equipos finales como supervisión, diagnóstico, troubleshooting, etc. Aparte, al disponer de un módulo SFP podremos conectarlo a enlaces de fibra o par de cobre.

Ya sobre equipos de red tradicionales, podemos poner un ejemplo con switches Cisco. La funcionalidad la recoge este fabricante como puerto SPAN (Switched Port Analyzer). Aquí las posibilidades, como es lógico, son mayores y pasamos a la interfaz de consola. Podéis encontrar más información en este enlace.

Hasta ahora hemos visto switches “tradicionales”, sin embargo otros específicos de entornos OT también poseen esta funcionalidad como los muestra SIEMENS en este enlace y de donde se extraen las siguientes imágenes.

Port Mirroring SPAN Puerto Espejo Siemens

Port Mirroring SPAN Puerto Espejo Switch Siemens

Sin embargo esto no es exclusivo de equipos de networking. Por ejemplo, el fabricante Fortinet la incluye en sus dispositivos. A continuación se muestran capturas sobre un FortiWifi 60D con versión de FortiOS 5.4.5. Como podemos ver la forma de acceder a ella es a través del apartado de “Interfaces”.

Port Mirroring SPAN Puerto Espejo Fortigate

En mi caso “HW_SW_01”, y ya en su configuración veremos el campo correspondiente:

Port Mirroring SPAN Puerto Espejo Fortigate

Como vemos el criterio es similar, interfaz a monitorizar y a hacia cuál queremos enviar la copia de los paquetes. Haciendo una prueba, he conectado en el puerto “internal1” un servidor Modbus (10.10.10.100) y desde el puerto “internal2” (10.10.10.200) el cliente desde cual hacer las lecturas. Finalmente, un equipo con Wireshark en el puerto “internal3” donde capturar el tráfico.

Wireshark_Modbus_01

Un caso de uso podría ser en un equipo donde se le aplique una estrategia de “Virtual Patching” y necesitemos saber qué es lo que está sucediendo desde, hacia, él. Hace tiempo escribí a este respecto, os dejo los enlaces:

Hasta aquí la entrada de hoy con la que espero hayáis podido descubrir una nueva funcionalidad de vuestros equipos. Puede que escondida, pero seguro de utilidad en un futuro. Las aplicaciones pueden ser varias, espero poder escribir sobre alguna de ellas. Sólo falta tiempo.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Edorta

Identificando tráfico en redes ICS, Grassmarlin.

Son muchos los motivos que nos pueden llevar a realizar un análisis de tráfico, desde una auditoría, documentación de tráfico, hasta una labor de troubleshooting, etc. En concreto esto cobra mayor importancia en los entornos industriales con la evolución de los protocolos de comunicaciones hacia estándares Ethernet y TCP/IP permitiendo la integración con otros sistemas y tecnologías dando lugar a la llamada Industria 4.0 e IIoT.

Pero esta integración también tiene sus riesgos, ya que el grado de exposición dentro de la red aumenta con lo que resulta necesario implementar estrategias de seguridad que reduzcan los riesgos de sufrir un incidente.

Dentro de un proceso de securización, en concreto, de un entorno industrial, una de las primeras zonas donde intervenir es a nivel de infraestructura de red. Aquí surgen dos conceptos importantes como son “Separación” y “Segmentación”. Por separación entendemos dividir las redes de entornos IT tradicionales como por ejemplo “Oficinas”; y las redes de automatización OT como pueden ser las de producción en una empresa manufacturera. Entre cada una de ellas es necesario instalar un elemento de seguridad que filtre todas aquellas comunicaciones entre ambos entornos, siendo el más común un NGFW que además de las funciones tradicionales de un cortafuegos añada una capa más de seguridad con motores Antivirus, IDS/IPS, Control de Aplicación, DPI, etc.

Separacion_01

Hecho esto, la siguiente fase es segmentar nuestro entorno OT. Esto es, fraccionar en áreas, zonas, celdas, más pequeñas nuestra red o conjunto de redes, de tal manera que en caso de incidente en una de ellas, éste no se propague al resto y ponga en peligro la totalidad de las instalaciones. Recordemos que la regla número uno es garantizar la “Disponibilidad”. Esto requiere que todo el tráfico de cada una de estas áreas, celdas, etc. pase nuevamente por un dispositivo tipo NGFW y quede condicionado a unas políticas de seguridad preestablecidas.

Escenario_01

Ahora bien, para que todo esto funcione deberemos en primer lugar identificar el tráfico y realizar el análisis del que hablaba al principio.

El primero de los pasos será capturarlo para posteriormente realizar el análisis para extraer de él la información que necesitemos. Para llevar cabo esta tarea contamos con la aplicación Grassmarlin.

GrassMarlin es una herramienta destinada a entornos industriales y sistemas SCADA con la que podremos llevar a cabo:

  1. Identificación de tráfico
  2. Descubrimiento de dispositivos.
  3. Representación lógica y física.
  4. Gráfico de segmentos o arquitecturas.
  5. Exportar información a formato .CSV.

Todo ello lo realiza de forma pasiva sin interceder en la operativo normal de la operación de los equipos. Para ello permite dos opciones:

  1. Interpretar la información contenida en un fichero PCAP
  2. Captura de tráfico con la propio Grassmarlin.

Para conseguir esta información sin interceder en la operativa, la forma de hacerlo es la configuración de un puerto en modo “port-mirroring” (puerto espejo) de tal manera que recibamos una copia de todo el tráfico hacia/desde otros que sean de nuestro interés. Os dejo dos enlaces ejemplo sobre cómo hacerlo sobre dispositivos de distintos fabricantes.

Siemens

Cisco

Es posible descargarla desde aquí, estando disponible para sistemas operativos Microsoft Windows y Linux. Su última versión es la 3.

Para el presente artículo voy a partir de una captura que importaré a Grassmarlin.

captura_01

En la zona de “Network Tree Map” podremos ver tanto las redes y los nodos existentes; mientras que en la parte derecha la “Logical View” la forma gráfica de la misma con los enlaces entre uno y otro.

Si sobre uno de los nodos hacemos “botón derecho”, “Show all connections” podremos ver todas aquellas relacionadas con éste, junto con un gráfico representativo del tamaño del paquete en función del tiempo.

captura_02

Si sobre uno ellos hacemos nuevamente “botón derecho” podremos ver dicha captura en Wireshark. Esta aplicación se instala por defecto, pero en una versión antigua. Si disponemos una más reciente, podremos configurarlo en “Option – Preferences – Wireshark Executable Path” y abrirlo con ésta. Luego, en la esquina inferior derecha tendremos la opción de exportar el contenido a un fichero con formato CSV y a partir de ahí formatear y explotar la información para uno u otro propósito.

captura_03

La aplicación incluye por defecto algunos identificadores como pueden ser los primeros 24 bits que hacen referencia a los fabricantes en las direcciones MAC. No obstante, si no localizamos alguna podremos dar de alta nuevas en función de nuestras necesidades.

captura_04

Lo mismo ocurre con los protocolos.

captura_05

Allí encontraremos un buen número de ellos, pero si en el caso de que queramos bien editar uno existente o crear el nuestro propio, tendremos la capacidad de hacerlo. Aquí os dejo una muestra de modbus.

captura_06

Finalmente comentar que Grassmarlin dispone de una vista física. Esto es una representación de los equipos. Según he visto en distintas webs, la versión 3 sólo dispone de compatibilidad con dispositivos Cisco. La información que deberemos contener en un fichero de configuración para su importación es el resultado de los siguientes comandos:

  1. “show running-config”
  2. “show ip arp” (OU) “show mac address-table”
  3. “show interfaces”

Como podemos comprobar Grassmarlin puede sernos de mucha utilidad. En el proceso de trasformación de la industria y de la inclusión de políticas de ciberseguridad, identificar el tráfico resulta vital. Es muy común que los responsables o personas involucradas en procesos de fabricación, ingeniería, mantenimiento, etc. no estén familiarizados con todos estos términos y ni conozcan cómo y de qué manera se comunican sus equipos. Como mucho te puedan decir, si tal o cual equipos lo hace con tal o cual servidor o dispositivo, pero hasta ahí. Esta herramienta nos podrá facilitar mucho esta tarea y sobre todo poder comenzar a documentar todo aquello que sea necesario y evitar así esta situación.

Espero que os haya gustado, nos vemos en la siguiente.

Edorta

Herramienta whatportis para resolución de puertos

Una de las tareas obligadas dentro de la seguridad sea cual sea la circunstancia en la que nos encontremos, auditoría, administración, pentesting, consultoría, etc. es el análisis de tráfico. Si ya resultaba evidente en los entornos actuales, esto cobra más importancia con la incorporación de cada vez más y más dispositivos en nuestras infraestructuras de comunicaciones. La llegada del llamado “Internet de las Cosas” y más concretamente en los entornos industriales con la proliferación de protocolos basados en Ethernet, está propiciando que nuestros switches, routers, puntos de acceso, firewalls, soporten más clientes y por ende más información a mover.

Es por esto que supervisar y analizar volúmenes, patrones y tipos de tráfico, resulta indispensable cara al cumplimiento de las políticas de seguridad de nuestra organización y reducir los riesgos de sufrir un incidente. Hay que reconocer que la tarea puede ser bastante tediosa, con lo que dependiendo de los entornos, deberemos contar con herramientas, que nos faciliten la tarea. Por citar algunas,

Fortinet FortiAnalyzer

HP IMC Network Traffic Analyzer

Ntop

Cacti

Pero hoy no voy a hablar de ninguna de ellas, sino de otra más sencilla pero de  bastante utilidad.

Dentro del tráfico capturado los tres parámetros más representativos son las direcciones IP y los puertos. Sobre las primeras resulta bastante sencillo identificarlas sobre todo en lo que se refiere a públicas y privadas. Me refiero a IPv4. Sin embargo en materia de puertos, si bien es fácil acordarse de los más empleados, existen otros muchos que seguramente no tengamos tan presentes.

Para ayudarnos en esta tarea contamos con una herramienta con la que podremos consultar de una manera rápida la información de un puerto y servicio asociado. Hablamos de whatportis. Se trata de un comando con el que podremos buscar tanto el número como el nombre por defecto.

Para su instalación:

root@kali02:~# pip install whatportis

Downloading/unpacking whatportis

Downloading whatportis-0.4.tar.gz (258kB): 258kB downloaded

Running setup.py (path:/tmp/pip-build-At_8q_/whatportis/setup.py) egg_info for package whatportis

Downloading/unpacking click==6.2 (from whatportis)

Downloading click-6.2-py2.py3-none-any.whl (70kB): 70kB downloaded

Requirement already satisfied (use –upgrade to upgrade): prettytable==0.7.2 in /usr/lib/python2.7/dist-packages (from whatportis)

Installing collected packages: whatportis, click

Running setup.py install for whatportis

Installing whatportis script to /usr/local/bin

Successfully installed whatportis click

Cleaning up…

root@kali02:~#

Por ejemplo, si deseásemos averiguar qué hay detrás del puerto 1194:

Captura 01

O bien, si deseásemos obtener el servicio asociado a una aplicación como por ejemplo mysql:

Captura 02

También podríamos buscar un patrón sin conocer el nombre exacto del servicio emplearíamos la opción –like. A continuación pondremos un ejemplo, con el término  opc  para averiguar la información sobre el protocolo utilizado en entornos SCADA:

Captura 03

La herramienta emplea la lista de puertos publicada por IANA la cual consulta regularmente.

Así pues dejamos la entra de hoy con una herramienta, que sin duda nos podrá ayudar en esa rápida y primera instancia en la identificación de puertos y servicios.

Un saludo y nos vemos en la próxima.