Resumen—La suplantación de dirección MAC mediante el ARP spoofing es una gran preocupación para la comunidad en general. Se plantea una herramienta para ilustrar esta debilidad, Arpoison y se concluye que es necesario encontrar mecanismos para evitar la alteración de las tablas ARP con base en los sistemas operativos.

Palabras claves—ARP, spoofing suplantación, MAC, man-in-the-middle, Arpoison.

I. INTRODUCCIÓN

ara entender todos los aspectos de este documento es necesario tener al menos un conocimiento general del

protocolo ARP, se hará entonces una explicación general del funcionamiento de ARP para ver sus susceptibilidades y entender la teoría de los ataques más comunes en este nivel.

P

En una red que sólo tuviera el nivel Físico del modelo OSI, los dispositivos sólo se conocerían entre sí por medio de su dirección física y dicha dirección tiene que ser única para evitar errores de envío. Pero como los protocolos de alto nivel direccionan las máquinas con direcciones simbólicas (como en IP) tiene que existir un medio para relacionar las direcciones físicas con las simbólicas, un traductor o manejador de direcciones [4]. Así tenemos la aparición de un modulo ARP que, dándole una dirección IP, retornará una dirección física. El protocolo ARP se encuentra en el nivel de enlace del modelo OSI, y dicho nivel se encarga de identificar la conexión física de una máquina para lo cual se usan las direcciones físicas de cada dispositivo que son únicas, aunque como se explicará más adelante, pueden ser alteradas permitiendo suplantaciones en las comunicaciones [3].

Manuscrito aplicado el 9 de Septiembre , 2003. Este trabajo fue realizado gracias al apoyo financiero e incondicional de nuestros respectivos padres.

G.A. Pulido es ingeniero mecánico de la Universidad de los Andes, ingeniero de sistemas certificado por Microsoft y cursa actualmente 9o semestre de Ing. de Sistemas, en la Universidad de los Andes, teléfono: 3394949 e-mail: g-pulido@ uniandes.edu.co.

M. Niño es candidato a título de biologo de la Universidad de los Andes, y cursa actualmente 11o semestre de Ing. de Sistemas, en la Universidad de los Andes teléfono: 3394949 e-mail: marc-nin@uniandes.edu.co.

D. Lizarazo cursa actualmente 10o semestre de Ing. de Sistemas, en la Universidad de los Andes teléfono: 3394949 e-mail: d-lizara@uniandes.edu.co.

L. Varela cursa actualmente 10o semestre de Ing. de Sistemas, en la Universidad de los Andes teléfono: 3394949 e-mail: l-varela@uniandes.edu.co.

G. Peñuela cursa actualmente 10o semestre de Ing. de Sistemas, en la Universidad de los Andes teléfono: 3394949 e-mail: go-penue@uniandes.edu.co.

También se debe anotar el uso de una tabla (o caché) para mantener las últimas direcciones usadas por el computador, esta tabla es actualizada a ciertos intervalos de tiempo que dependen del sistema operativo, o cuando la dirección requerida no se encuentra en la tabla, en este caso se envía un “broadcast” 3 en la red con un formato de ARP request1, que básicamente pregunta a todas las máquinas en el segmento si su IP corresponde a la especificada en la petición. La máquina que concuerda debe responder con un ARP reply2 al computador que hizo la solicitud. [1] Dicha respuesta incluirá la dirección física del hardware e información sobre el enrutamiento (esto si el paquete ha pasado por diferentes máquinas entre el origen y el destino), esta dirección y la ruta son almacenadas en la caché del host solicitante. De allí en adelante todos los paquetes enviados a la IP se asocian con la dirección física que aparece en el caché [5, 9].

ARP fue diseñado para ser usado en redes que soporten broadcast4 y debe estar muy relacionado con el manejador del dispositivo de red, por lo que en las especificaciones de ARP no se habla de su implantación, sólo se habla de las funciones esperadas del protocolo [7,9].

Cuando una aplicación quiere enviar datos a una dirección IP destino el mecanismo de enrutamiento determina cuál es la dirección IP del siguiente salto, que puede ser el destino u otro punto intermedio, en este punto el módulo ARP debe revisar la tabla en búsqueda de la pareja dirección IP / dirección MAC requerida. En caso de encontrarlo retorna la dirección MAC correspondiente (de tamaño 8 bytes), en caso contrario genera un broadcast con un ARP request [1].

