Si necesitamos almacenar información sensible en nuestro sistema, a parte de tener en cuenta los procedimientos de borrado seguro, tenemos varias opciones:

• Cifrar una partición entera con LUKS (Truecrypt también lo permite): Como desventaja la configuración es más costosa y si hablamos de la partición principal del sistema, en el arranque el usuario ha de introducir la contraseña para que la máquina pueda iniciarse (no es útil para servidores). Por contra, tenerlo todo cifrado te garantiza que no dejas información por error en lugares no cifrados del disco.
• Crear un archivo que contendrá información cifrada (por ejemplo mediante Truecrypt): las desventajas es que el tamaño del fichero es fijo (se ocupan X GB aunque no haya información) y no se pueden realizar copias de seguridad incrementales, por contra Truecrypt tiene la ventaja de que es compatible con sistemas Linux y Windows (ideal para USB pendrives) y es muy fácil de usar gracias a su interfaz gráfica.
• Cifrar un directorio mediante EncFS: permite realizar copias de seguridad incrementales y no nos impone una ocupación en disco mayor que la necesaria

Veamos como podemos utilizar la tercera opción:

sudo apt-get install encfs
sudo adduser miusuario fuse
sudo chmod 660 /dev/fuse
sudo chown root:fuse /dev/fuse
sudo modprobe fuse

Al igual que sshfs, EncFS utiliza Fuse y por tanto cualquier usuario que pertenezca al grupo ‘fuse’ podrá crear y montar directorios cifrados:

mkdir ~/.private
mkdir ~/Private
encfs ~/.private ~/Private

La primera vez que ejecutamos ‘encfs’, deberemos escoger si queremos una configuración en modo experto o deseamos una de las configuraciones predefinidas: paranoica o estándar. La segunda será suficiente siempre y cuando establezcamos una contraseña robusta.

En el ejemplo, cabe destacar que EncFS guardará los archivos cifrados en ~/.private y los nombres de los ficheros también estarán cifrados (lo único que no se oculta es la cantidad de ficheros, información poco valiosa habitualmente). Para desmontar el directorio podemos ejecutar:

fusermount -u ~/Private

Si tenemos acceso a un servidor remoto con SSH, podemos acceder a los ficheros de la máquina mediante herramientas como gftp o WinSCP. Pero lo realmente útil es montar un directorio remoto en uno local, de forma que si por ejemplo tenemos un fichero de música/vídeo en el servidor, lo podremos reproducir sin necesidad de descargarlo completamente.

Para esto haremos uso de fuse (tecnología que permite a los usuarios de sistemas Linux montar dispositivos, es decir, no se requiere que sea ‘root’) y sshfs:

sudo apt-get install sshfs
sudo adduser miusuario fuse
sudo chmod 660 /dev/fuse 
sudo chown root:fuse /dev/fuse 
sudo modprobe fuse

Con estos comando hemos instalado sshfs, hemos añadido un usuario al grupo fuse (si corresponde a nuestro usuario actual, probablemente necesitaremos reiniciar la sesión para que tenga efecto), nos hemos asegurado que el dispositivo /dev/fuse tiene permisos de lectura/escritura para el grupo fuse y finalmente hemos añadido el módulo al kernel.

Para montar el directorio remoto por SSH/SFTP:

mkdir ~/Remoto/
sshfs -o ro,allow_other miusuario@servidor.com:/home/miusuario ~/Remoto -p 22

Con este comando hemos montado el directorio remoto ‘/home/miusuario’ en ‘~/Remoto’, conectando por el puerto 22 con el servicio de SSH. Además, hemos indicados en las opciones que el acceso sea de solo lectura (ro = read-only) y que otros usuarios puedan entrar en el directorio (allow_other), por supuesto estas opciones se pueden eliminar para que no deshabilitar su efecto.

Para desmontar el directorio podemos ejecutar:

fusermount -u ~/Remoto

Si no disponemos de una partición cifrada, es posible que nos interese borrar determinados ficheros confidenciales de forma segura, para ello utilizaremos ‘secure-delete’:

apt-get install secure-delete

Secure-delete nos proporciona 4 comandos de borrado:

• srm: Borrado seguro de ficheros (análogo del comando ‘rm’). Por ejemplo: ‘srm -ll fichero’
• sfill: Realiza un borrado el espacio libre del disco duro, generando un fichero que ocupe todo el espacio que actualmente se encuentra libre. Resulta de utilidad para asegurarnos que los archivos que hemos borrado en el pasado son completamente eliminados. Por ejemplo: ‘sfill -ll /’
• sswap: Borra de forma segura la información presente en la memoria swap.
• smem: Igual que al anterior, pero afecta a la memoria RAM.

