Preparando un lab para pen-testing WiFi

Tras haber conseguido que la Raspberry Pi consiga hablar con una máquina virtual Kali y sea capaz de capturar las tramas 802.11 y enviarlas para su análisis al Kali, voy a empezar a auto-educarme en pruebas de penetración en redes inalámbricas. Para ello, voy a montar un entorno de lab sobre la base de la cacharrería que tengo por casa.

En primer lugar, como punto de acceso WiFi voy a utilizar mi viejo router Belkin F5D7632-4. El router lo he reseteado a los settings por defecto y lo configuraré para que haga de punto de acceso inalámbrico.

DCP_1498

Como máquina atacante voy a emplear un viejo Dell Latitude E6400 con la batería estropeada al que le he añadido una interfaz wireless adicional USB que tenía por casa (una Belkin Wireless G F5D7050) ésta la voy a usar para comunicarme con el equipo y la tarjeta wireless interna (PCI) la usaré para monitorizar la red. Al equipo le voy a montar un Kali Linux que arranque desde un pincho USB en el que grabé la imagen con Rufus.

dell-e6400

Belkin_F5D7050_Wireless_G_USB_Network_470079

Finalmente, la máquina atacada va a ser la Raspberry Pi Model B:

Pi2ModB1GB_-comp

Voy a ir relatando los pasos que voy a seguir para configurar el entorno de pruebas para que cuando tenga que volver a hacerlo, poder emplear este post como referencia.

1. Configuración del Router

Empecemos con el router. Para arrancar limpiamente, he reseteado el router al estado inicial de fábrica , me conecto con un cable ethernet y arranco la interfaz de administración (en el caso del Belkin hay que conectarse a la IP 192.168.2.1).

Lo primero que hago es establecer una contraseña de administrador y, a continuación, configuro los parámetros de la LAN incluyendo la configuración de DHCP. Para el lab, voy a emplear la clase C privada 192.168.200.0/24.

Imagen4b

Al aplicar los cambios necesito volver a conectarme (he cambiado la red y la dirección del router). Hago login con mi nueva contraseña y paso a configurar la WiFi. Establezco el SSID (HACKME_001) y el canal (9) de forma que no haya conflictos con otras WiFis de los alrededores:

Imagen2b

Inicialmente quito la seguridad:

Imagen3b

2. Configuración del PC

Voy a configurar ahora el PC. Como ya comenté antes, mediante el programa Rufus, cree una imagen arrancable de Kali (version 2016-2) en un pincho USB. Los pasos que sigo son:

  1. Configurar la BIOS para que el PC arranque desde un puerto USB
  2. Conectar el pincho con la imagen arrancable a un puerto USB.
  3. Conectar, a otro puerto USB, la tarjeta WLAN.

Una vez completado esto, pulso el botón de ON y, el PC arranca y aparece el desktop de Kali.

Imagen5a

A continuación, voy a ver qué interfaces tiene el PC. Debería tener dos interfaces wireless LAN. Para verlo, lanzo el comando ifconfig.

Screenshot from 2016-07-25 19-59-34

Efectivamente, aparecen dos interfaces: wlan0 y wlan1 pero ahora necesito saber cuál es cuál. Empleando los comandos lsusb y lspci averiguo que la interfaz interna es una Intel Corporation WiFi Link y que la conectada en el puerto USB es una Belkin F5D7050 Wireless G Adapter pero sigo sin saber cuál es wlan0 y cual wlan1. Otros comandos (iwconfig, dmesg) siguen sin aclararme las dudas pero, finalmente, yendo al directorio /sys/class/net consigo aclararme, parece que wlan0 es la interfaz PCI y wlan1 la interfaz USB.

Screenshot from 2016-07-25 20-05-04

Screenshot from 2016-07-25 20-05-33

Screenshot from 2016-07-25 20-23-25

Le echo un ojo a lo que dice iwconfig. Voy a usar wlan0 para hacer de monitor y wlan1 para conectarme a la red doméstica y, por lo tanto, a Internet.

Screenshot from 2016-07-25 20-25-36

Ahora toca configurar las interfaces de red. Esto lo hago a través de la interfaz gráfica. La interfaz wlan1 (la que voy a usar para conectarme al mundo) la configuro con una dirección IP estática (me facilita la vida para conectarme al equipo por SSH) y la interfaz wlan0 usará una dirección IP dinámica obtenida del router Belkin:

Imagen6

Pruebo que haya conexión a todos lados:

Imagen7

Instalo el servidor open-ssh para poder acceder en remoto, lo configuro y compruebo que accedo:

Screenshot from 2016-07-25 21-16-34

Imagen5b

Rearranco y … ¡cagada!, arranqué la imagen como Live (amd64) y debería haberla arrancado como Live USB Persistence (amd64), toda la configuración realizada se fue al garete. ¡Suerte que tengo todos los pasos documentados!, no tengo más que repetir lo que acabo de hacer.

Segunda cagada, necesito seguir las instrucciones que dicen como crear una imagen persistente de Kali así que, de nuevo, a repetir todo el proceso.

Finalmente, a la tercera fue la vencida, ya se mantienen los settings entre arranques aunque queda por configurar que pida contraseña al arrancar y cambiar la contraseña de root. Para hacer esto, sigo los pasos que se identifican aquí y me pide usuario y contraseña para entrar.

El último aspecto que dejo para más adelante es el de la fecha y hora. El portátil no la mantiene y es un rollo tener fecha de hace seis meses.

Conseguida la configuración de la máquina atacante.

3. Configuración de la Raspberry Pi

Aquí la configuración a realizar debería ser, simplemente, la relacionada con la tarjeta WiFi. Como esto no parece muy complicado, empiezo intentando encontrar una forma de cambiar de conectarme a distintas redes WiFi sin necesidad de tocar ficheros de configuración ni rearrancar el aparato. En casa tengo dos puntos de acceso (router de banda ancha y repetidor WLAN) y, además, los de los routers que utilizo para pruebas y si salgo fuera, necesito poder configurar las WiFi de forma fácil.

Hay bastantes respuestas en Internet para cambiar de WiFi automáticamente pero no consigo encontrar una que me permita hacerlo de forma manual. Lo que consigo es liarme y perder tres días jugando con los ficheros de configuración. Finalmente he decidido mantener distintos juegos de ficheros de configuración y reemplazarlos y rearrancar cuando sea necesario. Sin embargo, me queda buscar una solución para esto y lo anoto como una tarea a futuro.

He configurado que la Rasp tenga una dirección IP estática dentro del rango de la clase C del lab. En concreto, la 192.168.200.2. A continuación pongo los fragmentos de los ficheros de configuración que he tenido que tocar:

  • Fichero: /etc/network/interfaces

Imagen8

  • Fichero /etc/dhcpcd.conf

Imagen9

  • Fichero /etc/wpa_supplicant/wpa_supplicant.conf

Imagen10

Rearranco la Rasp y vamos a ver qué configuración tiene y si hay conectividad con los restantes elementos de la WiFi:

Imagen11

Imagen12

Imagen13

Vamos a probar que hay conectividad desde el Kali a la Rasp:

Imagen14

¡Conseguido!

Anuncios

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

Instalando un servidor LDAP

Al igual que en el caso del servidor DNS, voy a crear un servidor Ubuntu con 1GB de RAM y 25GB de disco para el servidor LDAP. La instalación y pre-configuración del servidor es calcada a la que hice para el servidor de nombres así que voy a obviar los detalles. La única diferencia es que mi servidor LDAP va a estar conectado a la red de Backend en lugar de a la DMZ como en el caso del servidor de nombres.

ldap1

La idea es instalar un servidor OpenLDAP para la autenticación y autorización de usuarios del entorno lab. Para empezar, me descargo los correspondientes paquetes y, durante la instalación, se me solicita la contraseña para el directorio.

ldap2

ldap3

A continuación, lanzo la reconfiguración del paquete instalado y voy contestado a las distintas cuestiones relativas a la configuración:

ldap4

ldap5

ldap6

ldap7

A continuación instalo la interfaz web de administración del directorio (phpLDAPAdmin) en el servidor de administración:

ldap8

Realizo la configuración editando el fichero /etc/phpldapadmin/config.php.

ldap10

ldap11

Una vez establecida la configuración, ya se puede acceder al servidor LDAP mediante phpLDAPadmin:

ldap2_1

Ahora un servidor de nombres

1. Introducción

Una vez completada la configuración de la red de gestión, voy a empezar a configurar distintos servidores en el entorno. Para empezar, voy a desplegar un servidor de nombres, basado en bind para mi entorno.

El servidor DNS, como no podía ser de otra forma, lo voy a instalar en la DMZ. La red virtual del lab, va tomando forma de este modo:

dns3

2. Creación y preconfiguración de la máquina virtual

Creo una máquina virtual con la configuración estándar (1GB de RAM y 10 GB de disco):

dns1

Instalo el sistema operativo, Ubuntu para no variar. Antes de ponerme con el despliegue de bind, tengo una serie de tareas que completar:

a) En primer lugar me toca configurar la segunda tarjeta de red para que se conecte a la red de gestión. Esto es, a priori, sencillo, no hay más que configurar la interfaz de gestión en /etc/network/interfaces

dns7

dns8

b) El segundo aspecto a configurar es enviar los logs al servidor de logs. Editamos el fichero /etc/rsyslog.conf y añadimos al final la línea correspondiente:

dns9

c) Por último, necesitamos instalar NRPE y configurarlo para poder monitorizar el servidor DNS desde Nagios. Los pasos a seguir están descritos aquí. Asimismo, tengo que crear los objetos necesarios en el servidor de Nagios para que la monitorización sea efectiva. Finalmente, ya tengo controlado el nuevo servidor en Nagios:

dns10

3. Instalando bind

Instalo el paquete bind9, las utilidades asociadas y la documentación:

dns11

Compruebo que el servicio named esté a la escucha en el puerto 53:

dns12

Todo correcto pero voy a hacer que sólo resuelva para IPv4. Para ello edito el fichero /etc/default/bind9 y añado –4 al parámetro OPTIONS.

dns13

Rearranco el servicio y verifico que no esté escuchando en el puerto 53 en IPv6:

dns14

4. Configurando bind

Ahora voy a configurar bind para que sea el servidor de nombres de mi dominio lab (tcantos.local).

Editamos el fichero de opciones de configuración de bind (/etc/bind/named.conf.options), añadiendo un acl para las redes de mi lab y configurando las opciones de acuerdo a mi entorno. El fichero queda de la siguiente forma:

dns15

A continuación vamos a definir las zonas. Para ello editamos el fichero /etc/bind/named.conf.local. Definimos una zona de resolución directa para las distintas redes del entorno lab y cuatro zonas de resolución inversa para las distintas redes:

dns16

dns17

Ahora definimos los ficheros de datos de bind para la resolución directa e inversa:

  • tcantos.local.db

dns18

  • 2.1.10.db (servidores de backend)

dns20

  • 3.1.10.db (Red de estaciones de trabajo)

dns21

  • 2.168.192.db (DMZ)

dns19

  • 199.168.192.db (Red de Gestión)

dns22

Una vez creados los ficheros necesarios, los llevamos al servidor y verificamos la configuración, las zonas y rearrancamos el servidor bind.

dns23

Finalmente, configuramos los clientes. En los servidores ubuntu editamos el fichero /etc/resolvconf/resolv.conf.d/head para añadir las líneas necesarias y ejecutamos resolvconf:

dns24

Verificamos el funcionamiento del servidor dns con dig y nslookup:

dns25

dns26

dns27

Parece que todo funciona, sólo queda configurar el resto de los equipos.

Configurando el gestor Nagios

En los posts anteriores (aquí y aquí) abordé cómo configurar los elementos que van a monitorizarse en la red para permitir su gestión desde el servidor Nagios. En este post voy a abordar la configuración de Nagios.

Nagios, de acuerdo a la instalación que tengo, mantiene la información de configuración en el directorio /usr/local/nagios/etc. Bajo este directorio y los subdirectorios correspondientes se encuentran una serie de ficheros de configuración.

El primer paso es traerse toda esta información de configuración al PC para poder editar los ficheros de forma más amigable (aunque vi/vim es un gran editor, prefiero hacerlo con UltraEdit). Después de los líos con la creación de una imagen y su montaje que tuve para transferir archivos desde el PC a una máquina virtual, descubrí que la forma más fácil de mover ficheros es a través de un pincho USB. Lo único que hay que hacer es añadir a las máquinas virtuales un controlador USB y, cuando se monta el controlador reconoce los dispositivos pinchados en el PC que ejecuta el vClient.

