Securitizando SSH

En todas las distribuciones de GNU/Linux y Solaris he encontrado SSH como vía estándar de comunicación remota. ¿Por qué? Es simple de implementar, de utilizar y sumamente segura por su carácter de encriptación de los puentes que se hacen. No solo podemos sustituir Telnet, también podemos hacer túneles que nos permiten escapar de los firewalls restrictivos. 

Al ser un punto de entrada,  por ello capital, es necesario aplicar ciertas políticas de seguridad, especialmente en aquellos sistemas que son productivos.

Las siguientes políticas podrían ser útiles para tal tarea.

  • No permitir validación de root
  • Reducir la cantidad de usuarios que pueden autenticarse
  • Sólo permitir la versión 2 de SSH
  • Usar llaves para autenticarse

El root es digamos que el usuario más perseguido en las intrusiones, pues su carácter casi bíblico lo hace ser el súper usuario, el usuario de usuarios. Para evitar que por algún descuido alguien pueda robarnos la cuenta, y robarnos lo que sea, desactivamos la directiva del archivo de configuración de SSHD. Editamos el siguiente archivo:

$ vi /etc/ssh/sshd_config
 Y ahora buscamos la siguiente directiva y la establecemos en no. Si no existe, la incluimos de todas maneras:

PermitRootLogin no

Reiniciamos el servicio de sshd y listo, ya no podremos autenticarnos remotamente con el root.

No es necesario que cualquier usuario que tengamos dado de alta en nuestro sistema se autentique remotamente, eso eleva potencialmente el riesgo de que nuestro sistema sea comprometido, ya sea por un hurto de credenciales o por un malintencionado empleado que nada tiene que hacer ahí.

Para conseguir la autenticación de usuarios selectos o denegar a todos aquellos que explícitamente quisiéramos denegar el acceso, utilizamos la siguientes directivas:


AllowUsers usuariopermitido
AllowGroups gruposdemiusuario
DenyUsers usuariopeligroso
DenyGroups grupospeligrosos

Las reglas se llevan a cabo como una ACL, es decir, la primera que coincida es la que se lleva a cabo. Como pueden ver, podemos listar los usuarios que tengan acceso o los usuarios que no queremos. La elección depende de la situación.

El restringir versiones de SSH es recomendable, por las vulnerabilidades que llevaron a la versión 1, escribir la versión 2.

El último punto está descrito en otro artículo, ya que no solo pertenece a la seguridad de SSH.

Con estas simples medidas, podrán mantener con cierta tranquilidad el control de los accesos a su sistema.


Comentarios

Entradas populares de este blog

Análisis de conexiones TIME_WAIT

Agregar un usuario a un grupo secundario

Desencriptar passwords AES y DES en WebLogic 10