Proteger el acceso por ssh

SSH (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red.

Permite manejar por la computadora mediante un el intérprete de comandos instalado en la misma (bash, ksh, etc..), y también puede redirigir el tráfico de X-Windows para poder ejecutar programas gráficos si tenemos un Servidor X arrancado en nuestra máquina local.

Asegurando SSH:

Aunque SSH en sí es un protocolo seguro, podemos afinar los parámetros de configuración para hacer que su utilización resulte todavía más segura.

Pasos que seguiremos:

• Deshabilitar SSH 1.
• Autenticación basada en llave RSA.
• No permitir autenticación mediante login/password.
• No Permitir acceso como root sin llave.
• Cambiar el puerto por Defecto.
• Banear IPs tras 5 logins erróneos.

Deshabilitar SSH 1:

Puesto que en la versión del protocolo ssh 1 hay algunas inseguridades, es mejor usar sólamente el protocolo 2, aunque en Debian ya viene así por defecto, para otras distros editaremos el fichero de configuración /etc/ssh/sshd_config y cambiaremos la opción:

# /etc/ssh/sshd_config
Protocol 2

Nota: Al efectuar cualquier cambio en la configuración de SSH, debemos reiniciar el servicio para que sea efectivo en los siguientes accesos. La sesión a través de la que estamos conectados no se verá afectada. Por ejempo en Debian ejecutaríamos /etc/init.d/sshd restart.

# /etc/init.d/sshd restart

Autenticación mediante llave RSA:

Entrar con usuario y password está muy bien, pero nuestro servidor será pasto de los niñatos-scriptadores y de los lamers (el día que tenga tiempo me voy a dedicar a cascarles un HoneyPot y a denunciarlos a la Guardia Civil) provistos de diccionarios de claves. En unos días observaremos como hay continuos intentos de autenticación desde las mismas IPs, con vanos resultados si nuestra clave es medianamente complicada, pero... ¿Por qué arriesgarse?

Creando nuestra llave RSA:

Esto lo haremos en nuestra própia máquina, portátil o desktop, no en el servidor que estamos fortificando.

# ssh-keygen -t rsa

Este programa lo que hace es generar un par de claves rsa, con una parte pública, que es la que pondremos en los servidores y la que podemos pasar a cualquiera sin problemas, por ejemplo a otro administrador para que la ponga en un servidor de un cliente y poder acceder nosotros también, y una privada, que deberemos conservar en secreto, en nuestro ordenador y con al menos una copia de seguridad a buen recaudo.

Al ejecutar el comando anterior nos pedirá una "passphrase" o "frase de paso", es decir, una clave. La podemos dejar en blanco si queremos, si nadie accede a nuestra llave privada RSA, el método es seguro, no hace falta una passphrase que puede ser un poco incordio, pero si queremos una mayor seguridad, podemos asignarla, de esta forma el cliente SSH nos pedirá la passphrase cada vez que necesite utilizar la llave, y aunque alguien se haga con nuestra llave, no se servirá de mucho sin ella.

Colocando nuestra llave en el servidor:

Nuestra llave se guarda en el directorio .ssh de nuestra carpeta personal o home, concretamente nuestra llave pública está en ~/.ssh/id_rsa.pub,y queremos ponerla en el fichero /root/.ssh/authorized_keys del servidor.

Podemos utilizar diversos medios para ello, por ejemplo hacer un cat del llave pública, copiarla al portapapeles, editar el fichero del servidor de llaves autorizadas y pegarla. Así de fácil, eso funciona perfectamente.

Pero como tenemos acceso con password vamos a hacer una de estas cosas de BOFHER con las que los novatos se quedan pillaos una semana ;-), desde la máquina cliente:

# cat ~/.ssh/id_rsa.pub | ssh root@miserver.midominio.com -C "cat - >> /root/.ssh/authorized_keys"

Virguero, pero es muy fácil, le tiramos la llave pública al comando ssh por su entrada estándar, le decimos que comprima la transmisión (-C) y en la remota ejecutamos cat de la entrada estándar con redirección añadida (>>) al fichero de llaves autorizadas.

Habilitar autenticación mediante llave en el servidor:

En Debian no hace falta, ya viene por defecto y ya podemos acceder al servidor con nuestra llave, en otras distribuciones es posible que tengamos que modificar el fichero de configuración /etc/ssh/sshd_config y cambiar estas opciones:

# /etc/ssh/sshd_config

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Deshabilitar la autenticación por password:

Para fortificar de verdad el ssh deberíamos desactivar la autenticación mediante contraseña para todos los usuarios, especialmente para el root:

# /etc/ssh/sshd_config

PasswordAuthentication no

Hay muchos admins que no permiten acceder como root al servidor (PermitRootLogin no) y te obligan a entrar con un usario no privilegiado y ejecutar todo con sudo. Personalmente opino que es innecesario y molesto en la mayor parte de los casos, suele ser suficiente, y mucho más cómodo, así:

# /etc/ssh/sshd_config

PermitRootLogin withoutpassword

Es decir, se puede entrar como root pero sólo con llave, no con contraseña.

Cambiar el puerto por defecto:

Es rizar el rizo, y a veces ganar mucha incomodidad por un poquito más de seguridad, pero bueno, os contamos como hacerlo:

# /etc/ssh/sshd_config

Port 25142

El puerto puede ser el que tú quieras, no tiene porque sér el 25142, aunque es recomendable poner uno alto, por ejemplo el 6666 y añadir alguna medida de protección contra el escaneo de puertos, pero eso ya queda fuera del alcance de este artículo.

En cualquier caso recuerda que no deberías utilizar los puertos privilegiados (< 1024) porque normalmente se utilizan para otros servicios y están reservados, y que el número máximo de puerto es el 65535 (64K).

Banear a las ips que hacen mas de 5 logeos erroneos:

Para esto usaremos una herramienta llamada fail2ban, aunque hay otras como logcheck que pueden hacer un servicio similar.

Instalamos fail2ban:

En Debian:

# apt-get install fail2ban

Una vez instalado crearemos una directiva para ssh añadiendo lo siguiente al fichero /etc/fail2ban/jail.local:

# vi /etc/fail2ban/jail.local

[ssh]
enabled  = true
port     = 25142
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5

Reiniciamos fail2ban:

# /etc/init.d/fail2ban restart

¡Y listo!

Recuerda: Al efectuar cualquier cambio en la configuración de SSH, debemos reiniciar el servicio para que sea efectivo en los siguientes accesos. La sesión a través de la que estamos conectados no se verá afectada. Por ejempo en Debian ejecutaríamos /etc/init.d/sshd restart.

--- Basado en un artículo original de TuXed ---