Contraseñas más seguras con Keepass

Uno de los problemas más comunes actualmente es el infierno de las contraseñas. Te registras y tienes cuentas en muchas páginas web. En cada una de ellas tienes que tener un usuario y contraseña, pero es imposible recordar tantas contraseñas si son diferentes. ¿Qué suele hacerse? Pues tener la misma en todo o al menos dos o tres diferentes según la criticidad de los datos que alberga la página.
Esto no es lo óptimo en cuanto a seguridad. El otro día me llegó un correo de un foro de linux: habían atacado la página y se habían filtrado contraseñas. Y hace poco idem de lo mismo con kickstarter. ¿Tengo que cambiar la contraseña en todas las páginas en la que la puse? Complicado y pesado.
En el trabajo me enseñaron una utilidad de lo más práctica: keepass. Es software libre y permite almacenar y generar contraseñas. Solo debes recordar la contraseña maestra para abrir la base de datos cifrada del programa y tienes acceso a todas las demás.
Los datos están cifrados en tu disco duro y sin la clave maestra no puedes abrirlos. Una vez abiertos el funcionamiento es muy cómodo. Puedes crear entradas en la base de datos indicando usuario, url a la que pertenece, contraseña, notas, caducidad, etc.
Se puede buscar entre las entradas y agruparlas por categorías que también son configurables. Además, tiene un generador de contraseñas aleatorias al que le puedes indicar la longitud y complejidad.
Como decía antes es software libre y está disponible para linux, windows, mac y android. (En linux se llama keepassx)
Es una solución muy buena para tener contraseñas complejas y diferentes para cada lugar al que necesites acceder y que su uso sea cómodo.
Eso sí: recuerda tener copia del archivo de las claves para no perderlo.

Para mejorar un poco la experiencia se puede usar el recordatorio de contraseñas del navegador. En firefox, por ejemplo, permite algo similar a keepass poniendo una clave maestra. De esta forma te la solicitará una vez cuando abras el navegador y luego tendrás las claves de las páginas que hayas memorizado disponibles sin tener que buscarlas en keepass.
En mi caso, además, lo tengo centralizado con mozilla sync en mi owncloud. El tráfico viaja también cifrado y se almacena en un ordenador de mi confianza. De esta forma en los ordenadores en los que confío sincronizo el firefox y tengo las mismas contraseñas (y marcadores) disponibles.

Para terminar, un enlace muy interesante. Se trata de un manual sobre seguridad. Habla de keepass, Tor, OTR y un montón de temas más:
https://www.cryptoparty.in/documentation/handbook

Compartir y permisos

Recientemente compartí parte de un disco duro con NFS en casa. En principio somos solo dos usuarios, pero surgieron problemas de permisos rápidamente. Después de darle un par de vueltas, decidí meter a los dos usuarios en un grupo:
groupadd shared
usermod -aG shared usuario1
usermod -aG shared usuario2

Sin embargo, si lo hacemos así los archivos creados o copiados no serán del grupo "shared", sino del primario del usuario, probablemente "users".
Así que podemos cambiar el grupo primario en lugar de añadir el grupo
usermod -g shared usuario1
usermod -g shared usuario2


Ahora hay que darle permisos la los archivos ya existentes. ¿Cómo lo hacemos? Pues decidí darle permiso de lectura y escritura a todos los archivos al usuario propietario y a los pertenecientes al grupo.
sudo chown -R usuario1:shared directorio
sudo chmod -R 660 directorio

Pero hay un pequeño problema... ¿qué pasa con los directorios? Para poder listar sus contenidos hay que dar permisos de ejecución. Y lo acabamos de quitar con el comando anterior. ¡Hay que ir de uno en uno! Noooo...
sudo find directorio -type d -exec chmod 770 {} \;

¿Y los archivos nuevos? Para eso está umask. Usaremos la máscara 007. Los permisos serán 777-007: 770 para directorios y 660 para archivos.
Editamos los .bashrc de los usuarios y añadimos:
umask 007


Con esto estaría listo. Bueno, queda un detalle más. No compartimos solo dos usuarios. Hay un tercero: el demonio de transmission. Este demonio crea los archivos con el usuario transmission y grupo transmission. Así que añadimos  a los usuarios al grupo de transmission:
usermod -aG transmission usuario1
usermod -aG transmission usuario2

