Este método no pone la interfaz de red en modo promiscuo. Esto no es necesario porque los paquetes son para nosotros y el switch enrutará los paquetes hacia nosotros. Vamos a ver como es esto posible.
El método consiste en “envenenar” la cache arp de las dos máquinas que queremos sniffear. Una vez que las caches estén envenenadas, los dos hosts comenzarán la comunicación, pero los paquetes serán para nosotros, los sniffearemos y los enrutaremos de nuevo al host apropiado. De esta forma la comunicación es transparente para los dos hosts. L a única forma de descubrir que existe “a man in the middle” en nuestra conexión sería ver la cache arp de nuestra máquina y comprobar si existen dos maquinas con la misma dirección MAC. El esquema de la comunicación es sencillo:
Desde nuestra máquina enviaremos paquetes de tipo arp-reply falsos a las dos host que queremos sniffear. En estos reply’s debemos de decirle al host 1 que la dirección ethernet del segundo host es la nuestra, quedando esta información almacenada en su cache arp. Este equipo enviará ahora los paquetes al host 2 pero con nuestra dirección MAC. Los paquetes ya son nuestros. El switch se encargará de hacernos llegar los datos. Imaginemos la siguiente situación:
Enviamos un flujo constante de arp-reply (para evitar que la cache arp de las maquinas se refresque con la información verdadera) al host 1 y host 2 con los siguientes datos:
HOST 1 : arp-reply informando que 192.168.0.2 tiene dirección MAC 03:03:03:03:03:03
HOST 2 : arp-reply informando que 192.168.0.1 tiene dirección MAC 03:03:03:03:03:03
De esta forma estamos “envenenando” las cache arp. A partir de ahora lo paquetes que se envíen entre ambas nos llegarán a nosotros, pero para que ambos hosts no noten nada extraño, deberemos de hacer llegar los paquetes a su destino final. Para ello deberemos de tratar los paquetes que recibamos en función del host de origen:
Paquetes procedentes de HOST 1 -----------------> reenviar a 02:02:02:02:02:02
Paquetes procedentes de HOST 2 -----------------> reenviar a 01:01:01:01:01:01
De esta forma la comunicación entre ambos no se ve interrumpida, y podemos “ver” todo el tráfico entre ellos. Solo tendremos que utilizar un sniffer para poder capturar y filtrar el tráfico entre amos, ya sea login/passwd de telnet, ftp, POP3,..., o incluso la sesión completa. Eso ya depende de la habilidad y el interés de cada cual.
Como podes comprobar el proceso no es complicado, pero ¿que utilidades tenemos disponibles para poder enviar los paquetes arp falsificados?
Existen varios programas para “juguetear” con el arp-spoofing: Arptool, Arp-Fun, ettercap. Este último esta muy completo, ya que permite varios tipos de sniffeo: Por IP, MAC y Arp-Spoofing. Pudiendo ejecutarse bien en modo comando, o mediante un entorno de ventanas. En este entorno se nos mostrará al inicio un listado de los hosts encontrados en la LAN. Para realizar esta búsqueda, el programa envía un ARP-REQUEST de las IP teniendo en cuenta la IP del host donde se está ejecutando y la máscara de red. Obteniendo a continuación los ARP-REPLYs podremos componer la lista de los hosts presentes en la red. Hay que tener mucho cuidado con la máscara de red que usemos, porque si es de clase B (255.255.0.0) el programa realizará 255*255=65025 ARP-REQUEST, lo cual le llevará su tiempo ya que el retardo entre cada petición es de 1 milisegundo.
Hasta aquí hemos visto la forma en la que se pueden utilizar las vulnerabilidades del protocolo ARP para poder espiar en nuestra red. Pero las posibilidades son múltiples: ataques DoS (Denegación de servicio), si “envenenamos” la cache arp de una máquina haciéndonos pasar por el gateway de la red, toda comunicación con el exterior pasará por nosotros. Si desechamos los paquetes procedentes de este host y no los reenviamos al gateway, el host no podrá comunicarse con el exterior. Algunos switches pueden ser manipulados mediante paquetes ARP para que en vez de actuar en modo “bridging” lo hagan en modo “repetición”. Es decir, que en vez de enviar los paquetes por la “boca o puerto” adecuado del switch, los enviará por todos, a todas las máquinas les llegarán todo los paquetes de la red. Esto se consigue inundando la tabla de direcciones con gran cantidad de direcciones MAC falsas. El switch al recibir un paquete cuya dirección MAC de destino no tenga en su cache, lo enviará a todos los equipos, esperando la respuesta del equipo para poder almacenar su MAC en la cache. Pero como estamos “bombardeándola” con direcciones MAC falsas, esto no ocurrirá.
ARP-SPOOFING y servidores redundantes
El ARP-SPOOFING no solo sirve como herramienta para espiar en una red o realizar ataques DoS. También se puede utilizar para crear servidores redundantes, servidores con tolerancia fallos. La idea consiste en crear un servidor auxiliar que tome la identidad del servidor que ha dejado de funcionar. Para ello haremos uso de IP alias y de ARP-SPOOFING. Es una solución rápida y no muy ortodoxa, pero nos puede ser útil si nuestro presupuesto no es muy elevado.
En muchas ocasiones es vital la redundancia en un determinado servicio: HTTP, FTP, SMTP, POP... . Los equipos que nos permiten la redundancia en un servicio suelen ser bastante caros, por lo que este método nos puede solucionar el problema. La situación es la siguiente:
Tenemos un servidor principal con dos interfaces de red (la segunda nos permitirá acceder al servidor cuando el backup esté funcionando) y un servidor de backup también con dos tarjetas de red (o bien puede utilizarse una sola en el redundante y emplear IP Alias para poder disponer de dos direcciones IP).
El servidor de backup debe de configurarse de forma que cuando se active (porque el principal ha sufrido algún problema y deja de funcionar) configure su tarjeta de red con la IP del servidor principal que debe de sustituir (bien configurando la única tarjeta con IP Alias o configurando una segunda tarjeta). A continuación el servidor de backup utilizará ARP SPOOFING para asegurarse de que recibe todos los paquetes destinados al servidor que el está sustituyendo. Los paquetes ARP que se enviarán informarán de que la dirección MAC correspondiente a la IP del servidor principal es ahora la MAC del servidor de backup. Este envío debe de producirse de manera continua, mientras dure la caída del principal, evitando así que las cache arp se refresquen con la dirección MAC verdadera del servidor principal. Si la cache arp expirase y se actualizase con la MAC verdadera del servidor principal, se produciría un “race condition”, si el servidor de backup responde al ARP REQUEST con su ARP REPLY antes que el servidor principal, el ARP REPLY del backup se “machacará” con el del principal. Mientras que si es al contrario, será el ARP REPLY del principal el que será sustituido por el del servidor de backup. Esto no debe de llegar a producirse, ya que sino el proceso de redundancia sería inútil.
La activación del servidor de backup deberá de producirse de forma automática, ya que estos problemas suelen producirse de madrugada (no siempre claro) y no serviría de nada que fuésemos nosotros los que tuviésemos que activarlo manualmente.
Utilizar un servidor de NFS para ambos equipos sería lo más conveniente, ya que de esta forma podremos acceder a los mismos contenidos desde ambos servidores, una solución interesante para servicios como HTTP, POP3, FTP...