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:

ntp-001-005

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

ntp-001-002

Verificamos el estado de sincronización:

ntp-001-006

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:

ntp-001-008

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:

ntp-001-009

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:

ntp-001-010

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

ntp-001-011

Anuncios

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.

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.

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.

Latitude-E5420

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.

toshiba-ocz-tl100-240gb-box

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.

SL270304

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

SL270306

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.

SL270307

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.

SL270310

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

SL270313

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.

SL270315

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.

Conectando Arduino a la WiFi (II)

En el post anterior me quedé en el conexionado del prototipo de lo que va a ser mi futura estación remota. Una vez completada la parte de conexión le toca el turno al software. Voy a empezar con un sketch muy sencillo que adapté mínimamemte de uno obtenido de Internet. La idea es ir probando los comandos AT.

El sketch es el siguiente:

image

Inicialmente establezco la velocidad de comunicación con la consola y con el módulo ESP8266 a 115200 baudios, inicializo la consola serie y el módulo. El proceso es sencillo, si hay caracteres disponibles en uno de los dispositivos (consola o módulo WiFi) los leo y los escribo en el otro módulo.

Lo primero que hago es buscar la documentación del módulo y veo que se encuentra disponible online en GitHub, en concreto aquí.

Conecto el arduino con el cable USB

Imagen3

Aparecen caracteres extraños, los comandos AT funcionan (aparentemente) pero la salida que se ve en la consola, en algunos casos, no se entiende.

Investigo un poco más y encuentro varias pistas para resolver el problema. Al parecer hay dos problemas:

  1. El módulo ESP8266 utiliza niveles de 3,3V y el Arduino los niveles lógicos que emplea son de 5V por lo que es necesario adaptarlos. Probé poniendo un potenciómetro de 10K Ohmios en la línea de transmisión de Arduino al ESP para reducir la tensión a 3,3V y, aparentemente funciona pero, lo que no se puede hacer con resistencias es aumentar la tensión de 3,3 a 5V. Al final, lo que hice fue comprar un convertidor de niveles lógicos (menos de 3€) y me quito el problema de encima.
  2. La segunda parte del problema tiene que ver con el módulo SoftwareSerial de Arduino. Al parecer, no soporta velocidades de transmisión elevadas así que lo que voy a hacer es reducir la velocidad de transferencia hasta que funcione correctamente.

Aprovechando que me acerqué a la tienda de electrónica para comprar el convertidor de niveles lógicos, me compré un Arduino Nano. El esquema del nuevo circuito es:

ESP8266-2_bb

ESP8266-2_schem

Y el aspecto que tiene en la realidad es:

image

Una vez verificadas las conexiones estoy listo para comenzar a tirar comandos AT para probar las capacidades del módulo ESP. La documentación del ESP8266 se encuentra aquí y el manual con el conjunto de comandos AT soportados se puede descargar de aquí (documento pdf).

Tras repasar someramente el manual (leerme el índice) voy a empezar a probar algunos comandos AT. Lo primero que voy a hacer es restaurar la unidad a los parámetros de fábrica (comando AT+RESTORE). El resultado es, obviamente, que deja de funcionar. Probablemente, al restaurar los parámetros de fábrica la velocidad de comunicación se resetea a 115.200 baudios. Por lo tanto, lo que hago es retocar el sketch de Arduino y volverlo a arrancar.

Aparecen caracteres raros en el display así que voy a reducir la velocidad de transmisión a 57.600 baudios. Para ello, lanzo el comando:

AT+UART_DEF=57600,8,1,0,0

Los parámetros son 57.600 baudios, 8 bits de datos, 1 bit de parada, sin paridad (0) y sin control de flujo (0). Tengo que volver a cambiar el sketch para la nueva velocidad.

image

Cargo el nuevo sketch, y una vez descargado al Nano desconecto y conecto la fuente de alimentación a la que tengo conectado el ESP. El resultado es el siguiente:

image

Lo que voy a hacer a continuación es comprobar la versión, conectarme a la WIFI doméstica y verificar que estoy conectado:

  • AT+CWMODE=1. Para establecer el modo estación.
  • AT+CWJAP=”essid”,”passwd” para conectarme a la WiFi doméstica.
  • AT+CIFSR para averiguar la dirección IP asignada.

imageimageImagen8

Al parecer estoy conectado. Voy a comprobar si hay ping tanto dentro de mi red doméstica como en Internet:

image

Parece que hay ping, vamos a ver si responde a ping …

image

Hasta ahora todo correcto, en el siguiente post seguiré avanzando en el setup de comunicaciones.

Conectando Arduino a la WiFi (I)

Una vez decidido a arrancar mi proyecto IoT y, habiendo decidido que la interconexión entre los distintos dispositivos va a implementarse sobre WiFi, necesito ver la forma de conectar los microcontroladores Arduino a la red inalámbrica.

Explorando un poco por Internet descubro que uno de los módulos WiFi más empleados y con más referencias es el ESP8266. El ESP8266 es un sistema en chip (SOC) que tiene integrada la pila de protocolos TCP/IP y que proporciona acceso a la WiFi a los controladores. Este módulo permite, al microcontrolador, externalizar toda la carga de la comunicación. Sin más investigación previa, me decidí a comprar una unidad en mi proveedor habitual (Amazon) su precio (8€ puesto en casa) me pareció adecuado y su funcionalidad, de acuerdo a lo leído, más que apropiada.

image

Lo que más me sorprendió al recibirlo fue su pequeño tamaño. Quitando el espacio dedicado a las conexiones, no es más grande que la uña del dedo pulgar:

image

Una vez recibido, me propongo conectarlo para empezar a hacer pruebas pero, leyendo más en internet, descubro que recomiendan que la unidad no se alimente desde el pin del Arduino UNO ya que, al parecer, si se hace de este modo, se producen cortes en la comunicación con el microcontrolador. Por lo tanto, decido comprar una placa para una fuente de alimentación externa. En este caso se trata de una WINGONEER MB102 3.3V/5V (6,99€ puesta en casa en Amazon).

image

Configuro los jumpers para que dé una salida de 3,3V, la conecto a una fuente de alimentación y compruebo la salida con un polímetro verificando que el voltaje de salida es adecuado. Todo está OK y tengo los materiales necesarios para montar la placa del prototipo. Aquí están en una foto de familia:

image

Voy a proceder a realizar las conexiones. El esquema de pines del módulo ESP8266 es como sigue:

image

Las conexiones a realizar son:

ESP8266 Breadboard/Arduino
GND GND
TXD Pin 3 Arduino
CH_PD 3,3V
VCC 3,3V
RXD Pin 2 Arduino

En algunos sitios recomiendan no conectar directamente TXD y RXD a los correspondientes pines de Arduino. Las salidas de Arduino son de 5V y el ESP8266 funciona a 3,3V. Inicialmente, voy a emplear dos potenciómetros de 10KOhmios para hacer de divisores de tensión. La prueba no funciona y la unidad, como funciona es conectada directamente a los pines del Arduino.

Lo que sí es importante es que todas las masas estén conectadas para tener una referencia común del voltaje.

El esquema queda como sigue:

ESP8266_bb

ESP8266_schem

Reviso las conexiones una vez más y procedo a conectar un cable USB al Arduino y la fuente de alimentación a la placa de alimentación de la placa del prototipo.

image

En el siguiente post entraré con el software.

Reventando la autenticación de sistema abierto WEP

El objetivo de este post es ver cómo se obtiene la clave de una red WiFi protegida por autenticación de sistema abierto (Open System Authentication) mediante un ataque de fragmentación.

En primer lugar, voy a configurar el punto de acceso para que emplee este tipo de seguridad, adicionalmente, para estas pruebas iniciales, voy a quitar el filtrado MAC que, por otra parte, se cómo saltármelo.

Accedo al punto de acceso a través de la interfaz web de gestión y veo las opciones de seguridad:

Imagen20

Las opciones de seguridad tienen que ver, no sólo con la autenticación sino con el cifrado de la comunicación. Voy a establecer la opción WEP Open System y a definir la clave de acceso:

Imagen21

Como se ve voy a usar una clave de 40 bits (5 bytes) bien sencillita. Lo bueno que tiene LuCi es que, según vas escribiendo la clave, el color es rojo y se pone en negro cuando es una clave válida. Salvo y aplico la nueva configuración.

image

Como se ve, la configuración aplicada es cifrado WEP de sistema abierto empleando una clave de 40-bits.

En un post anterior, vimos la secuencia de autenticación y asociación de 802.11, voy a echarle un ojo a las tramas intercambiadas. Para ello, voy a conectarme con el cliente legítimo (Raspberry PI) y voy a capturar la secuencia de paquetes intercambiados con Wireshark.

image

La solicitud de autenticación:

image

La respuesta a autenticación desde el punto de acceso:

image

En la interfaz de administración del punto de acceso, vemos el cliente asociado a la WiFi:

image

Naturalmente, para el resto del ejercicio vamos a asumir que conocemos el BSSID, ESSID y canal del punto de acceso así como lo relativo a las características del cifrado y autenticación empleadas. Hemos visto cómo obtener esta información en posts anteriores.

Lo primero que hago es poner la interfaz en modo monitor en el canal del punto de acceso. Una vez configurada la interfaz lo que voy a hacer es una autenticación falsa con el punto de acceso. Recordemos que el mecanismo de autenticación es Open System lo que, en esencia, significa que no hay autenticación.

image

Para hacer esta autenticación falsa voy a utilizar el comando aireplay-ng con la opción 1 (autenticación falsa):

Screenshot from 2016-11-27 20-09-36

Los parámetros proporcionados al comando aireplay-ng significan:

-1. Autenticación falsa

0. Tiempo de re-asociación (en segundos)

-e HACKME_001. ESSID de la WiFi.

-a <bssid>. Dirección MAC del punto de acceso (BSSID).

-h <MAC>. Dirección MAC de la interfaz WiFi de la máquina atacante.

wlan1mon. Interfaz en modo monitor.

Y vemos, en el punto de acceso, que la estación atacante queda asociada:

image

La estación atacante ya está autenticada con el punto de acceso y asociada al mismo. Para intentar determinar la clave WEP, voy a empezar con un ataque de fragmentación (ya haré un post con la teoría). Para ello, utilizamos el comando aireplay-ng:

image

El resultado del ataque nos indica que hemos obtenido 1500 bytes del PRGA mediante el envío de fragmentos de un paquete. El keystream correspondiente se almacena en el fichero indicado.

Vamos a crear un paquete ARP y cifrarlo con el keystream obtenido en el paso anterior. Para ello usamos el comando packetforge-ng y vamos a cifrarlo (flag –y) con el PRGA obtenido en el paso anterior.

image

Una vez que tenemos el paquete ARP (arp-req) procedemos a inyectarlo en la red. En una nueva ventana de terminal, lanzo el comando airodump-ng para capturar las respuestas a los paquetes ARP que voy a ir inyectando:

image

image

Lanzamos, en la primera ventana de terminal, el comando aireplay-ng para inyectar los paquetes ARP en la red:

image

Vemos que se va incrementando el contador de paquetes enviados y, en la salida del comando airodump-ng (segunda ventana), que aumenta el número de paquetes lanzados por nuestra estación.

Finalmente, abrimos una tercera ventana de terminal y lanzamos el comando aircrack-ng para intentar obtener la clave WEP empleada para el cifrado a partir del fichero de capturas obtenido por airodump-ng:

image

Hemos tenido éxito. Comprobamos que la clave funciona conectándonos a la WiFi desde Kali.

image

image