Archivo de la categoría: Monitorización

Supervisión de redes y sistemas. Seguridad, métodos, protocolos, entre otros.

Puerto espejo, un aliado a veces olvidado.

Posted on por
Anuncios

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 Reply, diciendo “–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.

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.

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.

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

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

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.

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

Syslog, ¿amigo o enemigo? Parte II

Posted on por
Anuncios

Aquí volvemos con la segunda parte. Como dijimos en el post anterior Syslog, ¿amigo o enemigo? Parte I, a continuación veremos que también puede tener inconvenientes …

Ahí va la primera!

Syslog emplea UDP, concretamente el puerto 514. Al emplear UDP podríamos generar fácilmente paquetes manipulados haciéndonos pasar por el equipo legítimo. Éstos los enviamos al servidor y conseguiríamos confundir, o engañar, a los administradores informando de supuestas actividades en los equipos que en realidad no están sucediendo. Y ¿con qué fin? Por ejemplo obligar a un administrador a que se conecte al supuesto equipo que está fallando. Ahí podríamos llevar a cabo un MITM o cualquier otro ataque factible que nos permitiese capturar, por ejemplo, las credenciales de este administrador que por otro medio no podríamos. Y aquí es donde quedaría incluida la idea que hablaba al inicio, la 1. Es decir, si directamente no podemos hacernos con ese usuario y contraseña, vamos a generar falsas alarmas para obligarle a que se conecte y mediante otro ataque cumplir con el objetivo inicial.

Vale, y esto, ¿cómo lo hacemos?

Pues con el generador de paquetes Mausezahn. No viene instalado por defecto en Kali, pero desde el instalador de software lo podemos hacer fácil.

Aquí os dejo algunos tutoriales que he encontrado, Link 1 , Link 2 , Link 3

Supuesto apagado de varias interfaces.

O bien podríamos decir que un Switch tiene una temperatura > 70º C. Aquí le introduciremos un retardo de 60 segundos entre mensaje y mensaje de forma indefinida. Ver columna de tiempo, la diferencia es de un minuto.

La segunda desventaja…

Basándonos en la primera, ¿qué pasaría si en lugar de mandar paquetes sueltos mandásemos 30, 50, 100, 200? ¿y si encima lo hiciésemos a intervalos distintos? Y para más difícil, que pasa si además lo hacemos supuestamente desde equipos distintos? Pues yo me volvería loco. Imaginaros la situación, empezar a recibir mensajes (que de normal no llegan) desde distintos equipos de la red. Vamos sembramos la confusión, y entre esa confusión un atacante podría iniciar otro ataque contra otro equipo. Es decir, el atacante desvía la atención del administrador hacia unos equipos que se supone están fallando, pero que en realidad no es así, y de mientras inicia un ataque contra otro sistema. Y además si éste equipo atacado genera algún tipo de alarma es más probable que pase desapercibida ya que estaremos generando un montón de otras falsas. Y aquí es donde incluiría la segunda idea, la 2. Esto es, generamos mucho ruido, provocamos que salten las alarmas y entre todas ellas nos camuflamos.

Estos ejemplos los he hecho utilizando un router que es lo que tengo más a mano, pero bien podría ser otros dispositivos.

Por ejemplo, los autómatas industriales también soportan Syslog. En el siguiente enlace podréis encontrar como lo aplican los de la gama Siemens S7-300.

Autómatas S7-300

Envío de mensajes Syslog en S7 CPUs

Library description: Sending SYSLOG messages with a SIMATIC S7 CPU

¿Y si en lugar de mensajes de un router mandamos haciéndonos pasar por un autómata? Os imagináis que pasaría si en una estación de transformación llegasen mensajes diciendo que una línea eléctrica se ha caído cunado no es así? ¿O que una entrada de un autómata está DOWN mientras que todo sigue funcionando?

Por ejemplo podríamos hace pensar que se podría estar llevando un ataque aprovechando un vulnerabilidad de los autómatas cuando no es así. Esto seguramente cuando poco sembraría una confusión que conllevaría un revuelo en mayor o menor medida y quién sabe si la toma de alguna decisión si haber ninguna necesidad. Ni qué hablar que tal vez paralelamente  sí que estuviesen llevando un ataque en sí mismo.

En fin es para pensarlo, bueno o malo que cada cual emplee Syslog según sus criterios y decida si es un amigo un enemigo.

Un saludo.

Syslog, ¿amigo o enemigo? Parte I

Posted on por
Anuncios

Hola de nuevo, aquí estamos con otra entrada. A decir verdad, me cuesta un poco la manera de catalogarla si como un ataque en sí mismo o bien como como un ataque que sirva de pantalla a otro. Bueno, principio quieren las cosas, así que vamos a ello.

Vamos a dejar momentáneamente las cuestiones técnicas a un lado para charlar un poco de otros conceptos. Cuando se trata de auditar o realizar un test de penetración no siempre hemos de ir directos contra nuestro objetivo. Esto es, quizás debemos comprometer primero un equipo o sistema y luego desde éste, dirigirnos al objetivo en cuestión. ¿Qué es lo que quiero decir con esto? Que muchas veces deberemos dar un “rodeo” o dar pasos “intermedios” para conseguir nuestro fin. Este es el concepto número 1.

Una vez dentro de ese proceso de “pentesting” una premisa es hacer el menor “ruido” posible para no ser descubierto ya que eso mismo es lo que trataría de hacer un atacante. Un atacante, procurará ser sigiloso, discreto, cauto, no sólo para no levantar sospechas sino para que las distintas medidas y equipos de seguridad no hagan saltar alarmas y delaten su presencia. Obviamente, no empleará configuraciones “por defecto” sino que modificará los parámetros, campos, según sus necesidades. Sin embargo, esto no tiene por qué ser siempre así. Me explico. La idea es que no te detecten, pero esto también puede lograse haciendo mucho ruido y colándote entre la multitud. Imaginemos a un ladrón que ha conseguido burlar las medidas de seguridad de un banco; se hace con el botín; tira una bomba de humo o gas lacrimógeno y hace que todos los clientes entren en “modo pánico” y salgan despavoridos de la oficina, entre ellos, el ladrón. Este es el concepto número 2.

Bueno, se me olvidaba. Para que el ladrón burle las medidas de seguridad una buena opción podría ser suplantar la identidad (spoofear) de algún miembro del personal del banco. Este es el concepto número 3.

Vale, vale, tanto rollo ¿para qué? ¿Qué tiene que ver esto con Syslog? Venga va, ahora sí nos metemos con las cuestiones técnicas.

Syslog es un protocolo con el que podemos hacer que un equipo o sistema (cliente) envíe a un servidor mensajes que informen sobre eventos en él. Entre otras cosas, podría ser:

1.- Acceso correcto o incorrecto al sistema.

2.- Anomalías de algún tipo.

3.- Cambios en las configuraciones.

4.- Errores en los sistemas.

5.- Otros…

Existen servidores de pago y también algunas versiones gratuitas como Free Kiwi Syslog Server u otros que podréis encontrar en Sourceforge. Iros allí y buscar por la palabra, como es lógico, Syslog.

Para esta entrada voy a tener 3 equipos. Un router virtualizado con GNS3, un servidor Syslog con el software Free Kiwi Syslog Server y un equipo con Kali Linux. Estos últimos en máquinas virtuales.

Aquí os dejo una muestra de lo que sería mensaje de un login del usuario “netadmin” al router.

Deshabilitar y habilitar de la interfaz Fastethernet 1/1.

El tipo de mensaje que recibamos irá en función del nivel de aviso que queramos que se nos comunique. A más nivel, mayor control de lo que pasa pero también tendremos más cantidad de mensajes y, dependiendo el número de equipos, que tengamos pues puede llegar a ser un poco caótico.

Esto es yendo a buenas pero ¿qué pasaría si alguien intentase lanzar un ataque para ganar acceso a nuestro equipo mediante la herramienta THC-Hydra?

Por cada intento de conexión recibiremos un aviso.

Una de las posibilidades que nos puede ofrecer el software de servidor Syslog es que cada aviso que recibamos podremos enviarlo a su vez por correo electrónico, lo cual puede llegar a ser de gran utilidad si creamos una cuenta específica para el servidor y recibimos los avisos a nuestro correo. Lo digo no para dar más trabajo sino para esos puestos que requieran hacer guardias o disponibilidad 24×7, etc.

Sin embargo, ¿son todo ventajas? Tal vez no, puede haber algún inconveniente. Eso lo dejamos  para la próxima….