La forma en que reacciona una máquina cuando recibe un paquete ARP se describe en diagrama de flujo del anexo 1.

Si se analiza la descripción hecha del funcionamiento de ARP, se puede ver que el protocolo tiene comportamientos que pueden ser explotados por personas con suficiente conocimiento del mismo. Por ejemplo, cuando se hace broadcast se abre la posibilidad de que alguna máquina con

3

1 ARP Requests: Es un requerimiento para la dirección hardware de destino. Es típicamente enviado a todos los host.

2 ARP Reply: En respuesta al requerimiento esta indica al host la dirección hardware del destino host

43 Broadcast: Divulgación o difusión de un mensaje a todos los miembros de una red

G. A. Pulido; M. Niño; D. Lizarazo; G. Peñuela; L. Varela. Universidad de los Andes.

Principios Básicos de ARP Spoofing: Arpoison, un primer paso para la incomunicación del

servicio.

1

tarjeta de red en modo promiscuo5 capte paquetes que están dirigidos a otras máquinas, o que se envíen paquetes ARP mal formados (que se explicará más adelante) que el protocolo no comprueba, o también se puede aprovechar el hecho de que el protocolo recibe paquetes incluso si la máquina no los necesita, con lo que se refresca la tabla con los nuevos datos recibidos, y estos datos pueden ser erróneos o alterados a propósito.

Debido a las falencias descritas anteriormente del protocolo ARP, si se altera un paquete usado en la comunicación entre dos máquinas se podría suplantar la dirección MAC de una de ellas, realizando el ataque conocido como “Man in the Middle” [6,2,4] o se podría dejar a una de las máquinas por fuera de la “conversación” ya que el otro computador tendría una dirección errada a la cual enviar todos los paquetes y éstos nunca llegarían a su verdadero destino.A continuación se explicará un escenario en el cual se podrá analizar porqué no se pueden interceptar los paquetes en un segmento basado en un switch [5].

En primer lugar hay tres hosts, el host 1 tiene como sistema operativo Unix, con un demonio6 FTP; el host 2 es la estación de trabajo del administrador de la red y el host 3 es su computador. Estos host están conectados a través de un switch de nivel 27 como lo muestra la siguiente tabla.

Hosts Puerto(en el switch)

MAC IP

Host 1 Puerto 1 ABCDEF000001 169.254.0.1Host 2 Puerto 2 ABCDEF000002 169.254.0.2Host 3 Puerto 3 ABCDEF000003 169.254.0.3

En este caso vamos a suponer que el kernel del host (núcleo del sistema operativo del servidor) 2 está construyendo un paquete y el destino será el host 1, éste se verá así:

Encabezado TCPEncabezado IPEncabezado 802.3 Datagrama

Protocolo

Ip origen

IP destino

MAC origen MAC destino

Enc. TCP

X X X X

Enc. IP

169.254.0.2

169.254.0.1

X X

Enc. 802.3

X X ABCDEF000002 ABCDEF000001

Datagrama

X X X X

Cuando el switch se inicia, construye una tabla de direcciones MAC de todos los Hosts que están conectados a éste. Cada vez que se envían ARP requests sobre la red la

5 Promiscuo: Está escuchando todo el tráfico que pasa por la red a la cual está conectado

6 Demonio FTP: Programa que se dedica a escuchar peticiones ftp de la red.

7 La expresión "nivel 2" referencia a la capa de enlace de datos del modelo OSI (Open System Interconnection.)

tabla se reconstruye, lo mismo sucede cuando se envían los ARP reply.

Cuando el switch recibe un paquete, éste sólo leerá el encabezado 802.3 o el Ethernet, como ya se especificó que ocurre en un switch de nivel 2. Así la dirección MAC de destino se comparará con la tabla local de ARP encontrando la dirección buscada. Suponiendo que el destinatario IP es 169.254.0.1, la fuente IP es 169.254.0.2 y tanto el destinatario como la fuente MAC son ABCDEF000001 y ABCDEF000002 respectivamente, entonces el host detrás del puerto 1 es el destino y el switch envía el paquete al host 1.

El paquete no pasará sobre la interfaz de red en el host 3. Así se deduce porqué un sniffer no sería de mucha utilidad, ya que, aunque su aparato de red este en modo promiscuo, éste no podrá interceptar paquetes destinados para su vecino.

Continuando con el ejemplo, se pretende enmascarar múltiples direcciones MAC en el puerto 3 del switch, para este caso se busca enmascarar una dirección MAC extra en dicho puerto. Entonces la tabla MAC del host "detrás" del puerto 3 se vería así: ABCDEF000003 & ABCDEF000001para que cuando el host 2 envíe un paquete al host 1, el switch encuentre dos ocurrencias de la dirección MAC destino, logrando el cometido de recibir al igual que el host 1 el paquete destinado únicamente a este último [5].

Esto parece muy fácil, pero tiene muchas complicaciones, una de ellas es que algunos switches se actualizan cada 30 segundos de la manera indicada antes, enviando ARP requests a todos los hosts que están físicamente conectados a éste, en otros casos sucede que no se permite asignar más de una dirección MAC a cada puerto, esto con la desventaja del precio que piden por ellos [5], como pasa en los switches de 3COM8.

II.METODOLOGÍA

A. Materiales.

• Máquina 1neptune.localdomain.local (atacante)Pentium 4 2.4GHz512MB RAM80GB DiscoMandrake Linux 9.1Tarjeta de red 100Mbit/s

• Máquina 2.pluto.localdomain.local (víctima)486 20MHz20MB RAM348MB DiscoWindows 95

87 Empresa proveedora de hardware para redes, http://www.3com.com

2

Tarjeta de red 10Mbit/s.

• Máquina 3.mercury.localdomain.local (servidor)Pentium 133MHz32MB RAM9GB DiscoSolaris 8Tarjeta de red 10Mbit/s

B. Preparación del Ataque.

Primero, aprendemos a utilizarPreparación del Ataque.Primero, a partir de una investigación exhaustiva se encontró que lo adecuado para el ataque que se deseaba simular era una herramienta llamada arpoison [2], la cual permite generar paquetes ARP utilizando los parámetros que se deseen. Sin embargo, no permite manipular otro tipo de paquetes. Luego, se procedió a obtener la herramienta.

Arpoison: http: //arpoison.sourceforge.net/

Y este software, a su vez, depende de una herramienta llamada libnet para su correcto funcionamiento.

Libnet: http://www.packetfactory.net/libnet/

Luego, se procedió a compilar el código fuente de la herramienta. Para esto se ejecutan los siguientes comandos9.

# Copiar los archivos que se bajaron a un directorio temporal:cp arpoison-0.6.tar.gz /tempcp libnet.tar.gz /temp

# Descomprimir los archivos que se bajaron, al directorio temporal:tar -zxvf libnet.tar.gztar -zxvf arpoison-0.6.tar.gz

# Cambiar al directorio de libnet:cd Libnet-latest

# Compilar e instalar libnet:./configuremakemake install (se debe tener permisos de root [8])

# Cambiar al directorio de arpoison:cd ../arpoison

# Preparar arpoison para compilar:# Hay que editar el archivo Makefile de arpoison y agregar la ruta completa al archivo libnet-config en # este archivo. En nuestro caso, la ruta será “/temp/Libnet-latest/” la cual debe ser colocada antes de cada # ocurrencia de libnet-config. Luego, se guarda el archivo con estos cambios.

#Compilar e instalar arpoison:

9 Sólo se muestra el comando, no se muestra la salida de los mismos, ya que es bastante extensa, e irrelevante para el propósito de este texto.

makecp arpoison /usr/local/bin

Ahora, ya se debe tener una instalación completa de arpoison. Para probarlo, se ingresa el comando arpoison y se da ENTER.Debe aparecer lo siguiente:

[root@neptune root]# arpoisonUsage: -i <device> -d <dest IP> -s <src IP> -t <target MAC> -r <src MAC> [-a] [-w time between packets] [-n number to send][root@neptune root]#

Ya tenemos lista y funcionando la herramienta con que se va a realizar el ataque. Sólo necesitamos la información necesaria para llevarlo a cabo, lo cual es simple de obtener en este caso.

I. RESULTADOS

Primero, se determina la dirección MAC de la máquina que se quiere atacar, para esto podemos hacer ping a ésta, y luego utilizar el comando arp -a para ver la dirección MAC:

[root@neptune root]# ping 192.168.0.10PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.64 bytes from 192.168.0.10: icmp_seq=1 ttl=32 time=1.62 ms64 bytes from 192.168.0.10: icmp_seq=2 ttl=32 time=0.961 ms64 bytes from 192.168.0.10: icmp_seq=3 ttl=32 time=0.953 ms --- 192.168.0.10 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2020msrtt min/avg/max/mdev = 0.953/1.178/1.622/0.315 ms[root@neptune root]# arp -a? (192.168.0.10) at 00:A0:24:64:E8:C0 [ether] on eth0? (192.168.0.10) at 00:A0:24:64:E8:C0 [ether] on eth0[root@neptune root]#

