Securizando el servicio SSH

Secure Shell, mejor conocido por las siglas SSH y nombrado simplemente como «shell», es el nombre de un popular software que implementa un protocolo homónimo y es utilizado para acceder a servidores remotos. Mediante la interpretación de comandos que posee SSH, es posible manejar en forma completa un servidor, o bien en caso local, una computadora.

Como a través de shell podemos ganar acceso a un servidor remoto, es posible que un atacante gane acceso a nuestro server si logra descifrar las contraseñas necesarias. Para evitar esto, existen algunas pautas que podemos seguir y así evitar que alguien inesperado se cuele a nuestro servidor. Estas reglas que se siguen para mejorar la seguridad del shell es lo que se conoce como securización de SSH.

Cabe destacar que en esta oportunidad nos centraremos en un sistema bajo CentOS, Fedora o RedHat, pero la securización en la mayoría de los servidores que corren con una distro de Linux suele ser muy similar a esta.

Recuerda que todos los cambios los aplicas bajo tu propio riesgo. El fichero que debemos editar es el siguiente:

/etc/ssh/sshd_config

Procedemos a editarlo:

pico -w /etc/ssh/sshd_config

Aquí dentro hay un monton de directivas y variables, pero a nosotros nos interesan una pocas. Si estamos haciendo la securización inicial, lo primero que debemos hacer es cambiar el puerto (si al ingresar al server usaste un puerto distinto del 22, olvida este paso). La mayoría de los servidores por defecto no especifican un puerto para SSH o bien especifican el 22. Nosotros vamos a asignar otro puerto (menor a 1000 en lo posible) y que además no sea usado por otro servicio como Apache, MySQL, etc. Para cambiar el puerto, buscamos la variable «Port» y especificamos el puerto deseado de esta forma (reemplazando las XXXX por el puerto deseado):

Port XXXX

Recuerda siempre tomar nota en un archivo de tu PC sobre los cambios que vas realizando. Y por sobre todo, también actualiza el número de puerto en las reglas del firewall, de lo contrario no podrás ingresar al servidor.

Lo siguiente es activar «Protocol 2». Esta línea en ocasiones viene comentada y en algunas ocasiones no. Si está comentada, la descomentamos. Si existe una línea «Protocol 1» que está descomentada, procedemos a comentarla inmediatamente (le añadimos # al principio). Protocol 1 está en desuso y tiene algunas vulnerabilidades, por eso se usa la segunda opción. En resumen, debe verse así:

#Protocol 1
Protocol 2

Ahora vamos a reducir el tiempo del que disponemos para ingresar la contraseña cuando intentamos acceder por SSH al servidor. Si tenemos la contraseña, no necesitamos ni 10 segundos para ingresar, pero cuando se trata de un atacante, puede que el mismo se lo piense dos veces antes de intentarlo, por lo tanto debemos evitar que tenga mucho tiempo a su disposición. La variable que controla esto es «LoginGraceTime«. Podemos establecerla en segundos o en minutos, según queramos. Recomendamos que el tiempo sea de 1 minuto, por lo que establecemos reemplazando la X por «60» (segundos) o bien por «1m» (minutos).

LoginGraceTime X

Lo que haremos ahora es evitar que los archivos del directorio /home no tengan permisos de escritura para cualquier que no haya ingresado, lo cual hacemos estableciendo la siguiente directiva:

StrictModes yes

Hay una variable interesante llamada «PermitEmptyPasswords«. ¿Qué hace? Pues permite usar contraseñas vacías. ¿Nos sirve? Claro que no, así que la desactivamos, aunque de seguro ya esté desactivada:

PermitEmptyPasswords no

¿Qué te parece si reducimos los intentos de ingreso para sacarnos de encima a scipts que entran por la fuerza? Cambia X por el número deseado. Te aconsejo dejarlo en 2 o en 3.

MaxAuthTries X

Ahora veremos tres directivas interesantes. «PrintMotd» especifica si el servicio SSH debería mostrar el contenido de «/etc/motd» cuando el usuario ingresa. «PrintLastLog» muestra la última vez que alguien ingresó al servidor con el mismo usuario con que ingresamos nosotros. Cuando el servidor DNS no funciona correctamente, «UseDNS» puede afectar al ingreso por SSH, enlenteciendo la conexión que realizamos, por lo que la dejamos desactivada. En resumen, establecemos las siguientes directivas (en caso de que alguna no exista por defecto, la creamos nosotros):

PrintMotd yes
PrintLastLog yes
UseDNS no

AllowUsers es una opción que por defecto no está creada en el server. Debemos añadirla en el archivo que estamos editando (sshd_config). Lo que esta opción hace es marcar cuáles usuarios tienen permitido el ingreso posterior como root al server (la usaremos en conjunto con el «usuario wheel», tema que veremos en breve). Se debería ver similar a esto:

AllowUsers usuario1 usuario2 usuario3

Ahora, antes que nada, deja de editar el fichero que hemos estado editando y guarda los cambios. Reinicia el servicio SSH para tomar los cambios («service ssh restart»). Abre un shell nuevo de ssh e intenta conectar. Recuerda que como estableciste un puerto nuevo, tendrás que hacerlo de la siguiente forma (reemplaza las XXXX por el puerto):

ssh -p XXXX root@ip.del.servidor

Si has hecho todo bien, deberías estar adentro nuevamente.

El siguiente paso es el útimo, es uno de los más efectivos e involucra el uso de un usuario wheel. Debemos impedir que se ingrese al servidor directamente como root, para lo cual necesitamos un usuario wheel. Este usuario wheel es un usuario que tiene el poder para loguearse como root (haciendo su -). Normalmente su grupo suele venir creado en el servidor. ¿Cómo verificamos si está creado? Debemos mirar el archivo «/etc/group» y si encontramos la línea «wheel:*:0:root» quiere decir que el grupo existe y no necesitamos crearlo. Si el grupo no existe, debemos editar el mencionado fichero y simplemente añadir la mencionada línea. Una vez verifiquemos la existencia del grupo wheel, procedemos con lo siguiente:

adduser -G wheel -m -s /bin/bash -d /home/nuevo_usuario nuevo_usuario

Explico:

«-G wheel» sirve para crear al usuario dentro de dicho grupo.
«-m» crea el directorio home en caso de que no exista.
«-s» indica el shell del usuario.
«-d» indica el nombre del directorio del usuario.

Obviamente debemos reemplazar «nuevo_usuario» por el nombre del usuario que podrá ingresar como root al server. Una vez hecho esto, le asignamos una contraseña, y asegúrate de que la misma sea fuerte. ¿Cómo crear una contraseña «fuerte»? Revisa este post. Para asignar la contraseña usamos:

passwd nuevo_usuario

Recuerda anotar los datos importantes como contraseñas, nombre de usuarios y demás ya que lo necesitarás a continuación. Lo que haremos ahora es volver a editar el archivo sshd_config e impedir los ingresos directamente como root, para lo cual debemos negar la siguiente directiva «PermitRootLogin»:

PermitRootLogin no

No te olvides de añadir el usuario wheel que creaste a la directiva «AllowUsers». Ahora salimos del archivo, guardamos los cambios y reiniciamos el servicio SSH. Salimos del servidor y ahora para ingresar debemos hacerlo de la siguiente forma:

ssh -p XXXX usuariowheel@ip.del.servidor

Una vez hayas ingresado con el usuario wheel, puedes pasarte a root haciendo «su -» y poniendo la contraseña de root. ¿Cómo comprobar que no puedo ingresar directamente como root? Abre una nueva sesión de shell e intenta lo siguiente:

ssh -p XXXX root@ip.del.servidor

Si has hecho todo como hemos indicado, no debería de funcionarte el acceso directo como root y por lo tanto será necesario que cualquiera que ingresa lo haga primero por medio del usuario wheel. Este simpático usuario, como puedes ver, es una capa de seguridad extra (como si a una casa que tiene sólo una puerta le pones además un portón).

Y eso sería todo. Lo cierto es que la seguridad a nivel de SSH no es nada complicado de configurar (e incluso podemos hacerla un poco más agresivo de lo que hemos visto aquí), pero debemos recordar que si no está presente entonces nuestro servidor será muy vulnerable.

Esto es todo por hoy. Cualquier duda la puedes comentar aquí abajo.