Ataques contra el protocolo SSH

Muchas de las consideraciones sobre la protección que proporciona SSL/TLS son aplicables también al protocolo SSH. Este protocolo está diseñado para que un atacante no pueda leer el contenido de los mensajes ni alterarlos, y tampoco cambiar la secuencia de los mismos.

La confidencialidad queda garantizada con el método de intercambio de claves basado en criptografía de clave pública, que protege contra los ataques “del hombre a medio camino” que hemos visto en el apartado sobre SSL/TLS. Además, este método permite que el cliente se asegure de que se está conectando al servidor auténtico. Para comprobar que la clave pública que envía el servidor es realmente la suya, se pueden usar certificados, o bien una base de datos local del cliente en la que estén guardadas las claves de los servidores reconocidos. Y para autenticar al usuario mediante una clave pública (la suya o la del cliente desde el cual se conecta, dependiendo del método de autenticación), también existen las dos opciones: certificados o una base de datos de claves en el servidor.
Si no se usan certificados, el protocolo contempla la posibilidad (aunque no se recomienda) de dar por buena la clave pública de un servidor la primera vez que se establezca una conexión, sin necesidad de ninguna comunicación previa. Esto no es apropiado en un entorno donde la seguridad sea crítica, porque representa una vulnerabilidad a ataques “de hombre a medio camino”. En otros entornos, y mientras no se disponga de una infraestructura de claves ampliamente extendida, aceptar directamente claves recibidas por primera vez puede suponer un equilibrio entre comodidad de uso y seguridad.
Una característica interesante añadida a SSH2 es que las longitudes de los paquetes se envían cifradas. Un atacante que vea los datos intercambiados como un flujo de bytes no puede saber dónde empieza y dónde acaba cada paquete SSH2 (si tiene acceso al nivel de paquetes TCP puede intentar hacer deducciones, pero sin una certeza absoluta). Esto, juntamente con la posibilidad de incluir padding arbitrario (hasta 255 bytes) y enviar mensajes IGNORE, puede servir para ocultar las características del tráfico y dificultar los ataques con texto claro conocido.
Por otra parte, merece la pena señalar que los métodos de autenticación de usuario mediante listas de acceso se basan en la confianza del servidor en el administrador del sistema cliente (del mismo modo que los protocolos rsh y rlogin):
• Cuando no se autentica el sistema cliente (posibilidad contemplada solamente en SSH1), el servidor sólo tiene que aceptar conexiones que provengan de un puerto TCP privilegiado (menor que 1.024) para que a un usuario cualquiera no le sea fácil enviar paquetes suplantando la identidad de otro.
• Cuando hay autenticación del sistema cliente, el servidor confía que los usuarios no tendrán acceso a la clave privada de este sistema, porque si no podrían utilizarla para generar mensajes de autenticación con la identidad de otro usuario.
Finalmente, igual que pasa con SSL/TLS, el protocolo SSH está diseñado para ofrecer determinadas protecciones, pero el nivel de seguridad que proporcione en cada caso vendrá dado por las implementaciones y por el uso que se haga del mismo. Se recomienda que se puedan deshabilitar o restringir las características (métodos de autenticación de usuario, redirección de puertos TCP, etc.) que en un determinado entorno impliquen alguna vulnerabilidad o posibilidad de abuso.