Otra posibilidad, quizás un poco menos elemental, es interpretar el tráfico del ping. Para todas las capturas de tráfico, utilizamos tcpdump, que es una herramienta disponible para cualquier sistema operativo (UNIX o windows)10.

A. Captura de tráfico para ping

[root@neptune root]# tcpdump -xtcpdump: listening on eth008:52:31.760238 arp who-has 192.168.0.10 tell neptune.localdomain.local 0001 0800 0604 0001 0007 e99f 09b4 c0a8 0004 0000 0000 0000 c0a8 000a

08:52:31.760985 arp reply 192.168.0.10 is-at

10 Aquí no describiremos su instalación, ya que comúnmente viene instalada

3

0:a0:24:64:e8:c0

El tráfico completo puede ser visto en el anexo No.2. Se ha resaltado la parte donde puede ser identificada la dirección MAC de la máquina destino. El resto de la captura corresponde a solicitudes ICMP y a respuestas ICMP principalmente, ya que la captura corresponde a un ping.

Ahora, ya se tiene toda la información que se necesita para llevar a cabo la incomunicación de los dos sistemas (Se lleva a cabo una incomunicación de un solo sentido, donde la máquina atacada no puede conectar a la máquina que especifiquemos, pero la comunicación en sentido inverso se lleva a cabo de manera exitosa).

B. Manejo de Arpoison.

Primero, aprendemos a utilizar la herramienta arpoison, lo cual es bastante sencillo:

[root@neptune root]# arpoisonUsage: -i <device> -d <dest IP> -s <src IP> -t <target MAC> -r <src MAC> [-a] [-w time between packets] [-n number to send][root@neptune root]#

donde:

<device> es el dispositivo de la tarjeta de red en el computador atacante, para nuestro caso, eth0, pero esto varía dependiendo el sistema operacional.<dest IP> es la dirección IP del sistema que queremos atacar, es fácilmente obtenible.<src IP> es el “origen” del paquete ARP, usualmente la máquina con la que queremos incomunicar a nuestra víctima<target MAC> es la dirección MAC de la víctima, obtenida en el paso anterior.<src MAC> es la dirección MAC de la máquina remitente del mensaje. Usualmente, queremos poner aquí cualquier MAC, excepto la MAC real del servidor, porque en este caso estaríamos generando un paquete válido ARP.

A continuación llevaremos a cabo el ataque. Nótese que éste comando se puede efectuar desde una tercera máquina, que no sea ni la víctima ni el servidor:

[root@neptune root]# arpoison -i eth0 -d 192.168.0.10 -s 192.168.0.5 -t 00:a0:24:64:e8:c0 -r aa:bb:cc:dd:ee:00 -w 2ARP reply 1 sent via eth0ARP reply 2 sent via eth0ARP reply 3 sent via eth0ARP reply 4 sent via eth0 [root@neptune root]#

Y a continuación se muestra la captura de tráfico correspondiente al comando anterior, realizada en la máquina atacante:[root@neptune root]# tcpdump -xtcpdump: listening on eth009:07:36.650287 arp reply 192.168.0.5 is-at aa:bb:cc:dd:ee:0 0001 0800 0604 0002 aabb ccdd ee00 c0a8

0005 00a0 2464 e8c0 c0a8 000a09:07:36.651266

El tráfico completo puede ser visto en el anexo No. 3.

C. Conclusión

Se realizó una captura completa de 4 paquetes enviados por arpoison, pero en el primero que se envía, se puede ver que es lo que realiza, vamos a analizarlo:09:07:36.650287 arp reply 192.168.0.5 is-at aa:bb:cc:dd:ee:0 0001 0800 0604 0002 aabb ccdd ee00 c0a8 0005 00a0 2464 e8c0 c0a8 000a

El primer renglón, es solo la traducción que realiza tcpdump del paquete, y no se analizará. Lo interesante, es el volcado hexadecimal que realiza. ¿Qué significa? es lo que veremos. Se va a analizar parte por parte:

