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).
15.2.08
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario