SSH. Un poco de seguridad parte 2

Tal y como mencione en mi anterior post voy a continuar con el tema del SSH.

Soy un PESADO, pero aún así reitero mi introducción del primer post.

Ante todo comentar que no soy un super profesional en seguridad, simplemente soy un administrador de sistemas que se preocupa en tener sus sistemas lo más securizados posibles, entre otras cosas por eso de que me gusta dormir tranquilo por las noches 🙂 , seguramente la gran mayoria de vosotros me daréis mil vueltas en estos temas, mi objetivo principal es dar unas pequeñas pautas sobre como dar un poco de seguridad al SSH, no voy a cubrir la instalación ya que hay abundante información sobre ello en internet y considero que repetir el proceso constantemente es perder el tiempo, adjuntaré algunos enlaces a algunos tutos excelentes y lo más sencillos posibles, y siempre que sea posible intentaré enlazar con documentación en castellano (por si alguien no se defiende bien con el inglés).

Al tajo, suponiendo que el equipo al que queremos acceder tenga varias tarjetas de red por X razones (porque hace de proxy, o de firewall, o cualquier otra), no estaría mal por nuestra parte limitar qué tarjeta de red atenderá las peticiones SSH acotando así el área de exposición ante un posible ataque.

Imágen  cogida de la web de pello.info
Imagen cogida “prestada” de pello.info

En este ejemplo podemos ver que el equipo es un Firewall, con 2 interfaces, una al router y otra a la red local, es posible que nos interese acceder solo desde una de las 2 interfaces, o desde la red local o desde internet, ambas opciones tienen sus pros y sus contras y según las necesidades del administrador utlizará la que más le convenga, suponiendo que la interfaz entre el Firewall (FW a partir de ahora) y el router sea la eth1 con ip 10.0.3.15 y la interfaz entre el FW y la red local sea la eth0 con ip 192.168.88.33, voy a poner un ejemplo para limitar el acceso al FW por ssh para que solo la interfaz de la red local conteste a SSH.

Realmente es sencillo, bastará con descomentar el parámetro ListenAddres dejándolo como sigue:

ListenAddress 192.168.88.33

Reiniciamos el servicio y vemos si realmente está escuchando donde le hemos dicho.

listenlimit

Como me gusta este parámetro -putan :-). Biennn vamos mejorando un poco la seguridad de nuestro ssh ahora seguiremos con otro tema, cuando accedemos al sistema por ssh esto es lo que nos aparece.

 

banner1

mmmmmm nada de nada …. bueno, el que avisa no es traidor, vamos a pone un banner de PRE-LOGIN para advertir a quien se conecte que el servidor es privado y que solo tienen permiso los usuarios autorizados, esto os puede sonar raro, pero en algunos países, es necesario advertir para después poder tomar represalias legales.

Crearemos un fichero en /etc que llamaremos banner-ssh.txt donde escribiremos los siguiente

##############################################################
#
# THIS SYSTEM IS PROVIDED FOR USE BY AUTHORIZED USERS ONLY.
#
# EL ACCESO A ESTE SISTEMA ES SOLO PARA USUARIOS
# AUTORIZADOS
###############################################################

lo grabaremos y editaremos el fichero sshd_config descomentando y modficando el parámetro:

Banner /ec/banner-ssh.txt

Reiniciamos el servcio y vemos que ocurre ahora.

banner2

El que avisa no es traidor 🙂 evidentemente no es una opción de seguridad pero al menos de esta forma nadie podrás decir que no lo sabían.

Continuamos, otro parámetro del sshd_config que merece mención es el MaxAuthTries, donde podemos definir el número de intentos para dar contraseña a un sistema, por defecto SSH te permite 3 intentos, pero podemos todavia reducirlo más. ¿Que ganamos con esto? …. relentizar algunos scripts por fuerza bruta, debido a que si en lugar de tener 3 intentos para probar contraseñas tiene por ejemplo 2 o 1 y se desconecta la sesión, evidentemente se hace más laborioso tener que volver a establecer conexión y volver a probar.

El parámetro no aparece por defecto en el fichero de configuración, así que lo añadimos:

MaxAuthTries 2

Reinicamos el servicio del ssh: #service ssh restart

Veamos su efecto.

maxauthtries

Vemos que antes he podido insertar 3 contraseñas pero que después me ha sacado fuera al introducir la 2ª.

Otra opción más que interesante es MaxStartups con la que podemos limitar el número de intentos de login simultáneos. Intentaré explicarme un poco mejor. Supongamos que tengo el MaxStartups a 1, significa que solo 1 conexión podrá intentar acceder al sistema, si mientras estoy intentando hacer login hay otra conexión que intenta acceder, el ssh cerrará la conexión. Os adjunto un pantallazo para que se vea más claro.

maxstartups

Vosotros me diréis, pues vaya tontería, bueno… tontería según para quien se mire, con esto evitamos que los ataques que utilicen multithreads para realizar fuerza bruta o comprobar diccionarios se vean muy mermados si en lugar de poder realizar las 10 conexiones simultáneas de login que permite por “defecto” el ssh se encuentran con que solo permite 1 o 2. Aquí como en todo los posts, que cada uno utilice lo que le interese o pueda necesitar, o que lo adapte a sus necesidades reales.

Se me olvidaba, el parámetro MaxStartups no viene por defecto, lo tenemos que agregar al fichero tal que así:

MaxStartups 1

Acordaros de reiniciar el servicio después de guardar cualquier cambio en el sshd_config.

Otros parámetros que merece la pena comentar:

LoginGraceTime Este parámetro indica el tiempo que podemos estar esperando en la pantalla de login para introducir nuestros datos de autenticación, antes de que el ssh nos desconecte, por defecto viene en 120 segundos (2 MINUTOS!!!!), con 30 segundos es más que suficiente. Sería así:

LoginGraceTime 30

Y lo último por hoy, si no voy a utilizar el sftp, scp, rsync ¿porque los dejo disponible por “defecto”?. La forma más sencilla es comentando la línea:
# Subsystem sftp /usr/lib/opeenssh/sftp-server

Y este es el resultado:

sftp

Como habéis podido observar hasta el momento, simplemente cambiando unos cuantos parámetros de configuración del SSH con “cabeza” adaptándolo a vuestras necesidades se puede mejor BASTANTE la seguridad del mismo, me gustaría hacer hincapié en que las configuraciones por defecto ya sea en cualquier sistema operativo, servicio, etc. no son las más adecuadas para todo tipo de usuarios, esto es un mal que tanto usuarios, empresas y profesionales pecan todos los días sin tener en cuenta las repercusiones que puede producir este tipo de configuraciones. Recordad, aprended con que estáis trabajando y de vez en cuando RTFM.

Bueno, y hasta aquí por hoy, seguiremos con esta serie de post sobre un poco de seguridad con ssh.

Reitero lo mismo de siempre, si encontráis algún fallo, error o no entendéis algo, ya sabéis que estoy a vuestra disposición (en mi tiempo disponible que no es mucho).

Espero que os sirva de ayuda. See you ….

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *