Vamos entonces con la segunda parte de Mejorando SSH. Como decía, si bien SSH en sí mismo nos da unas garantías de seguridad podemos realizar algunas configuraciones adicionales para afinarlo un poquito más. Pero… ¿con qué objetivo? A esto vamos hoy.

Uno de los ataques o pruebas de Pentest que podemos sufrir o hacer, es mediante aplicaciones que lancen sucesivos intentos de conexión proporcionando usuarios y contraseñas generadas u obtenidas previamente, para tratar de ganar acceso al equipo en cuestión.

Un ejemplo de este software es THC-Hydra, que como ellos lo definen es un “A very fast network logon cracker which support many diferent services” y que viene incluido dentro de la distribución Backtrack. Entre todos los protocolos que soporta no podía falta SSH.

A continuación veremos qué ocurre si lanzamos un ataque de esta índole a un equipo, en concreto el utilizado para hacer este post, con el fin de saber la respuesta de éste. Como digo bien fruto de un intento de acceso ilegítimo o prueba de Pentest.

Abriremos nuestra máquina con Backtrack y ejecutaremos THC-Hydra pero en su versión gráfica que resulta más amigable. Iremos pues a Backtrack -> Privilege Escalation -> Password Attacks -> Online Attacks -> hydra-gtk

Ahora deberemos configurar la herramienta acorde a nuestras preferencias, es decir:

Seleccionamos el objetivo, 192.168.10.10. Nosotros ya lo sabemos, no obstante, podremos aprovecharnos de otros protocolos mal configurados como CDP, STP, etc. o lanzando un NMAP, ver por nombres de equipo cuál puede ser más distinto que el resto, o bien por los primeros 24 bits de la MAC que identifican al fabricante.

Indicamos los ficheros que contienen tanto el nombre de los usuarios como las contraseñas.

Indicamos la contraseña de “enable” para dispositivos Cisco, en mi caso he puesto “labtest,test,admin”:

 

Y finalmente daría a “Start”:

Si a nuestro equipo no le hubiéramos configurado los siguientes parámetros del post anterior:

ip ssh time-out 15

ip ssh authentication-retries 2

ip ssh source-interface Vlan10

ip ssh logging events

ip ssh version 2

¿Qué pasaría?

Que Hydra comenzará a tratar de conectarse al equipo abriendo conexiones en SSH. Esto implicará un aumento en la carga de CPU ya que deberá repetirse el proceso de establecimiento de conexión de TCP, negociado y cálculo de claves antes de realizar el envío de credenciale (usuario y contraseña), lo cual requiere una carga computacional. Si eso se repite constantemente…. Pues para ver lo que pasa ejecutaremos:

LAB_TEST#show processes cpu history 

Y obtendremos la siguiente gráfica:

Como podemos apreciar la CPU se sube de “vueltas” con esta acción alcanzando porcentajes del 99%. Lógicamente esto puede desembocar en problemas con las comunicaciones con los equipos finales, los usuarios estarían diciendo “Esto va un poco lento”, “La red no funciona”, “le cuesta abrir mucho este archivo”, etc. etc. etc. El problema es que salvo que tengamos otros protocolos, alertas, etc. configurados en el equipo, o monitorizando su actividad no nos enteraríamos ya que no tenemos registro de los intentos de conexión que está queriendo hacer Hydra.  De ahí que si logueamos las conexiones de SSH con:

LAB_TEST(config)#ip ssh logging events 

Y entonces, va a ser un no parar de mensajes en consola, pero por lo menos nos enteramos de la que nos está cayendo…

 

Además, ¡Ya tenemos las IP desde dónde nos están mandando los intentos de conexión!

Otro ejemplo claro sería el comando:

LAB_TEST(config)#ip ssh time-out 15

De esta manera si alguien abriese sucesivas conexiones a nuestro equipo y no introducimos el usuario, el switch se mantendrá esperando 120 segundos. ¿Para qué tanto tiempo? Limitémoslo a 15 que es más que suficiente.

En el caso de la versión, si no especificamos la 2 un usuario podría conectarse en la versión 1 configurando el cliente SSH para ese efecto y  dado que SSHv1 presenta una vulnerabilidad… Pues vamos a intentar no utilizar un protocolo vulnerable, ¿no? De todos modos os dejo la forma en la que podríamos hacerlo.

Y la consiguiente captura…

Pero si configuramos:

 LAB_TEST(config)#ip ssh version 2

Pues nos sale:

Y nuevamente la captura:

Bueno creo que ya ha quedado demostrado lo importante que a pesar de utilizar protocolos que ofrecen garantías de seguridad, cómo debemos ir más allá y “pulir” parámetros mejorar el acceso a nuestros equipos y si algo anómalo pasase pues darnos cuenta de ello. También hay que decir que las opciones expuestas no son las únicas, pero el ejemplo lo que querido hacer sobre un switch normalito cuyo uso tendrá más alcance que uno de la serie 6500 por ejemplo. 

No debemos olvidar que el acceso SSH se realiza por la línea VTY y ésta también tiene otras opciones que reforzarán a las que acabamos de explicar. Entre otras, limitar el número de conexiones concurrentes; reducir el time-out de conexión; aplicar una ACL para que las conexiones se realicen desde equipos concretos como los de los administradores de red; etc, etc.

Espero que hay gustado, os dejo hasta la próxima…

Seguiremos informando.