Google authenticator como 2FA en Debian

El año pasado probé Google Authenticator como 2FA en una CentOS. Hoy he usado la información de esa entrada para configurar, ¡por fin!, un 2FA para el acceso por SSH a mi almacenamiento personal.

Como la distro es Debian, hay un pequeño cambio: el paquete que debemos tener instalado:

apt-get install libpam0g-dev

Debemos tener instalado tanto gcc como make para poder compilar la librería de google.

Un detalle más es que, al contrario de lo que comenté en mi anterior entrada, para configurar mi Android he preferido usar la secret key que obtenemos al ejecutar Google Authenticator para el usuario que queremos proteger.

¡Espero que os sea útil!


ownCloud y Raspberry PI

Tras un aviso de Dropbox para que reduzca los muchísimos GB que me sobran al haber “caducado la oferta” por pertenecer a la UA, he decidio crearme mi “ownCloud” con un disco duro de 1TB que tenía y una Raspberry PI.

Sobre como instalarlo hay muchas entradas en la red (I, II, III, IV,  …) así que poco más que añadir o comentar, salvo:

Leer más


Más sobre fortificación de SSH

En cuanto ponemos un servicio SSH accesible desde cualquier parte de Internet, los ataques de fuerza bruta y demás se suceden casi al instante (es una licencia, evidentemente, hay un tiempo de “descubrimiento”). Nos llegan desde todo el globo terráqueo por lo que, hablando de protección y suponiendo que nunca accederá un usuario desde determinados continentes o países, aplicar la Geolocalización IP para deshabilitar conexiones se convierte en una opción muy interesante. Aún reconociendo la importancia de realizar buenos filtros y de implementar mecanismos de autenticación multifactor, en esta entrada nos vamos a centrar solo en las opciones de SSH básicas para su protección. He tomado como base, la clase que impartía en Administración de Servicios de Internet dedicada a SSH y su fortalecimiento.

Las opciones con las que vamos a intentar mejorar y adaptar la configuración de nuestro servicio a nuestra política de seguridad y a nuestras necesidades, las encontraremos en el fichero /etc/ssh/sshd_config.

Empecemos….

Leer más


Sistema de archivo remoto accesible mediante SSH

Si queremos compartir o acceder a un directorio de un equipo al que ya accedemos mediante SSH, una buena opción es usar el mismo servicio (ssh) para conseguir este objetivo. Para ello necesitamos:

  • Que el núcleo incluya FUSE. Si no lo está: basta con instalar fuse-source e instalarlo con module-assistant.
  • Que el usuario local pertenezca al grupo fuse.
  • Instalar sshfs: apt-get install sshfs.
  • Tener correctamente configurado el servidor SSH en el equipo en el que queremos montar el directorio.

Hecho lo anterior ya podemos montar cualquier directorio y utilizarlo en nuestro equipo como si fuera un directorio local. La orden debería seguir el patrón:

sshfs [email protected]_del_sevidor:<directorio a exportar> <directorio local>

  • usuario será el del servidor al que tenemos que acceder,
  • ip del servidor en el que se encuentra el directorio a exportar,
  • y directorio local será el punto de montaje a partir del cual estarán disponibles los ficheros del directorio exportado del servidor desde el punto de vista del “cliente”

Si queremos que esté disponible en el arranque, tenemos que configurar el montaje en el fichero /etc/fstab. Para ello, debemos añadir una línea al fichero /etc/fstab que siga la siguiente sintaxis:

sshfs#[email protected]:<directorio a exportar>   <directorio local>   fuse   defaults 0 0

  • donde, al igual que con la orden dada anteriormente, tenemos que indicar el usuario del servidor con el que debemos conectarnos para acceder al directorio, el directorio y el punto local de montaje.
  • Aquí debemos indicar también el tipo de sistema de archivo (fuse). Como opciones de montaje podemos dejar las “defaults” o utilizar cualquier otra de las que disponemos (ro, rw, nosuid, async, noexec, noauto, …).
  • El penúltimo campo (dump) indica si se quiere o no realizar un volcado de los errores (0 ó 1) .
  • El último indica si no queremos (0) realizar un chequeo del sistema de archivos o y, en este caso, 1, 2, marcará el orden en el serán comprobados*. En nuestro caso, creo que es mejor usar la opción 0 y no chequear (ya lo haremos, en todo caso, en el propio servidor donde se encuentra el directorio).

Una vez introducida la línea en /etc/fstab, para probarla sin necesidad de reiniciar, podemos ejecutar mount -a.

Debemos tener en cuenta que si queremos montar automáticamente en el arranque, lo más lógico es autenticar mediante clave pública** para que se monte correctamente en el inicio del equipo y que no tenga que pedirnos la contraseña, además de guardar la clave pública del servidor en el fichero known_hosts de ssh para que no solicite confirmación.

Para desmontar/desasociar el directorio, debemos ejecutar la orden

 fusermount -u directorio_local

¡Ojo! Este mecanismo NO te cifra el directorio. Te da privacidad en la comunicación estableciendo una conexión cifrada. ¡Y tampoco lo puedes usar con Dropbox!

Todas las técnicas de protección que usemos para el servidor SSH, influirán positivamente en la seguridad de nuestro “servicio de disco”, pero esto, lo dejamos para otro día.

Referencias:

  1. Hardening de servidores GNU/Linux, de Carlos Álvarez Martín y Pablo González Pérez
  2. Administración de sistemas operativos Windows y Linux. Un enfoque práctico, de Juan Antonio Gil, Julio Gómez y Nicolás Padilla.

* Normalmente se utiliza 1 para el sistema de archivos raíz, 2 para el resto. La comprobación, por defecto, se realiza cada 29 desmontajes y se puede modificar por sistema de archivo (ver la orden tune2fs).

** Debemos copiar la clave pública de los usuarios al servidor (la podemos generar mediante la orden ssh-keygen) en la ruta que esté indicada por la directiva AuthorizedKeysFile del fichero /etc/ssh/sshd_config Por defecto, indica que está en el directorio HOME del usuario ($HOME/.ssh/authorized_keys) Es importante para la automatización, que NO activemos un PIN a la clave privada.


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.