Ejemplo de ataque de ARP poisoning (envenenamiento ARP) y cómo prevenirlo. El objetivo de esta prueba de laboratorio es configurar un conmutador de paquetes (switch) de forma segura para evitar ataques de MitM (man-in-the-middle) basados en el protocolo de resolución de direcciones ARP.

• Laboratorio inicial.
• Perpetrar ataque ARP poisoning o Envenenamiento de ARP.
• Proteger el switch frente a ataques ARP Poisoning mediante entradas estáticas en la tabla ARP.
• Bastionado de switch mediante DHCP secured ARP para evitar ataques ARP Poisoning.

Laboratorio inicial

Se describe, en la imagen, el escenario de partida, que tiene la organización de ejemplo, que será la que reciba el ataque de ARP poisoning, explotando una de sus vulnerabilidades:

Como se puede observar, en la imagen, el equipo marcado en rojo es el propio equipo con Kali Linux, en el que se despliega el laboratorio de red con los distintos switches (swX), cortafuegos (fwX), equipos (pcX) y diferentes VLAN y redes.

Para este ejemplo de explotación de vulnerabilidad ARP, únicamente usaremos el equipo Kali Linux, desde el que ejecutaremos Ettercap para simular el ataque por envenenamiento de ARP.

La dirección MAC del equipo Kali Linux, que será el que usemos para realizar el ataque será: ea:52:1e:6b:71:f0. Este dato es importante porque será la MAC con la que se envenene el equipo de pruebas atacado posteriormente:

Perpetrar ataque ARP poisoning o Envenenamiento de ARP

Para realizar el ataque ARP poisoning, accederemos al switch de nuestro laboratorio de pruebas y asignaremos una IP (10.1.12.20) a la VLAN internal:

Comprobaremos que hay conectividad con esta IP desde un equipo de pruebas del laboratorio, desde el pcL1, haciendo un ping:

Desde el modo gráfico de Kali Linux ejecutaremos la herramienta ettercap-graphical, que está en el grupo «09 – Sniffing & Spoofing»:

Elegiremos la interfaz de red de Kali Linux que tengamos conectada a la red interna del laboratorio (entorno de pruebas), en nuestro caso «kaliL.eth0» [1], marcaremos «Sniffing at startup» y pulsaremos en el botón validar [2]:

Ettercap configurará la interfaz de red en modo promiscuo, de forma que permitirá capturar todo el tráfico que se genera en la red a la que pertenece la interfaz.

Activaremos el escaneo por hosts, para ello, en Ettercap, pulsaremos en el botón de los tres puntos verticales. En el menú emergente pulsaremos en «Hosts»:

Y pulsaremos en «Scan for hosts»:

Volveremos al menú «Hosts» para pulsar ahora en «Hosts list»:

De esta forma, Ettercap mostrará un listado de los equipos escaneados, su dirección IP y su MAC:

En la lista anterior, Ettercap habrá descubierto, entre otros, el equipo de pruebas (pcL1, con IP 10.1.12.11) y el switch (conmutador, con IP 10.1.12.20).

Realizaremos el ataque MitM sobre estos dos dispositivos (switch y pcL1). Para ello, seleccionaremos el switch de la lista de hosts descubiertos (la IP 10.1.12.20) [1] y pulsaremos «Add to Target 1» [2]:

Ahora seleccionaremos la IP del pcL1 (10.1.12.11) y pulsaremos «Add to Target 2»:

Pulsaremos en el botón de la bola del mundo y, en los posibles ataques que se pueden realizar desde Ettercap, pulsaremos en «ARP poisoning»:

Marcaremos «Sniff remote connections» y pulsaremos «OK» para llevar a cabo el ataque de envenenamiento de las tablas ARP de los dos dispositivos elegidos:

Comprobaremos que el ataque ARP Poisoning ha sido efectivo. En la consola de Ettercap mostrará ARP poisoning victims:

Ahora vamos a comprobar que, efectivamente, las tablas ARP de los equipos seleccionados han sido envenenadas. Desde el switch, ejecutaremos el comando:

En la tabla ARP, podremos comprobar que la dirección MAC que se ha asociado al pcL1 es la de la máquina atacante (la máquina Kali Linux con IP 10.1.12.4 y MAC ea:52:1e:6b:71:f0), en lugar de su MAC original 02:fd:00:01:11:01:

Con lo cual podemos confirmar que el ataque ARP Poisoning ha sido efectivo.

Desde el PC atacado (pcL1), en su consola, ejecutaremos el siguiente comando:

Obtendremos la misma dirección MAC para el switch (conmutador), con IP 10.1.12.20 que para la máquina atacante Kali Linux, con IP 10.1.12.4. Con lo cual tendremos los tres dispositivos con la misma MAC (el pcL1, el switch y la máquina atacante).

Para verificar aún con mayor detalle que el ataque se ha llevado a cabo, comprobaremos que todo el tráfico entre el equipo pcL1 y el switch pasa a través de la máquina atacante, haciendo un MitM en toda regla. Para comprobarlo, desde el equipo atacante (máquina Kali Linux), con el superusuario root, ejecutaremos el siguiente comando:

Ahora, desde el equipo atacado pcL1, realizaremos un ping al conmutador, con el comando:

Efectivamente, en el equipo atacante, vemos que todos los paquetes de ping enviados del pcL1 al switch pasan por él:

Proteger el switch frente a ataques ARP Poisoning mediante entradas estáticas en la tabla ARP

Realizaremos el bastionado de un switch Extreme Networks, con sistema operativo EXOS. El proceso variará para switches de otros fabricantes (Cisco, Huawei, HP, etc.), aunque la idea general es la misma

Los switches Extreme Networks tienen activada, por defecto, la función ARP learning, que se encarga de construir la tabla ARP del conmutador dinámicamente, a partir de los paquetes ARP request y ARP reply.

Existen dos formas de proteger el conmutador (switch) frente ataques de tipo ARP:

• Desactivar la función ARP learning y añadir manualmente las entradas estáticas en la tabla ARP.
• Activar la función DHCP secured ARP.

Empezaremos por desactivar la función ARP learning. Para ello, desde la consola del switch, ejecutaremos el siguiente comando:

Que desactivará la función ARP learning para todos los puertos de la vlan internal. A continuación, borraremos la caché de ARP actual, para la VLAN internal, con el comando:

También borraremos la caché ARP en el equipo de pruebas pcL1, con el comando:

A partir de ahora, las tablas ARP quedan eliminadas y el switch no podrá aprender nuevas asociaciones. Si ahora ejecutamos en el switch:

Aparecerá una lista vacía:

Si ahora lanzamos un ping desde el equipo pcL1 al switch

Comprobaremos que no tenemos conectividad:

Si añadimos manualmente una entrada estática en la tabla ARP del switch, ejecutando el siguiente comando:

Donde:

• 10.1.12.11: será la dirección IP del pcL1.
• 02:fd:00:01:11:01: será la dirección MAC real del pcL1.

Ahora habrá vuelto la conectividad y funcionará el ping anterior:

Y si ejecutamos el comando siguiente en el switch:

Podremos comprobar que se ha añadido una entrada estática (static = yes) correspondiente al equipo pcL1:

De esta forma, con el bastionado del switch, los ataques de ARP Poisonnig no tendrán efectividad, dado que las asignaciones ARP se realizan de forma manual por el administrador de red.

Bastionado de switch mediante DHCP secured ARP para evitar ataques ARP Poisoning

Como hemos comentado anteriormente, otra forma de proteger un switch de nuestra red frente a ataques ARP Poisoning es mediante la técnica de DHCP secured ARP, que explicamos a continuación.

Eliminaremos de nuevo las tablas ARP del switch. En este caso, al tratarse de una entrada ARP estática, deberemos ejecutar el siguiente comando en el switch para eliminarla:

En el equipo pcL1 ejecutaremos:

Configuraremos ahora la función DHCP secured ARP en el switch. Con esta función evitaremos tener que añadir de forma manual (como en el caso anterior) todas las entradas estáticas en la tabla ARP. DHCP secured ARP se basa en que, de forma automática, la tabla ARP se actualiza, exclusivamente, durante la asignación por DHCP de las direcciones IP de los sistemas finales. Por esta razón, es importante configurar de forma segura el servicio DHCP. Evitar la suplantación del servidor DHCP puede evitar ataques
de tipo ARP Poisoning. En el siguiente enlace explicamos cómo bastionar el switch para evitar el ataque de suplantación de DHCP, mediante la activación de la función DHCP Snooping:

• Ejemplo de ataque ARP poisoning y cómo evitarlo.

Para activar el aprendizaje mediante DHCP secured ARP, para todos los puertos de la VLAN internal, desde la consola del switch, ejecutaremos el comando:

Comprobaremos que la asignación funciona correctamente, para ello, desde la consola del equipo pcL1, eliminaremos la configuración de red actual, con el comando:

Y volveremos a solicitar una nueva configuración de red mediante DHCP, con el comando:

Comprobaremos, desde el switch, que se ha asignado en la tabla ARP la dirección IP y MAC del equipo pcL1, con static = yes. Para ello, en el switch, ejecutaremos el comando:

Si ahora volvemos a realizar el intento de ataque ARP Poisoning con Ettercap, veremos que no se hace efectivo. La tabla ARP no habrá sido envenenada y será correcta. En cambio, hay que tener en cuenta que la tabla ARP del equipo pcL1 sí que será envenenada. Esto es así porque, si bien el switch sí implementa medidas contra el ataque ARP Poisoning, el equipo pcL1 no tiene ningún mecanismo de seguridad que permita protegerse de este ataque, habría que implementar alguno y esto dependerá del sistema operativo.