Acceder a un servidor SSH/SFTP como si fuese un directorio local (sshfs)

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

Borrado seguro de ficheros en Ubuntu GNU/Linux

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 😉

Mantener sesiones/conexiones SSH abiertas con autossh

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)).

Redirección de tráfico TCP/UDP mediante túneles SSH

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

Entornos aislados en Ubuntu GNU/Linux con debootstrap y chroot

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.

Ubuntu 8.10 (Intrepid Ibex) no soporta Xen

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.

Securización de un sistema Ubuntu (GNU/Linux)

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

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)

Servidor Ubuntu con soporte de virtualización Xen

Veamos como podemos configurar un servidor Ubuntu como plataforma de virtualización mediante el uso de Xen. En primer lugar debemos instalar un kernel con soporte Xen:

apt-get install ubuntu-xen-server
mkdir /home/xen/

Nos aseguramos que las opciones de configuración de grub sean correctas en ‘/boot/grub/menu.lst’ y que el kernel con soporte Xen es el que arranca por defecto. A continuación reiniciamos:

reboot

En el siguiente inicio del sistema podemos comprobar que Xen esta corriendo si se ejecuta correctamente el siguiente comando:
Continue reading Servidor Ubuntu con soporte de virtualización Xen

Máquina virtual Xen con servicio web Apache / Windows Vista, problema de conexión lenta

Tengo montado un servidor con soporte Xen, donde he virtualizado un servidor web con Apache. Desde hace un par de días me he dado cuenta que cuando intento acceder a la web usando como cliente Windows (indistintamente del navegador), la conexión era terriblemente lenta, mientras que desde un GNU/Linux la web me cargaba sin problemas.

Llevo casi 2 días obsesionado por ver que era lo que ocurría, el esquema virtualizado es el siguiente:

Internet < ==> | [Host real] ----> redirige puerto 80 ---> [Guest virtualizado] |

En la configuración del servidor securicé el sistema cambiando parámetros del kernel (p.ej. Syn cookies), realizando hardening de Apache, configurando el firewall con iptables, estableciendo QoS, etc… Me he pasado horas cambiando toda esa configuración para determinar el origen del problema.
Continue reading Máquina virtual Xen con servicio web Apache / Windows Vista, problema de conexión lenta