¿Y qué pasa con los archivos que cree?
Pues en mi distribución el archivo de configuración está en /var/lib/transmission/.config/transmission-daemon/settings.json
Hay que cambiar el valor de "umask" y cambiarlo a 2.

Con esto ya está todo configurado.

Copia de seguridad de contactos y calendario de Owncloud

He cambiado todos mis calendarios y contactos a Owncloud. Pero están en un disco duro en mi casa. ¿Qué pasa si falla?
Ya tenía preparada una copia de seguridad automática de varios directorios, así que la voy a aprovechar para que me saque copia también de Owncloud.
Lo que necesitamos es una forma de descargar los contactos y calendarios automáticamente. Por suerte owncloud te proporciona un enlace para eso. Aprovechando este enlace, he generado este script:
$HOME/bin/backup_oc.sh :

#!/bin/sh
BACKUP_DIR=$HOME/store/liber/backup_oc/

wget --auth-no-challenge -O - http://localhost/index.php/apps/calendar/export.php?calid=1 | gzip > ${BACKUP_DIR}default_cal.ics.gz
wget --auth-no-challenge -O - http://localhost/index.php/apps/calendar/export.php?calid=2 | gzip > ${BACKUP_DIR}cumples_cal.ics.gz
wget --auth-no-challenge -O - http://localhost/index.php/apps/contacts/addressbook/local/2/export | gzip > ${BACKUP_DIR}contactos.vcf.gz

Hay que recordar darle permisos para ejecutarse:
chmod +x $HOME/bin/backup_oc.sh

Lo que estamos haciendo es descargar primero dos calendarios y luego los contactos. Conforme los descarga los comprime y los deja en una ruta en la que tenemos la copia automática.
Hasta aquí muy bien, pero... ¿y el usuario y contraseña?
No es muy buena idea ir dejándolos por ahí en scripts. Por suerte hay un sitio centralizado que usan varios programas, entre ellos wget.
$HOME/.netrc :
machine localhost login usuario password clave

No hay que olvidar, después de crear el archivo, cambiarle los permisos para que sólo el usuario propietario pueda leerlo y escribirlo. Aún así no es de lo más seguro, habría que ver otra forma de autenticarse.
chmod 600 $HOME/.netrc

Para terminar,  lo dejamos programado para que se haga automáticamente. Vamos a hacer una copia diaria a las doce de la noche.
Editamos el crontab del usuario con "crontab -e" y añadimos esta línea:
0 0 * * *  $HOME/bin/backup_oc.sh

Y ya está preparada la copia diaria de contactos y calendarios.
Hay dos mejoras obvias. Una de ellas es la seguridad en cuanto a las credenciales del usuario. La otra es un log y un aviso automático de cuando no se hace bien la copia.

Fuente: http://tanghus.net/2012/04/backup-owncloud-calendar-and-contacts/

Mejorando los scripts de acceso a contenido cifrado

Hace un par de días creé un área cifrada al estilo truecrypt.
Los scripts daban muchas cosas por sentado y era muy fácil que fallasen. He hecho algunos cambios para que resulten más flexibles y cómodos. Se sigue dando por hecho que el archivo está en una carpeta NFS, pero ahora es un poco más general y menos propenso a fallos.

Servirían para tener el número que queramos de archivos de este tipo. Se podría hacer que se le pasen parámetros por la línea de comandos, pero de momento se definen los valores en el directorio /etc/crypt
Por ejemplo, esto sería /etc/crypt/docs1
NFS_MOUNT=/media/wand/
CRYPTED_FILE=store/crypted
PLAIN_MOUNTPOINT=/home/liber/docs1

Para acceder al área cifrada, teclearíamos: mount_crypt docs1
el /usr/local/bin/mount_crypt quedaría así:
#!/bin/sh
source /etc/crypt/$1
CRYPTED_DEV_MAP=crypt_${1}
LOOP_DEV=`losetup -f`

mountpoint -q $NFS_MOUNT
if [ "$?" -ne "0" ]
then
    mount $NFS_MOUNT
fi

losetup $LOOP_DEV ${NFS_MOUNT}${CRYPTED_FILE}
cryptsetup open --type luks $LOOP_DEV $CRYPTED_DEV_MAP
mount /dev/mapper/${CRYPTED_DEV_MAP} ${PLAIN_MOUNTPOINT}


Y el umount_crypt, que también necesitaría el parámetro del nombre que queremos desmontar: umount_crypt docs1
/usr/local/bin/umount_crypt:
#!/bin/sh
CRYPT_MAP=crypt_${1}
LOOP_DEV=`cryptsetup status ${CRYPT_MAP} | grep device | cut -d':' -f2`
MOUNT_POINT=`grep ${CRYPT_MAP} /proc/mounts | cut -d' ' -f2`

umount $MOUNT_POINT
cryptsetup luksClose ${CRYPT_MAP}
losetup -d $LOOP_DEV

Acceder a un fichero sin copiarlo a través de ssh

Hoy me he encontrado con un problema en el trabajo y un compañero me ha dado una solución de lo más interesante.
Hay un servidor en el que hay un archivo comprimido que ocupa mucho espacio. Se trata de un export de una base de datos.
Tenemos que restaurar esa base de datos en otro servidor, pero no hay espacio para copiar el archivo. Además, la utilidad para restaurar la exportación de la base de datos sólo acepta el nombre de un archivo que debe estar sin comprimir y no hay ningún espacio compartido común con suficiente hueco para guardar el archivo. ¡ssh y pipes al rescate!

En el servidor destino:
mknod /tmp/tuberia p

En el origen:
cat fichero.Z | ssh usuario@srvdestino "zcat > /tmp/tuberia"

El comando se quedará esperando hasta que alguien lea en el otro lado.
Finalmente, en el destino:
imp file=/tmp/tuberia

leerá de la tubería /tmp/tuberia como si fuese un fichero local descomprimido.
Para finalizar borramos la tubería con nombre que hemos creado:
rm /tmp/tuberia

Documentos cifrados

Tengo un disco compartido con NFS en el que uno de los directorios tiene documentos personales. El ordenador en el que tengo este disco tiene algunos puertos abiertos en el router desde internet y no me fío demasiado de que alguien pudiera colarse. 
Sería interesante tener el directorio que contiene los ficheros personales cifrado.
Hay muchas opciones diferentes para proteger los datos, como cifrar una partición, un volumen lógico o un espacio en disco sin formato. En este caso quiero montar un sistema de ficheros en el interior de un fichero y  poder copiar el sistema entero a otro sitio sin tener que acceder a su contenido y que siga protegido. Además, no voy a montar el sistema de archivos desde el ordenador que lo contiene, sino por red.
El contenido sería vulnerable sólo cuando el archivo esté montado como un sistema de archivos, pero no se montará en el ordenador desde el que se tiene acceso por internet. Si robaran el archivo, no deberían poder acceder a su contenido.
Es lo mismo que si usáramos truecrypt, pero utilizando únicamente la funcionalidad que lleva GNU/Linux de serie.
Primero hay que crear el archivo, que en mi caso será de 200MB. 
Ojo: Cuando ejecutemos el luksFormat pedirá una contraseña. Es la que nos pedirá más adelante para poder abrir el archivo. Es importante no olvidarla o no podremos acceder a los datos.

head -c 200M /dev/zero > /nfs/luksfile # creamos el archivo contenedor
losetup /dev/loop0 /nfs/luksfile  # lo asignamos a un dispositivo loopback
cryptsetup luksFormat /dev/loop0 # lo inicializamos como dispositivo cifrado
cryptsetup luksOpen /dev/loop0 c1  # contenido plano a /dev/mapper/c1
mkfs.ext4 /dev/mapper/c1 # damos formato al dispositivo plano
mount /dev/mapper/c1 /media/cifrado # montamos el resultado

A partir de ahora solo hay que preocuparse de montarlo y desmontarlo cuando queramos acceder a él.

En mi caso me he creado dos scripts (muy mejorables) que he puesto en /usr/local/bin:

mount_crypt:

#!/bin/sh
losetup /dev/loop0 /nfs/luksfile
cryptsetup luksOpen /dev/loop0 c1
mount /dev/mapper/c1 /media/cifrado

umount_crypt:

#!/bin/sh
umount /media/cifrado
cryptsetup luksClose c1
losetup -d /dev/loop0 

Al ejecutar mount_crypt pedirá la clave para abrir el archivo.

Fuentes:
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions