linux

Aquí van algunos consejos para proteger el acceso remoto a un servidor linux, corriendo Secure Shell (SSH).

CONFIGURAR CORRECTAMENTE EL SERVIDOR SSH

• NOTA: el archivo de configuración, al menos en Debian, se encuentra situado en /etc/ssh/sshd_config
• Protocol 2
  La versión 1 del protocolo tiene algunas vulnerabilidades conocidas, así que quitamos su soporte, obligando a acceder utilizando únicamente la versión 2 del protocolo.
• ListenAddress ip
  Comprueba que el servidor escuche únicamente la interfaz de red que quieras realmente (puede que sólo te interese acceder a tu pequeño servidor casero desde tu propia red local, y tengas activado por defecto la escucha en todas las IPs, incluida la pública).
• PermitRootLogin No
  Es indispensable que el usuario root no pueda acceder via SSH. Siempre podremos escalar privilegios, una vez hayamos accedido al servidor, a través de su o sudo, pero es importante que el usuario root no pueda acceder directamente desde el servidor SSH.
• Listen num-puerto
  Cambiando el puerto de escucha por defecto pondremos otra piedra en el camino de aquellos que pretendan entrar remotamente en nuestro sistema. Hay formas de deducir qué programa está escuchando un puerto, pero al menos se lo pondremos un poquito más dificil a aquellos que hacen uso de scripts automatizados.
• PermitEmptyPasswords No
  Ya que estamos intentando aumentar la seguridad de acceso a nuestro sistema, parece lógico prohibir las contraseñas vacías, ¿no? :-)
• AllowUsers usuario1 usuario2 ...
  Si como yo, administras una pequeña red local, probablemente solo quieras dar acceso SSH a uno o dos usuarios, así que ¿por qué no limitar el acceso al servidor solamente a esos usuarios?
• AllowGroups grupo1 grupo2 ...
  Si por el contrario hay más usuarios que acceden via SSH, tal vez sería interesante filtrar el acceso al servidor SSH, permitiendo solamente aquellos usuarios que pertenezcan a un determinado grupo.
• PasswordAuthentication Yes
  Mediante esta directiva configuramos si permitimos la autenticación mediante clave al servidor SSH. El acceso tradicional al servidor se realiza mediante usuario y clave, aunque si prohibimos este acceso mediante usuario/clave (PasswordAuthentication No), aumentaremos la seguridad, dejando el acceso solamente a través de pares de claves públicas y privadas (si has usado alguna vez un programa de cifrado tipo GPG o similar ya sabrás a qué me refiero).
• Hay otras directivas que incrementan la seguridad, como LoginGraceTime, MaxAuthTries, MaxStartups y algunas otras, aunque considero que estas de aquí arriba son las más importantes. Como siempre un simple man sshd_config te te permitirá profundizar más en las directivas de configuración.

AUTENTICACION SSH BASADA EN PARES DE CLAVES

• Para deshabilitar el acceso con usuario/clave, y habilitar el acceso con pares de claves, necesitaremos comprobar que el servidor SSH (recuerda: /etc/ssh/sshd_config) está configurado correctamente:

# Desactivamos la autenticación via usuario/clave:
PasswordAuthentication No
# Activamos la autenticación con pares de claves:
PubkeyAuthentication yes
# Definimos el archivo donde irán las claves de acceso autorizadas.
# Como mi partición home está cifrada, defino que las claves se almacenen,
# de manera centralizada, dentro de /etc/ssh. Hay más información al respecto
# (importante el tema de los permisos en las carpetas) en la siguiente URL:
# https://help.ubuntu.com/community/SSH/OpenSSH/Keys
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
# Activamos la atenticación RSA
RSAAuthentication yes

• Una vez configurada la parte del servidor correctamente, lo que haremos será crear, en nuestra máquina cliente (desde la que accedemos al servidor) una clave pública que copiaremos luego al servidor. El par de claves (pública y privada) las podremos generar mediante el comando ssh-keygen -t rsa (si estamos bajo GNU/Linux), o usando el programa puttygen.exe del cliente PuTTY (si estamos en un entorno MS Windows). Para este ejemplo, suponemos que hemos llamado a la clave pública ssh-publico.key y a la clave privada ssh-privada.key.ppk.
• Para subir la clave pública a nuestro servidor SSH, haremos uso de la utilidad scp (pscp si usamos PuTTY):

scp ssh-publico-key usuario@nuestroservidor:/etc/ssh/usuario

• Reiniciamos el servidor sshd y voilà, ya podemos acceder usando el par de claves RSA.

Teneis más información sobre este último tema en los siguiente enlaces:

• SSH access via PuTTY. Public/private key pair authentication
• Ubuntu : SSH/OpenSSH/Keys
• Password-less logins with OpenSSH

Hoy me he encontrado con que he tenido que montar una partición Truecrypt bajo Linux, usando la línea de comandos. Vago que es uno :-) me apunto aquí la chuletilla, para futuras referencias y por si a alguien le puede ser de utilidad.

El comando quedaría algo así:

truecrypt --filesystem='ntfs-3g'  --mount /dev/sdb2 /mnt/truecrypt  --fs-options='uid=1000,gid=1001,umask=0002'

Obviamente, es necesario tener instalado el soporte NTFS en linux, mediante el paquete ntfs-3g, así como el propio Truecrypt. Las opciones de --mount son autoexplicativas: primero la partición y luego la ruta destino para el montaje. Como parámetros a ntfs-3g (fs-options), le ordenamos que monte la partición como el usuario con id 1000 y grupo con id 1001, con unos permisos (umask) de 0002 que pondrá los archivos con los permisos 664 y los directorios con 775.

Para algo más de información, podeis ojear estas páginas que he encontrado en la red:

• Wiki de Archlinux
• LinuxQuestions.org - Mounted Truecrypt files let me just view them, and do nothing else

Ayer fue un día de esos en los que te das cuenta de que lo que empezó siendo la simbiosis entre un proyecto de sustitución de Minix por parte de un estudiante (Linus Torvals) de la Universidad de Helsinki, y el proyecto GNU iniciado por Richard Stallman, ha ido poco a poco copando nichos de mercado, hasta poderlo encontrar en las tripas de mucha de la cacharrería electrónica que invade nuestro mundo.

Digo que fue ayer porque, al descargarme por la mañana el manual de la tele LG 32LF pude leer un "Aviso de software de código abierto", advirtiendo que la tele incluye un kernel 2.6, busybox, lzo, uClibc y Nanox (The Nano X-Window System).

Algo más tarde me fuí al IKEA y al pagar en una de esas cajas rápidas se bloqueó el lector de tarjetas de crédito, por lo que tuvieron que resetear mi TPV. Al reiniciarlo, pude ver las familiares líneas de arranque de un sistema GNU/Linux (solo me faltó andar listo y hacerle una foto con el móvil).

Tal vez este año tampoco sea el año de Linux en sistemas de escritorio, pero parece que avanza a buen ritmo en otro tipo de entornos...

Desde que me pillé el Dell Mini 10v he estado intentando encontrar un rato para cifrar la partición /home, no vaya a ser que me lo tomen prestado un día y mi información personal acabe en malas manos.

He estado investigando un poco y parece que lo que se lleva es hacerlo con LUKS y dm-crypt. En este artículo se explica la manera de hacerlo:

Partición cifrada con dm-crypt en Debian.

Al parecer, según se puede leer en la página de la Wikipedia referente a LUKS, LUKS pretende convertirse en un formato estándar de cifrado, independiente de la plataforma. Para acceder a particiones LUKS bajo Windows, por ahora nos tendremos que conformar con FreeOTFE.

LUKS (de las siglas en inglés, Linux Unified Key Setup) es una especificación de cifrado de disco creado por Clemens Fruhwirth, originalmente destinado para Linux. Mientras la mayoría del software de cifrado de discos implementan diferentes e incompatibles formatos no documentados, LUKS especifica un formato estándar en disco, independiente de plataforma, para usar en varias herramientas. Esto no sólo facilita la compatibilidad y la interoperabilidad entre los diferentes programas, sino que también garantiza que todas ellas implementen gestión de contraseñas en un lugar seguro y de manera documentada.

La implementación de referencia funciona en Linux y se basa en una versión mejorada de cryptsetup, utilizando dm-crypt como la interfaz de cifrado de disco. En Microsoft Windows, los discos cifrados con LUKS pueden ser utilizados con FreeOTFE. Ha sido diseñado para ajustarse a la clave de configuración TKS1 de sistema seguro.

Esta mañana al compilar un nuevo kernel para el servidor de la oficina algo ha ido mal. Al reiniciar la máquina, he visto fugazmente un mensaje de error que rápidamente ha desaparecido de la pantalla. Tras esperar algunos segundos y realizar el login, no he podido encontrar el mensaje de error ni en /var/log/syslog, ni ejecutando dmesg, ni retrocediendo con shift+pgup o parando el torrente de información con ctrl+s o la tecla ScrollLock.

Y es que a veces el error aparece tan temprano en el arranque no que se hace dificiil verlo. Para poder ver los mensajes de arranque en Debian de una forma fácil, tenemos que activar bootlogd, simplemente editando el archivo /etc/default/bootlogd y
habilitarlo. Bootlogd creará en el siguiente inicio de la máquina el archivo /var/log/boot. Por último, señalar que esta característica no está disponible para Debian Woody o anteriores.

Un truquillo realmente útil para depurar kernels creados por nosotros o ver los mensajes de error de los scripts de arranque.