jueves, 6 de diciembre de 2018

Dándole esteroides a nuestro SSH para que sea un poco más seguro

Hay una cosa que me gusta y es darle mil vueltas a un servicio para fortificarlo, siempre se puede fortificar más. Siempre hay algún parámetro que se puede revisar mejor y darle más caña para una configuración mayor. Hoy vamos a tocar uno de los servicios más importantes a configurar para fortificar su seguridad en nuestros servidores. Ese servicio no es otro que el servicio SSH.


Vamos a ver varios puntos que van a mejorar bastante la seguridad de nuestro servicio SSH. Algunas de estas cosas no se implementan en mi empresa por más que insisto, pero bueno, yo por dejar la información que no sea.

1. Utiliza par de claves privadas/públicas.

Sobre esto ya he hablado un poco en uno de los 10 mandamientos y en un post específico sobre cómo configurar este par de claves ssh. Tenéis la información, seguidla.

2. Seguridad por oscuridad cambiando el archivo authorized_keys

La seguridad por oscuridad es algo de lo que discrepa mucha gente, pero ayuda sin duda. No es lo mismo utilizar el directorio por default, ya que si un atacante accede al servidor y va a esa default path, se va a encontrar el archivo y, si consigue escalar privilegios, podrá modificar ese archivo y provocar un gran problema en nuestro servidor a pesar de utilizar un par de claves privadas/públicas.


Podemos utilizar algunas variables como %u para denominar al usuario y %h para llevar al $HOME directory. Podemos utilizar cualquier otra ruta como, por ejemplo /var/%u/falcon/hippi3c0w. Es una ruta y un archivo que no da ninguna pista de que contenga llaves ssh, y quieras que no pone las cosas más difíciles a un posible atacante.

3. Si utilizamos claves, no permitir las empty passwords

Esto me parece algo super lógico pero que después al mirar archivos de configuración, casi siempre me encuentro comentada y mal, muy mal.  No podemos permitir que una contraseña esté vacía, es demasiado absurdo que tan si quiera lo permitamos aunque no haya ningún usuario con una password as empty. Es que podríamos a llegar a tener el problema de que un atacante acceda al servidor, escale privilegios y cree un usuario con password empty.


Algo que también es recomendable es limitar el tiempo que un usuario tendrá para typear la password. Yo le doy poco, unos 20 segundos está bien.


Y otra cosa que considero fundamental es el limitar el número de intentos. Yo siempre he puesto este parámetro a 3, pero últimamente me estoy volviendo más restrictivo con esto y lo estoy limitando a 2.



4. Denegar el acceso al usuario root.

Polémica. Cuando llego a este punto siempre hay polémica. Es comentar esto y todo el mundo te mira mal, muy mal. No debería ser así, ya que basta con dar más privilegios a usuarios administradores. A ver, si das más privilegios a un usuario que sea administrador y encima saben la password de root, a unas malas hacen un su, introducen la password y ya. Así evitas el problema de que hagan fuerza bruta al usuario root en el servicio ssh.

Las empresas (las grandes sobre todo) ponen muy mala cara a dar más privilegios a otros usuarios. Prefieren asumir el riesgo de permitir el acceso al usuario root que dar privilegios a administradores. Sobre esto ya hablaré largo y tendido en otro post, pero tela eh.


5. Denegar el acceso mediante password

Otro gran hit para que los mandamás de toda empresa grande se tire de los pelos y crea que te has vuelto loco. Yo personalmente no le encuentro sentido que utilices el par de claves, pero además una contraseña. Lo considero una estupidez enorme. 

Para empezar, si permitimos el acceso mediante contraseña, un atacante que no tenga la clave pública del usuario con el que quiera entrar, podría realizar un ataque de fuerza bruta. Y aquí llegan las excusas

