Instalar Snort en una Raspberry Pi (I)

En este post voy a mostrar la instalación del IDS Snort en una Raspberry Pi. Snort es un IDS de red (NIDS) que captura los paquetes que circulan en la red y sobre la base de una heurística programada por reglas, para cada tipo de intrusión, es capaz de disparar alertas.

En concreto, para este ejercicio, voy a emplear una Raspberry Pi 2B. Voy a partir de una instalación fresca de Raspbian Stretch Lite. El proceso de instalación del Sistema Operativo es exactamente el mismo que el descrito aquí. Por hacer un resumen rápido del proceso:

1. Descargo la imagen de Raspbian al PC de sobremesa.
2. Grabo la imagen descargada, empleando el programa Win32DiskImager.
3. Creo, en la partición de boot, un fichero vacío con nombre ssh, para habilitar el servidor SSH en el arranque.
4. Conecto la Raspberry Pi a la red a través del switch que tengo.
5. Arranco la Raspberry y averiguo (conectándome) al router de banda ancha, la dirección IP que le asigna por DHCP.
6. Me conecto por SSH empleando Putty a la Raspberry para continuar con la configuración inicial.

Una vez conectado por SSH realizo los siguientes pasos de configuración inicial:

1. Cambio la password por defecto:

pi@raspberrypi:~ $ passwd
Changing password for pi.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

2. Actualizo los paquetes instalados:

pi@raspberrypi:~ $ sudo apt update
pi@raspberrypi:~ $ sudo apt upgrade

3. Mediante el programa raspi-config configuro el teclado.

4. Adapto el fichero dhcpcd.conf para realizar la configuración de la dirección IP estática de la Raspberry.

# dhcpcd.conf

# Static IP configuration

interface eth0
        ipv4only
        static ip_address=192.168.1.28/24
        static routers=192.168.1.1
        static domain_name_servers=10.1.4.2 208.67.222.222 208.67.220.220

5. Creo el fichero dhcpcd.exit-hook para configurar las rutas a las redes del entorno de lab:

pi@raspberrypi:/etc $ cat dhcpcd.exit-hook
ip route add 10.1.2.0/24 via 192.168.1.4
ip route add 10.1.3.0/24 via 192.168.1.4
ip route add 10.1.4.0/24 via 192.168.1.4
pi@raspberrypi:/etc $

6. Rearranco y verifico que la dirección IP correcta y las rutas están establecidas.

