15.2.08

SSH: seguridad básica

OpenSSH es el estándar en lo que a conexión remota se refiere, de ahí que muchos de los ataques se dirijan específicamente a este servicio. En entradas anteriores hemos visto como proteger una máquina contra un ataque basado en diccionario, utilizando el paquete Denyhosts:

http://joservilas.blogspot.com/2006/07/denyhosts-no-ms-flood-mi-sshd.html

Ahora veremos como efectuar una configuración muy simple pero a la vez segura para optimizar el acceso al servicio, toqueteando el fichero de configuración /etc/ssh/sshd_config:

Lo primero será deshabilitar el acceso del superusuario (root) de forma remota

PermitRootLogin no

o, si lo queremos, dejar que acceda pero nunca mediante password, obligándolo a utilizar un juego de claves ssh que se deberán almacenar en /root/.ssh/authorised_keys o en el propio fichero de configuración

PermitRootLogin without-password


Siguiendo con la misma política, será interesante indicar (si el número no es grande) los usuarios que pueden acceder al sistema, en lugar de permitirlos todos añadiendo la(s) línea(s)

AllowUsers nombre_de_usuario
AllowUsers jose
AllowUsers pepe
...


y aunque el valor "PermitRootLogin" esté marcado como "yes", si no marcamos una línea "AllowUsers root", el sistema no validará al superusuario.

Como complemento a este parámetro, podemos especificar la(s) máquina(s) desde la(s) que podremos acceder, denegando los restantes intentos

AllowUsers jose@172.16.0.5
AllowUsers jose@mustafar
AllowUsers jose@mi_isp.mi_host.com
...


apartado en el que se pueden utilizar comodines

AllowUsers jose@192.168.*
...


Por último, es muy probable que no se necesite autentificación PAM, salvo que utilicemos un servidor LDAP o similar, con lo que no está de más deshabilitar esta entrada (ya que OpenSSH sabe de sobra donde validar usuarios)

UsePam no

Como complemento, podremos utilizar DenyHosts, TcpWrappers o forzar la validación mediante pares de certificados, pero tal cual, ya se trata de una configuración realmente segura (salvo la predecible posibilidad que se deriva de la "mala praxis" de acceder desde redes no fiables con el riesgo de un ataque spoofing).

No hay comentarios: