Archivo de la etiqueta: sysadmin

Certificados SSL gratis

Hoy vengo a contaros que se pueden conseguir certificados SSL válidos en todos los navegadores, y sistemas operativos, por cero Euros. Aunque realmente lo que quiero contar es como ponerlo en marcha rápidamente, que es lo que espero no sepáis para que terminéis de leer esto 🙂

Let’s Encrypt lleva unos meses funcionando y posiblemente para cuando termine de escribir esta entrada ya habrán generado más de dos millones de certificados. Su objetivo no es acabar con la mafia y el timo de (la mayoría de) los certificados SSL de pago. Su propósito es el que tráfico de Internet viaje cifrado, para que al menos les cueste algo más de presupuesto espiarnos a todos aquellos que lo hacen.

No voy a entrar en detalle sobre el protocolo que desarrollaron (ACME), sólo comentaré las piezas que necesitamos conocer y espero que con un poco de copiar y pegar estéis funcionando en minutos.

Software

Existen varias implementaciones del «cliente ACME» necesario para gestionar la petición de certificados. De entre ellos yo elegí acme-tiny porque su código es sencillo de entender y no tiene apenas dependencias, básicamente Python y openssl. En su repositorio de github tenéis sus instrucciones de uso, muy fáciles de seguir, pero si lo queréis algo un poco más fácil he creado un pequeño script en shell, usa acme-tiny para funcionar y sólo requiere como argumento el nombre, o nombres, de dominio para los que solicitar el certificado.

También necesitaremos un servidor web, aunque el certificado SSL sea para un servidor de correo, XMPP, o lo que se os ocurra. Es necesario porque Let’s Encrypt hará una petición a nuestro servidor web para validar que el dominio del certificado solicitado es realmente nuestro. El funcionamiento a grandes rasgos es: El «cliente ACME» solicita un certificado a Let’s Encrypt, estos piden al cliente que ponga un fichero que pruebe que el dominio es nuestro (challenge) en el servidor web y posteriormente Let’s Encrypt pide al servidor web del dominio en cuestión el fichero acordado. Si el fichero está allí y es correcto, se entiende que el dominio está bajo nuestro control y el certificado se emite.

Configuración

Lo primero que necesitaremos (además de tener acme-tiny  (enlace para «wget-ear») y opcionalmente mi script (enlace para «wget-ear»)) es un directorio para guardar claves privadas y certificados. Para no ejecutar acme_tiny como root crearemos ese directorio con permisos de escritura para un usuario no privilegiado (no es buena idea usar alguno bajo el que se ejecute Apache/nginx o algún servicio), podemos usar nuestro propio usuario (en mi caso será «agi«). Ya que, en Debian, tenemos los directorios /etc/ssl/(private|certs), yo elegí /etc/ssl/letsencrypt:

# mkdir /etc/ssl/letsencrypt
# chown agi:ssl-cert /etc/ssl/letsencrypt
# chmod 750 /etc/ssl/letsencrypt

Bajaremos el certificado intermedio de Let’s Encrypt para que no de problemas la cadena de validación de nuestro certificado SSL. Lo dejaremos en el directorio creado:

# cd /etc/ssl/letsencrypt
# wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem

Crearemos una clave privada para establecer la comunicación con Let’s Encrypt:

# cd /etc/ssl/letsencrypt
# openssl genrsa 4096 > account.key
# chmod 600 account.key
# chown agi account.key

Ahora crearemos el directorio donde el «cliente ACME » dejará los ficheros de validación (challenge) y que el servidor web tendrá que devolver cuando Let’s Encrypt lo solicite:

# mkdir /var/www/letsencryptchallenges
# chown agi /var/www/letsencryptchallenges

Y configuraremos el servidor web para que sirva el contenido de ese directorio. Si tenemos un sólo dominio lo podemos hacer en la configuración es éste, y si tenemos varios configurar el directorio de forma global. A forma de ejemplo, esta sería la configuración para un servidor Apache:

Alias /.well-known/acme-challenge/ /var/www/letsencryptchallenges/
<Directory /var/www/letsencryptchallenges>
  Options None
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Y esta para un servidor nginx:

location /.well-known/acme-challenge/ {
  alias /var/www/letsencryptchallenges/;
  try_files $uri =404;
}

Llegado este punto, si no vas a usar mi script deberías seguir las instrucciones de acme-tiny para crear un CSR (Petición de firma de certificado), instalar el certificado y programar una tarea periódica que lo renueve.

Si vas a usar mi script deberías repasar las variables de configuración que tiene al principio para ajustar los ficheros y directorios que usará (los comentados anteriormente). Si estás siguiendo literalmente los pasos que llevamos hasta ahora posiblemente sólo tendrás que cambiar el path al script acme_tiny.py (apuntar la variable ACME_TINY al path donde lo dejaras y no olvidar dar permisos de ejecución a ambos). Si ya has recargado la configuración del servidor web, para que se sirva correctamente el directorio de los ficheros challenge, sólo queda una cosa que hacer, pedir el nuevo certificado:

## Ejecutar con el usuario no privilegiado, no como root!
## Lo más sencillo es dejar new_cert en el PATH (p.e. /usr/local/bin)

$ new_cert midominio.com

## Si queremos un certificado para varios (sub)dominios podemos pasar todos
## como argumentos al script.
## IMPORTANTE: En este caso, asegúrate de que el servidor web devolverá
## el fichero challenge correctamente en todos ellos
$ new_cert midominio.com www.midominio.com eldominiodemiprimo.com

Si todo fue bien, deberíamos tener varios ficheros, que toman su nombre del primer dominio especificado en la llamada a new_cert, en el directorio de trabajo que usemos. Los importantes son: DOMINIO.key, la clave privada, y DOMINIO_chained.crt, el certificado solicitado con el certificado intermedio de Let’s Encrypt. Con ellos tendremos que configurar el virtual HTTPS de nuestros dominios. Ejemplo en Apache:

<VirtualHost *:443>
  ServerName DOMINIO
  SSLEngine on
  SSLCertificateFile /etc/ssl/letsencrypt/DOMINIO_chained.crt
  SSLCertificateKeyFile /etc/ssl/letsencrypt/DOMINIO.key
......
</VirtualHost>

Ejemplo en nginx:

server {
  listen 443;
  server_name DOMINIO;
  ssl on;
  ssl_certificate /etc/ssl/letsencrypt/DOMINIO_chained.crt;
  ssl_certificate_key /etc/ssl/letsencrypt/DOMINIO.key;
...
}

Existen varios parámetros (tanto en los servidores web mencionados como en otro tipo de servidores) para mejorar la seguridad y compatibilidad SSL. En el sitio github de acme_tiny mencionan algunos (para deshabilitar SSLv3 e inferiores y corregir posibles ataques conocidos), aunque yo soy fan de la herramienta de análisis (y  recomendaciones) de Qualys SSL Labs. Así que no os quedéis en instalar el certificado y darle un repaso a parametrización del SSL.

Mantenimiento

Los certificados de Let’s Encrypt, al menos en el momento que escribo estas líneas, tienen una vigencia de tres meses. Por ello es importante que preparemos un mecanismo automático de renovación. Que consiste en algo tan simple como una entrada de cron que solicite un nuevo certificado antes de que caduque el actual. En mi caso tengo un fichero en /etc/cron.d llamado local-letsencrypt (el prefijo local- me permite diferenciar los ficheros instalados por el gestor de paquetes de los creados por mi) con el siguiente contenido (y donde digo nginx, digo apache2, postfix, prosody, dovecot, …):

# Ajustar el nombre de usuario, el path a new_cert y el comando para recargar
# la configuración del servidor correspondiente (salvo que uséis nginx y systemd)
0 6 1 * * agi /usr/local/bin/new_cert DOMINIO(s) && sudo systemctl reload nginx

# Y no olvidéis permitir a vuestro usuario ejecutar ese comando con sudo en
# el /etc/sudoers:
agi ALL=NOPASSWD: /bin/systemctl reload nginx

