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

Robo de archivos

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