Creando un WIDS casero (II)

En la primera parte de la historia me quedé con mi flamante router D-Link 2740B recién flasheado con OpenWRT. Se me olvidó contar, al final de ese post, que lo último que hice fue una copia de seguridad para poder volver al punto donde lo dejé si fuera menester.

El objetivo de este esfuerzo es construir un sistema de detección de intrusiones en la red inalámbrica basado en un antiguo router y el software de Kismet. Kismet es un software que, de forma pasiva, es capaz de detectar los dispositivos y redes inalámbricas (802.11*) que hay en su rango de detección. Es una herramienta de captura de información muy útil pero, llegar a construir un sistema de detección de intrusiones a partir de estos mimbres es, más que nada, realizar una prueba de concepto o de factibilidad. El resultado de esta prueba de concepto podría ser una solución de seguridad para redes WiFi económicamente muy accesible (si la comparamos con soluciones de Meraki, Aruba, Fortinet o Mojo Networks) y que podría ser muy válida para PYMEs u oficinas o delegaciones pequeñas.

Menos rollos y vamos al tajo. Kismet tiene tres componentes:

  1. Kismet Drone que captura las tramas radio y las envía al servidor.
  2. Kismet Server que almacena las tramas capturadas.
  3. Kismet Client que proporciona acceso a los datos almacenados en el servidor.

En principio la idea es instalar el drone en el router D-Link y el servidor y cliente en un servidor virtual desplegado en el entorno ESXi del lab casero.

En este post, voy a abordar el intento de instalación del Kismet Drone en el router D-Link. Si este intento es satisfactorio, abordaré en posts posteriores la configuración del servidor y cliente Kismet.

En primer lugar, me conecto a través de SSH al router, empleando, como no podía ser de otra forma, putty:

Imagen8

Navego hasta el fichero /etc/network/config para ver la configuración de red que tengo:

Imagen9

Como vemos, no está configurada la red inalámbrica (todavía). Abordamos, a continuación, la instalación de Kismet Drone. Entro en LuCI y me voy a la opción System > Software:

Imagen10

y pulso el botón Update list:

Imagen11

Ahora busco kismet drone en la lista de paquetes disponibles …

Imagen12

y le doy a la opción “Install” …

Imagen13

¡Cagada!, el equipo no tiene espacio suficiente para la instalación de los paquetes necesarios.

He probado distintas alternativas (desinstalar LuCI, ir a una versión de OpenWRT más antigua, etc) y sigue sin tener espacio. El cacharro es verdaderamente antiguo y no queda más que reconocer la derrota.

Pero como sigo empeñado en intentarlo, voy a probar con la Raspberry Pi como drone. Más en el siguiente post.

Anuncios

Creando un WIDS casero (I)

Antes de nada aclarar, para quien no lo sepa, que WIDS son las siglas, en inglés, de sistema de detección de intrusiones inalámbricas (Wireless Intrusion Detection System). Un WIDS es, por lo tanto, un dispositivo que monitoriza las redes inalámbricas para detectar la presencia de puntos de acceso no autorizados y que puede tomar las contramedidas necesarias frente a esta situación (prevención de intrusiones).

La idea es, aprovechando que con el cambio en la red doméstica, mi antiguo router inalámbrico D-Link 2740B (que hacía las funciones de bridge inalámbrico) se ha quedado en paro, darle un nuevo servicio. Voy a utilizarlo como sonda de detección de intrusiones en mi red inalámbrica. No es que me haya vuelto paranoico es, simplemente, que quiero aprender algo.

d-link-dsl-2740b.3391432

Lo que pretendo hacer es montar un entorno de detección basado en Kismet que es una herramienta de código fuente abierto que se encarga de la captura y proceso de tramas 802.11. El principal problema al que me enfrento es que el router, tal y como viene de fábrica, soporta los estándares antiguos (802.11b/g) y no los más nuevos. El router hace como equipo de captura de tramas y tendré que montar un servidor específico (virtual) para el análisis de esas tramas. Veremos hasta dónde somos capaces de llegar.

En esta serie de post voy a intentar ser más preciso y detallado lo que, sin duda, va a redundar en una mayor longitud de los mismos. En esta primera parte, voy a describir el proceso de flashear el equipo y dejarlo listo para la detección.