## O sin depender de sudo (recomendación de Tincho):
0 6 1 * * root su -u agi -c "/usr/local/bin/new_cert DOMINIO(s)" && systemctl reload nginx

Cuidado con las cosas gratis

Para los que no se fían de las cosas gratis, les recomiendo que sigan los pasos anteriormente descritos y luego envíen 200 EUR a mi cuenta de Paypal. Una vez al año, por la renovación, claro. Les garantizo que sus  datos viajarán cifrados igualmente que con el certificado más caro de [insertar entidad certificadora aquí].

$ exit

DNSSEC. Asegurando las respuestas de nuestro dominio. La práctica (II)

Validar tu implementación de DNSSEC

Si seguiste las indicaciones de mi post anterior, ahora tendrás tu dominio bajo DNSSEC. En este momento es vital que te asegures de que todo está correcto, ya que si tu dominio «anuncia» (mediante la publicación de un registro DS en el registrador) que soportas DNSSEC, pero la implementación es errónea (claves no corresponden al DS, firmas caducadas, …) tu dominio dejará de ser visible para aquellos que usen DNSSEC (que cada día serán más). Es decir, adiós a tu correo, tu web, etc…

Para comprobar que todo está OK podemos usar servicios web como:

  • http://dnssec-analyzer.verisignlabs.com/ Que lista todos los pasos para validar el soporte DNSSEC de tu dominio.
  • http://dnsviz.net/ Que visualiza la relación (firmas) entre las claves desde el dominio raíz hasta el tuyo. Además de comprobar que está correcto, ayuda a entender la relación entre los diferentes (sub-)dominios y sus claves.

Si somos más de consola, los siguientes comandos nos permitirán comprobar que nuestro dominio valida correctamente:

## Primero guardamos las claves (KSK y ZSK) de la zona raíz (.)
$ dig . DNSKEY | grep -Ev '^($|;)' > root.keys

## Luego hacemos la validación de la cadena completa (desde la raíz
## hasta nuestro dominio)
$ dig +sigchase +trusted-key=./root.keys inittab.net. SOA

Autopsia de un registro DNSSEC

Una vez seguros de que nuestra configuración de DNSSEC es correcta, nos queda un asunto que tratar… el periodo de validez de la zona firmada! Como comenté en el post anterior, la zona se firma para un periodo de tiempo limitado, por defecto 30 días. Es necesario por tanto volver a firmar antes de que caduque, ya que en caso contrario… adiós web, correo, etc… Veamos un ejemplo de registro firmado:

inittab.net. 21569 IN A 91.121.65.176 
inittab.net. 21569 IN RRSIG A 14 2 21600 20150521144640 20150421144640 34840 inittab.net. uY8......

Primero vemos el RR de tipo A para inittab.net (la IP a la que apunta). Y luego tenemos el RR de tipo RRSIG (Resource Record SIGnature) que le acompaña permitiendo verificar la validez del RR de tipo A. Analicemos los campos del RRSIG:

Después de IN RRSIG, encontramos el tipo de registro al que se refiere. En este caso: A. Luego sigue el algoritmo con el que está firmado 14 (ECDSAP384SHA384). El 2 indica el número de etiquetas (net e inittab). Si fuera para un nombre tipo foo.bar.inittab.net. el valor sería 4. Detrás tenemos el TTL original, 21600. El siguiente campo es el más relevante para tema que nos preocupa, la fecha de caducidad de la firma 2015052114464021 de mayo de 2015, a las 9 de la noche (UTC). Antes de esa fecha deberemos volver a firmar la zona o las respuestas de nuestro DNS serán interpretadas como inválidas. La siguiente fecha indica cuando se realizó la firma del registro 21 de abril de 2015, y con que clave (ZSK en este caso) se hizo, 34840 de inittab.net. Por último estará la firma propiamente dicha.

Automatizando el proceso de firma

