Debido a esto, algunas claves de encriptación usadas en OpenSSH, OpenVPN o certificados SSL podrían ser mucha más comunes de lo que deberían ser y alguien podría averiguarlas mediante un ataque de fuerza bruta. De poco sirve blindar OpenSSH con bugs así…

Al margen del debate surgido acerca de si el fallo está o no solucionado, nos centraremos en la solución más inmediata para OpenSSH que pasa por averiguar si nuestras claves actuales están comprometidos y como regenerarlas en ese caso.

Las versiones de Debian afectadas por el fallo son etch, lenny y sid, en Ubuntu lo están la 7.04, 7.10 y 8.04, así que tenéis alguna de ellas instalada, actualizad como primera medida para disponer de la versión corregida de OpenSSL:

$ sudo aptitude update && sudo aptitude upgrade

Podemos averiguar si alguna de las claves de nuestro sistema está comprometida con una nueva herramienta incluida en la actualización:

$ sudo ssh-vulnkey -a

Si alguna de ellas figura como “COMPROMISED” procederemos a regenerarlas para nuestro usuario:

$ ssh-keygen

Y, en caso de necesitarlo, para el servidor OpenSSH:

$ sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
$ sudo dpkg-reconfigure -plow openssh-server

Con esto debería valer por el momento. Si os va el tema, podéis ver como en Slashdot se pone verde a algunos desarrolladores

Más información: Debian – Ubuntu

En este mini-tutorial vamos a ver como blindar un servidor OpenSSH, usado frecuentemente en sistemas Unix, para protegernos de los ataques más comunes.

Cambiar el puerto por defecto

SSH usa por defecto el puerto 22, esto es algo que todos los posibles juankers y script kiddies que traten de hacerse con el control de tu servidor saben, por lo que es una buena idea cambiarlo.

Para modificar esta opción y las siguientes editaremos el fichero de configuración shd_config, que por defecto se encuentra en el directorio /etc/ssh/. Utilizad vuestro editor de texto favorito, aquí usaré nano:

sudo nano /etc/ssh/sshd_config

Tenemos que usar un puerto cualquiera por encima del 1024, así que escoged el que queráis. En este ejemplo usaré el 3729, así que la opción Port del fichero de configuración quedaría así:

Port 3729

Apuntadlo para abrirlo en el router y poder especificarlo en el cliente al conectaros con la opción -p.

Desactivar el Protocolo 1

La primera versión del protocolo SSH tiene varias vulnerabilidades conocidas y por tanto no hay razón para permitir su uso.

Buscamos la opción Protocol y nos aseguramos de que quede así:

Protocol 2

De esta forma sólo aceptaremos conexiones que usen la segunda versión del protocolo SSH.

Deshabilitar el acceso del superusuario (root)

No es muy recomendable permitir el acceso remoto directo al usuario root, por lo que lo desactivaremos:

PermitRootLogin no

Una vez logueados con otro usuario podremos cambiar a root usando su.

Definir un número máximo de intentos de conexión

Muchos de los ataques llevados a cabo por los malvados script kiddies se basan en fuerza bruta, estableciendo un número máximo de intentos de conexión lograremos disuadirles o, al menos, retrasar su “sofisticado” intento de hacking:

MaxAuthTries 2

El número de intentos de logueo fallidos antes de desconectar ya depende de la torpeza o mala memoria de los usuarios legítimos del sistema .

Restringir el acceso a determinados usuarios

Si un usuario de nuestro sistema no necesita acceder de forma remota al mismo, no hay razón para permitírselo. Para hacerlo modificaremos la siguiente opción:

AllowUsers yo

De esta forma el usuario “yo” sería el único que puede hacer login remoto de forma directa a nuestro sistema.

Activar el modo estricto

La opción StrictModes debe activarse para que, por ejemplo, los usuarios despistados que establecen permisos de escritura para todo el mundo en sus archivos y directorios no se lleven una desagradable sorpresa cuando otro usuario los modifique .

StrictModes yes

Impedir la conexión al servidor gráfico

Si nuestro servidor no tienen entorno gráfico instalado, o no queremos que los usuarios se conecten a él, definiremos esta opción en el fichero de configuración:

X11Forwarding no

Desactivar todo autenticación basada en .rhosts

La autenticación basada en ficheros .rhosts está obsoleta y es insegura, así que la desactivaremos:

IgnoreRhosts yes
HostbasedAuthentication no
RhostsAuthentication no
RhostsRSAAuthentication no

Ahora guardamos los cambios realizados en el fichero de configuración y reiniciamos el servidor para que sean efectivos:

sudo /etc/init.d/ssh restart

Una vez seguidos todos estos pasos tendremos funcionando un servidor OpenSSH medianamente seguro al que podremos conectarnos usando el comando ssh y especificando el puerto destino de la siguiente forma:

ssh -p 3729

Donde 3729 es el puerto usado en este ejemplo.

Si queréis más información sobre las diferentes opciones de configuración del servidor OpenSSH, podéis consultad las páginas del manual en internet o ejecutar:

man sshd_config

Para terminar, una frase de Gene Spafford sobre seguridad:

El único sistema seguro es aquél que está apagado en el interior de un bloque de hormigón protegido en una habitación sellada rodeada por guardias armados.