Cuando VLANs y Firewalls no son suficientes

Como comentaba en la entrada anterior, hace poco terminé el curso sobre Ciberseguridad en Sistemas de Control y Automatización Industrial impartido por el Instituto Nacional de Ciberseguriad (INCIBE) antes, INTECO.

Dentro de su contenido, en uno de sus módulos se trataba el tema de los incidentes de seguridad sobre dichos sistemas, analizando desde los posibles objetivos potenciales hasta las deficiencias técnicas, pasando por controles de acceso físico pobres o incluso nulos.

Entre esos puntos se apuntaba como orígenes a la red corporativa y a cortafuegos perimetrales mal configurados. En el primero de ellos, se explicaba que tanto los sistemas empresariales como industriales comparten la misma infraestructura de comunicaciones  permitiendo  llevar ataques desde la red corporativa a la de control aprovechando alguna vulnerabilidad en aquéllos. En lo referente a los cortafuegos perimetrales, se comentaban las malas configuraciones sobre ciertos protocolos y también, no considerar el sentido de las conexiones. Como ejemplo se hablaba de una intrusión en los sistemas de control, la ejecución de un “payload” en ellos e iniciar una conexión a un equipo remoto empleando un puerto abierto en el firewall.

Partiendo de la base que ninguna red es igual ya que las necesidades y usos pueden ser bien distintos, en la entrada de hoy voy a hablar de dos aspectos que afectan a las ideas descritas en los apartados anteriores.

Por mi experiencia, es muy común que equipos corporativos convivan con los de control dentro del mismo switch. Por ejemplo, en una cadena de producción tenemos un PC donde  ejecutamos distintas aplicaciones relacionadas con el proceso de fabricación, mientras que en otros puertos tenemos los autómatas que controlan la maquinaria (robots, sensores, válvulas, etc.). También puede ocurrir que existan incluso puntos de acceso inalábricos para aquellos dispositivos no cableados tipo PDAs industriales, lectores de códigos de barras, PCs portátiles de personal de mantenimiento, etc. ¡Y posiblemente todo dentro de la misma VLAN! Resultaría costosísimo, o incluso inviable, implementar dos o tres infraestructuras paralelas para separar físicamente todo el tráfico, así que la realidad es que unos y otros deben “viajar” por el mismo equipo y por la misma red, aunque separados lógicamente mediante el uso deVLANs.

Por otro lado, debemos pensar que a la hora de interconectarlo todo, no se puede implementar cortafuegos por cada enlace, subred, equipo, etc. para regular el tráfico a permitir o denegar. Si bien la inversión, condiciona en gran medida la solución tecnológica a utilizar (salvo que sobre el dinero, que viendo los tiempos que corren es poco probable…), debemos pensar,  en lo a la parte técnica se refiere, que los switches nos pueden ofrecer una serie de ventajas que, a veces, los cortafuegos no lo hacen. Por ejemplo, mayor densidad de puertos y uso de módulos SFP para distintos medios físicos como cable y fibra óptica. También es cierto que los cortafuegos realizan tareas que no hacen los switches. Unos no  son mejores que los otros, sino que cada cual hace su papel y se complementan.

A estas ideas debemos sumar también la implantación de medidas que garanticen una alta disponibilidad de los servicios prestados, con lo que aparte de equipos de comunicaciones, de seguridad, control, automatización, etc. debemos disponerlo todo de tal manera que en caso de producirse un fallo, la red pueda seguir funcionando sin que esto suponga un impacto en la calidad del servicio ofrecido.

Como bien dice el refrán “Una imagen vale más que mil palabras”  he creado un escenario para tratar de entender mejor lo dicho. He utilizado la aplicación de Cisco Systems, Packettracer, utilizada para la preparación de las certificaciones CCNA y CCNP, entre otras.

Basándome en los criterios de este post, aquí os dejo la topología:

Topología

Topología

Para explicarlo empezaremos de izquierda a derecha.

Tenemos el equipo “Switch Acceso” (Switch L2) al que se conectan por un lado los autómatas PLC-01 y PLC-02, y por otro un PC que pueda ser utilizado para la ejecución de aplicaciones relacionadas con la actividad industrial. También se ha incluido una impresora, como un elemento de red más que pueda ser utilizado para la impresión de algunos documentos, órdenes de montaje, códigos de barras para temas logísticos, etc.

Para segmentar el tráfico, los PLCs,  el PC y la impresora se han situado en VLANs distintas. PLC-01 y PLC-02 en la VLAN 10 con direccionamiento 192.168.10.0 /24; y PC-01 y Printer0 en la VLAN 20, y red 192.168.20.0/24. Como puerta de enlace será la primera IP de ambas redes, la .1.