-"Pero tenemos limitado el número de intentos"
R: Con eso lo único que logras es que tarden más. Lanzarán intentos de 2 en 2 por ejemplo. Además, muchas empresas tienen la brillante idea de que si intentas loguear con un usuario más de 2 veces bloquean al usuario en lugar de banear al que lo ha intentado. Es decir, si trato de acceder con el usuario "user01" más de 2 veces, bloquean al user01 en lugar de al usuario que ha realizado esos intentos. Una estupidez enorme porque un esquema de fuerza bruta te bloquea un usuario que puede ser importante.

-"Pero tenemos password complejas"
R: ¿Y? Si alguien la saca es copiar y pegar

-"¿Y si hay un problema con las claves y no nos dejan acceder?"
R: Lo primero es que las backups están para algo. Lo segundo es que si ocurre eso es porque muy posiblemente alguien haya tocado algo que no debe o un atacante haya accedido ¿Cómo? Pues a lo mejor mediante la password que hemos dejado habilitada y posteriormente aprovechando una configuración incorrecta para escalar privilegios. Es decir, por algo que se podría evitar si no dejásemos que pase eliminando el acceder con password.



6. Separación de privilegios

Esta opción suele venir activada por defecto pero, lo de siempre, comentada. Esta opción lo que hace es realizar el login mediante un proceso que no tenga más permisos que atender al tráfico y lanzar la conexión, pero que una vez que se loguea el usuario sí que atiende a los permisos normales de ese usuario. Así evitamos que el simple login ya pueda ser un vector de ataque.


7. Denegar conexiones concurrentes sin autenticación

Lo lógico es que un atacante trate de loguear desde varios usuarios a la vez para agilizar el proceso. No todos los usuarios tendrán la misma seguridad, por lo que el atacante podría lanzar varias terminales probando acceder a los distintos usuarios que haya sacado.


Aquí yo lo tengo establecido a 5. Yo suelo ser más restrictivo y lo pongo a 2, pero bueno, si somos permisvos, y dependiendo del entorno y d enuestra aplicación, podremos asignar un valor más alto. Para mí 5 ya es un número más que alto.

8. Cambiar el puerto y  limitar los equipos de escucha.

Con lo del puerto es algo en lo que siempre hay mucho debate. Es cierto que igualmente se podría sacar si el servicio está open o no si se lanza la query de nmap correcta. Aquí el tema es poner al atacante en una situación lo más difícil posible, así que nunca está de mal. Además podemos hacer que solamente sea posible la escucha desde el mismo dispositivo.


9. Desconectar a usuarios inactivos

Tener a un usuario inactivo consume muchos recursos, por lo que con ClientAliveInternal definimos el tiempo que un usuario debe estar inactivo para expulsarlo. Con ClientAliveCountMax definimos cuántos avisos se le darán al usuario del tipo "Tu sesión se cerrará en X minutos" para así no desconectarlo. Con 10 minutos de inactividad ya está bien, y yo los avisos los pongo a 0 para evitar que un usuario descuidado se conecte desde la cafetería de la empresa, o en su casa un día festivo que tenga que trabajar desde casa y reciba visita de sus familiares y se vaya al servicio dejando el ordenador sin bloquear. Soy muy restrictivo con estas políticas, pero yo siempre prefiero prevenir.



10.  Advertencia en el banner

Podemos crear una advertencia mediante un archivo que creemos. Posteriormente definimos en el parámetro Banner el archivo donde creamos el aviso.


La advertencia lo suyo es que sea creible del tipo "El acceso a este servidor está prohibido".

11. Ocultar la versión del sistema operativo.

Esta opción es sólo para Debian (Otro minipunto) y con el parámetro DebianBanner podemos definir esto. Esto es para evitar fugas de información. Ya sabéis que cualquier fuga puede suponer un alto riesgo.


Con estos 11 tips mejoraremos notablemente la seguridad de nuestro SSH. Son tips muy recomendables y que no en todas en las empresas se siguen.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...