Reflexionando sobre el manejo de la cantidad de ficheros de configuración involucrados en el lab, se me ocurre que, probablemente sea una buena idea montar un control de versiones (por ejemplo, svn) para mantener gestionadas todas estas configuraciones (le echaré una pensada a lo largo de la semana).

Volviendo al tajo tras la digresión, lo que voy a hacer es organizar los elementos de configuración en una serie de subdirectorios, en la actualidad, lo que hay es un subdirectorio ‘objects’ con distintos objetos de configuración y uno ‘servers’ con los ficheros de configuración de los distintos hosts de la red. En el directorio raíz se encuentran los ficheros de configuración generales de Nagios. Mi plan es organizar la configuración de la siguiente forma:

  • En el directorio raíz los ficheros de configuración generales: nagios.cfg, resource.cfg, cgi.cfg, nrpe.cfg y htpasswd.users.
  • Subdirectorio commands. Ficheros .cfg de los distintos comandos.
  • Subdirectorio contactgroups. Ficheros .cfg de los contact groups.
  • Subdirectorio contacts. Ficheros .cfg de los contactos.
  • Subdirectorio hostgroups. Ficheros .cfg de los grupos de hosts.
  • Subdirectorio hosts. Ficheros .cfg de los distintos hosts existentes en el lab.
  • Subdirectorio services. Ficheros .cfg de los distintos servicios.
  • Subdirectorio servicegroups. Ficheros de .cfg correspondientes a los grupos de servicios.
  • Subdirectorio timeperiods. Ficheros .cfg con la configuración de períodos de tiempo.

Para que surja efecto es necesario que, en el fichero de configuración general de nagios (nagios.cfg), se establezca que estos directorios deberán ser contemplados en la carga de la configuración:

nag_cfg9

Una vez completada esta labor, lo que queda es pasarla al servidor nagios y probar la configuración. Empleando el pincho usb la transferencia de la configuración es coser y cantar y tras unas mínimas correcciones consigo que la configuración sea correcta:

nag_cfg10

Re-arranco Nagios y me conecto a la interfaz web desde una máquina virtual Lubuntu conectada a la red de gestión.

nag_cfg11

Se ve que los tres hosts de mi red están levantados pero tengo cuatro problemas críticos:

nag_cfg12

Los cuatro problemas críticos tienen que ver con el router vyos, uno de ellos es el servicio SSH que no estará levantado y los otros tres están relacionados con SNMP. Voy a investigar qué pasa.

Al editar la definición del servicio Uptime me doy cuenta enseguida del error. La community del comando check_snmp está puesta a public y en el setup de SNMP del router VyOS la community que establecí es mylab. Un pequeño cambio en la configuración de los servicios basados en SNMP y este problema debería quedar arreglado:

nag_cfg13

nag_cfg14

En el caso del SSH, voy a levantar el servicio SSH en el router vyos:

nag_cfg15

Ya sólo queda comprobar la configuración de Nagios, re-arrancar el servicio y ver qué pasa:

nag_cfg16

A priori, todo pinta bien, veamos cómo está el router VyOS:

nag_cfg17

Todo verde, tarea completada (por ahora) queda por definir qué voy a monitorizar del router, pero eso ya será en otro lugar.

Monitorizando la red virtual (I)

Una vez instalado Nagios en el servidor designado para ello, el siguiente paso en el camino es monitorizar el resto de los elementos. Ahora mismo, mi red está así:

Dibujo3

Los elementos a monitorizar (por ahora) son, además del propio servidor Nagios, el servidor de Syslog y el router Vyos. Lo que hay que hacer es configurar el servidor Nagios para poder realizar la monitorización. No tengo mucha idea de cómo va esto pero, a priori, el secreto consiste en atacar el router VyOS a través de SNMP y los servidores a través del plugin NRPE.

En este post voy a cubrir la configuración del servidor NRPE en el servidor de syslog.

Para poder monitorizar el servidor de syslog, lo que hay que hacer, en primer lugar, es instalar NRPE y los plugin de Nagios:

add@ubsyslog~$ sudo apt-get update 
add@ubsyslog~$ sudo apt-get install nagios-plugins nagios-nrpe-server

El siguiente paso es editar el fichero de configuración del servidor NRPE. Este fichero es /etc/nagios/nrpe.cfg. En este fichero, establecemos el host desde donde se van a lanzar los comandos de monitorización (servidor ubnagios):

nag_cfg1

y las directivas include para estructurar el contenido de la configuración:

nag_cfg2

Dentro del directorio nrpe.d voy a crear un fichero de configuración (cmds.cfg) que contiene los comandos que van a utilizarse para monitorizar el servidor remoto.

En el caso del servidor ubsyslog, lo que, inicialmente, voy a monitorizar es:

  • Que el servidor esté vivo. Esto se lleva a cabo lanzando un ping desde el servidor de monitorización por lo que, en local, no hay que hacer nada.
  • El número de usuarios conectados al servidor. Para ello empleamos el plugin nrpe check_users estableciendo un nivel de warning a 5 y el nivel crítico a 10.
  • La carga del servidor. Se monitoriza mediante el comando check_load de forma que eleve un aviso si los niveles de carga (de acuerdo a la salida del comando uptime) superan 5,10 y 15 y lanza un nivel crítico cuando estos niveles superan los valores 30, 25 y 20.
  • La ocupación del disco duro del servidor (sistema de ficheros ‘/’), empleando el comando check_disk. El comando emitirá un warning cuando el espacio libre en el disco duro baje del 20% y un aviso crítico cuando el espacio libre esté por debajo del 10%. Es importante saber cuál es el dispositivo en el que se monta el sistema raíz que, en el caso del servidor ubsyslog, es /dev/dm-0 (obtenido mediante el comando ‘df –h /’).
  • El número total de procesos. Para esto, se utiliza el comando check_total_procs, estableciendo un nivel de warning en 150 y el nivel crítico en 200.
  • El espacio de swap libre. Para obtener este valor empleamos el comando check_swap estableciendo el nivel de warning al 20% y el nivel crítico al 10%.
  • El espacio utilizado por los logs (directorio /var/log). Para obtener esto empleamos el comando check_folder_size estableciendo los niveles de warning y crítico respectivamente a 5GB y 6GB (el disco duro total inicial es de 10GB).

El fichero cmds.cfg queda de la siguiente forma:

nag_cfg3

Antes de continuar voy a hacer un breve inciso sobre cómo configurar el comando check_folder_size.sh (yo lo renombré a check_folder_size2.sh) ya que el conseguir que funcione supuso un esfuerzo considerable.

El shell script check_folder_size.sh lo descargué al PC donde ejecuto el vSphere client desde el sitio de internet de Nagios Exchange. Una vez en el PC, surgió el problema de cómo llevarlo a la máquina virtual, la solución que empleé, fue crear una imagen ISO, subirla a vSphere y montarla en la unidad de CD de la máquina virtual. Aquí explican más o menos el mecanismo.

A continuación, tuve un pequeño problema con los permisos. Tuve que cambiar el usuario y los permisos del fichero:

add@ubsyslog:/usr/lib/nagios/plugins$ sudo chown nagios:nagios check_folder_size2.sh
add@ubsyslog:/usr/lib/nagios/plugins$ sudo chmod 755 check_folder_size2.sh

Una vez completado todo esto, conseguí que el comando funcionara en local. Ahora llega la hora de probar que todos los comandos funcionan en remoto desde el servidor de nagios (ubnagios) utilizando el comando check_nrpe:

nag_cfg5

Todo funciona OK y esto me va a servir de plantilla para siguientes configuraciones.

Probando la nueva red

Como he contado aquí y aquí, he reconfigurado la red del entorno lab para que sea más eficiente. Ahora llegó el momento de probar los cambios realizados y que todo funciona de acuerdo a lo esperado.

Para probar la conectividad con la DMZ voy a conectar a la misma una máquina virtual Lubuntu con dirección IP 192.168.2.130:

red20

1. Conectividad desde el PC conectado a la red lab

red18

red19

red21

red22

2. Conectividad desde el PC conectado a la WiFi doméstica

Para esto desactivo la conexión ethernet y activo la conexión WiFi.

red27

red28

red29

3. Conectividad desde la DMZ

red23

red24

red25

red26

Parece que todo funciona correctamente.