El primer paso, y esto es importante, es pensar un poco por anticipado los pasos a seguir para no perder tiempo rehaciendo cosas. Para flashear el equipo necesito:

  • La imagen que voy a poner en el equipo.
  • Un equipo desde el que conectarme, transferir la imagen y realizar las primeras y más básicas configuraciones.

Descubrir la imagen de OpenWrt no es tarea fácil. La web, en formato Wiki no ayuda mucho y uno acaba dando mil vueltas. En primer lugar entro en la página correspondiente a mi modelo de router y veo que el chip que tiene es un BCM6358.

Busco, a continuación, en la tabla de hardware de la web de OpenWrt, los detalles técnicos del equipo y me lleva a esta página donde aparece el enlace a la imagen a descargar.

Imagen2

El equipo desde el que me voy a conectar al router para flashearlo va a ser mi Raspberry Pi con sistema operativo Raspbian. Fundamentalmente porque, como está encima de la mesa, es más fácil realizar los tejemanejes de cables y cambios de direcciones IP necesarios para poder configurar el router. Lo primero que hago es arrancar la Rasp y, a través de WinSCP copiar la imagen recién descargada a la Rasp.

Voy a flashear el router. En primer lugar, lo que necesito hacer es arrancarlo en el modo que permite la carga de imagen flash. Los pasos que sigo son:

  1. Conecto la fuente de alimentación del router.
  2. Conecto el cable de red de la Rasp al puerto 1 del router.
  3. Presiono con un objeto punzante el botón de reset del router y, con este botón presionado:
  4. Arranco el router (botón de power).
  5. El router se enciende y la luz de power parpadea, al cabo de unos segundos se queda fija en color rojo, momento en el que dejo de presionar el botón de reset.

En principio, ya me puedo conectar al router para subir e instalar la imagen de OpenWRT. Por defecto, el router tiene la dirección IP 192.168.1.1 y la interfaz eth0 de mi Rasp la dirección 192.168.1.12 por lo que debería haber conectividad.

Abro un navegador en la Rasp y me conecto a la dirección IP del router y voilá:

2016-09-11-103843_1360x768_scrot

Siguiente paso, pulso el botón “Elegir Archivo” y navego hasta donde se encuentra la imagen a instalar:

2016-10-17-225331_1360x768_scrot

Selecciono el archivo correspondiente a la imagen y pulso el botón “Update Software”. En principio da un error pero veo que el LED de encendido del router parpadea al igual que el LED de la interfaz a la que está conectado el cable Ethernet de la Rasp. Cuando el LED de encendido del router se queda fijo me conecto de nuevo por http a la dirección IP del router y accedo a la página de login de Luci (la interfaz web de OpenWRT). Introduzco el nombre de usuario (root) y sin contraseña, entro en el entorno OpenWRT:

2016-10-17-225654_1360x768_scrot

Lo primero que hago es configurar una contraseña para root:

2016-10-17-230123_1360x768_scrot

Y, a continuación, una dirección IP que me permita conectar este equipo a la red doméstica (la dirección 192.168.1.1 es la del router de acceso a internet).

2016-10-17-230835_1360x768_scrot

A continuación apago el router, conecto la interfaz ethernet de la Rasp al switch y la boca 1 del router a otra boca libre del switch y rearranco el router. Ahora, debería poder acceder desde mi PC (o cualquier otro equipo de la red) a la interfaz web de OpenWRT:

Imagen5

Imagen7

En el siguiente post de esta serie voy a entrar a transformar en router en una sonda de paquetes WiFi para detectar intrusiones.

La nueva red

Como soy un poco culo inquieto, he decidido cambiar de nuevo la red doméstica. En abril había montado la conectividad de mi entorno lab sobre la base de un antiguo router WiFi tuneado con OpenWRT. El entorno lab era una subred (192.168.2.0/24) que se conectaba a la red doméstica a través del susodicho router en modo repetidor.

Lo cierto es que la disposición funcionaba pero el rendimiento del enlace radio era muy mejorable. Para mejorar el rendimiento, decidí cambiar la arquitectura de la red.

En primer lugar adquirí un par de PLCs de la marca Devolo. En concreto, el producto dLAN 1200+ Starter Kit PLC que proporciona conectividades de Gb Ethernet sobre la red eléctrica. El aspecto que tienen los cacharros es el siguiente:

devolo-dlan-1200-plc-pl1110856_0