pi@raspberrypi:~ $ ifconfig -a
eth0: flags=4163  mtu 1500
        inet 192.168.1.28  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::ba27:ebff:fec2:4299  prefixlen 64  scopeid 0x20
        ether b8:27:eb:c2:42:99  txqueuelen 1000  (Ethernet)
        RX packets 179  bytes 13849 (13.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 129  bytes 18433 (18.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@raspberrypi:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
10.1.2.0        192.168.1.4     255.255.255.0   UG    0      0        0 eth0
10.1.3.0        192.168.1.4     255.255.255.0   UG    0      0        0 eth0
10.1.4.0        192.168.1.4     255.255.255.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

7. Creo, en el servidor SVN el repositorio para los ficheros de configuración de la Raspi.

8. Instalo subversion para mantener la configuración de la máquina alojada en el repositorio SVN del entorno lab.

pi@raspberrypi:~ $ sudo apt install subversion

9. Creo, desde la Raspi, un directorio en el repositorio SVN para mantener los ficheros de configuración existentes bajo /etc. La operación va a avisar que los certificados que uso no son de una autoridad reconocida y me va a solicitar la autenticación

pi@raspberrypi:~ $ sudo svn mkdir https://svnrepo.tcantos.com/svn/rpisnort/etc -m ""

10. Hago un checkout inicial en el directorio /etc y añado al repositorio SVN los ficheros de configuración:

pi@raspberrypi:/ $ cd /etc
pi@raspberrypi:/etc $ sudo svn add hosts issue dhcpcd.conf dhcpcd.exit-hook hostname
A         issue
A         dhcpcd.conf
A         dhcpcd.exit-hook
A         hostname
A         hosts
pi@raspberrypi:/etc $ sudo svn commit -m ""
Adding         dhcpcd.conf
Adding         dhcpcd.exit-hook
Adding         hostname
Adding         hosts
Adding         issue
Transmitting file data .....done
Committing transaction...
Committed revision 2.

11. En el PC de sobremesa, creo el directorio para la copia local y hago un checkout. A partir de este momento puedo trabajar con los ficheros de configuración en el PC.

12. Añado las entradas correspondientes al nuevo equipo en la base de datos de mi servidor DNS y rearranco el servidor.

13. Por último, configuro que la Raspi sincronice tiempos con el servidor de tiempos del lab.

Con esto queda configurada la Raspberry Pi para los pasos siguientes.

 

Sincronizando Tiempos

Una de las cosas que faltaba en el entorno lab era una fuente de tiempo que permitiera mantener sincronizados los relojes de los distintos servidores. Disponer de una fuente de tiempo para la sincronización permite, entre otras cosas, una correlación precisa de los eventos y logs de la red.

La idea es, por lo tanto, desplegar un servidor NTP en la red del lab. El primer problema que me planteo es dónde conectar el servidor. Como lo que pretendo es que de servicio, no sólo a los servidores virtuales, sino a otras máquinas de la red incluso a los servidores de la red doméstica, no queda otra alternativa que colocarlo en la DMZ del entorno virtual.

Voy a crear, por lo tanto, un servidor virtual Ubuntu con dos interfaces de red, una hacia la DMZ y otra hacia la red de gestión. El servidor va a ser necesariamente pequeño (1 GB de RAM y 10 GB de disco). Una vez creado y realizada la configuración básica del servidor de acuerdo a los estándares de mi red procedo a instalar el servidor NTP que, en este caso, va a ser ntpd.

Conectándome como administrador, procedo a instalar el servidor ntp:

$ sudo apt-get update 
$ sudo apt-get install ntp ntpdate 

Una vez instalado, el servidor arranca y se pone a la escucha en el puerto 123 UDP:

$ netstat -atun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
udp        0      0 192.168.199.20:123      0.0.0.0:*
udp        0      0 10.1.4.16:123           0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp6       0      0 fe80::20c:29ff:feb7:123 :::*
udp6       0      0 fe80::20c:29ff:feb7:123 :::*
udp6       0      0 ::1:123                 :::*
udp6       0      0 :::123                  :::*

A continuación, es necesario configurar el servidor. Mi servidor NTP va a sincronizarse con los servidores del proyecto NTP Pool así que lo que tengo que hacer es editar el fichero /etc/ntp.conf añadiendo las líneas necesarias para conectarme al pool europeo de servidores. Además, por si acaso, añado los servidores del pool de Ubuntu y el propio servidor NTP para el caso de que no tenga una conexión a Internet:

Una vez salvados los cambios, rearrancamos el servicio ntp y verificamos que el servidor se sincroniza con las fuentes establecidas:

Verificamos el estado de sincronización:

Por último, lo que necesito hacer es que los servidores de la red sincronicen los relojes hardware con el servidor NTP que acabo de desplegar. En los servidores Ubuntu, el proceso es el siguiente:

1. Verifico que el reloj de los servidores se sincronice a través de la red:

2. Si al ejecutar este comando, el resultado es que Network time on está a no o NTP synchronization está a no lo que hay que hacer es ejecutar el comando siguiente:

$ sudo timedatectl set-ntp true

3. Comprobar a qué servidor de tiempos se conecta el equipo:

4. Si el servidor de tiempos al que se conecta no es el de nuestra red (como en el caso anterior), es necesario configurarlo correctamente. Para ello seguimos los siguientes pasos:

4.1. Editamos el fichero /etc/systemd/timesync.conf y establecemos el nombre de nuestro servidor NTP de la siguiente forma:

4.2. Rearrancamos el servicio systemd-timesyncd y, una vez que arranca, el servidor de tiempos debería ser el nuestro.

Montar un Servidor DNS en una Raspberry PI 2 (II)

En la anterior entrada, completamos la configuración básica de la Raspi. Algunas cosas más que no quedaron reflejadas en el post fue, por ejemplo, el establecimiento de la zona horaria. Esta entrada se centra en la configuración de la red.

Lo primero que voy a hacer es echarle un ojo a la configuración de las interfaces de red:

Lo que estamos viendo es que:

• El nombre de la máquina sigue siendo “raspberrypi”
• La dirección IP sigue siendo la que obtenemos por dhcp.
• Está activado IPv6. Dado que yo no uso IPv6 en mi red voy a deshabilitarlo.

Pasito a pasito. Para empezar, para establecer el nombre de la máquina edito el fichero /etc/hostname y pongo el nombre de la máquina con el dominio.

El establecimiento de la dirección IP estática lo hago editando dhcpcd.conf. Para ello, ya que es más cómodo que andar usando vi (o nano) me lo voy a traer al PC y usar un editor de texto más amigable. Para estos movimientos de ficheros utilizo WinSCP. Establezco, en dhcpcd.conf las siguientes líneas:

Los servidores de nombres los he establecido al propio host y a los servidores de OpenDNS. Después de estos dos cambios, rearranco y pruebo a ver si el nombre de máquina, el dominio y la IP ya están establecidos.

El nombre del host si cambió, la dirección IP no. Afortunadamente la Pi volvió a coger la dirección IP que le había dado el servidor DHCP. Tras dar unas vueltas con el syslog miro la configuración de las interfaces (ifconfig) y aparece esto:

No aparece la interfaz eth0 y aparece un nombre largo de interfaz. Lo que ocurre es que no está usando nombres de interfaces predecibles. Para corregirlo, edito el fichero /boot/cmdline.txt y añado, al final, la directiva net.ifnames=0

Rearranco y compruebo si ha cogido la nueva IP haciendo un ping desde el PC:

Ya no responde la 192.168.1.133 y ahora responde la 192.168.1.6. Voy a conectarme con putty a la nueva IP ver qué es lo que dice ifconfig:

La interfaz eth0 ya está bien configurada pero sigue estando activo el IPv6. Investigando un poco, para deshabilitar IPv6 hay que añadir la directiva ipv6.disable=1

Rearranco y verifico que IPv6 ya no aparece. Para terminar con esta parte y, antes de instalar bind, voy a comprobar si el servicio avahi está activo y si lo está, desactivarlo:

Como se ve está activo, así que lanzo el comando:

sudo systemctl disable avahi-daemon

Rearranco (una vez más) y compruebo que el servicio esté desactivado. En la siguiente entrega, la instalación de bind.

Montar un Servidor DNS en una Raspberry PI 2 (I)

Después de llevar mucho tiempo sin publicar voy a seguir registrando mis experimentos. Lo que voy a intentar es montar un servidor DNS para la red doméstica sobre la Raspi.

Para empezar, un poco de planificación. Ya tengo un servidor DNS en el entorno lab montado sobre Ubuntu y ser capaz de operar con dos servidores es un reto. Las posibilidades de configuración son casi infinitas pero me decido por tener dos servidores master que, lo único que significa es que ambos servidores tienen su propia copia de la información de zonas que sincronizaré (espero) a través del servidor de svn. La idea es que puedan funcionar de forma independiente y que no necesite tener arrancado uno u otro para que todo el entorno funcione.

La ventaja de una configuración Master – Slave es que los datos de zona están en un solo sitio (en el master) y el slave accede a ellos a través de transferencias de zona. La desventaja es, por supuesto, que para que pueda darse la transferencia de zona, el master tiene que estar arrancado.

Hay otra configuración posible que es configurar el DNS del lab virtual como stealth master pero, a estas alturas del partido, me parece complicar mucho el entorno y no tengo claro que, para que esto funcione, no tenga que tener arrancada la Raspi además del DNS en la DMZ del entorno virtualizado. Así que configuración master – master y replicación de la información de zonas a través de svn.

Para empezar voy a partir de una instalación limpia de Raspbian sobre una tarjeta MicroSD de Clase 10 de 16GB. La Raspi va a conectarse sólo por cable ethernet a través de un switch de 8 puertos. La dirección IP va a ser fija (192.168.1.6), dentro del rango de direccionamiento de la LAN doméstica (192.168.1.0/24). La la Raspi va a ser headless así que toda la configuración la voy a hacer a través de SSH.

Lo primero es descargarse Raspbian, como quiero un sistema lo más simple posible, me descargo la versión Raspbian Stretch Lite. Descomprimo la imagen descargada y mediante Win32DiskImager grabo la imagen a la tarjeta SD.

Una vez que acabe la grabación, insertaremos la MicroSD en la Raspberry y estaremos listos para el primer arranque de Raspbian.

El primer problema es encontrar la Raspi en la red. Probablemente obtenga una dirección IP por DHCP (está conectada por cable ethernet) pero no sabemos cuál es. La forma fácil es conectarse al router y ver qué dirección le asigna:

Le ha asignado la dirección 192.168.1.133. Nos conectamos a esta dirección mediante putty y … ¡Houston tenemos un problema!, la Raspi rechaza la conexión. Resulta que Raspbian viene con el SSH deshabilitado por defecto. La solución, para habilitar SSH es crear un fichero vacío, de nombre SSH en la partición de boot de la Raspberry. Apago la Rasp y saco la MicroSD y vuelta al PC.

Expulsar la SD, extraer la micro, insertarla en la Raspi, arrancar de nuevo e intentar de nuevo la conexión con putty. En el primer intento voy a confiar que el servidor DHCP le haya asignado la misma IP, sino es así, me tocará repetir los pasos que he hecho antes con el router de banda ancha.

Aparece el mensaje de advertencia de seguridad en la conexión SSH en relación con la clave del host, pulso “Sí”:

Me aparece la consola solicitándome las credenciales del usuario. Introduzco las credenciales por defecto (pi, raspberry) y entro:

Como soy un tío serio, antes de nada voy a cambiar la contraseña del usuario:

El siguiente paso es actualizar los componentes del sistema operativo:

Tras un rato actualizando cosas y un rearranque abordaremos el último paso para dejar la Raspi lista para el combate. Este último paso es expandir la partición root para usar todo el espacio de la tarjeta MicroSD. Primero lanzo el comando lsblk para ver cómo está el almacenamiento y veo (sorpresa) que está ocupado todo el almacenamiento de la tarjeta. Así que no hay nada que hacer.

De haber sido necesario hubiera utilizado raspi-config.

Más en la siguiente entrega.

Revitalizando un antiguo PC

Una de las causas de que haya estado un cierto tiempo alejado sin publicar nada es que, a 31 de diciembre, dejaba la compañía donde he trabajado los últimos 27 años. La verdad es que la dejo en unas condiciones magníficas y, en ese aspecto, no tengo ninguna queja. En la empresa me han dejado llevarme el PC corporativo que tenía, eso sí, tras el preceptivo borrado de los programas licenciados y formateo del disco duro.

El PC en cuestión es un Dell Latitude E5430 que trae un I5 a 2,60GHz y 4GB de RAM. La batería todavía aguanta aunque está empezando a pedir oxígeno. El resto supongo que es bastante estándar.

El PC lo voy a emplear para trastear un poco incluyendo practicar pen-testing pero, para esos menesteres, prepararé un pincho USB con Kali. Para aprovecharlo como PC de sobremesa, tenía en mente instalar otro desktop Linux.

Lo primero que me voy a plantear es actualizar el hardware, en especial, ampliar la memoria RAM y cambiar el disco duro por un SSD. Este último cambio, además de proporcionar velocidad, va a permitir reducir la necesidad de potencia y alargar, si es posible, la vida de la batería.

Encontrar el disco SSD fue fácil, me acerqué al MediaMarkt y estuve mirando un poco que es lo que tenían y, al final, me compré un Toshiba OCZ TL100 de 240GB (76€). No es un prodigio de velocidad pero creo que va a cumplir con lo que se espera de él.

Lo de la RAM ya es otra historia. Después de un peregrinaje por distintas tiendas he visto que nadie la tiene en stock y que el precio de los dos módulos de 8GB supera los 120€. Así que la solución será comprarla on-line en un par de meses.

Nunca he cambiado el disco duro de un portátil así que no se que es lo que me va a esperar. La idea de este post, es ir recogiendo el relato para poder volver a hacerlo. Antes de ponerme con ello, visualizo un par de videos en Youtube para, por lo menos, saber como abrir el cacharro.

El primer paso es quitar la batería. Este parece sencillo. y no requiere ni esfuerzo ni herramientas.

A continuación procedo a sacar la tapa posterior. Parece que está sujeta únicamente con dos tornillos. Sin ningún esfuerzo, una vez liberados los tornillos, la tapa se retira con facilidad y puedo ver tanto la memoria como el disco duro.

El disco duro tiene una solapa de plástico transparente de la que tengo que tirar para sacarlo. Primer intento y ni pá dios. Con las gafas de leer puestas me doy cuenta que hay cuatro tornillos que retirar.

El propio disco duro, está fijado por cuatro tornillos a una carcasa. Se trata de un Seagate Momentus Thin de 320GB.

Una vez desembalado el SSD me pongo a montarlo en la carcasa y luego en el espacio correspondiente del portátil. La primera en la frente, lo he montado en la carcasa al revés y ahora no entra. De nuevo a desatornillarlo de la carcasa y darle la vuelta. Pasadas estas tribulaciones, consigo montar el disco duro, montar la tapa trasera y verificar que la BIOS reconoce el nuevo disco duro.

Listo el equipo para la instalación del software. Voy a instalarle un sistema operativo Linux, en concreto la distribución LXLE Desktop version 16.04.1 que está basada en Lubuntu.

Creando un WIDS casero (y IV)

En el post anterior de la serie, detallé cómo configuré la Raspberry Pi para actuar de sonda en la captura de paquetes 802.11 empleando Kismet (en modo drone). El objetivo es analizar esos paquetes para detectar la presencia de puntos de acceso inalámbricos no autorizados.

En este post, último de la serie, voy a describir como configuro el drone de Kismet en la Rasp y el servidor y el cliente en una máquina virtual para comprobar que puedo capturar los paquetes inalámbricos. En futuros posts iré viendo qué capacidades tiene esta solución.

En la arquitectura de Kismet, el drone captura los paquetes a través de la interfaz inalámbrica y el servidor se conecta al drone para procesar los paquetes que van a ser presentados a través de una aplicación cliente.  En mi entorno, servidor y cliente se ejecutarán en una una máquina virtual sobre Kali Linux, conectada a la DMZ de mi laboratorio virtual. Voy a obviar los detalles de la instalación de Kali para centrarme en el WIDS. La dirección IP de la máquina donde se encuentra el server será 10.1.4.9.

Lo primero que voy a hacer es comprobar que existe conectividad entre la rasp y Kali:

Hasta ahora todo bien, voy a configurar ahora el drone en la Rasp. Lo que voy a hacer es poner, bajo control de versiones, los ficheros de configuración de kismet para poder editarlos cómodamente en el PC.

En la Raspberry edito el fichero /usr/local/etc/kismet_drone.conf y configuro la conectividad del drone:

En kali, edito el fichero /etc/kismet/kismet.conf y configuro, como fuente de paquetes el drone:

Arranco el drone en la Rasp en modo daemon y compruebo que esté a la escucha en el puerto 2502:

Ahora toca el turno al cliente y al server en Kali. En una consola introduzco el comando kismet y, despues de un par de cuestiones relacionadas con el arranque del server veo algo así:

Esto está conseguido.

Creando un WIDS casero (III)

Tras el fracaso con el viejo router D-Link he decidido no darme por derrotado e intentarlo con la Raspberry Pi. Ya comente en otra parte que tengo una Raspberry Pi Model B con una instalación fresca de Raspbian que utilizo, fundamentalmente, para jugar con sensores. Bien, ahora voy a emplearla como sensor de tramas de 802.11.

El viejo router lo voy a emplear para que haga de punto de acceso falso y para otras pruebas de penetración que tengo en mente.

La única duda que me surge es si la tarjeta WiFi USB que tengo es de las soportadas por Kismet. Si no lo fuera, ya veríamos que rumbo tomamos a futuro pero lo que tengo claro es que se me ha metido en la cabeza construir el maldito WIDS.

Lo primero que voy a hacer es actualizar el Raspbian:

Después de un buen rato tengo mi dispositivo actualizado.

El siguiente paso es comprobar si la interfaz WiFi que tengo está soportada por Kismet. Fundamentalmente, lo que importa es ver si se puede poner en modo monitor.

El dispositivo WiFi que tengo en mi Rasp es un dispositivo USB como éste:

Le echo un ojo, en primer lugar, a la configuración de las interfaces de red (comando ifconfig):

La interfaz wireless, como no podía ser de otra forma, es la wlan0. Voy a mirar ahora en los dispositivos USB (comando lsusb):

El dispositivo es el número 004 y es del fabricante Ralink Technology y se trata de un adaptador inalámbrico modelo RT5370. Si quisiéramos obtener información más detallada podríamos usar el comando:

lsusb –D /dev/bus/usb/001/004

Miramos los parámetros del dispositivo inalámbrico con iwconfig:

Por último, comprobamos si el adaptador puede ponerse en modo monitor lo que permite capturar los paquetes:

Todo parece OK así que voy a instalar Kismet. La instalación de Kismet voy a hacerla por el camino largo, esto es, tal y como se describe en la documentación de Kismet: me voy a descargar el código fuente, realizar la configuración previa, compilarlo y, por último, instalar el producto.

Para empezar instalo algunas dependencias:

Ahora me voy a descargar, desde la web de Kismet la última versión estable de código fuente que, en el momento de escribir esto, es la 2016-07-R1. Una vez descargada, voy a usar WinSCP para copiarla a la Raspberry.

Extraemos y configuramos:

Todo parece correcto así que puedo lanzar el make y esperar (la compilación se tomará su tiempo).

A continuación lanzo la instalación. Kismet debe estar instalado en /usr/local/bin

Por último, para completar la instalación, voy a añadir el usuario pi al grupo kismet.

sudo usermod -a -G kismet pi

Rearranco la pi y me meto con la configuración.

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:

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

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:

y pulso el botón Update list:

Ahora busco kismet drone en la lista de paquetes disponibles …

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

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

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.

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.

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á:

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

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:

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

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

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:

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:

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.

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í: