Backups automatizados en red: Bacula

Bacula es una solución open source de backups, que permite realizar copias de seguridad de forma automatizada y programada, y su principal característica a destacar es que permite hacerlo a través de la red. Esto es, aunque se puede utilizar en entornos domésticos (aunque quizás ésta no sea la mejor solución, sino ésta otra), donde mejor se desenvuelve Bácula es en un entorno empresarial, donde hay máquinas y servidores virtuales, servidores dedicados, equipos de usuario, etc...

Aquí tenéis la web del proyecto: http://www.bacula.org

Supongamos el siguiente escenario: Estamos en una red donde tenemos un dispositivo de almacenamiento tipo NAS o similar, de varios chorrocientos de gigas. También tenemos en la misma red varios equipos de usuario y algún que otro servidor. Pues bien, lo que queremos hacer es que todos los sábados (por ejemplo) se haga una copia de seguridad completa de ciertos directorios y archivos de interés de todos nuestros equipos, y que todos los días se haga una copia incremental de los mismos. Aquí es donde entra en juego Bacula.

Cabe decir que Bacula no es apropiado para backup de bases de datos, sino de archivos.

Bacula se compone de varias partes, las explicaré de forma resumida, y luego veremos más en detalle cómo se configura todo ello (supondremos que todos los equipos corren Linux Debian o similar, para simplificar un poco).

• Por un lado tenemos el Storage Daemon, o Bacula-sd, es el demonio de almacenamiento, el que va a almacenar las copias.
• Tenemos también los clientes, o Bacula-client, que son los demonios instalados en los equipos de los cuales queremos hacer backup.
• Disponemos también de una consola llamada bacula-console, que nos servirá de utilidad a la hora de hacer backups manuales, restaurar un backup antiguo, simular una operación de backup (a modo de "a ver cómo quedaría"), crear/modificar/eliminar dispositivos de almacenamiento, etc.
• Y por último tenemos el Director de la orquesta, o Bacula-director, es el componente que va a dirigir el cotarro, por así decirlo, es el que dice quién hace qué en cada momento.

Debo decir que Bacula permite trabajar con las llamadas "tapes", pero aquí veremos almacenamiento digital, sobre un disco duro (ya sea cifrado o no).

En primer lugar instalamos el Director en el servidor principal desde el cual controlaremos el proceso de copias (luego veremos cómo configurarlo):

aptitude install bacula-director-common bacula-director-mysql

Instalamos también todas las dependencias requeridas, claro.

Después instalamos el Storage Daemon en el servidor que hará el almacenamiento de las copias (puede ser el mismo servidor en el que instalamos el director):

aptitude install bacula-sd

Por último, instalamos el cliente en cada equipo del que queremos realizar un backup:

aptitude install bacula-client

Con las herramientas instaladas, vamos a ver cómo configurarlo.

Como cada "demonio" puede ser nombrado de una forma determinada, nosotros les llamaremos debian-dir al Director, debian-sd al Storage Daemon, y debian-fd1/2/3... a cada cliente (ya que, por defecto, Bacula coge el hostname para nombrar cada componente). Aún así, la mayor parte de la configuración por defecto está bien, pero modificaremos algunas cosas.

En el bacula-sd (/etc/bacula/bacula-sd.conf) debemos configurar los parámetros de la unidad de almacenamiento (puede ser un volumen local, remoto, o puede estar sobre un sistema de ficheros cifrado). Empezamos por el Storage, que es la definición del propio módulo en sí:

Importante: Bacula no trabaja bien con nombres de hosts, por lo que siempre que haya que configurar una ip, así lo haremos (aunque sea una dirección de localhost, definiremos la ip que utiliza en la red).

A continuación le decimos a bacula-sd quién es el Director:

Aquí figuran 2 directores, el principal por así decirlo (debian-dir) y el monitor (debian-mon). El monitor es el que va a consultar el estado en el que se encuentra bacula-sd. Como véis, tenemos que decirle con qué pass se va a conectar cada uno (ojo, no son pass de usuario, ni mucho menos, son contraseñas que sólo usará Bacula). Sí, ya sé que es una barbaridad enviar contraseñas sin cifrar por la red, pero es así como funciona (también las enviábamos en conexiones http y nadie se echaba las manos a la cabeza... :-) ).

A continuación definimos el tipo de almacenamiento que utilizaremos:

También tenemos la opción de definir un  cargador de cintas, pero en este caso no lo vamos a utilizar.
Por último, permitiremos que bacula-sd envíe mensajes al Director:

Pasemos ahora a los clientes. En cada uno de ellos configuraremos los siguientes parámetros:

Tenemos el Director y el monitor, con sus respectivas contraseñas. También definimos el propio demonio cliente y el envío de mensajes.

Finalmente, definiremos el bacula-dir (este tiene un poco más de chicha). Principalmente se basa en definiciones de trabajos y entidades, ahora lo veremos.

En primer lugar definimos como siempre al propio Director:

Seguidamente definimos un trabajo de backup:

Definimos también el trabajo que engloba a esta definición de trabajo (es un poco lioso, pero al final es una jerarquía de Trabajo -> Definición de Trabajo -> Definición de elementos que lo componen).

Definimos un trabajo de Restore, para poder restaurar las copias que hagamos (los parámetros son casi autoexplicativos):

Definiremos un File Set, es decir, los archivos de los que queremos hacer backup, y los que queremos excluir, si los hubiera. También podemos definir una firma de tipo MD5, que utilizará Bacula para determinar si ha habido cambios o no.

Definimos ahora la programación horaria, para decir cuándo se ha de hacer un backup completo, cuándo un icremental, etc. En este caso haremos un backup completo todos los domingos a las 23:05, y un incremental todos los días a las 23:05:

Definimos también el catálogo, donde Bacula hará su inventario de archivos de los que ha hecho backup, diferencias, etc...

Ahora definiremos los clientes de los cuales hay que hacer backup:

Le decimos el dispositivo de almacenamiento:

En caso de tener un cargador de cintas, lo definiríamos aquí. En la configuración por defecto hay unos cuantos ejemplos.

Especificamos los datos de conexión a la base de datos:

Y habilitamos el envío de mensajes estándar y, opcionalmente, por email, en cuyo caso debemos especificar la dirección en el parámetro %r:

Definimos los Pool que servirán de almacenamiento, el tiempo durante el cual se guardarán los volúmenes y el tamaño máximo y número de volúmenes.

Definimos la consola:

Antes de arrancar la consola, nos aseguramos de que tiene puesta la ip correcta del Director al que tiene que conectar (/etc/bacula/bconsole.conf):

También debemos definir todos los componentes (director, sd y fd) en el archivo /etc/bacula/tray-monitor.conf.

Tras comprobar que todo está correcto, vamos a testear el sistema a mano para asegurarnos de que todo funciona correctamente. Para ello, iniciamos todos los servicios:

/etc/init.d/bacula-sd start

/etc/init.d/bacula-fd start

/etc/init.d/baclua-dir start

Y comprobamos las configuraciones de todos los ficheros:

/usr/sbin/bacula-sd -t -c /etc/bacula/bacula-sd.conf

/usr/sbin/bacula-fd -t -c /etc/bacula/bacula-fd.conf

/usr/sbin/bacula-director -t -c /etc/bacula/bacula-dir.conf

En mi caso, el Director me dio un error de autorización del usuario bacula en la base de datos. Esto lo solucioné dando permisos a dicho usuario y estableciendo el parámetro DB Address del bacula-dir.conf a localhost.

Arrancamos la consola de Bacula para administrar el sistema de backups de forma manual:

bconsole

Primero tecleamos help para ver una lista de los comandos disponibles, y tras ello creamos un volumen de almacenamiento:

Ahora vamos a crear un backup:

A partir de aquí, si tecleamos "yes", ejecutará el backup. En este caso, detecta que es un backup incremental. Sin embargo, si no hay ningún Full Backup que le sirva de base para hacer el incremental, hará un Full. Con un status dir obtenemos el estado del Director, así como un listado de los útlimos jobs:

En este caso, hemos hecho un Full, y después hemos hecho un Incremental (jobs 7 y 8), mostrando en cada caso los bytes copiados:

El comando restore es muy parecido, sólo hay que seguir las opciones disponibles para ejecutar un trabajo de restauración de archivos. Pongamos que ahora borramos todos los archivos de los que hemos hecho backup. Vamos a hacer un restore para comprobar (con archivos dummy por supuesto) que funciona bien.

Listamos los últimos 20 Jobs, y elegimos el último de ellos:

A partir de aquí podemos explorar el backup para ir seleccionando los archivos que queremos restaurar mediante el comando mark [nombre de archivo] o mark all para seleccionar todos los archivos:

En este caso sólo podemos seleccionar un archivo porque hemos seleccionado restaurar un backup Incremental, y es ese archivo el que habíamos modificado después de hacer el Full Backup. Tecleamos done para terminar, seleccionamos un cliente donde restaurar, y aceptamos:

Nos mostrará un mensaje del trabajo que se ha añadido a la cola para procesar y, si no hay trabajos pendientes, lo hará inmediatamente.

No obstante, aquí tenéis una completa guía de la consola de bácula donde se detallan todas las opciones disponibles y su funcionalidad.

Podemos comprobar que se ha restaurado correctamente el Full Backup, con los incrementales correspondientes hasta llegar al que habíamos seleccionado para restaurar:

Y ya está, tenemos un sistemas de backups completos e incrementales automatizados y, si quisiéramos, sobre un sistema de ficheros cifrado.

Seguramente hay soluciones mucho mejores, pero en cuanto a open source no está nada mal. Es fácil de montar y de gestionar, y lo que es más importante, la restauración de archivos funciona exactamente igual que los backups, evitando así la tediosa labor de rescatar un backup y devolver los archivos a sus sitios originales.

También podríamos comprimir los volúmenes llenos, bien mediante un cron o un script por ejemplo, pero eso ya lo dejamos a elección del lector.

--EOF--

RWAP

En esta entrada os voy a presentar a RWAP (Rogue Wifi Access Point), un script en bash cuya función es sencillamente la que indica su nombre, levantar un punto de acceso wifi falso y realizar un ataque de MITM a los clientes que se conecten a ella.

Mucho se ha hablado ya de este tema (aquí tenéis un ejemplo y aquí tenéis una demo), de modo que no vamos a repetir lo que ya se ha explicado montones de veces, además de haber cientos de tutoriales perfectamente explicados por internet. Si os interesa el hacking wifi, aquí tenéis una serie de posts geniales para centraros en este tema.

Rwap tiene dos modos de funcionamiento principalmente: normal y "twin". En el modo normal, lo que hace rwap es levantar un punto de acceso wifi con un essid del tipo WLAN_XXXX, donde XXXX son los cuatro últimos dígitos de la mac generada aleatoriamente para cambiar la mac de la tarjeta wifi con la que hacemos el ataque. En el modo "twin", el script levanta airodump para escanear las redes wifi cercanas, y preguntar por el essid y el bssid que queremos clonar, he intentará funcionar con la máxima potencia posible.

Sea en un modo u en otro, se arranca un servidor dhcp para proporcionar ip's a los clientes (cuyo fichero de configuración se lo podemos pasar como parámetro, o cogerá el que trae rwap por defecto), y se arranca sslstrip y ettercap para realizar el ataque MITM. Por defecto, rwap abrirá 4 terminales en los que podremos visualizar las diferentes salidas de los scripts arrancados, o podemos especificar un fichero de salida al que volcar los logs de ettercap.

Lógicamente, rwap requiere que tengamos instalada la suite aircrack (o airodump y airmon), sslstrip, ettercap, macchanger y isc-dhcp-server.

Hay soluciones mucho mejores (y más bonitas) que ésta por internet, pero aquí la tenéis para quien quiera testearla, usarla, mejorarla, etc...

Os dejo con el "help" del script:

--EOF--

DictMaker

A la hora de elegir una contraseña, dependiendo de para qué servicio sea, tenemos en cuenta unos factores u otros. Por ejemplo, si es para acceder a nuestro correo electrónico, solemos utilizar una contraseña fácil de recordar sobre todo, ya que la vamos a utilizar con frecuencia. Si es para darnos de alta en un servicio que rara vez vamos a utilizar, o incluso sólo la vamos a necesitar una única vez, utilizamos una contraseña cualquiera, del tipo "1234", o "pass", ya que nos importa bien poco la protección de la cuenta de turno.

Es muy frecuente también que utilicemos la misma contraseña para todos o muchos de los servicios a los que accedemos, con los riesgos de seguridad que ello conlleva, y a pesar de las miles de veces que se ha dicho que no se utilicen este tipo de "política de contraseñas". Todo esto, en un entorno "doméstico", digamos.

En cambio, si nos encontramos en entornos corporativos, es posible que se utilicen contraseñas aleatorias para acceder a los diferentes servidores de la empresa (ya que es poco probable que los usuarios utilicen este tipo de contraseñas). En este caso, lo más probable es que se acceda a algún servicio web del tipo randomkeygen.com por ejemplo, para generar éstas.

DictMaker es precisamente eso, un generador de los tipos más comunes de contraseñas aleatorias (no apto para lo más puristas de la aleatoriedad), y está escrito en python. Así, tenemos un tipo de contraseñas "decentes" (que constan de letras mayúsculas, minúsculas y números, con una longitud de 10 caracteres), contraseñas frecuentemente utilizadas para acceso root (mayúsculas, minúsuculas, números y caracteres especiales con una longitud de 30), diferentes tipos para wep y wpa, etc...

Sólo hay que pasarle como parámetros los tipos de contraseñas que queremos generar, y el tamaño total del diccionario (tamaño aproximado):

Así, el diccionario generado se puede utilizar para hacer un "reparto" de contraseñas, o bien para realizar un ataque de diccionario a algún hash o algún servicio de login. Tampoco nos engañemos, en un espacio de caracteres donde puede haber billones de combinaciones posibles, es poco probable que, generando un diccionario de 100M, demos en el blanco.