0001: Tipo de dirección de hardware, 1 = Ethernet, 6 = IEEE 802 LAN0800: Tipo de dirección de protocolo, corresponde a Ipv406: Longitud de las direcciones de hardware. El 6 representa el número de bytes necesarios para representarlas.04: Corresponde al tipo de protocolo usado, Ipv40002: Identifica el tipo de operación que se realizara, 1 es una solicitud, 2 es una respuesta.aabb ccdd ee00: Es la dirección de hardware que realiza la solicitud (en este caso, fue la que falseamos, para que el ataque resulte)c0a8 0005: Corresponde a la IP que tiene la MAC especificada anteriormente. En este caso, toca convertirla de hexadecimal:c0 = 192, a8 = 168, 00 = 0, 05 = 500a0 2464 e8c0: corresponde a la dirección de hardware de la máquina objetivo, la que se desea actualizarc0a8 000a: Corresponde a la dirección IP de la máquina destino. Nuevamente, es necesario realizar la conversión de hexadecimal.

El resto de paquetes, corresponden a la operación normal de los protocolos, o a solicitudes iguales a la que se analizó anteriormente.

II.DISCUSIÓN

Se pudo observar en el laboratorio de redes los efectos de la manipulación de paquetes Ethernet y la consiguiente suplantación de direcciones MAC usando el programa conocido como ARPoison. Los resultados se constataron en la máquina 3 donde se alteró la tabla ARP. Antes del experimento se hizo un ping a la máquina 2 y luego se revisó la tabla ARP para obtener su dirección MAC que era 00:C0:DF:22:20:C0, después de correr ARPoison se revisó de nuevo la tabla ARP y para la dirección ip del computador 2 aparecía una dirección MAC diferente AA:BB:CC:DD:EE:ZZ que era la especificada por nosotros. Como es evidente, era una dirección inválida, para

4

comprobar estas observaciones se hizo un nuevo ping desde el computador 3 a la máquina 2, y como se esperaba esta última nunca contestó ya que la máquina 3 intentaba contactarse con una dirección inexistente, así en términos prácticos la máquina 2 dejó de existir para la 3.” Por esto podemos concluir que una persona inescrupulosa podría potencialmente observar TODA comunicación no encriptada que viaje por la red, utilizando una herramienta de fácil acceso y de todavía más sencillo manejo, generando un falla gigantesca en los niveles de seguridad de cualquier red.

A. ¿Cómo evitarlo?

¿Estamos totalmente desprotegidos y en cualquier momento nos pueden dejar incomunicados?

Si existen maneras de evitar este ataque, pero casi nunca se implementan. Sin embargo, un análisis más profundo de la tecnología nos indica lo siguiente: ya que los ataques ARP se aprovechan de la falta de seguridad en un protocolo de bajo nivel y que es requerido por TCP/IP para funcionar, no se puede corregir sin alterar el funcionamiento mismo de ARP, lo cual no es una tarea sencilla si se tiene en cuenta que, como se mencionó antes, hay diferentes implantaciones del protocolo debido a su estrecha conexión con la máquina en la que corre. Pero si se puede prevenir, o al menos intentar, usando alguna de las siguientes técnicas [10].

-Si se quiere proteger una red pequeña se puede recurrir al uso de direcciones IP estáticas y tablas ARP también estáticas. Usando comandos CLI, "ipconfig/all" en Windows o "ifconfig" en sistemas Unix (Linux), [12,16,17] se puede obtener las direcciones MAC de todos los dispositivos conectados a dicha red. Si se usa el comando "arp -s" se pueden adicionar entradas estáticas para todos los dispositivos conocidos. Usando estas entradas estáticas se evita que los intrusos alteren las tablas a su gusto pudiendo aprovechar todas las debilidades ya explicadas. Incluso se puede crear un script que llene estas entradas estáticas en los computadores cada vez que estos sean reiniciados [10, 13].

El problema con esta solución es la gran dificultad para mantener estas entradas ARP, y si se piensa en redes grandes es casi imposible llevar a cabo esta labor, ya que cada vez que un nuevo computador o máquina se conecte a la red se debe actualizar las entradas en el script que llena las tablas ARP, o se debe adicionar manualmente a las tablas ARP de todas las demás máquinas en la red.[11]

Para redes grandes se tendría que analizar las características de "Port Security" de los switches, una de estas características permite forzar al switch a permitir sólo una dirección MAC para cada puerto físico en el switch, lo cual impide que alguien cambie la dirección MAC de su máquina o que trate de usar más de una dirección a la vez. Esto último permite prevenir los ataques de Man-in-the-Midle.[10]

Para todas las redes la mejor defensa es entender los métodos y comportamientos de ARP poisoning y monitorear en busca de estos comportamientos sospechosos usando herramientas como ARPWatch, explicada a continuación, que alertan cuando alguna comunicación ARP sospechosa es llevada a

cabo, y permiten afinar los métodos de búsqueda y detección usados.Debería ser claro en este punto que saber la dirección MAC de cada maquina no debería dejarse a la configuración automática usada en un protocolo o instalación de un switch. A menos que se controle el proceso de ARP, “poisoning” y “sniffing” pueden ocurrir. La manifestación de este problema puede causar desde reducir el tiempo de respuesta en la red, hasta el daño de todo el tráfico de red. Este problema puede ser detectado únicamente a través de otro “sniffer” para ver que es lo que esta pasando a nivel de MAC o mirando las tablas ARP en ambos lados, la maquina del cliente y la del servidor.[14]

En este punto es necesario identificar las direcciones MAC de cada computador y cada “gateway” de la LAN. Correr un ipconfig /all en Microsoft Windows NT mostrará la dirección MAC de la tarjeta Ethernet. También mostrará las direcciones MAC de los adaptadores virtuales VPN, Sun Solaris y Linux usan el comando ifconfig –a, mientras que FreeBSD usa dmesg. Las máquinas Microsoft Windows 9x usan el comando winipcfg. [12,16,17]

Armado con la lista de direcciones MAC, el sistema puede ahora ser asegurado. Es recomendable un script de login que automatice el comando arp –s para guardar todos las IP de los hosts y sus direcciones MAC.[14]

Reemplazar tarjetas de red inconsistentes va a requerir cambios adicionales en cada host. Los sistemas tales como impresoras no tendrán la capacidad de guardar una lista de direcciones MAC estáticas, la mayoría de los switches tienen una opción de puerto de seguridad que permite únicamente una dirección MAC por puerto(así reduciendo el “sniffing”). SSH tiene una opción de StrictHostKeyChecking. Ésta opción especifica si SSH va a automáticamente agregar nuevas llaves de host a su archivo de hosts conocidos. Con esta opción configurada a SI(YES), el computador atacante no podrá “entrar en el medio” a menos que ya sea un host de confianza(trusted host). [11,13,15]

Teniendo un archivo de hosts estático y listando los nombres DNS, también se reducirán los ataques basados en DNS, es recomendable usar ambos sistemas para alta seguridad. Hay que tener en cuenta que algunas versiones de Microsoft Windows aceptarán y usarán rutas dinámicas inclusive si las rutas estáticas han sido configuradas [17].

Con los hosts ahora cerrados, es importante monitorear el tráfico ARP y DNS. Aunque la mayoría de IDS monitorean a nivel de IP y no de ARP.

La siguiente es una herramienta que puede ser usada para el monitoreo a nivel ARP:

ARPWATCH11 Arpwatch contiene 2 utilidades diseñadas para monitorear las tablas IP/MAC y enviar por mail cualquier cambio. Es una pieza de software bastante simple, acá se encuentran algunos ejemplos de lo que se mostraría en el archivo /var/log/messages.

11 http://www.redhat.com/swr/i386/arpwatch-2.1a4-29.i386.html

5

Sep 20 12:36:11 myhost arpwatch: new station 192.168.a.b 0:50:94:d7:ca:d5Sep 20 12:35:07 myhost arpwatch: changed ethernet address 192.168.a.c0:10:a4:bf:b1:c9 (0:0:86:45:32:fa)La primera línea muestra una nueva combinación de direcciones IP/MAC, esto continuará para cada host en la LAN. La segunda línea muestra que la dirección MAC ha cambiado para el host 192.168.a.c la nueva dirección MAC es 0:10:a4:bf:b1:c9. La dirección anterior era 0:0:86:45:32:fa. Esto debe causar que el administrador del sistema pare y revise alguna información básica acerca del host, Si es un servidor dedicado entonces la dirección no debería cambiar sin cambiar el hardware.

Este host puede también estar usando DHCP. Si un host deja la red y otro host usa su dirección IP, este cambio es apropiado, no de otra manera. Al usar las direcciones hardware para identificar el vendedor, se puede encontrar que el cambio de dirección MAC cambió de un Xircom a un Gateway Communications. Esto también podría alertar acerca del hardware que esta fuera del inventario de nuestra LAN.

Finalmente, se puede ser encriptar todo el tráfico de la red, lo cual puede ser complicado, además que genera un trabajo adicional de las máquinas para encriptar y desencriptar todo el tráfico [3].

Otra manera de evitar este problema, es instalar un software que cumpla la función de un firewall de nivel 2 que filtre el tráfico ARP. De nuevo, presenta los mismos inconvenientes que las anteriores alternativas.

Creemos firmemente que la solución debe venir principalmente de los fabricantes de sistemas operativos, quienes deben implementar procedimientos eficaces con los cuales sea practicamente imposible alterar las tablas ARP, sin que esto signifique una encripción o tenga un efecto nocivo en la configuración de las redes, sobre todos las DHCP .

De nuevo, se comprueba como la facilidad, confiabilidad y operabilidad de los estándares de internet para la comunicación por la red es a la vez la fuente de su peor pesadilla. La seguridad es un compromiso constante entre eficiencia, disponibilidad y a la vez, atención y cuidado perenne que puede bien estar en los límites de la paranoia.

AGRADECIMIENTOS

Todos los autores agradecemos comedidamente a nuestros familiares y compañeras sentimentales, por el apoyo en todo momento, y a nuestro Profesor Jeimy Cano por su invaluable aporte a nuestro crecimienco académico y profesional.

REFERENCIAS

[1] Wagner, R. “Address Resolution Protocol Spoofing and Man-in-the-Middle Attacs:” in Practical Assignment GSEC Version 1.2 f (amended August 13 2001.

[2] Peiraki, C;Fogie, S. “The Ingredients to ARP Poison,” in governement Security.org.http://www.governmentsecurity.org/articles/TheIngredientstoARPPoison.php, October 18, 2002.

[3] Whalen, S. “An introduction to ARP spoofing” 2600 magazine, http://www.node99.org/projects/arpspoof/.April, 2001

[4] Gunnarson, Andreas “Security in IP Networks: A layered view of security problemas and solutions” Carlstedt Research & Tecnhology. May 2001.

[5] Data wizard, Altering ARP Tables (version 1.00) , The Nederlands.

2001.http://packetstormsecurity.nl/papers/general/Altering_ARP_Tables_v_1.00.htm

[6] Kasslin, K; Tikkanen, A. “Hijacking a Network Connection on a Switched Network”www.hut.fi/~autikkan/kerberos/docs/phase1/ pdf/LATEST_hijacking_attack.pdf. May 2003.

[7] Forsberg, E. “Man in the Middle Attack against Microsoft Terminal Services” in Cendio System www.cendio.se/files/mitm_en.pdf., April 2003.

[8] R. García, Laboratorio de Sistemas distribuidos. Uniandes, comunicción privada. Septiembre 2003.

[9] D. Plummer, et al. RFC 826, http://www.rfc-editor.org. November 1982.[10] C.Nachreiner, WatchGuard Network Security Analyst “Anatomy of an

ARP Poisoning Attack” http://www.watchguard.com/infocenter/editorial/135324.asp

[11] Hewes, Douglas “I Can See you Behind Layer 2… Overcoming the difficulties of Packet Capturing on a Switched Network” (14 September 2000)http://www.sans.org/infosecFAQ/switchednet/layer2.htm

[12] Watson, Keith and Noordergraaf, Alex “Solaris Operating Environment Network Settings for Security” (December 2000) http://www.sun.com/blueprints/1200/network-updt1.pdf

[13] Fermilab – Data Communications and Networking Group “How to find your MAC address” (05 February 2001) http://www-dcn.fnal.gov/DCG-Docs/mac/

[14] Mourani, Gerhard “Securing and Optimizing Linux: RedHat Edition – A Hands on Guide” (2000) http://www.linuxdoc.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Editionv1.3/chap15sec121.html

[15] Roesch, Martin “Snort Users Manual, Snort Release: 1.8.1” (10 August 2001)http://www.snort.org/docs/SnortUsersManual.pdf

[16] EcoPRO “Windows NT, PC Networking – Windows NT 4.0” (1999)http://www.ecoproimaging.com/nt_networking.htm

[17] ARP table information for Windows NT Whalen, Sean “An Introduction to ARP Spoofing” (April,2001) http://packetstormseurity.org/papers/protocols/intro_to_arp_spoofing.pdf

6