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:

Imagen23

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.

Imagen27

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:

Imagen25

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:

Imagen30

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

Imagen31

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

Imagen32

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:

Imagen33

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

Imagen34

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:

Imagen35

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.

Anuncios

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.

Imagen3

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.

Imagen5

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:

Imagen7

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.

Imagen9

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.

Imagen10

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

Imagen11

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

Imagen12

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

Imagen14

El siguiente paso es actualizar los componentes del sistema operativo:

Imagen17

Imagen18

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.

Imagen21

De haber sido necesario hubiera utilizado raspi-config.

Más en la siguiente entrega.

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!

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:

Imagen27

Imagen28

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:

Imagen29

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

Imagen30

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

Imagen31

Imagen32

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

Imagen33

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:

Imagen14

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:

Imagen16

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

Imagen15

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

Imagen17

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:

Imagen18

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

Imagen19

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:

Imagen20

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.

Imagen21

Extraemos y configuramos:

Imagen22

Imagen23

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

Imagen24

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

Imagen25

Imagen26

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.

Programando GPIO en JavaScript

En el post anterior verifiqué que el acceso a GPIO funciona, ahora toca escribir el primer programa en JavaScript para acceder al mundo exterior desde la Raspberry Pi.

Lo primero que voy a hacer es crear una estructura de directorios para mantener los distintos archivos que conforman el proyecto. En el directorio raíz del usuario ‘pi’ voy a crear un directorio labs donde voy a colocar los distintos componentes de las aplicaciones. Dentro de este directorio, voy a crear un directorio, gpiojs, donde irán los componentes de este proyecto.

En primer lugar creo un fichero de dependencias (package.json) y lo sitúo en la raíz del proyecto. Los contenidos del fichero son:

{
   "name": "led",
   "version": "0.0.1",
   "description": "Basic test of GPIO",
   "dependencies": {
      "rpio": "^0.9.11"
   }
}

A continuación lanzo el comando para la instalación de las dependencias:

Imagen2

Por último, escribo un pequeño programa en JavaScript que va a probar la comunicación a través de GPIO:

//|   led_1.js
//|   Primer programa de acceso a GPIO usando rpio.

var rpio = require('rpio');

// Inicializar los pines a utilizar.

var red     = 11;
var green   = 12;

// Abrir los pines para salida estableciendo el nivel de salida bajo.

rpio.open(red, rpio.OUTPUT, rpio.LOW);
rpio.open(green, rpio.OUTPUT, rpio.LOW);

// Bucle principal.

for (var i = 0; i < 5; i++) {
   rpio.write(red, rpio.HIGH);         // Encender LED rojo
   rpio.sleep(1);
   rpio.write(red, rpio.LOW);          // Apagar LED rojo
   rpio.msleep(500);
   rpio.write(green, rpio.HIGH);       // Encender LED verde
   rpio.sleep(1);
   rpio.write(green, rpio.LOW);        // Apagar led verde
   rpio.msleep(500);
}

Ya sólo queda lanzarlo y ver el resultado:

A partir de ahora, iré poniendo todo el código en GitHub.

Primeros pasos con GPIO en la Raspberry

Una vez instalados Raspbian y Node.js en la Raspberry, llega el momento de empezar a desarrollar software. Lo que necesito es, en primer lugar, encontrar un módulo JavaScript que me permita acceder a GPIO. Investigando un poco, descubro que hay muchos paquetes que permiten controlar la GPIO de la Rasp desde JavaScript.

Por lo que he ido mirando, quizás los que más destaquen sean:

  1. pi-gpio. Proporciona una interfaz muy simple para el manejo de la GPIO.
  2. rpi-gpio. Parece un poco más elaborado que el anterior. Este paquete usa el esquema de numeración de pines de GPIO propio de Raspberry (en lugar de la numeración del pin físico) y todas las funciones de entrada/salida son asíncronas lo que, a priori, encaja mejor con el esquema de funcionamiento de Node.
  3. onoff. Proporciona funciones tanto síncronas como asíncronas para el acceso de E/S a GPIO. Además, proporciona un mecanismo de detección de interrupciones que permite la invocación de callbacks cuando cambia la señal en un pin y evita estar haciendo pooling a GPIO.
  4. node-rpio. Sólo proporciona funciones síncronas pero tiene una amplia cobertura funcional y parece que es muy rápido.

Tras unos primeros intentos con rpi-gpio, me voy a decantar por trabajar con el último de los cuatro (node-rpio).

Una cosa que hay que tener en cuenta es que para el acceso a los pines de GPIO en la Rasp es necesario tener privilegios de administrador. Desde el punto de vista de seguridad, no es una buena práctica el conceder privilegios de administrador a diestro y siniestro así que, en primer lugar, voy a instalar la herramienta gpio-admin:

Imagen1

Imagen2

Cerramos la sesión y volvemos a entrar y ya debemos tener la membresía del grupo gpio.

Otro aspecto a considerar es el esquema de nombrado de los pines. Dado que este es un aspecto que puede ser muy importante (nos podemos cargar la Rasp conectándola mal) voy a ver si recapacito un poco. El módulo node-rpio soporta dos esquemas de numeración de interfaces: la numeración física y el esquema de numeración de GPIO (WiringPi).

Imagen3

En fin, vamos a por ello. Voy a empezar con algo sencillo empleando un LED de dos colores (verde y rojo) conecto la pata de rojo al pin 11 (físico, GPIO.0 en numeración WiringPi) y la pata verde al pin 1 (fisico, GPIO.1 en numeración wPi) y la tierra al pin 6. El montaje, con los accesorios que tengo, queda así:

Imagen6

Empiezo probando que funciona desde la línea de comandos, establezco el modo de los pines correspondientes a los colores a salida.

Imagen4

Compruebo que, efectivamente, el valor está establecido a out (pin 0 y 1 wPi o pines físicos 11 y 12):

Imagen5

Si ahora escribo el valor de salida 1 en el pin 0 debería encenderse el LED de color rojo:

Imagen7

Imagen8

Escribo el valor de salida 0 en el pin 0 y el valor de salida 1 en el pin 1 y el LED deberá lucir en verde:

Imagen10

Imagen9

Bueno, hemos superado la primera prueba. En el siguiente post empezaré a programar en JavaScript para hacer esto mismo.