Dado que es un entorno de alta disponibilidad, se ha configurado en los switches “sw-core-01” y “sw-core-02” (Ambos multicapa o L3) interfaces virtuales para cada una de las VLANs, y en ellas, el protocolo HSRP, aunque también hubiera servido VRRP. Si no sabéis o queréis refrescar los conceptos de interfaces virtuales o dejo un link a un artículo que publiqué hace un tiempo, aquí.

Luego tenemos los cortafuegos, que filtrarán el tráfico entre la red de servidores donde se sitúa el servidor de SCADA, Historiadores, etc y el resto. Esta red tiene un direccionamiento 192.168.254.0/24, y está en la VLAN 254. También está configurado HSRP.

No he dibujado la red corporativa como oficinas ya que no viene por ahí el problema de seguridad que quiero explicar, pero de existir, deberían colgar de cada uno de los nodos del firewall, como lo están las dibujadas.

Como podréis ver los cortafuegos tiene un enlace entre sí. Todo tiene una explicación.

Al igual que en los equipos de red tenemos HSRP, VRRP y GLBP para implementar alta disponibilidad, los cortafuegos tienen los suyos también. Lo que se hace es una topología tipo “Activo-Pasivo” o “Activo-Activo”. La primera de ellas, sería equiparable al comportamiento de HSRP y VRRP, donde uno de los nodos soporta todo el tráfico, el “Master”, mientras que el otro está de respaldo, el “Backup”. En caso de que el “Master” falle, el “Backup” entra en funcionamiento. El modo “Activo-Activo” es aquél en el que ambos nodos funcionan a la par, proporcionando no sólo una alta disponibilidad, ya que si uno falla el otro asume su rol, sino que además existe un balanceo de carga ya que se puede repartir el tráfico entre ambos.

En cualquiera de los dos casos, ambos nodos deben tener un enlace donde compartir una tabla con las conexiones que tiene abiertas, ya que si el nodo “Master” falla, el de “Backup” debe seguir permitiéndolas. Si no existiese este enlace y el nodo de “Backup” no tuviese dicha tabla, cuando uno de los equipos finales volviesen a generar tráfico de una sesión ya establecida, las cortarían.

Por no estar hablando siempre de Cisco, Juniper tiene su protocolo NSRP. Os dejo algunos enlaces pero si buscáis en por ahí  encontraréis un montón de información al respecto.

 Link 1

Link 2

Link 3

Fortinet también tiene soluciones similares. Os dejo más links:

Link 1

Link 2

Link 3

Vale, tenemos el PC y la impresora en una VLAN; y los PLCs en otra de tal manera que a nivel de capa 2 los tenemos “aislados” y cada uno en su propio dominio de broadcast. Mismo criterio con los servidores. Sin embargo, los equipos PLC no están todo lo protegidos que debieran.

¿Por qué? Porque si nos fijamos el PC-01 a pesar de estar en una VLAN distinta de los PLCs puede llegar a ellos sin problemas. Vamos a abrir un navegador del PC-01 y la IP del PLC-01.

Configuración Autómata

Configuración Autómata

¿Por qué? Sencillo. Cuando abrimos el navegador el tráfico llega al switch sw-core-01. Como éste tiene acceso a la VLAN donde está la dirección IP de destino, la 192.168.10.100, es el propio switch el que lo envía por la interfaz de la VLAN 10 ya que están ambas en el mismo equipo. La 10 y la 20.  Podríamos cambiar manualmente el enrutamiento para que fuese todo al tráfico hacia el firewall y éste lo descartase, pero tampoco tiene mucho sentido hacerlo “subir” hasta ahí para luego descartarlo  y ocupar un ancho de banda por poco que sea, nos puede resultar necesario, especialmente a los PLC en su comunicación con el servidor SCADA.

 Por tanto, hay una cosa que es clara y es que tenemos que filtrar el tráfico para evitar que ningún equipo de la red 192.168.20.0/24 pueda llegar a la 192.168.10.0/24. Sin embargo, sí que tenemos que permitir el tráfico desde la red 192.168.20.0/24 a cualquier otro equipo de la red.

Así que, ¿qué alternativa tenemos? La alternativa son las ACL, Access List. Pero esto lo dejamos para la siguiente entrada.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Otros modelos…

Para que nuestra red “funcione” y se comporte de la manera que necesitemos, no sólo tendremos que configurar e interconectar los equipos de la manera que más se ajuste a nuestros requerimientos, sino hacerlo siguiendo el mejor modelo. Cada organización, empresa o cualquiera que tenga una infraestructura de comunicaciones tendrá los suyos propios, con lo que establecer un patrón genérico puede a veces no ser lo más idóneo.

Por ejemplo, muchos de nosotros se nos ha enseñado la idea de que una red está compuesta por 3 capas, “Acceso”, “Distribución” y “Core”. Obviamente debe existir una jerarquía  y una segmentación de las funciones pero, no siempre puede darse esta estructura. Os dejo un par de imágenes que representan esta idea:

221701

Routedlinks

Como digo, todas las organizaciones pueden no necesitarlo, y es más, con los tiempos que corren los recursos económicos no son los suficientes como para invertir en tanto equipo. Por eso, puede darse el caso como el que os traigo.

Lo que vamos a  hacer, es unir tanto la capa de “Core” como la de “Distribución”, con switches de Capa 3 y definiendo interfaces virtuales. Os dejo en enlace donde podréis ver un artículo donde hablaba de ello, pincha aquí.

¿Por qué esto? Bueno puede haber distintos motivos. El primero de ellos es que directamente no sea necesario; otro que al eliminar una de las capas, eliminamos los equipos que están en ella, y por tanto es menos dinero a invertir. Otra es que los equipos de hoy en día traen consigo muchas funcionalidades (Protocolos, configuraciones, medidas de seguridad, etc.) y capacidades (velocidad de conmutación,  densidad de puertos, etc.) comunes a ambas capas y por tanto no hacen necesario segmentarlo de esta manera. Sin embargo no todos son ventajas, y deberemos por tanto ser cuidadosos a la hora de diseñar la red. Es decir, si suprimimos una capa, podremos penalizar la escalabilidad.  Como todo, antes de hacer nada deberemos pensar muy bien lo que hacemos y analizar todas las necesidades de deba cumplir, a corto y medio plazo, nuestra infraestructura y los requerimientos que debamos ponerle a nuestros equipos.

Así pues a continuación ilustro este concepto de “unión”.

Topologia_01

Como podemos ver, se colapsan las dos capara de “Core” y “Distribución”. Es un entorno que ofrece redundancia entre los equipos de acceso situados en la parte inferior de la imagen y los servidores en la superior. Tras haber evaluado las características de los equipos, éstos soportan protocolos de alta disponibilidad como HSRP, VRRP, STP, etc; también disponemos de enlaces redundantes tanto desde los switches de acceso, sw-of-01, así como como entre switches de Core/Distribución que nos proporciona una tolerancia ante fallos. Contando de que éstos tengan puertos a 1 Gbps podremos agregar enlaces (Etherchannel) para vencer posibles cuellos de botella al conectar más switches de acceso; también podremos implementar “Listas de Control de Acceso” (ACLs); y como no, al ser equipos de L3 configurar algún protocolo de enrutamiento (OSPF, EIGRP) o enrutado manual (ip route XXX.XXX.XXX.XXX ….) para el envío de pquetes.

Lo que se trata de hacer ver es que podremos llevar a cabo otras topologías, al margen claro está, de que los modelos “genéricos” no sean la mejor opción para posibles implementaciones a las que tengamos que hacer frente. Eso deberemos conocer y tener en cuenta todas las funcionalidades que los equipos y tecnologías nos ofrecen, sus costes y alternativas de fabricantes.

 Nos vemos en la próxima!!!

Protegiendo STP, Parte II

Seguimos con STP. En esta ocasión vamos a ver algunos comandos sobre STP que nos van permitir evitar posibles ataques a este protocolo y que vimos en la “Parte I”.La primera de ella es proteger el switch que va a ejercer como “Root Bridge”. Esto es, si le llegase una BPDU con indicando que existe otro switch con una prioridad menor (bien porque se conecta uno o porque se generan mediante un software como Yersinia) no la considere, lo descarte. Se aplica sobre la interfaz que lo une a otros switches. En nuestro ejemplo se aplicaría sobre la Fa 1/0 en el “SW-CORE-01”.

SW-CORE-01(config-if)# spanning-tree guard root 

Otra de las configuraciones a realizar es activar la opción “BPDU Guard”. Este parámetro configurado en los puertos de los switches de acceso provocará que el puerto se deshabilite al recibir una BPDU. A diferencia del anterior, este comando habría que ejecutarlo en los switches de acceso, sonde se conectan los equipos finales ya que en caso de añadir un switch legítimo podrían no detectarse los bucles en la red y por tanto STP no ser efectivo

SW-OFICINAS-01(config-if) # spanning-tree bpduguard enable 

Igualmente, podríamos conseguir que el switch no envíe BPDUs sobre puertos donde tengamos un equipo final, ya que estamos seguros de que no es necesario enviar información de STP. ¿Para qué mandar información que no es necesaria?

SW-OFICINAS-01(config-if) # spanning-tree bpdufilter enable 

STP nos ofrece otras muchas configuraciones también de utilidad. Quizás no tanto con la seguirdad pero só con la funcionalidad. Por ejemplo, podríamos ser capaces de que un switch sea el “Root Bridge” y otro sea un “Backup” de éste. En el nuestro esto sería:

SW-CORE-01(config) # spannig-tree vlan 10 root primary

SW-CORE-02(config) # spannig-tree vlan 10 root secondary

¿Qué quiere decir esto? Para VLAN 10, el switch “SW-CORE-01” el será el root bridge. Si éste cae, el “SW-CORE-02” será el “Root Bridge”. ¿Cómo se consigue esto? Ambos switches modificarán sus prioridades para que el “SW-CORE-01” sea el primario y el “SW-CORE-02” el “Backup” en un funcionamiento normal.

Existen más comandos que permiten modificar y optimizar los valores que STP tiene por defecto, pero no entraremos en ellos ya no es el objetivo de esta entrada. Por ahora lo dejamos así.

Un saludo, seguiremos informando…

Protegiendo STP, Parte I

Spanning Tree Protocol (STP) es un protocolo que permite dotar a nuestra red de un entorno  de tolerancia ante fallos mediante la creación de enlaces redundantes. Estos enlaces generarán bucles en la red, lo cual  introduce serios problemas a nuestra infraestructura. Dada la ausencia de un campo como el TTL en las cabeceras del protocolo IP, que se decrementa en “1” por cada dispositivo de capa 3 por el que pasa; en una trama, unidad de capa 2, no hay nada similar con lo las tramas pueden circular indefinidamente en nuestra red. Esto es especialmente dañino en el caso de tramas Broadcast pudiendo afectar también el Unicast,  provocando una ralentización de la red tanto por el consumo de ancho de banda de los enlaces como de CPU de los switches.

No me voy a detener en explicar cómo funciona dicho protocolo, para eso os dejo algunos enlaces cuyos autores lo hacen muy bien:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5

A partir de este protocolo han ido surgiendo otros como RSTP, PVSTP+, PVRSTP y MST que basándose en la idea original han ido evolucionando y aportando mejoras.

Lo cierto es que este protocolo no está exento de problemas. Me explico, como todo protocolo es fácil “ponerlo en marcha”, pero desde el punto de vista de la seguridad y de la topología de nuestra red debiéramos añadir algunas configuraciones adicionales para no llevarnos “sustos”.

Pongamos un ejemplo. Dada la siguiente topología, tenemos el switch “SW-CORE-01” como el switch con “menos” prioridad, 8192. Luego el “SW-CORE_02”, con 32768. Finalmente el “SW-OFICINAS-01”, con 65535. Esto quiere decir que inicialmente todo el tráfico a nivel 2, generado por los equipos conectados a “SW-OFICINAS-01” irá hacia el “SW-CORE-01” por la interfaz Fa 1/14. Si este enlace se rompiese por alguna razón, el “SW-OFICINAS-01” levantará el enlace que tiene bloqueado, el Fa 1/15 que lo une con “SW-CORE-02” y comenzará a enviar las tramas hacia él.

Captura_01

La configuración de los tres equipos quedaría así: 

sw-core-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

This bridge is the root

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    8192

Address     c200.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD     0  8192 c200.0480.0000 128.41

FastEthernet1/15     128.56   128    19 FWD     0  8192 c200.0480.0000 128.56

SW-CORE-02#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

Cost        19

Port        56 (FastEthernet1/15)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32768

Address     c201.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD    19 32768 c201.0480.0000 128.41

FastEthernet1/15     128.56   128    19 FWD     0  8192 c200.0480.0000 128.56

SW-OFICINAS-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    8192

Address     c200.0480.0000

Cost        19

Port        55 (FastEthernet1/14)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    65535

Address     c202.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.41

FastEthernet1/14     128.55   128    19 FWD     0  8192 c200.0480.0000 128.41

FastEthernet1/15     128.56   128    19 BLK    19 32768 c201.0480.0000 128.41

A todo esto tenemos un atacante en conectado a interfaz FA 1/0 del “SW-OFICINAS-01”.

Pero… ¿qué podría hacer nuestro atacante? Bueno si tenemos el switch de acceso “SW-OFICINAS-01” configurado sin más parámetros referentes a STP, pueeeesssss bastante daño…

Mediante la aplicación Yersinia, de la cual ya he hablado en otros posts,  podríamos lanzar un ataque enviando BPDUs especialmente diseñadas y provocar que la red se desestabilice. ¿Cómo? Ahí vamos…

Correremos la aplicación en modo daemon_

root@bt:~# yersinia –D

Luego abrimos un teleet contra la interfaz loopback. Las credenciales son root, root.

root@bt:~# telnet 127.0.0.1 12000

Trying 127.0.0.1…

Connected to 127.0.0.1.

Escape character is ‘^]’.

Welcome to yersinia version 0.7.1.

Copyright 2004-2005 Slay & Tomac.

login: root

password: root 

MOTD: Do you have a Lexicon LX-7? Share it!! 😉

Entramos como super usuario. La contraseña es tomac

yersinia> enable

Password:

Definimos la interfaz por donde lanzaremos el ataque:

yersinia# set stp interface eth0

De los distintos ataques que tenemos lanzaremos el número 2. Lo que haremos será mandar BPDUs de configuración indicando que el PC del atacante tiene una prioridad “0” para el protocolo STP. Esto provocará que los otros equipos al recibir esta BPDU, verán que existe “otro switch” con una prioridad menor que los otros y por lo tanto el supuesto switch deberá ser el “root bridge” y no el “SW-CORE-01”.

yersinia# run stp

<0>   NONDOS attack sending conf BPDU

<1>   NONDOS attack sending tcn BPDU

<2>   DOS attack sending conf BPDUs

<3>   DOS attack sending tcn BPDUs

<4>   NONDOS attack Claiming Root Role

<5>   NONDOS attack Claiming Other Role

<6>   DOS attack Claiming Root Role with MiTM

<cr>

yersinia# run stp 2

Ahora si verificamos la configuración de STP en cada uno de los switches nos queda:

sw-core-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     32d6.7e27.7660

Cost        38

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    8192

Address     c200.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.55

FastEthernet1/15     128.56   128    19 FWD    38  8192 c200.0480.0000 128.56

SW-CORE-02#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     1f33.e802.aab3

Cost        38

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32768

Address     c201.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD    19 65535 c202.0480.0000 128.56

FastEthernet1/15     128.56   128    19 BLK    38  8192 c200.0480.0000 128.56

SW-OFICINAS-01#show spanning-tree vlan 10 brief

VLAN10

Spanning tree enabled protocol ieee

Root ID    Priority    0

Address     1330.452b.42d1

Cost        19

Port        41 (FastEthernet1/0)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    65535

Address     c202.0480.0000

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Aging Time 300

Interface                                   Designated

Name                 Port ID Prio Cost  Sts Cost  Bridge ID            Port ID


FastEthernet1/0      128.41   128    19 FWD     0 23630 1330.452b.42d1 128.2

FastEthernet1/14     128.55   128    19 FWD    19 65535 c202.0480.0000 128.55

FastEthernet1/15     128.56   128    19 FWD    19 65535 c202.0480.0000 128.56

Como podemos comprobar para el “SW-OFICINAS-01” el switch “root bridge” se alcanza por el puerto Fa 1/0 que es donde está conectado el supuesto atacante. Ahora en este switch el puerto Fa1/15 en lugar de estar en modo “BLOCK” está en “Forward”. Por otro lado ahora el que está en modo “Blocked” es el Fa 1/15 del “SW-CORE-02”.

Si analizamos con Wireshark el tráfico vemos como las BPDUs indican un cambio de topología, “Topology Change = 1”. También podemos ver que la dirección MAC es distinta en todos los casos, eso es porque Yersinia manda las distintas Tramas con MAC de origen aleatoria.

Screenshot

¿Cómo evitar todo esto? Eso es el tema de la siguiente entrada….

Seguiremos informando…

Mejorando acceso por SSH (Parte II)

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

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.

Target

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

passwords

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

 Specific

Y finalmente daría a “Start”:

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:

cpu_history

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…

 intentos_conexion

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.

sshv1

Y la consiguiente captura…

captura_sshv1

Pero si configuramos:

 LAB_TEST(config)#ip ssh version 2

Pues nos sale:

error_sshv1

Y nuevamente la captura:

error_sshv1_wrshrk

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.