Un poco aparatosos pero, la realidad es que funcionan muy bien. Empleando estos PLCs puedo conectar a velocidades de Gb el router de acceso a Internet con los dispositivos que tengo en el lab y descargar la WiFi del lab.

Adicionalmente, para proporcionar conectividad, adquirí un switch de 8 puertos, en concreto un Netgear GS308 de 8 puertos 10/100/1000Mb. Sin embargo yo creo que es mas un hub que un switch.

5168e9kwtrL._SL1200_

Una vez establecidas todas las conexiones, fue necesario reconfigurar la red. Ahora, los equipos de la red cableada están dentro de la red doméstica (192.168.1.0/24) y no es necesaria una segunda subred para el lab. Esto requiere quitar alguna ruta estática configurada en el router de acceso a Internet así como la configuración de las direcciones IP de las interfaces del servidor ESXi.

Otra ventaja es que el PC de sobremesa que tengo está accesible a toda la casa sin necesidad de cambiar la conexión. Esto es importante ya que el PC actúa como servidor de impresión y tiene varios discos compartidos. Pot otra parte, al liberar el router OpenWRT voy a poder empezar a jugar con Kismet.

En resumen, el aspecto que tiene mi red doméstica es ahora así:

ca1

Replanteando la red (II)

En esta segunda parte voy a concretar los pasos seguidos para reconfigurar la red en el sentido anticipado en el post anterior. En principio, los elementos que tengo que tocar son:

  • El router de acceso a Internet
  • El router con OpenWRT
  • El PC de sobremesa
  • El servidor ESXi
  • Las redes virtuales del lab.

Vamos a ir paso a paso con cada uno de los elementos:

Cambios en el router de acceso a Internet

Este cambio es, a priori, uno de los más fáciles. No hay más que añadir ruta estática que envíe el tráfico dirigido a la red 192.168.2.0/24 a la interfaz WAN del router OpenWRT que tiene la dirección 192.168.1.2. Para ello, nos conectamos a la interfaz web de administración del router y configuramos la ruta estática:

red3

Cambios en el router con OpenWRT

Aquí es donde está realmente la chicha. Nos conectamos a la interfaz web del router basada en Luci:

red4

A continuación deshabilitamos la interfaz pseudobridge (starbridge) que implementaba el relay entre la red doméstica y la red del lab. Además eliminamos el paquete ralayd que ya no necesitamos (lo siento no tengo captura de pantalla de esto).

Configuramos la interfaz wireless estableciendo la dirección IP estática 192.168.1.2. Esta interfaz está asociada a la zona de firewall WAN.

red5
Creamos una interfaz que haga asociada a la LAN del lab y configuramos la dirección IP 192.168.2.1 (gateway de la LAN del lab). Asociamos esta interfaz a la zona de firewall LAN:

red6

Creamos dos rutas estáticas: una que dirija el tráfico hacia la LAN doméstica e internet hacia la interfaz wireless y otra que dirija el tráfico hacia la subred 192.168.2.128/25 (DMZ) hacia la dirección IP 192.168.2.4 donde va a estar el router VyOS virtual.

red7

Finalmente, configuramos las reglas de firewall que permitan el paso del tráfico desde la LAN doméstica (WAN en este router) y la LAN de lab:

red8

Con esto, el router OpenWRT debería quedar configurado.

Configuración del PC de sobremesa

La configuración del PC de sobremesa no debería ser un arco de iglesia. Abrimos el centro de redes y recursos compartidos, abrimos el enlace de los adaptadores, pinchamos el adaptador ethernet, seleccionamos Propiedades:

red9

Editamos las propiedades del protocolo de Internet versión 4, asignamos la dirección IP a 192.168.2.2, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1. Establecemos los valores de los DNS de Telefónica y ¡listo!:

red10

Configuración del servidor ESXi

La configuración a realizar en el servidor ESXi consiste en establecer la nueva dirección IP para la interfaz de red de administración. Para ello, arrancamos el servidor y, en la consola, establecemos la dirección IP de la interfaz de administración a 192.168.2.3, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1.

Configuración del servidor entorno virtual

Para configurar el entorno virtual, habilito la conexión ethernet del PC de sobremesa y deshabilito la WiFi y me conecto al servidor ESXi a través de vCenter:

red11

red12

Arrancamos el router VyOS y nos conectamos a la consola. Cambiamos, en primer lugar la dirección IP estática de la interfaz WAN.

red13

Cambiamos la interfaz de la DMZ para darle el direccionamiento correspondiente a la subred 192.168.2.128/25.

