Cambiar puerto por defecto

La seguridad mediante ocultación no es la solución, pero evitarás ataques automatizados. Además de usar un cortafuegos, una buena manera de proteger aún más nuestra máquina contra posibles intrusiones externas es cambiar los puertos por defecto de los distintos servicios que estemos usando.  En el fichero de configuración /etc/ssh/sshd_config podemos modificar el puerto del servidor SSH, 

Si lo hacemos, hemos de tener en cuenta que a partir de entonces, cuando queramos acceder al servicio del servidor SSH, lo indicaremos con -p puerto, del siguiente modo:

ssh -p 3426 el-brujo@ns2.elhacker.net

Asegurar el servidor SSH

Lo primero que tenemos que hacer es entrar en el archivo de configuración para realizar los cambios:

sudo nano /etc/ssh/sshd_config

Veremos una gran cantidad de opciones de configuración en él. Una de las primeras que encontraremos es la que indica el puerto de acceso al servidor, que por defecto es el 22. Si lo cambiamos (poniendo, por ejemplo, el puerto 3426), dificultaremos mucho el trabajo a quien intente acceder a nuestra máquina:

Port 3426

Algo importante que debemos comprobar es la directiva de seguridad que permite o deniega el acceso a root, el superusuario o administrador de los sistemas UNIX/Linux. Muchos de los ataques que se realizan, especialmente contra servidores, se concentran en particular sobre este usuario con la esperanza de que tenga una contraseña débil, algo que (desgraciadamente) sucede con demasiada frecuencia.

Por defecto, la directiva que controla el acceso de root se encuentra así:

PermitRootLogin prohibit-password

Esto significa que se prohíben todos los métodos de autentificación interactivos, permitiendo sólo la autentificación mediante Publickey, Hostbased y GSSAPI. Sin embargo, es mucho más seguro no permitir el acceso del administrador del sistema de ninguna de las maneras. Por eso, lo que haremos será impedir la entrada a root de todas las formas posibles, sean cuales sean, lo que conseguiremos cambiando así esta línea:

PermitRootLogin no

Otra opción que podemos modificar es la que indica la cantidad de minutos que la pantalla de login estará disponible para que el usuario se identifique. Pasado ese tiempo, si no nos hemos identificado, la conexión se cerrará:

LoginGraceTime 1m

Prestaremos atención asimismo a las dos siguientes directivas de seguridad:

MaxAuthTries 3
MaxSessions 4

Sirven para dificultar los ataques de fuerza bruta. La primera indica el número máximo de errores permitidos al hacer login. Si sobrepasamos ese número, se nos mostrará un mensaje de error y habrá que volver a empezar de nuevo. La segunda directiva se refiere al número máximo de conexiones simultáneas por IP que permite el servidor.

También nos aseguraremos de que se exija el uso de una contraseña de acceso y que no acepte contraseñas vacías o en blanco:

PasswordAuthentication yes
PermitEmptyPasswords no

Si hay varios usuarios en el sistema, podemos añadir también al final del fichero de configuración una directiva para que sólo los usuarios especificados tengan acceso al mismo:

AllowUsers pi elhackernet

O, si se prefiere, usar en su lugar esta otra para permitir el acceso a todos menos a los que se indican expresamente en ella:

DenyUsers luisp manu root

Guardamos los cambios y comprobamos que la configuración del fichero es correcta, para lo cual hay que escribir este comando:

sudo sshd -t

Si no aparece ningún mensaje de error, es que todo está bien. Es importante comprobar que el archivo de configuración es correcto porque si no, cuando reiniciemos el servicio (o la propia Raspberry), el servidor SSH no arrancará y no podremos conectarnos.

Una vez que nos hemos asegurado de que todo está en orden, necesitamos reiniciar el servicio para que los cambios surtan efecto:

sudo service ssh restart

Periódicamente es aconsejable mirar el fichero /var/log/auth.log para comprobar si ha habido algún intento de entrada ilegal. Si los hubiese, el siguiente comando nos ayudará a encontrarlos:

sudo cat /var/log/auth.log | grep 'invalid user\|Failed'

Y este otro contará cuántas líneas con intentos de intrusión aparecen:

sudo cat /var/log/auth.log | grep 'invalid user\|Failed' | wc -l

Para finalizar, añadiremos un par de notas importantes:

1. 1.) Las contraseñas de usuario que usemos deben de ser "fuertes", es decir, tener cierta extensión (8 caracteres o más) y estar compuestas por una combinación de letras (mayúsculas y minúsculas), números y signos de puntuación. Además, la palabra resultante no debe tener sentido, de manera que no aparezca en ningún diccionario.
2. 2.) También podemos conectarnos empleando autentificación mediante clave pública, lo que nos ahorra el tener que memorizar la contraseña y además resulta más seguro.

Existen otras configuraciones recomendadas para evitar las conexiones no deseadas al servidor SSH:

• LoginGraceTime: Establece el tiempo necesario para introducir la contraseña, evitando que el atacante tenga que “pensar mucho”.
• MaxAuthTries: Número de intentos permitidos al introducir la contraseña antes de ser desconectados.
• MaxStartups: Número de logins simultáneos desde una IP, para evitar que se pueda utilizar la fuerza bruta con varias sesiones a la vez.
• AllowUsers: crear una lista blanca de usuario. Este parámetro permite configurar los usuarios que podrán conectarse. Una medida muy restrictiva pero a la vez muy segura ya que bloqueará todas las conexiones de los usuarios que no estén en el listado. Los usuarios que esten aquí podrán conectarse, y el resto no.
• DenyUsers: Parecido al anterior, pero ahora se crea una lista negra. Los usuarios que esten aquí no podrán conectarse, y el resto sí.
• AllowGroups/DenyUsers: Exactamente igual a lo anterior, pero en lugar de crear una lista blanca/negra de usuarios, es de grupos de usuarios.

Por ejemplo, un archivo de configuración de sshd_config sería el siguiente:

Port 22445
PermitRootLogin no
LoginGraceTime 30
MaxAuthTries 3
MaxStartups 3
AllowUsers elhackernet
DenyUsers pi

Desactivar re-envio de tráfico (pueden utilizar ssh para redireccionar tráfico)

AllowTCPForwarding No

Después de los cambios, se deberá reiniciar el servicio sshd utilizando (reiniciar para que los cambios surtan efecto)

$ sudo systemctl restart ssh