Seguridad en puerto


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….

3 pensamientos en “Seguridad en puerto

  1. Pingback: Un IDS para mi servidor VPN… « Enredando con redes …

  2. Pingback: Latino » Blog Archive » Un IDS para mi servidor VPN…

  3. Pingback: Defensa en Profundidad, breve repaso… | Enredando con redes ...

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s