A día de hoy sería extraño no encontrarse con configuraciones HSRP (Hot Standby Router Protocol), GLBP (Gateway Load Balancing Protocol) o VRRP (Virtual Router Redundancy Protocol) en organizaciones de pequeño/gran tamaño y más aún en entornos críticos donde prima la disponibilidad. El motivo es evidente: la mayor parte de los equipos son configurados con un Gateway estático generalmente obtenido por medio de DHCP. En caso de que dicho Gateway deje de funcionar implicaría la pérdida de paquetes hasta que el mismo se restableciera o bien hasta que otro Gateway fuera configurado en cada uno de los equipos. Aunque existen métodos para permitir una configuración dinámica del Gateway (proxy Arp, protocolos de routing RIP/OSPF, “ICMP router discovery protocol”, etc.) estos implican una configuración más “compleja” además de producir cierto overhead en la red. Por este motivo es por el que surgieron protocolos como HSRP, GLBP o VRRP, siendo este último la versión no propietaria de los protocolos desarrollados por Cisco.
La idea de VRRP es agrupar un conjunto de routers bajo una misma IP/MAC Virtual de forma que dicho grupo sea totalmente transparente de la configuración del cliente. En este grupo, solo uno de los routers (Master Virtual Router) será el encargado de enrutar paquetes a su destino mientras que el resto correrán a modo de backup monitorizando el estado del Maestro para, en caso de caída o fallo, ser suplantado por aquel que presente mayor prioridad, proporcionando así redundancia con un delay mínimo (el tiempo de convergencia suele ser inferior a un segundo).
Toda esta lógica implica el intercambio de una serie de advertisements que conforman el protocolo VRRP y que serán totalmente transparentes a la configuración de los clientes donde únicamente tendrá que especificarse la IP virtual del router. Estos advertisements comunican el estado así como la prioridad del router maestro y son encapsulados en paquetes IP que se envían a la dirección multicast 224.0.0.18.
Aparte de proporcionar redundancia, VRRP suele ser desplegado para proporcionar balanceo de carga entre varios routers. Para ello, se configuran varios routers virtuales los cuales son configurados como Gateway para diversos grupos de máquinas. De esta forma podremos distribuir la carga de tráfico entre todos los routers virtuales además de proporcionar redundancia en caso de que alguno de ellos deje de responder. Pueden ver más información al respecto en este enlace de Cisco.
Como se comentó anteriormente las prioridades asignadas a cada router jugarán un papel importante a la hora de determinar quién asumirá el rol de Master en caso de que éste no responda durante un tiempo preestablecido (Master_Down_Timer) y donde a mayor prioridad mayor será la preferencia en elegir al nuevo maestro. El RFC correspondiente establece que a los backups se les asignara una prioridad de 1 a 254 determinando así el orden de asignación cuando el Master deje de sondear paquetes.
En el caso del router Master, éste debe tener una prioridad de 255 cuando dicho router sea configurado con la misma IP que la asignada al router Virtual (y al que se denominará “IP Address Owner”) . Es importante tener esto en cuenta ya que en este caso siempre será el router maestro independientemente del valor Preempt_Mode asignado. Pueden ver más información al respecto en este enlace de Cisco.
El router maestro será por tanto el responsable de hacer forwarding de aquellos paquetes cuya capa de enlace tengan como MAC destino la MAC del router virtual (00-00-5E-00-01-{VRID}). Además, será el encargado de responder a peticiones ARP que pregunten por la IP virtual asegurando así que los clientes sepan cómo alcanzar el router virtual.
VRRP dispone de varios mecanismos de seguridad para a) asegurar que no sea posible inyectar paquetes en un entorno VRRP desde una red externa (esto lo consigue fijando un valor TTL 255 en los advertisements y descartando aquellos con un valor inferior) y b) autenticar que los paquetes de configuración VRRP proceden de routers legítimos. En este último caso, para asegurar la autenticación es posible:
a) No usar autenticación :)
b) Configurar un password en claro.
c) “IP Authentication Header” mediante MD5.
Hechas las pertinentes presentaciones y puestos en materia, en la entrada siguiente veremos cómo aprovecharnos y explotar una configuración VRRP desatendida en donde se ha configurado alguno de los 2 primeros métodos de autenticación. En lugar de utilizar Loki o Scapy para llevar a cabo el MiM , lo que haremos será capturar, modificar y reinyectar un advertisement para hacernos pasar por el router maestro y posteriormente hacer un MIM.