red14

red15

Configuramos la ruta estática de salida

red16

Finalmente eliminamos la reglas de NAT para la DMZ:

red17

En principio la red debería estar configurada y funcionando. En el próximo post vamos a realizar las pruebas.

Replanteando la red (I)

Comenté en un post anterior cómo había configurado la red para acceder al servidor ESXi. Esencialmente, lo que hice fue configurar un antiguo Router ADSL como un bridge WiFi mediante la instalación de OpenWRT. El esquema de la solución de conectividad que tengo desplegado es el siguiente.

red1

Tengo contratado el paquete Fusión fibra con Movistar. La ONT y el router están instalados en el salón y, directamente conectado al router están: el teléfono, el descodificador de Imagenio, un Android TV y una Play 3. Como la WiFi no llega  muy bien a toda la casa, instalé un repetidor WiFi.

A la WiFi se conectan los teléfonos móviles de la familia (4), los portátiles
de la familia (3), un par de tablets, un par de Kindles y, en la habitación de trabajo un PC de sobremesa que tiene conectados un escáner, una impresora y  varios discos duros compartidos en red. Además, en esta habitación de trabajo, está el router tuneado, al que se conectan por cable de red las dos interfaces del servidor ESXi y una Raspberry PI 2.

La solución de conectividad para el servidor ESXi basada en un pseudobridge sobre OpenWRT. La solución funciona pero, es cierto que, no a mi entera satisfacción.

El problema fundamental es que todo el tráfico del servidor ESXi pasa por la WiFi. Teniendo en cuenta que la WiFi no es uno de los puntos fuertes del router que suministra Telefónica, y el uso que la familia hace de ella, las probabilidades de saturarla son muy altas (prácticamente una certeza). Además la puñetera WiFi tiene cierta tendencia a caerse.

La idea es, dado que el PC de sobremesa (que es donde tengo instalado el
vCenter) tiene una interfaz ethernet (además de la WiFi), conectar esta interfaz al router con OpenWRT y las dos NICs del servidor ESXi. Esto haría que el tráfico del lab, con la excepción del tráfico Internet, se canalizaría por el router y no a través de la WiFi y me permitiría aprovechar el mayor ancho de banda de las conexiones de cobre.

Implementar esta solución supone convertir el pseudobridge en un router y segregar la LAN del lab de la LAN doméstica (192.168.1.0/24). Para el lab configuraré una nueva LAN (192.168.2.0/24). Las tareas a realizar son:

  1. Reconfigurar el router OpenWRT. Es necesario configurar la interfaz Wan (WiFi) con la dirección IP (192.168.1.2), deshabilitar la funcionalidad de pseudobridge y, en la parte LAN configurar dos subredes: la 192.168.2.0/25 para el PC de sobremesa (192.168.2.2) y las NIC del servidor ESXi (192.168.2.3 – Gestión y 192.168.2.4). La otra subred (192.168.2.128/25) la voy a dejar para el direccionamiento de la DMZ en el entorno virtual.
  2. Reconfigurar el router de banda ancha para añadir una ruta estática que dirija el tráfico destinado a la red 192.168.2.0/24 al router OpenWRT (192.168.1.2).

El esquema de red quedaría:

red2

Las ventajas que se me ocurre, proporciona esta solución son:

  1. Reducir el tráfico a través de la WiFi.
  2. Acelerar el acceso desde el vCenter a las máquinas virtuales.
  3. Evitar el doble NAT en la salida a Internet desde las máquinas virtuales (las de la DMZ).

Por otra parte, las desventaja fundamental es que el PC de sobremesa, al estar en una subred distinta al resto de los PCs, no puede compartir la impresora ni los discos duros sin desplegar un servidor de dominio (cosa que no pienso hacer). La solución pedestre es habilitar la interfaz ethernet cuando vaya a jugar con el lab y habilitar la interfaz WiFi el resto del tiempo.

Cómo hacerlo en el siguiente post.

La conectividad

Como ya he comentado en algún post anterior, el servidor que adquirí para mi lab casero no tiene (ni pretendo ponerle) conectividad WiFi dado que en la habitación donde trabajo sólo tengo conectividad WiFi, era necesario que buscara una solución de conectividad. En principio, esa solución de conectividad pasaba bien por instalar una solución de cableado PLC o bien buscar algún tipo de bridge WiFi. En cualquier caso, parecía claro que algo me iba a tocar comprar.

