Después de hablar de la posibilidad de sufrir, o realizar, una Denegación de Servicio (DoS) mediante la generación de un paquete HSRP a medida, vamos a hablar ahora de cómo mitigarlo.
Existe una manera y pasa por la configuración de la característica que Cisco denomina “HSRP MD5 Authentication” y cuya documentación la podréis encontrar aquí. En resumen, lo que se hace es configurar cada una de las interfaces con una contraseña que será empleada junto con el algoritmo MD5 para crear un hash que será anexado al paquete HSRP. El receptor del paquete calculará nuevamente el hash y lo comparará con el que tiene el paquete HSRP recibido. Si coinciden lo procesa, en caso contrario lo descarta.
A continuación se muestran dos capturas de paquetes HSRP. En la primera vemos a HSRP configurado por defecto, mientras que en la segunda lo está con la autenticación MD5.
Como podemos comprobar el segundo paquete es más extenso, además de figurar en el campo Authentication Data, “Non-Default ()”.
Para configurar esta característica deberemos configurar los switches , o routers, de la siguiente manera:
Switch CORE01:
CORE01(config)# interface Vlan11
CORE01(config-if)# ip address 10.10.11.2 255.255.255.0
CORE01(config-if)# standby 11 ip 10.10.11.1
CORE01(config-if)# standby 11 priority 200
CORE01(config-if)# standby 11 preempt
CORE01(config-if)#standby 11 authentication md5 key-string edorta
Switch CORE02:
CORE01(config)# interface Vlan11
CORE02(config-if)# ip address 10.10.11.3 255.255.255.0
CORE02(config-if)# standby 11 ip 10.10.11.1
CORE02(config-if)# standby 11 priority 150
CORE02(config-if)# standby 11 preempt
CORE02(config-if)#standby 11 authentication md5 key-string edorta
Si ahora repitiésemos el mismo ataque reflejado en el Post “DoS en HSRP Part I” pero modificando la contraseña “cisco” por “edorta” como sigue:
root@bt:~# yersinia hsrp -dest 01:00:5e:00:00:02 -dport 1985 -group 11 -hello 3 -hold 10 -interface eth1 -ipdest 2.0.0.224 -ipsource 101.10.11.10 -ipvirtual 1.11.10.10 -opcode 0 -password edorta -priority c9 -reserved 0 -source 00:00:0c:07:ac:0b -sport 1985 -state 10 -version 0 -attack 0
Obtendríamos en la consola de “CORE01” el siguiente log:
CORE01#
%HSRP-4-BADAUTH: Bad authentication from 10.11.10.101, group 11, remote state Active
%HSRP-4-BADAUTH: Bad authentication from 10.11.10.101, group 11, remote state Active
%HSRP-4-BADAUTH: Bad authentication from 10.11.10.101, group 11, remote state Active
CORE01#
Lo que nos demuestra que los switches “CORE01” y “CORE02” detectan una autenticación errónea y por tanto desestiman el paquete. Por tanto nuestro supuesto ataque, sufrido o ejecutado, no ha tenido efecto.