Encuentro especialmente útiles los 2 primeros comandos acompañados del parámetro ‘-ll’, esto hará que el borrado se realice con un único pase de datos aleatorios. Ese nivel de borrado ya se considera bastante seguro, hay muy pocos lugares en el mundo donde se pueda recuperar información que haya sido sobreescrita con datos aleatorios en 1 única pasada.

Podemos hacer una prueba creando un fichero de prueba de 100 MB y realizando su posterior borrado seguro:

dd if=/dev/zero of=test.img bs=1M count=100
srm -v -ll test.img

En mi sistema el borrado ha tardado 40 segundos, imaginaros cuanto tardaría si no indicásemos la opción ‘-ll’ y se realizasen los 38 pases con los que viene por defecto 😉

Nos podría interesar mantener una conexión SSH permanente en dos equipos, por ejemplo para aprovechar las capacidades de creación de túneles cifrados entre diferentes equipos. Si utilizamos el comando ‘ssh’ habitual, en caso de que se caiga la conexión por cualquier motivo (p.ej. desconexión temporal de la línea) tendremos que volver a ejecutar el comando manualmente.

Para evitar esta problemática tenemos autossh, el cual se encargará de relanzar la conexión ‘ssh’ en caso de que deje de estar operativa:

AUTOSSH_DEBUG=1
AUTOSSH_GATETIME=0
AUTOSSH_PORT=1610
autossh usuario@servidor.com -L 1610:127.0.0.1:1610

Para el correcto funcionamiento, es recomendable el uso de conexiones SSH con claves RSA, de lo contrario al relanzar la conexión SSH se requerirá la intervención del usuario para introducir la contraseña (ver sección ‘Acceso remoto: SSH’ de Securización de un sistema Ubuntu (GNU/Linux)).

SSH nos permite crear túneles entre puertos TCP, por ejemplo:

ssh -L 2500:127.0.0.1:25 usuario@servidor.com

El comando anterior abrirá el puerto TCP 2500 en la máquina cliente, redirigiendo todo el tráfico mediante la conexión establecida con ‘servidor.com’ hacia ‘127.0.0.1’ (también podría ser otra IP de la red a la que tiene acceso ‘servidor.com’). También podemos hacerlo en sentido inverso:

ssh -R 2500:127.0.0.1:25 usuario@servidor.com

En este caso, se abrirá el puerto TCP 25000 en la máquina servidor, y se redirigirá el tráfico al puerto TCP 25 del cliente.

El problema aparece cuando queremos redirigir puertos UDP, para éstos tenemos 2 opciones: utilizar netcat o socat.
Continue reading Redirección de tráfico TCP/UDP mediante túneles SSH →

En caso de que necesitemos tener un entorno para ejecutar aplicaciones de otras versiones de nuestra actual Ubuntu o si necesitamos instalar herramientas de desarrollo sin “ensuciar” el sistema, podemos optar por soluciones complejas de virtualización o por debootstrap y chroot.

Con debootstrap crearemos un sistema base Ubuntu en un directorio de nuestro sistema de ficheros, primero tendremos que descargarnos la última versión del repositorio Ubuntu, por ejemplo:

wget http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~intrepid1_all.deb
sudo dpkg -i debootstrap_1.0.10ubuntu1~intrepid1_all.deb

Y a continuación preparamos el directorio:

sudo apt-get install debootstrap
sudo mkdir -p /var/chroot/intrepid/
sudo debootstrap --arch i386 intrepid  /var/chroot/intrepid/ http://archive.ubuntu.com/ubuntu/

En este ejemplo, en ‘/var/chroot/intrepid/’ tendremos instalado una Ubuntu mínima en su versión 8.10 (Intrepid Ibex). Para trabajar dentro de ella, con el usuario root podemos hacer un chroot:

xhost +localhost
sudo mount -o /dev /var/chroot/intrepid/dev/
sudo mount -o /proc /var/chroot/intrepid/proc/
sudo chroot /var/chroot/intrepid/ /bin/bash

La primera línea únicamente es necesaria si estamos en las X.org y vamos a ejecutar algún programa gráfico dentro del chroot. Los mount’s hacen que los directorios especiales /dev y /proc se encuentren duplicados dentro del chroot. Finalmente, el comando chroot cambia nuestra raiz y partir de ese instante en esa terminal la raiz del sistema ‘/’, corresponderá realmente a ‘/var/chroot/intrepid/’.

En consecuencia, ahora podremos cambiar ‘/etc/apt/sources.list’, actualizar el listado de aplicaciones con ‘apt-get update’ e instalar aquello que necesitemos sin realizar ningún cambio sobre el sistema real (todos los cambios solo tienen efecto dentro de ‘/var/chroot/intrepid/’).

Por otra parte, si necesitamos que los usuarios puedan hacer chroot podemos utilizar schroot: schroot – chroot for any users. Más trucos en el wiki de Ubuntu.

Recientemente he hecho una migración a Ubuntu 8.10 de un servidor con máquinas virtualizadas mediante la tecnología Xen, sin saber que esta última versión de ubuntu no dispone de un kernel preparado como contenedor Xen. Por lo visto Ubuntu se ha decantado definitivamente por KVM, con el inconveniente de que para poder utilizar esa tecnología necesitamos disponer de un procesador con extensiones de virtualización (mi equipo no dispone).

Después de realizar la actualización, intenté hacer un downgrade (desactualización) sin éxito y después de bastantes horas acabé reinstalando el sistema. De este incidente saco varias conclusiones:

• No realizar actualizaciones sin antes asegurarte de que no existen incompatibilidades. En mi caso, aunque hice una búsqueda rápida no encontré ninguna referencia donde explicasen claramente que a partir de la 8.10 el soporte Xen había sido discontinuado completamente.
• Disponer de un entorno de pre-producción para probar todo tipo de actualizaciones. Obviamente, en mi caso es irrelevante porque no hay ningún impacto si me quedo sin servidor unos días o semanas. En una organización el impacto podría haber sido desastroso en términos económicos, reputación, etc.
• Las copias de seguridad me han permitido reinstalar el sistema en un tiempo récord. En mi caso ha sido suficiente con guardar todos los directorios con configuraciones, datos dinámicos (BBDD, webs, ficheros de cacti/nagios/etc.) y los paquetes instalados en el sistema (dpkg –get-selections).
• Si bien hay que considerar los posibles problemas de seguridad derivados de la virtualización, las máquinas (que habitualmente estan contenidas en unos pocos ficheros) son extremadamente fáciles de copiar y por tanto, de restaurar intactas.
• Valora los proveedores que ofrece acceso al servidor por KVM (Keyboard Video Mouse), perfecto cuando el sistema no arranca y necesitas acceder a la máquina como si estuvieses delante.

Últimamente he escrito varios posts sobre estándares y aspectos más estratégicos de negocio e IT, como por ejemplo:

• BS 25999-1: Gestión de la Continuidad del Negocio
• Cobit, estándar para el buen gobierno de los Sistemas de Información
• ITIL y ISO 20000, marcos de trabajo para servicios IT
• Metodologías de desarrollo
• Estructurar las organizaciones en procesos
• PMBOK, Project Management / Gestión de proyectos
• PRINCE2 como complemento a PMBOK para la gestión de proyectos (project management)
• Metodologías ágiles de gestión de proyectos (Scrum, DSDM, Extreme Programming – XP…)
• Scrum, gestión ágil de proyectos / agile project management
• Getting Things Done (GTD), organízate con eficacia de David Allen

Es habitual escuchar críticas a este tipo de enfoque más estratégico, aludiendo al hecho de que se habla y teoriza mucho pero no se concreta nada. En este nuevo artículo, en el que ha colaborado Raúl Gómez (experto en seguridad técnica), se plasman de forma técnica muchas de las ideas de buena gestión estratégica IT o de negocio.

Vamos a ver cómo podemos montar un servidor con Ubuntu Linux que cumpla mínimamente con las buenas prácticas de seguridad:

• Efectuar una configuración segura
• Establecer una política de contraseñas
• Utilizar herramientas para la gestión de usuarios
• Proteger los servicios de red
• Garantizar la trazabilidad
• Proporcionar herramientas de monitorización en tiempo real e histórica para facilitar proyecciones de futuras necesidades
• Establecer política de copias de seguridad
• Efectuar tests de stress del sistema

Y es que en definitiva el software libre, por más libre y abierto que sea, no tiene porque ser seguro a no ser que se establezca una configuración adecuada y alineada con las políticas/normativas/procedimientos de la organización.
Continue reading Securización de un sistema Ubuntu (GNU/Linux) →