Ya sabemos cuando caducan las firmas de nuestra zona, 2015-05-21-14:46:40 en este ejemplo. Sólo queda automatizar el proceso de mantener las firmas vigentes. Para ello podemos usar los comandos del paquete dnssec-tools, o un par de sencillos shell scripts. El primero (check_rrsig), de Hauke Lampe, comprueba la fecha de caducidad de las firmas y el segundo, de un servidor, firma la zona en caso de que sea necesario:

#!/bin/bash
## (c) 2015 Alberto González Iniesta. GPLv2
## Depends: /usr/local/bin/check_rrsig

## Configuración
#DOMINIOS="foo.com bar.net baz.org"
DOMINIOS="inittab.net"

SERVIDOR_DNS=localhost
DIR_ZONAS="/etc/bind"
DIR_CLAVES="${DIR_ZONAS}/keys"
##

SALIDA=0

renueva_firma() {
  echo -n "Renovando $1 .."
  cd "$DIR_ZONAS"
  SERIE_ACTUAL=$( dig +short @$SERVIDOR_DNS $1 soa | awk '{print $3}' )
  (( SERIE_NUEVO = SERIE_ACTUAL + 1 ))
  rndc freeze # por si la zona es dinámica
  SERIE_EN_FICHERO=$( cut -d';' -f1 $1 | awk 'BEGIN {ORS=" "} /SOA.*\(/,/\)/ ' | tr '\t' ' ' | tr -s ' ' | cut -d'(' -f2 | awk '{print $1}' )
  sed -i "s/$SERIE_EN_FICHERO/$SERIE_NUEVO/" $1
  dnssec-signzone -d "$DIR_ZONAS" -K "$DIR_CLAVES" -S -t -u -3 $( dd if=/dev/random bs=16 count=1 2>/dev/null | hexdump -e \"%08x\" ) -o $1 "${DIR_ZONAS}/$1"
  rndc thaw # por si la zona es dinámica
  if rndc reload > /dev/null 2>&1 ; then
    echo "OK"
  else
    echo "ERROR"
    SALIDA=1
  fi
}

for DOMINIO in $DOMINIOS ; do
  OUTPUT=$( /usr/local/bin/check_rrsig -n $SERVIDOR_DNS -z $DOMINIO -w +10days )
  [ $? -eq 0 ] || renueva_firma $DOMINIO
done

exit $SALIDA

Una entrada en cron para que se ejecute todos los días y listo!. El script supone que los ficheros de zona se llaman como el ORIGIN (dominio), es decir para el dominio inittab.net el fichero se llama inittab.net, y supone que está en /etc/bind. Así como que las claves se encuentran en /etc/bind/keys. Sin duda es mejorable y se aceptan parches. Pero si lo hago de esta manera es porque para aprender siempre es mejor usar el mínimo de magia. Un día migraré a dnssec-tools, que entre otras cosas gestiona el cambio (rotación) de claves (KSK y ZSK), proceso que habría que hacer con cierta periodicidad. Pero si has llegado hasta aquí ya tienes una base de DNSSEC para seguir solito 🙂

NSEC vs NSEC3. Evitando la enumeración de zona

Para tener un sistema seguro de DNS es necesario firmar respuestas negativas, evitando que alguien pueda negar la existencia de un registro por ti. Es decir, con DNSSEC una respuesta que indique que un registro no existe, también tiene que venir firmada.

No se puede firmar siempre lo mismo, es decir no se puede firmar un texto que diga «eso no existe«, ya que una respuesta negativa podría ser usada por un atacante para negar la existencia de registros que si existen (enviando la respuesta firmada «eso no existe» a un cliente). Véase Replay Attack

Tampoco podemos generar una firma por cada registro no existente, por ejemplo firmar «estonoexiste.inittab.net y estotampoco.inittab.net y …. ya que el coste computacional (firmar miles de preguntas sobre registros no existentes) sería enorme, además de requerir la clave (ZSK normalmente) en todos los servidores de la zona (el primario y todos los secundarios). Mucha exposición para la clave.

NSEC al rescate. Se ordenan los registros de la zona en orden alfabético y se crear un registro NSEC por cada dos registros consecutivos. Esto permite devolver un registro NSEC (con su correspondiente RRSIG) por cualquier pregunta al DNS de algo que no exista entre los dos registros que cubre el NSEC. Es decir, si tenemos bar.inittab.net, foo.inittab.net y nada entre ellos, habrá un registro NSEC con esta forma:

bar.inittab.net. NSEC foo.inittab.net. A RRSIG NSEC

Que se devolverá cuando se pregunte por cochino.inittab.net o demente.inittab.net o eclectico.inittab.net. El problema de NSEC es que permite enumerar la zona completa. Es decir, preguntando por entradas no existentes podemos ir obteniendo los registros existentes mediantes las respuestas NSEC. Y podrían desvelarse registros «no públicos», tipo desarrollo.inittab.net, que aunque el DNS no garantiza que sean secretos, con este sistema sería trivial descubrirlos.

Para evitar este problema se crea NSEC3. La idea es más o menos la misma, pero con un cambio importante. Primero se hace un hash de todas las entradas de la zona y son estos hash los que se ordenan y los que componen una respuesta NSEC3:

LCFQO0AOA1QL3Q7A8E0ONQ9T2PTRLFS3.inittab.net. 86400 IN NSEC3 1 0 10 874201500AC7C3CFDAB802EDD07EEFFD ( VPE6NRVJK9AI2SUFEJG8I0G36C1ANBGS CNAME RRSIG )

NSEC3 no evita, mediante ataques por fuerza bruta/diccionarios, que se termine por enumerar la zona. Pero lo hace bastante más complejo, sobre todo si se usan salts aleatorias (en el ejemplo anterior el campo que empieza por 87420….). De ahí las opción -3 y los dd/hexdump en el comando dnssec-signzone recomendado en éste y el anterior post. De hecho ya hay planes de un NSEC5 que solvente la posible enumeración con NSEC3

$ exit

Cifrando discos, particiones o ficheros con LUKS

Uno de los mecanismos más eficaces para proteger nuestra información es el cifrado. Hoy no se me pasa por la cabeza tener un portátil sin el disco cifrado. Lo grave no sería la pérdida física del mismo, sino la de la información que lleve y en las manos que pueda acabar. Pero esto no es sólo aplicable a portátiles, discos USB o pendrives con información sensible también deberían estar cifrados para evitar que dicha información sea accesible por terceros no autorizados.

En GNU/Linux tenemos múltiples opciones a la hora de cifrar nuestra información. GPG sobre ficheros, eCryptfsEncFS sobre directorios, TrueCrypt o dm-crypt sobre dispositivos,  loop-AES para ficheros loop, etc. De todas las opciones mi preferida es LUKS (Linux Unified Key Setup), que podemos usar sobre discos, particiones, volúmenes lógicos (LVs) o ficheros loop. Entre sus ventajas están: su sencillez de uso, incluido en el propio kernel y la capacidad de asignar, cambiar y revocar varias claves para un mismo dispositivo.

La instalación de muchas distribuciones actuales hace muy sencillo incorporar el cifrado del sistema completo desde el principio. Mi recomendación en un portátil es: crear una pequeña partición para /boot (que no irá cifrada) y dejar el resto del disco para ser cifrado con LUKS. Sobre dicho cifrado crear un PV para LVM y  todo lo que vaya sobre el LVM ya estará cifrado.

Pero en la entrada de hoy veremos como usar LUKS en un sistema que ya está corriendo, por ejemplo para cifrar un nuevo volumen lógico, un fichero loop donde guardar información sensible, o un dispositivo USB donde realizar backups.

Ingredientes

Tener instalado el paquete cryptsetup (también llamado cryptsetup-luks en algunas distribuciones). Tener un dispositivo sin usar (su información será reescrita al cifrarlo inicialmente), por ejemplo /dev/sdc, /dev/vgpruebas/cifrado, /dev/sdb2,… En el caso de querer user un fichero (loop) podemos crearlo con este comando:

## En este ejemplo 50 bloques de 1MB ~ 50MB
## Aunque es posible crecer el fichero posteriormente es
## algo enrevesado, mejor afinar con el tamaño que necesitemos
## Podemos usar /dev/zero como origen de datos en la creación
## del fichero también, pero facilitaría un posible criptoanálisis
$ dd if=/dev/urandom of=fichero_cifrado bs=1M count=50

Inicialización del cifrado

El primer paso será dar el formato LUKS al dispositivo. Para ello usaremos el comando cryptsetup con argumento luksFormat. Entre las diversas opciones que podemos especificar está el algoritmo de cifrado, el tamaño de la clave o la función hash (resumen) o el fichero clave.

Veamos algunos ejemplos:

## Cifrar el fichero creado en el ejemplo anterior con una
## contraseña, pidiéndola dos veces (para confirmar que
## se tecleó correctamente). Usando valores por defecto
## para el cifrado:
$ cryptsetup --verify-passphrase luksFormat fichero_cifrado

## Podemos averiguar el algoritmo, tamaño de clave y función
## hash que se usan por defecto con este comando:
$ cryptsetup --help | grep LUKS.*Key
 LUKS1: aes-xts-plain64, 
 Key: 256 bits, 
 LUKS header hashing: sha1, 
 RNG: /dev/urandom

## Si los valores por defecto no nos convencen, podemos
## especificar otros, por ejemplo un tamaño de clave de
## cifrado mayor (de 256 bits) y una función hash que no
## haya sido declarada insegura (como es el caso de SHA1):
cryptsetup --hash=sha256 --key-size=512 --verify-passphrase \
 luksFormat fichero_cifrado

## Cifrar un dispositivo (p.e. un disco USB) usando un fichero
## como contraseña.
## Primero creamos el fichero de contraseña (podemos hacerlo
## a mano, o usar /dev/random o /dev/urandom para rellenarlo)
$ dd if=/dev/urandom of=mi_secreto bs=1M count=1

## Un megabyte de contraseña!
## ¿Qué tamaño máximo de contraseña (tecleada o en fichero)
## podemos usar? El siguiente comando lo aclara:
$ cryptsetup --help | grep Maximum
   Maximum keyfile size: 8192kB,
   Maximum interactive passphrase length 512 (characters)
 
## Una vez tenemos el fichero de contraseña, podemos dar el
## formato LUKS usando éste, en vez de tecleando una contraseña
## de forma interactiva
## El siguiente comando lo ejecutamos como root, al tratarse
## de un dispositivo (/dev/sdc) y no un fichero de usuario:
# cryptsetup luksFormat /dev/sdc /path/al/fichero/mi_secreto
## o
# cryptsetup --key-file=/path/al/fichero/mi_secreto luksFormat /dev/sdc

## Por supuesto también podríamos modificar el tamaño de clave
## de cifrado o la función hash.

Clave de cifrado, contraseña y cabecera LUKS

Llegados a este punto debo (intentar) esclarecer algún término. Cuando damos formato LUKS a un dispositivo/fichero hablamos de dos términos similares, pero diferentes:

  • Contraseña. Ya sea una tecleada en el momento, o un fichero usado como tal, es la que nos permite acceder al dispositivo LUKS. Esta contraseña no es usada para cifrar los datos. De hecho, una de las ventajas de usar LUKS es que podemos usar varias contraseñas/ficheros contraseña para un mismo dispositivo. Más adelante daré un ejemplo.
  • Clave de cifrado. Esta clave se genera automáticamente cuando damos el formato LUKS al dispositivo. Se genera de forma aleatoria (por defecto usando /dev/urandom) y con el tamaño por defecto (256 bits) o el que se especifique con la opción –key-size. Si bien es posible especificar una clave de cifrado de forma manual (–master-key-file) no es recomendable hacerlo salvo que sepas exactamente que estás haciendo.

El formato LUKS se caracteriza por una cabecera que incluye la información del algoritmo de cifrado, tamaño de clave, contraseñas en uso, etc. Podemos consultar dicha cabecera (que no las contraseñas!) con el siguiente comando:

$ cryptsetup luksDump fichero_cifrado 
LUKS header information for fichero_cifrado

Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha256
Payload offset: 4096
MK bits: 512
MK digest: ca cb 7e f6 20 fa 42 8a 7e 0a 92 66 86 bd 20 46 77 28 a5 25 
MK salt: a1 e5 54 8d c2 4d db af 3d 72 73 4d f6 0b 9f b7 
 41 d7 46 31 ce dc f8 11 21 86 8c 22 d9 cf e5 ca 
MK iterations: 95125
UUID: d58132bd-ea6b-4879-aa73-c8d444300545

Key Slot 0: ENABLED
 Iterations: 378697
 Salt: 1a 54 1a cd 92 74 13 78 5d 72 f4 00 60 b4 69 85 
 c7 8a a9 fa 50 65 6b 32 f4 13 a4 e2 b6 3b c3 69 
 Key material offset: 8
 AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

En este ejemplo vemos que se está usando AES como algoritmo de cifrado, que el tamaño de clave es de 512 bits, la función hash es SHA256 y que hay una contraseña (de las 8 posibles) en uno (Key Slot 0: ENABLED). El resto de posibles contraseñas no están establecidas (DISABLED).

Usando el dispositivo cifrado

Una vez tenemos el formato LUKS en el dispositivo, para acceder a los datos en claro habrá que «abrir el contenedor cifrado». Es decir, antes de poder usarlo (montarlo o formatearlo) hay que descifrarlo:

## Si vamos a abrir un fichero protegido con
## contraseña "tecleada":
# cryptsetup luksOpen fichero_cifrado dispositivo_descifrado

## Si el fichero o dispositivo está protegido con un fichero
## contraseña, se lo indicamos como opción:
#  cryptsetup --key-file=mi_secreto luksOpen /dev/sdc dispositivo_descifrado

## Unos comentarios sobre estos ejemplos:
## 1.- "dispositivo_descifrado" es el nombre que queremos para el
##     dispositivo que se creará trás ejecutar este comando
##     y que será el que ya usemos para formatear o montar de forma
##     normal
## 2.- Si la contraseña es válida, desde este momento podremos acceder
##     al dispositivo "en claro" como /dev/mapper/dispositivo_descifrado
## 3.- Estos comandos se ejecutan con el usuario "root" ya que crean
##     un dispositivo nuevo. (Sí, seguro que hay interfaces de usuario
##     que permiten estas tareas a un usuario corriente)

Por supuesto, la primera vez que lo abrimos lo más frecuente será formatearlo, como con cualquier dispositivo nuevo:

mkfs.ext4 /dev/mapper/dispositivo_descifrado

Desde ese momento, y después de abrirlo con «luksOpen«, simplemente lo montaremos como el resto de dispositivos de almacenamiento:

mount /dev/mapper/dispositivo_descifrado /media/mis_datos_secretos

Cerrar después de usar

Cuando ya no necesitemos acceso a los datos, y después de desmontar como con cualquier otro dispositivo de almacenamiento, debemos «cerrar» el acceso al dispositivo sin cifrar. O como decía Mamá – deja las cosas como las encontraste:

## Desmontar antes de cerrar el acceso
# umount /media/mis_datos_secretos
## Eliminar el acceso al dispositivo descifrado
# cryptsetup luksClose dispositivo_descifrado

¿Varias contraseñas?

Para terminar comentaré una de las características que más me gustan de LUKS y que en un principio puede sonar extraña: la capacidad de tener varias contraseñas/ficheros contraseña.

Insistir en que las contraseñas no son las que se usan para cifrar, eso se hace con la clave de cifrado, sino para dar acceso a ésta y poder abrir el dispositivo. Poder usar más de una (y ser capaces de revocarlas, cambiarlas o añadirlas) permite:

  • Tener una contraseña por usuario para un mismo dispositivo. De forma que cada uno sabe la suya y si un día se decide evitar el acceso de uno de ellos basta con eliminar su contraseña, lo que no afecta al resto de usuarios.
  • Tener una contraseña para nosotros (que tecleamos cuando queremos acceso al dispositivo) y tener un fichero contraseña para tareas automatizadas (por ejemplo backups). Yo tengo un disco USB donde se hacen backups de mi portátil de forma automática. Para no tener que teclear la contraseña (y estar delante del ordenador) cuando se realiza el backup, en el disco del portátil tengo un fichero contraseña que le permite descifrar el USB y realizar el backup. Por supuesto este fichero contraseña sólo puede leerlo el usuario root y el disco de mi portátil está cifrado. Pero ¿qué pasaría si el disco de mi portátil muere? Ya no tendría el fichero contraseña para descifrar el disco USB de backup. Estúpida situación ésta… Salvo que el USB con LUKS tiene una segunda contraseña (que puedo teclear) y que me permitiría acceder a él aunque el disco de mi portátil muriera.

Sobra decir que hay que tener sumo cuidado con los ficheros usados como contraseña, su acceso debería estar extremadamente limitado (permisos, acceso al dispositivo donde se almacenan, etc..).

¿Cómo gestionamos las contraseñas de un dispositivo con LUKS?

Como vimos anteriormente, podemos ver la información de la cabecera LUKS con el comando «cryptsetup luksDump DISPOSITIVO«. En el veremos los «slots» («contraseñas») que están en uso. Normalmente el slot-0 siempre lo está, porque es donde se guarda la contraseña inicial. Podemos añadir una nueva contraseña con el siguiente comando:

## Si queremos una contraseña "tecleada"
# cryptsetup luksAddKey /dev/sdc

## Primero nos pedirá una contraseña ya existente
## en alguno de los slots, si no hay contraseña
## sino "fichero contraseña" deberemos usar la
## opción --key-file:
# cryptsetup --key-file=/etc/mi_secreto luksAddKey /dev/sdc

## Si queremos añadir un "fichero contraseña"
# cryptsetup luksAddKey /dev/sdc /etc/mi_nuevo_secreto

## Al igual que antes, si no hay una contraseña en
## algún slot, sino que son todo ficheros contraseña
## le indicamos alguno de los actuales con --key-file
# cryptsetup --key-file=/etc/mi_secreto \
    luksAddKey /dev/sdc /etc/mi_nuevo_secreto

También podemos borrar o cambiar contraseñas (o ficheros contraseña) existentes:

## Para borrar un "slot" tenemos dos opciones:
## Teclear (o especificar el fichero contraseña
## después del nombre de dispositivo)
$ cryptsetup luksRemoveKey /dev/sdc
$ cryptsetup luksRemoveKey /dev/sdc /etc/secreto_a_eliminar

## O si no tenemos/recordamos la contraseña, especificar
## el slot que queremos eliminar (nos pedirá alguna de las
## contraseñas (o ficheros contraseña con --key-file)
## restantes en otro slot
$ cryptsetup luksKillSlot /dev/sdc 2
$ cryptsetup --key-file /etc/secreto_valido /dev/sdc 2

Copia de seguridad

El punto más débil de nuestro dispositivo cifrado es la cabecera LUKS. Sin ésta sería imposible acceder a los datos que contiene. Es recomendable por tanto, realizar una copia de seguridad de ella que nos permita acceder a los datos cifrados en el caso de que la cabecera LUKS quede dañada (por error en su gestión, o daño físico en el dispositivo de almacenamiento).

## Podemos sacar una copia de la cabecera con el siguiente comando
$ cryptsetup luksHeaderBackup /dev/sdc --header-backup-file cabecera_backup
## O restaurar una cabecera dañada desde un backup
$ cryptsetup luksHeaderRestore /dev/sdc --header-backup-file cabecera_backup

No metas cosas en criptas, cogen humedad

Cada vez que alguien dice «encriptar» o «encriptado» Dios mata un gatito. FYI.

$ exit