Emular Port Mirror con Raspberry Pi (Parte I)

Hola:

Este artículo es la continuación del artículo: Instalación de Kali Linux en Raspberry Pi. Donde se explico como instalar la famosa distribución Kali Linux en una Raspberry Pi.

El objetivo que persigue este artículo es emular el funcionamiento de un Port Mirror de un Switch con una Raspberry Pi para obtener copias de los paquetes que viajan por nuestra red. Estas copias las podremos utilizar posteriormente para monitorizar la red o crear datasets de calidad. En esta primera parte, configuraremos el entorno para que nos resulte más amigable, profundizaremos en explicaciones y definiciones importantes y comentaremos varias de las problemáticas con la que nos iremos topando hasta conseguir nuestro objetivo final.

Una vez que hemos instalado en nuestra tarjeta microSD el sistema operativo Kali Linux para utilizarlo sobre la Raspberry Pi, procedemos con el primer arranque del sistema. Con lo que nos toparemos con una ventana de login para poder acceder a la sesión de usuario.

El usuario y contraseña por defecto es:

  • User: root.
  • Password: toor.

En mi caso, estoy comprobando que la Raspberry Pi A+ va muy justa, con tiempos de carga largos, parece que los 256 Mb de RAM se quedan cortos. Por este motivo voy a desactivar el entorno gráfico.

Para ello, desde un terminal, ejecuto lo siguiente:

nano /etc/X11/default-display-manager

Al final de la linea agrego “stop“.

/usr/bin/lightdm stop

Por último, reiniciamos el sistema para aplicar los cambios.

A partir de este momento la sesión de usuario se ejecutará a través de un terminal.

Lo siguiente será cargar el teclado en castellano, para ello simplemente ejecutamos:

loadkeys es

Comprobamos la hora del sistema mediante el comando:

date

En mi caso la fecha no es correcta. Por lo que la modifico de la siguiente manera:

date –set “2007-05-27 17:27”

Lo siguiente que voy a hacer es configurar la interfaz de red Wi-Fi.

Mediante iwconfig compruebo las interfaces que se encuentran disponibles.

Puedo verificar que existe una interfaz wlan0 que pertenece al módulo Wi-Fi que tengo conectado mediante una conexión USB a la Raspberry Pi.

Pasemos a configurar la interfaz para que se conecte a la red inalámbrica utilizando el protocolo de cifrado WPA2.

iwlist wlan0 scan | grep “essid”

Con el comando anterior compruebo si la tarjeta inalámbrica alcanza o detecta mi red inalámbrica  (Si el comando no devuelve ninguna salida es que no la ha detectado).

Como se trata de una red con WPA2 paso a generar la contraseña de la siguiente manera.

wpa_passphrase AQUI_ESSID AQUI_CONTRASEÑA > /etc/wpa_supplicant/AQUI_NOMBRE.conf

Mediante:

cat /etc/wpa_supplicant/AQUI_NOMBRE.conf

Verifico que se ha generado correctamente el fichero.

Por último, para que se conecte a la red automáticamente modificamos el siguiente fichero de configuración:

nano /etc/network/interfaces

Al que añadimos las siguientes lineas:

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/AQUI_NOMBRE.conf
iface default inet dhcp

He comprobado que la herramienta ifconfig no viene instalada por defecto, por lo que procedo a su instalación mediante:

apt-get install net-tools

Habría que tener varias cosas más en cuenta… pero todo esto se escapa del objetivo principal que persigue este artículo.  A través del entorno gráfico muchas de estas cosas resultan triviales y cualquier problema que pueda surgir seguro que se podrá solucionar con un par de búsquedas en google.

Antes de pasar a detallar las herramientas necesarias para emular un Port Mirror de un Switch daremos algunas explicaciones importantes que nos seran de vital importancia para comprender el escenario y los posibles problemas y conflictos a los que tendremos que enfrentarnos.

Port Mirror o Puerto espejo.
Port Mirror
o Puerto espejo es un puerto del switch que se configura para enviar copias de los paquetes que viajan por la toda la red. Normalmente con el objetivo de monitorear el tráfico de la red, tal como un IDS (Intrusion Detection System).

 

Escenario de red con Port Mirror.

 

Si estuviéramos en un medio compartido, cuando utilizamos un hub (Capa 1), bastaría con poner la tarjeta de red en modo promiscuo para obtener todos los paquetes que se propagan por la red. Puesto que lo que hace el hub es recibir un paquete por una de sus bocas (RJ-45) y reenviarlo por todas las bocas restantes, excepto por la boca por la que ha recibido el paquete. De ahí que sea denomine como medio compartido.

Si utilizamos un switch (Capa 2), la cosa cambia, pasamos a utilizar un medio conmutado, el switch mediante su tabla CAM, asocia cada una de sus bocas (RJ-45), sus puertos, con las direcciones MAC de los dispositivos que están directamente conectados a dichos puertos. Por lo que cuando recibe un paquete por una de sus bocas, extrae del paquete la dirección MAC de destino (el hosts de destino del paquete), la busca en su tabla CAM, y de esta manera conoce el puerto por donde debe de reenviar el paquete.

En este escenario, si ponemos la tarjeta de red en modo promiscuo tan solo capturaremos los paquete que son enviados a nuestro hosts. Por lo que para poder monitorizar tráfico de una red ethernet en un medio conmutado es necesario configurar uno de los puertos del switch como Port Mirror o puerto espejo.

Hoy en día, la mayoría de los usuarios utilizamos conexiones Wi-Fi en nuestros hogares para conectarnos a Internet. Cuando utilizamos una red Wi-Fi, estamos utilizando un medio compartido. En este caso, el medio es el aire, por donde se propagan todos los paquetes de forma inalámbrica a través de señales de radio.

Nuestro objetivo es capturar el todo tráfico Wi-Fi que se genera en nuestra red local, por ser este el escenario más habitual en la mayoría de los hogares.

A priori puede parecer que el escenario nos favorece, que nos facilita las cosas…. Lo cierto es que existen diferentes problemas que tendremos que ir solucionando para conseguir nuestro objetivo final.

Problemas a la hora de monitorizar una red Wi-Fi.
En este apartado pasamos a detallar todos los problemas con los que vamos a encontrarnos a la hora de monitorizar una red Wi-Fi.

Problema del canal en modo auto (channel-auto). Hoy en día son muchos los Routers/APs Wi-Fi que traen esta opción por defecto. Esta configuración lo que hace es: Elige el mejor canal cuando se inicia el AP, algunos, además, tienen una característica dinámica de canales que escanea las ondas en forma permanente (ya sea de forma continua o en intervalos establecidos) y cambian al canal que consideran que tiene una mejor calidad de señal.

Pongamos un ejemplo. El AP se inicia en el canal 1, cada x intervalos comprueba el resto de canales en busca de un canal mejor, detecta que el canal 10 es mejor, por lo que pasa a transmitir por canal 10.

A la hora del sniffing de redes Wi-Fi esto puede ser un inconveniente, puesto que nuestro sniffer tiene que estar muy atento y cambiar de canal al mismo tiempo que el AP. Puesto que si no lo hace, se perderían paquetes.

Esto se puede solucionar de varias formas:

  • Configurar el AP para que siempre utilice el mismo canal.
  • Realizar un MITM (Man in the middle u Hombre en el medio). Son muchos los que piensan que este tipo de ataques e una red Wi-Fi no tiene sentido, pero no es así. Por básicamente dos motivos.
    • Cuando la distancia entre el atacante y el AP es mayor que la distancia entre el cliente y el AP o cuando por motivos de una mala cobertura obtenemos perdidas de paquetes. Al realizar un MITM, el atacante solventaría estos problemas, puesto que todos los paquetes perdidos tendrían que ser reenviados ya que el cliente legitimo al no recibirlos volvería a solicitarlos, recuerda que para que los paquetes lleguen al cliente legitimo estos tiene que ser recibidos por el atacante para ser posteriormente reenviados al cliente legitimo.
    • Ciertos ataques necesitan controlar y modificar el tráfico en el momento (on-line). Por ejemplo, ciertos ataques al protocolo de cifrado SSL (Secure Socket Layer) bajo HTTP (HTTPS).
  • Configurar el sniffer para que salte de canal con el AP objetivo, indicándole para ello ciertas métricas. En este caso, la posibilidad de perdida de paquetes sigue siendo alta. Solo utilizaremos esta solución cuando no podamos tener acceso a la configuración del AP/Router Wi-Fi o no se trate de un ataque con objetivo marcado.

