SSH (Secure SHell, en español: intérprete de órdenes segura) 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 completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Cuando instalamos un servidor de ssh, por ejemplo OpenSSH (sudo aptitude install ssh), en ocasiones solemos dejarlo con las opciones de configuración que vienen por defecto, sobre todo en entornos domésticos, asumiendo que como ssh es un shell seguro, no necesitamos realizar más ajustes que los que vienen por defecto. Nada más lejos de la realidad. Vamos a ver algunas de las opciones del archivo de configuración (/etc/ssh/sshd_config) que nos pueden ayudar a comprender mejor como funciona ssh y lo expuestos que podemos estar frente a ataques basados en diccionario si no se toman las medidas oportunas.

Para editar el archivo necesitamos permisos de administrador:

sudo gedit /etc/ssh/sshd_config

Al editarlo podremos observar hay multitud de opciones de configuración, pero sólo nos vamos a centrar en las siguientes:

Port 20022
Protocol 2
LoginGraceTime 30
PermitRootLogin no
MaxAuthTries 2
MaxStartups 1
AllowUsers pepito
AllowUsers juanito@80.25.14.14

Veámos el significado de ellas:

  • Port 20022 indica el puerto de escucha de ssh, es decir, donde estará esperando conexiones el servicio de ssh. El puerto por defecto es el 22 y es importante cambiarlo, ya que muchos scripts de ataques están dirigidos a este puerto. Cambiar de puerto no garantiza que no pueda ser localizado por dichos scripts, pero desde luego se lo ponemos más complicado. ¿Piensas que no es necesario cambiar el puerto? ¿Por qué no le hechas un vistazo a los registros de log de autentificación en /var/log/auth.log? ¿Sorprendido? Si tienes una máquina conectada a Internet, con el puerto 22 abierto y redirigido a una máquina con acceso ssh, seguro que tienes mucho que mirar en dicho fichero, como por ejemplo intentos de conexión fallidos. Por ejemplo, unas cuantas líneas como estas:

    Feb 28 11:57:04 distantsuns sshd[25055]: Invalid user kid from 220.108.89.55
    Feb 28 11:57:13 distantsuns sshd[25111]: Failed password for root from 220.108.89.55 port 44336 ssh2
    Feb 28 11:58:25 distantsuns sshd[25775]: Failed password for invalid user kes from 220.108.89.55 port 48097 ssh2

    Mi recomendación es que utilicéis un puerto alto, por encima del 10000. La mayoría de los escaners de puertos buscan por defecto en los puertos bien conocidos (hasta el 1024) y algunos puertos por encima, pero no los revisan todos.
    Evidentemente, cambiar el puerto no nos asegura nada, pero pone las cosas un poco más difíciles a los scripts automáticos.

  • Protocol 2 existen 2 versiones de ssh, versión 1 y versión 2. La primera se mantiene sólo por compatibilidad y no debería ser usada ya que está obsoleta y tiene algunas vulnerabilidades bien conocidas.
  • LoginGraceTime 30 indica el número de segundos que estará disponible la pantalla de login. Pasados los segundos la conexión se cerrará. De esta forma evitamos que alguien esté intentando acceder mediante un script varias veces para adivinar un usuario y contraseña. El valor por defecto de este campo es 130, demasiado tiempo en mi opinión, se pueden realizar muchas pruebas automáticas en ese tiempo. Para cualquier ser humano con 30 segundos debería ser más que suficiente.
  • PermitRootLogin no muy importante no permitir conexiones remotas con el usuario root. Todos los ataques basados en diccionario saben que en los sistemas en UNIX, existe un usuario en el sistema llamado root. Por tanto una parte de la combinación usuario-contraseña ya la tendrían y no sólo eso, sino con acceso de administrador. Sorprendentemente esta opción estaba por defecto en mi máquina con el valor yes. Desde luego es un agujero de seguridad tremendo. Si necesitamos acceder vía ssh con permisos de administrador, podemos entrar al sistema con cualquier usuario estándar y una vez dentro cambiamos a root con el comando su.
  • MaxAuthTries 2 indica la cantidad de veces que podemos equivocarnos al validarnos como usuario, en este caso después de dos intentos, se perderá o cerrará la conexión. Si se diera el caso podemos volver a intentarlo, pero de esta forma evitamos ataques basados en la persistencia de la conexión.
  • MaxStartups 1 indica la cantidad de conexiones simultáneas de login que permitirá el sshd por ip que intente conectarse. Muchos de los ataques dividen su esfuerzo abriendo múltiples pantallas de login, llegando incluso a saturar el sistema. Es decir, el ataque se divide en una gran cantidad de logins, aumentando las posibilidades de obtener un usuario y contraseña más rápidamente. Tener este parámetro con el valor 1 no significa que no podamos tener varios shells remotos abiertos, simplemente cuenta pantallas de login. Una vez validados, podemos abrir otro shell sin problemas.
  • AllowUsers indica los usuarios que tienen permiso para acceder por ssh al sistema. Muy útil cuando tenemos muchos usuarios en el sistema y no podemos tener un control sobre la seguridad de las contraseñas que se hayan puesto dichos usuarios. Por tanto sólo daremos permiso a aquellos usuarios que sepamos que tienen una combinación de usuario y contraseña fuertes. Con esta opción también podemos indicar desde que máquinas permitimos el acceso. Por ejemplo podríamos hacer que el usuario juanito sólo pudiése acceder desde la ip 80.25.14.14 añadiendo la siguiente línea:
    AllowUsers juanito@80.25.14.14

    También podemos usar comodines para indicar que se permite acceso desde una red entera. Por ejemplo supongamos que nuestra red privada utiliza direcciones ip privadas de clase C del tipo 192.168.0.X (máscara por defecto 255.255.255.0). Podríamos añadir la siguiente línea para indicar que se permite el acceso al usuario alicia únicamente desde la red privada:

    AllowUsers alicia@192.168.0.*

 

Con este mini tutorial sobre la configuración podremos tener un sistema más seguro que unido al tutorial de verificación de rootkits, nos permite estar un poco más tranquilos.