No obstante, ahí queda para quien quiera testearlo, mejorarlo o simplemente enviarlo a /dev/null.

-- EOF --

Cracking WPA/WPA2 con reaver

Hace poco estuve cacharreando con reaver-wps, una herramienta que se publicó hace un tiempo para crackear las contraseñas de tipo WPA y WPA2 en conexiones Wifi.

Esta herramienta aprovecha una vulnerabilidad en el método de asocación cliente-router WPS, por el cual el cliente envía un número pin de 8 dígitos, y si éste coincide con el configurado en el router, se permite la asociación. De esta forma, existen 100 millones de combinaciones posibles.

El fallo reside en que el router envía una respuesta ante el envío de los 4 primeros dígitos. Si éstos no son correctos, el router envía una señal EAP-NACK, con lo cual reducimos el número de combinaciones a 10.000 en una primera atacada (10 elementos en grupos de 4 donde el orden es relevante y se pueden repetir). Una vez tenemos los 4 primeros dígitos correctos, nos quedarían 3 dígitos restantes, puesto que el último dígito es un checksum.

De esta forma tenemos en total 11.000 combinaciones posibles, las cuales se pueden completar en un período de tiempo medio de entre 4 y 10 horas (en mis pruebas, en la mayoría de los casos he conseguido descifrar la contraseña en torno al 95% del proceso total, unas 8 horas aprox.), pero también depende del tiempo entre cada comprobación de pin, de que el router bloquee durante un tiempo el intento de acceso, etc...

La herramienta en sí tiene varias opciones:

Entre ellas, las más típicas son:
   -i Para seleccionar la interfaz wifi que utilizaremos para el ataque
   -b Para seleccionar el BSSID del PA que queremos atacar
   -v o -vv Para que la herramienta nos reporte información adicional sobre el proceso
   --mac Para especificar la mac de nuestra tarjeta wifi

Para nuestras pruebas, lo primero que haremos será cambiar la mac de la tarjeta wifi para no revelar datos "comprometedores" en el ataque:

Después ponemos la tarjeta wifi en modo monitor:

Iniciamos airodump para ver las redes a nuestro alcance, el tipo de cifrado y el bssid:

Sé lo que estáis pensando, ¿para qué te vas a complicar con WPA2 si tienes disponible una WEP? Ya, pero no es el caso.

Así que iniciamos reaver (utilizaremos NUESTRO punto de acceso con nombre H0m3). Cabe destacar que como hemos spoofeado la mac de la tarjeta wifi, a reaver le tenemos que indicar la mac nueva que nos hemos puesto:

Al cabo de un tiempo (dependiendo de los segundos que pasen entre cada comprobación de pin), si el router que queremos atacar tiene activado la asociación por WPS, obtendremos la contraseña de acceso:

Hay que decir que durante el proceso se cayó la conexión wifi varias veces, con lo cual podemos estar provocando un DoS con este ataque.

La herramienta posee otras opciones también bastante interesantes, como restaurar una sesión o enviar claves DH pequeñas para incrementar la velocidad, pero esto lo dejamos para el lector.

La forma de protegerse frente a este tipo de ataques es desactivando la asociación por WPS en el router, dependiendo del modelo se hará de una forma u otra, pero básicamente basta con entrar en la configuración avanzada y desactivar esta opción.

Como dijeron al final de la RootedCon '10, Hack The World!

--EOF--

Wireless usb TP-Link TL-WN821N en Debian Wheezy

Normalmente suelo tener una máquina para hacer pruebas y cacharrear un poco, conectada a un router mediante cable ethernet. Pero esta vez se trataba de jugar con la tarjeta wifi, para lo cual eché mano de una tarjeta wireless usb que tenía por ahí. Cual fue mi sorpresa que al conectar el usb la típica interfaz wlan0 no se levantaba (que raro...) en mi Debian Wheezy. Reviso el syslog y encuentro lo siguiente: 

Vale, no encuentra el firmware. Reviso el directorio /lib/firmware y efectivamente, allí no está. Googleando un poco encuentro la descarga de carl9170-1.fw, puesto que el fabricante sólo proporciona drivers para Windows en este caso. Descargo el archivo, lo muevo al directorio de firmware, hago un rmmod carl9170 y modprobe carl9170, y la interfaz sigue sin levantarse. Vuelvo a revisar el syslog, el directorio, y lo que encuentro es un carl9170-1.bin.

Googleando un poco más, veo en las páginas de Debian que para instalar ese driver basta con instalar desde repositorios el paquete firmware-linux-free:

Instalo, hago un ifconfig y allí está, una bonita interfaz wlan0 levantada (entre otras).

Por curiosidad, vuelvo a revisar el directorio de firmware, y efectivamente, ahí está nuestro carl9170-1.fw