Resulta que tengo por casa un par de modems router ADSL antiguos y una idea era reutilizar uno de estos como base para la solución de conectividad del servidor. Los cacharros son un D-Link 2740B y un Belkin F5D7632-4.

d-link-dsl-2740b.3391432

DCP_1498

Buceando por Internet, encontré que existía un firmware, basado en Linux, DD-WRT que permite reciclar este tipo de equipos. Ni corto ni perezoso, busco en su base de datos si alguno de mis equipos estaba soportado pero, desgraciadamente, ninguno lo estaba. Mi gozo en un pozo, parece que no me libro de comprar un nuevo cacharro.

Buscando en Internet, descubro un nuevo sitio donde mantienen firmware open source para routers: OpenWRT. Al parecer, OpenWRT es un esfuerzo más open mientras que DD-WRT tiene una vertiente más comercial. Ambos parten de la misma base de código que no es otra cosa que un Linux embebido.

Busco en la base de datos de openWRT y descubro que para el Belkin no hay esperanza, sin embargo, el D-Link está soportado. Así que ¡manos a la obra! Ni la web de OpenWrt es de las más amigables del mundo ni yo me entero muy bien de cómo están organizadas las versiones de software así que en la página correspondiente al modelo de mi router me entero que la imagen que tengo que instalar es la experimental que tiene el problema que no tiene la interfaz web  Luci pero como se puede instalar a posteriori pues nada, a por ello.

Para la instalación del firmware voy a usar una Raspberry PI 2 que tengo con un Kali Linux. Me conecto a Internet con la Rasp a treavés de la WiFi y descargo las imágenes de OpenWRT, del firmware de mi router de la página de D-Link (por si acaso) y la última versión de Luci. A partir de este momento comienza el show, cojo aire y hago lo siguiente:

  1. Desconecto la rasp de la WiFi haciendo un down de la interfaz.
  2. Conecto un cable de red al puerto ethernet de la Rasp y a uno de los puertos del router.
  3. Configuro la interfaz ethernet de la Rasp a la dirección IP 192.168.1.2.
  4. Hago un reseteo del router en la forma específica para la carga inicial de firmware.
  5. 5. Abro una sesión de navegador a la dirección 192.168.1.1 (router) y me aparece una interfaz que me pide que seleccione la imagen a instalar.
  6. Selecciono la imagen a instalar (OpenWRT) y ¡adelante!
  7. Después de un par de minutos el router arranca, hago SSH al router y … ¡Me conecto!. Primer paso conseguido.

Ahora toca instalar Luci, pues vamos a por ello. ¡Coño! primer problema, para descargarme los paquetes, necesito que el router se conecte a internet y para esto tengo que configurar la interfaz WiFi del router para que se conecte a la WiFi casera, evitar el conflicto de direcciones IP, … Pero como no hay nada que perder, a por ello. Despues de una hora y un bote de cerveza está conseguido, hay ping desde el OpenWRT al 8.8.8.8 (DNS de Google) y lanzamos la descarga e instalación de Luci. Esto es fácil como en Ubunto pero en vez de apt opt.

Primera cagada, el dispositivo no tiene suficiente memoria para guardar el paquete e  instalarlo. Efectivamente, hago un df y todo está al 100%. ¡Mierda! al final va a haber que buscar un cacharro nuevo. Abro otro bote de Mahou y me pongo a mirar en Amazon qué comprar …

Antes de meter el pedido en Amazon de un repetidor WiFi con puerto Ethernet voy a hacer un último intento, voy a buscar en la última release de OpenWRT (Chaos Calmer) si hay una imagen estándar para mi router (la Wiki de mi modelo de router era antigua) y, efectivamente, la hay. Me la bajo a la Rasp y vuelvo a repetir los pasos numerados arriba. Esta vez el router arranca y, al conectarme, a través de HTTP aparece la página de Luci. ¡Cojonudo! ahora a configurar el bridge en modo cliente WiFi.

Descubro que lo que tengo que hacer es configurar un cliente WiFi en modo pseudobridge con relayd. Para no equivocarme sigo la receta y, en algún punto, la cago y no chuta. Después de un rato intentándolo decido que lo mejor es comenzar de cero y, por tercera vez, cargo la imagen en la flash, vuelvo a configurarla y esta vez lo consigo. Ya tengo mi bridge.