Las dos últimas opciones están descartadas por varios motivos.
La última opción podría perder paquetes, por lo que podríamos encontrarnos ante conexiones o sesiones incompletas.
La opción del ataque de MITM también la descartamos por dos motivos:

  • Por ser un ataque en sí. No queremos contaminar el tráfico que vamos a utilizar para generar el dataset y, por extensión, para entrenar el algoritmo de Machine Learning. A parte, tendríamos que realizar un MITM por cada equipo que se encuentre conectado a la red.

Por todos estos motivos vamos a utilizar la primera opción. Por ser está la opción más limpia y más sencilla de llevar a cabo.

Problema del estándar. Las redes Wi-Fi pueden trabajar con varios estándares, los más habituales a día de hoy son: IEEE 802.11 b, g, n y ac. El estándar ac utiliza la banda de 5 GHz (el resto utiliza la banda 2,4 GHz). Cada estándar define una velocidad máxima de transmisión.
La compatibilidad entre los diferentes estándares dependerá del dispositivo utilizado. Unos dispositivos pueden ser compatibles tan solo con los estándares IEEE 802.11 b y g, otros con los estándares IEEE 802.11 b, g y n y otros con los estándares IEEE 802.11 b, g, n y ac, dependiendo de la antigüedad del dispositivo. Lo ideal sería que todos los dispositivos de nuestra red, al igual que la interfaz que vamos a utilizar para el sniffing, soportarán el estándar de mayor velocidad. Puesto que la velocidad de la red no se vería reducida al estándar de menor velocidad. Sin embargo, en la práctica esta situación es difícil de conseguir.

En mi caso, la tarjeta que voy a utilizar para realizar el sniffing es una USD Edimax que utiliza los estándares IEEE 802.11 b y g. Mientras que los demás dispositivos que se conectan a la red Wi-Fi, se dividen entre los que utilizan los estándares IEEE 802.11 b, g y n y los que utilizan los estándares IEEE 802.11 b,g,n y ac.

Para evitar todo esto, he configurado el Router Wi-Fi para que solo utilice los estándares IEEE 802.11 b y g. Dicho de otro modo, he deshabilitado el uso del estándar IEEE 802.11n y he deshabilitado la segunda interfaz del Router Wi-Fi que utiliza la banda de 5 GHz (IEEE 802.11ac). De esta manera fuerzo a que todos los dispositivos utilicen el mismo canal y los mismos estándares.

Solo un modo, o MONITOR/RFMON o cliente. Otro de los problemas que nos encontramos a la hora de realizar un sniffing de red Wi-Fi, es que, la tarjeta inalámbrica que utilizamos no puede estar en modo cliente y modo monitor la vez, al contrario que pasa en ethernet, donde una tarjeta puede estar en modo promiscuo y trabajar como cliente, estableciendo conexiones y enviando o recibiendo paquetes. Precisamente esa es la diferencia fundamental entre el modo promiscuo de una tarjeta ethernet y el modo monitor o RFMON de una tarjeta Wi-Fi.

Tráfico capturado cifrado. El problema anterior provoca que todo el tráfico que capturemos mediante el sniffing será tráfico cifrado, no en texto plano. Por lo que tendremos que descifrarlo posteriormente. Esto tiene el inconveniente que antes de analizarlo tendremos que descifrarlo y esto solo es posible como veremos si capturamos el apretón de manos de 4 vías o four-way handshake y solo del tráfico posterior a este paquete.

Generación de “ruido”.  Al realizar un sniffing Wi-Fi no solo vamos a capturar el tráfico de nuestra red, también capturaremos tráfico de canales cercanos por temas de solapamiento de canales, a parte, de todo el tráfico Wi-Fi, beacons (balizas) que no nos sirve para nada, todo esto aun realizado filtrados muy detallados. Esto tiene solución, aunque es más un problema de espacio que un problema de “limpieza”.

Hasta aquí el artículo de hoy. Al final he decidido dividir el artículo en al menos dos partes (espero que no mucho más). Siempre me ocurre lo mismo, empiezo a explicarlo todo, me voy por las ramas y al final me quedan artículos más extensos de lo que pretendía.

El la Parte II comenzaremos a meterle mano a todo esto.

Un saludo.
NeTTinG.

Publicado en Artículos, Machine Learning, Seguridad Informática
One comment on “Emular Port Mirror con Raspberry Pi (Parte I)
  1. […] Artículo de continuación: Emular Port Mirror con Raspberry Pi (Parte I). […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: