LUK
12-02-2015, 19:58
Recientemente he estado revisando documentación de controles de red a nivel 2 y justo vino a mi memoria el post de Borja Merino de hace algún tiempo (http://foro.hackhispano.com/showthread.php?44387-Defensas-frente-a-ataques-DHCP) [1].
En el post, Borja hablaba de cómo hacer frente a ataques DHCP mediante la funcionalidad DHCP Snooping de Cisco, hablando de puertos confiables y no confiables, y de la tabla de asociación IP-MAC usada. También hace referencia a DAI (Dynamic ARP Inspection) (http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html) [2] como funcionalidad de seguridad para poder evitar posibles ataques MitM como ARP poisoning; es justo esta funcionalidad en la que nos centraremos en la entrada de hoy.
DAI es una medida de seguridad disponible en switches Cisco que nos permite validar los paquetes ARP de la red; al igual que en el post de Borja, DAI utiliza la tabla de asociaciones IP-MAC generada por DHCP Snooping, aunque esto es opcional. Para este post, daremos de alta las entradas de forma manual, algo poco eficaz en entornos grandes.
DAI intercepta las peticiones y respuestas de los puertos no confiables (untrusted) y las valida contra la tabla antes de actualizar su cache y permitir el tráfico. Puesto que el comportamiento por defecto es definir todos los puertos como untrusted, deberemos especificar los puertos confiables (trusted) mediante el comando ip arp inspection trust para evitar el bloqueo de puertos, por ejemplo de puertos de conexión con servidores o enlaces troncales entre switches.
Nuestra arquitectura de red es similar a la vista en el post de Borja, disponemos de un switch, en este caso un Cisco 3750, dos equipos de usuarios y un servidor DHCP aunque éste último, no vamos a usarlo ya que se configurarán manuales.
http://www.securityartwork.es/wp-content/uploads/2015/01/arp.jpg
Lo primero que hacemos es comprobar que existe conectividad entre ambos equipos (¡cuántas veces hemos asumido que todo funciona antes de modificar algo y luego, cuando no va y tenemos que ir deshaciendo lo realizado, vemos que antes tampoco funcionaba como tocaba!). Una vez aseguramos la conectividad, procedemos a activar DAI.
Por defecto, DAI inspecciona todos los paquetes ARP enviados desde los puertos no confiables para asegurar la presencia de una correspondencia IP-MAC en la tabla de asociaciones. Aunque pueden activarse validaciones de seguridad adicionales mediante el comando ip arp inspection validate, nosotros usaremos las funcionalidades por defecto.
Switch(config)# ip arp inspection vlan 1
La activación, como hemos comentado anteriormente, define todos los puertos como no confiables:
Switch# show ip arp inspection interfaces
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
…
Gi1/0/20 Untrusted 15 1
…
Gi1/0/24 Untrusted 15 1
Por lo que se comprobaría la presencia en la tabla de asociaciones de una entrada, algo que hemos dicho que realizaríamos de forma manual, y al no encontrar ninguna, bloqueará el tráfico. Esto podemos verlo claramente en el log que muestra la consola, y donde se especifica MAC origen, IPs origen, destino e interfaz.
01:16:20: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/20, vlan 1.([0024.beec.2526/172.18.0.222/0000.0000.0000/172.18.0.111/01:16:20 UTC Mon Mar 1 1993])
Aunque ya hemos visto que funciona, podremos validar que la funcionalidad se encuentra activada y se está bloqueando el tráfico:
Switch# show ip arp inspection vlan 1
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
---- ------------- --------- --------- ----------
1 Enabled Active
Vlan ACL Logging DHCP Logging Probe Logging
---- ----------- ------------ -------------
1 Deny Deny Off
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 0 971 971 0
El siguiente paso será añadir manualmente, las asociaciones IP-MAC de cada uno de los equipos en la tabla, especificando la interfaz donde están conectados:
Switch(config)# ip source binding 0024.beec.2526 vlan 1 172.18.0.222 interface gigabitEthernet 1/0/20
Switch(config)# ip source binding 0050.5b00.0dff vlan 1 172.18.0.111 interface gigabitEthernet 1/0/24
Y ver que se han almacenado correctamente:
Switch# show ip source binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:50:5B:00:0D:FF 172.18.0.111 infinite static 1 GigabitEthernet1/0/24
00:24:BE:EC:25:26 172.18.0.222 infinite static 1 GigabitEthernet1/0/20
Esta asociación también podría hacerse definiendo una ACL.
Llegados a este punto, volveríamos a tener conectividad, por lo que si volvemos a comprobar las estadísticas, vemos que ya aparece tráfico reenviado:
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 120 316 316 0
Hasta aquí, solo hemos visto el comportamiento normal del sistema, pero ahora, vamos a enviar tráfico con una dirección MAC (o IP) distinta de las introducidas en la tabla anterior; esto puede hacerse de forma manual cambiando la configuración del adaptador de red, o con herramientas de manipulación de tráfico como scapy.
Al cambiar la dirección MAC perdemos la conexión con el equipo remoto, y volvemos a ver avisos en el log donde se indica la nueva dirección MAC, la cual no aparece en la tabla de asociaciones:
1:32:15: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:32:15 UTC Mon Mar 1 1993])
Y vemos cómo el número de paquetes dropeados aumenta:
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 135 380 380 0
Esta configuración mostrará un aviso en el log, pero es más interesante configurar el equipo para que, en caso de detectar que el número de paquetes ARP que no tienen presencia en la tabla, supere un umbral definido, por ejemplo un paquete por segundo, bloquee el puerto (err-disabled) durante un periodo de tiempo (y lo notifique por SNMP).
Switch(config)# errdisable recovery cause arp-inspection
Switch(config)# interface gigabitEthernet 1/0/24
Switch(config-if)# ip arp inspection limit 1
Puesto que el equipo sigue intentando conectarse, el puerto se bloquea automáticamente:
01:42:47: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:42:46 UTC Mon Mar 1 1993])
01:42:47: %SW_DAI-4-PACKET_RATE_EXCEEDED: 2 packets received in 998 milliseconds on Gi1/0/24.
01:42:47: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi1/0/24, putting Gi1/0/24 in err-disable stateexit
01:42:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to down
Y así lo veremos el estado de la interfaz sospechosa:
Switch# show interfaces gigabitEthernet 1/0/24 status
Port Name Status Vlan Duplex Speed Type
Gi1/0/24 err-disabled 1 auto auto 10/100/1000BaseTX
También podríamos verlo si tenemos activado el log de violaciones detectadas por DAI mediante el comando show ip arp inspection log.
Dado que no hemos modificado el tiempo, el puerto estará 5 minutos bloqueado, pudiendo ver cuanto tiempo queda hasta la próxima comprobación:
Switch# show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
arp-inspection Enabled
…
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec) Errdisabled vlans
--------- ----------------- -------------- -----------------
Gi1/0/24 arp-inspection 118
Si mientras el puerto esta bloqueado, volvemos a dejar la dirección MAC correcta, una vez venza el timeout, el puerto volverá a levantar correctamente y recuperaremos la conectividad:
01:48:51: %PM-4-ERR_RECOVER: Attempting to recover from arp-inspection err-disable state on Gi1/0/24control Disabled
01:48:54: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/24, changed state to up
01:48:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to up
Como comentaba Borja en su entrada, existen distintas funcionalidades de seguridad a este nivel que debemos tener en cuenta a la hora de comprar nuevos equipos. No obstante, es habitual que este tipo de medidas vengan desactivadas por defecto y queden sin configurar salvo para casos puntuales.
Como reflexión final para los lectores, ¿disponen de medidas de seguridad a nivel 2 en sus organizaciones?
URL to article: http://www.securityartwork.es/2015/01/30/defensas-frente-a-ataques-arp/
URLs in this post:
[1] el post de Borja Merino de hace algún tiempo: http://foro.hackhispano.com/showthread.php?44387-Defensas-frente-a-ataques-DHCP
[2] DAI (Dynamic ARP Inspection): http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html
En el post, Borja hablaba de cómo hacer frente a ataques DHCP mediante la funcionalidad DHCP Snooping de Cisco, hablando de puertos confiables y no confiables, y de la tabla de asociación IP-MAC usada. También hace referencia a DAI (Dynamic ARP Inspection) (http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html) [2] como funcionalidad de seguridad para poder evitar posibles ataques MitM como ARP poisoning; es justo esta funcionalidad en la que nos centraremos en la entrada de hoy.
DAI es una medida de seguridad disponible en switches Cisco que nos permite validar los paquetes ARP de la red; al igual que en el post de Borja, DAI utiliza la tabla de asociaciones IP-MAC generada por DHCP Snooping, aunque esto es opcional. Para este post, daremos de alta las entradas de forma manual, algo poco eficaz en entornos grandes.
DAI intercepta las peticiones y respuestas de los puertos no confiables (untrusted) y las valida contra la tabla antes de actualizar su cache y permitir el tráfico. Puesto que el comportamiento por defecto es definir todos los puertos como untrusted, deberemos especificar los puertos confiables (trusted) mediante el comando ip arp inspection trust para evitar el bloqueo de puertos, por ejemplo de puertos de conexión con servidores o enlaces troncales entre switches.
Nuestra arquitectura de red es similar a la vista en el post de Borja, disponemos de un switch, en este caso un Cisco 3750, dos equipos de usuarios y un servidor DHCP aunque éste último, no vamos a usarlo ya que se configurarán manuales.
http://www.securityartwork.es/wp-content/uploads/2015/01/arp.jpg
Lo primero que hacemos es comprobar que existe conectividad entre ambos equipos (¡cuántas veces hemos asumido que todo funciona antes de modificar algo y luego, cuando no va y tenemos que ir deshaciendo lo realizado, vemos que antes tampoco funcionaba como tocaba!). Una vez aseguramos la conectividad, procedemos a activar DAI.
Por defecto, DAI inspecciona todos los paquetes ARP enviados desde los puertos no confiables para asegurar la presencia de una correspondencia IP-MAC en la tabla de asociaciones. Aunque pueden activarse validaciones de seguridad adicionales mediante el comando ip arp inspection validate, nosotros usaremos las funcionalidades por defecto.
Switch(config)# ip arp inspection vlan 1
La activación, como hemos comentado anteriormente, define todos los puertos como no confiables:
Switch# show ip arp inspection interfaces
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
…
Gi1/0/20 Untrusted 15 1
…
Gi1/0/24 Untrusted 15 1
Por lo que se comprobaría la presencia en la tabla de asociaciones de una entrada, algo que hemos dicho que realizaríamos de forma manual, y al no encontrar ninguna, bloqueará el tráfico. Esto podemos verlo claramente en el log que muestra la consola, y donde se especifica MAC origen, IPs origen, destino e interfaz.
01:16:20: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/20, vlan 1.([0024.beec.2526/172.18.0.222/0000.0000.0000/172.18.0.111/01:16:20 UTC Mon Mar 1 1993])
Aunque ya hemos visto que funciona, podremos validar que la funcionalidad se encuentra activada y se está bloqueando el tráfico:
Switch# show ip arp inspection vlan 1
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
---- ------------- --------- --------- ----------
1 Enabled Active
Vlan ACL Logging DHCP Logging Probe Logging
---- ----------- ------------ -------------
1 Deny Deny Off
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 0 971 971 0
El siguiente paso será añadir manualmente, las asociaciones IP-MAC de cada uno de los equipos en la tabla, especificando la interfaz donde están conectados:
Switch(config)# ip source binding 0024.beec.2526 vlan 1 172.18.0.222 interface gigabitEthernet 1/0/20
Switch(config)# ip source binding 0050.5b00.0dff vlan 1 172.18.0.111 interface gigabitEthernet 1/0/24
Y ver que se han almacenado correctamente:
Switch# show ip source binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:50:5B:00:0D:FF 172.18.0.111 infinite static 1 GigabitEthernet1/0/24
00:24:BE:EC:25:26 172.18.0.222 infinite static 1 GigabitEthernet1/0/20
Esta asociación también podría hacerse definiendo una ACL.
Llegados a este punto, volveríamos a tener conectividad, por lo que si volvemos a comprobar las estadísticas, vemos que ya aparece tráfico reenviado:
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 120 316 316 0
Hasta aquí, solo hemos visto el comportamiento normal del sistema, pero ahora, vamos a enviar tráfico con una dirección MAC (o IP) distinta de las introducidas en la tabla anterior; esto puede hacerse de forma manual cambiando la configuración del adaptador de red, o con herramientas de manipulación de tráfico como scapy.
Al cambiar la dirección MAC perdemos la conexión con el equipo remoto, y volvemos a ver avisos en el log donde se indica la nueva dirección MAC, la cual no aparece en la tabla de asociaciones:
1:32:15: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:32:15 UTC Mon Mar 1 1993])
Y vemos cómo el número de paquetes dropeados aumenta:
Switch# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
1 135 380 380 0
Esta configuración mostrará un aviso en el log, pero es más interesante configurar el equipo para que, en caso de detectar que el número de paquetes ARP que no tienen presencia en la tabla, supere un umbral definido, por ejemplo un paquete por segundo, bloquee el puerto (err-disabled) durante un periodo de tiempo (y lo notifique por SNMP).
Switch(config)# errdisable recovery cause arp-inspection
Switch(config)# interface gigabitEthernet 1/0/24
Switch(config-if)# ip arp inspection limit 1
Puesto que el equipo sigue intentando conectarse, el puerto se bloquea automáticamente:
01:42:47: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Gi1/0/24, vlan 1.([0050.5b00.0df1/172.18.0.111/0000.0000.0000/172.18.0.222/01:42:46 UTC Mon Mar 1 1993])
01:42:47: %SW_DAI-4-PACKET_RATE_EXCEEDED: 2 packets received in 998 milliseconds on Gi1/0/24.
01:42:47: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi1/0/24, putting Gi1/0/24 in err-disable stateexit
01:42:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to down
Y así lo veremos el estado de la interfaz sospechosa:
Switch# show interfaces gigabitEthernet 1/0/24 status
Port Name Status Vlan Duplex Speed Type
Gi1/0/24 err-disabled 1 auto auto 10/100/1000BaseTX
También podríamos verlo si tenemos activado el log de violaciones detectadas por DAI mediante el comando show ip arp inspection log.
Dado que no hemos modificado el tiempo, el puerto estará 5 minutos bloqueado, pudiendo ver cuanto tiempo queda hasta la próxima comprobación:
Switch# show errdisable recovery
ErrDisable Reason Timer Status
----------------- --------------
arp-inspection Enabled
…
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec) Errdisabled vlans
--------- ----------------- -------------- -----------------
Gi1/0/24 arp-inspection 118
Si mientras el puerto esta bloqueado, volvemos a dejar la dirección MAC correcta, una vez venza el timeout, el puerto volverá a levantar correctamente y recuperaremos la conectividad:
01:48:51: %PM-4-ERR_RECOVER: Attempting to recover from arp-inspection err-disable state on Gi1/0/24control Disabled
01:48:54: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/24, changed state to up
01:48:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to up
Como comentaba Borja en su entrada, existen distintas funcionalidades de seguridad a este nivel que debemos tener en cuenta a la hora de comprar nuevos equipos. No obstante, es habitual que este tipo de medidas vengan desactivadas por defecto y queden sin configurar salvo para casos puntuales.
Como reflexión final para los lectores, ¿disponen de medidas de seguridad a nivel 2 en sus organizaciones?
URL to article: http://www.securityartwork.es/2015/01/30/defensas-frente-a-ataques-arp/
URLs in this post:
[1] el post de Borja Merino de hace algún tiempo: http://foro.hackhispano.com/showthread.php?44387-Defensas-frente-a-ataques-DHCP
[2] DAI (Dynamic ARP Inspection): http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html