SecNot

1. Cambiar el puerto por defecto

Por defecto ssh escucha el puerto 22, de manera que es fácil para cualquier atacante escanear el puerto para determinar si ssh se está ejecutando. Cambiando el puerto se soluciona parcialmente el problema, los escaneos automáticos no encontrarán el puerto, en cambio un atacante interesado específicamente en tu servidor, puede escaneará todos los puertos hasta encontrar ssh.

Aun así este cambio es muy sencillo, nos protege de ataques automáticos, e hipotéticos exploits remotos que puedan aparecer algún día.

Para modificar el puerto sólo es necesario editar /etc/ssh/sshd_config añadiendo o modificando la linea:

# Nuevo puerto ssh
Port 7544

y reiniciar el servicio sshd

secnot@servidor:~$ sudo service sshd restart

para conectar ahora hay que usar

secnot@cliente:~$ ssh servidor -p 7544

2. Desactivar login al root

Acceder como root a cualquier sistema es una mala practica, especialmente en logins remotos, siempre es preferible tener un usuario con permisos sudo para ejecutar comandos como root. Si este es tu caso, es recomendable prohibir el acceso por ssh al usuario root.

El primer paso es asegurarnos que tenemos al menos un usuario con permisos para usar sudo, si no es así nos quedaríamos sin acceso como root al servidor.

secnot@servidor:~$ whoami
secnot
secnot@servidor:~$ sudo whoami
[sudo] password for secnot:
root

Si da algun problema al ejecutar sudo no continuar con este paso. Para modificar la configuracion editamos /etc/ssh/sshd_config:

# Desactivar login para root
PermitRootLogin no

y reiniciamos el servicio

secnot@servidor:~$ sudo service sshd restart

3. Desactivar protocolo 1

SSH puede usar dos protocolos 1 y 2, el protocolo 1 es el más antiguo y fue remplazado por el 2, cuando se descubrieron ciertas vulnerabilidades, pero algunas distribuciones de unix/linux, aún continúan permitiendo usar ambos para mantener compatibilidad hacia atrás. Es recomendable desactivar el protocolo 1, para ello editamos /etc/ssh/sshd_config:

# Protocol 2,1
Protocol 2

y reiniciamos el servicio

4. Usar autenticación de clave Publica

Tiene dos ventajas, la primera es que es posible hacer login sin introducir la clave, y la segunda, es que podremos desactivar completamente el login con claves, haciendo imposibles los ataques por fuerza bruta o diccionario. El primer paso es generar un par del claves publica/privada en el cliente:

secnot@cliente:~$ ssh-keygen -b 4096 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/secnot/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/secnot/.ssh/id_rsa.
Your public key has been saved in /home/secnot/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:dd:b9:33:73:fb:f1:6e:3e:ce:d7 secnot@client
The keys randomart image is:
+--[ RSA 4096]----+
|     ..          |
|      .. .  .    |
|      .oo o. o   |
|     .+o.=. . .  |
|     ..oSo   .   |
|       ooo. .    |
|        E..  .   |
|         . .  .. |
|            ..o. |
+-----------------+

Primero pregunta en que directorio deseas guardar el par de claves, a no ser que tengas otro par y no quieras confusiones, usa el directorio por defecto.

En el segundo paso te pide un passphrase (una clave para proteger el par de claves), si no se la proporcionas cualquiera que consiga acceso al par de claves, tendrá acceso automático al servidor, a cambio no tendrás que introducir una clave cuando hagas login. En cambio si proporcionas un passphrase si que tendrás que introducir una clave para hacer login, pero si el par de claves es robado, no podrán usarlo para acceder al servidor. Tu decisión

Por último queda subir las claves al servidor, para ello hay que añadir el contenido de la clave pública id_rsa.pub al archivo ~/.ssh/authorized_keys de tu usuario en el servidor. Para facilitar la tarea existe la utilidad ssh-copy-id:

secnot@cliente:~$ ssh-copy-id -i .ssh/id_rsa.pub secnot@servidor
secnot@servidor's password:
Now try logging into the machine, with "ssh 'secnot@servidor'", and check in:

~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Si ssh-copy-id no está disponible en tu sistema, puedes hacerlo manualmente, si no existe creamos el directorio .ssh en el servidor

secnot@servidor:~$ mkdir .ssh
secnot@servidor:~$ chmod 700 .ssh

copiamos el archivo de clave publica .ssh/id_rsa.pub al servidor:

secnot@cliente:~$ scp ~/.ssh/id_rsa.pub secnot@servidor:./

añadimos id_rsa.pub a ~/.ssh/authorized_keys, y nos aseguramos que los permisos del archivo sean los correctos

secnot@servidor:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
secnot@servidor:~$ chmod 600 ~/.ssh/authorized_keys
secnot@servidor:~$ rm id_rsa.pub

Una vez tengas comprobado que todo funciona correctamente, y que puedes hacer login usando ssh, ya sea sin clave o con tu passphrase, puedes dar el ultimo paso, desactivar la autenticación por clave, modificando el archivo /etc/ssh/sshd_config

# Desactivar logins usando claves
PasswordAuthentication no

Por ultimo, asegúrate de guardar una copia de el par de claves id_rsa e id_rsa.pub, si las pierdes no podrás acceder al servidor remotamente.

Seguridad SSH parte II