Introducción al protocolo VRRP y a su funcionamiento
1. Presentación del protocolo VRRP
El Protocolo de Redundancia de Enrutadores Virtuales (VRRP) es un protocolo cuyo objetivo es aumentar la disponibilidad de la puerta de enlace predeterminada de los hosts de una red. El principio consiste en definir la puerta de enlace predeterminada para los hosts de la red como una dirección IP virtual que hace referencia a un grupo de enrutadores.
El VRRP se utiliza ampliamente en arquitecturas de red en las que es fundamental mantener una conectividad constante, incluso en caso de que falle uno de los routers. Cuando un router deja de estar disponible, el VRRP permite que otro router tome el relevo de inmediato, sin interrumpir las comunicaciones.
El VRRP es un estándar de la IETF [Internet Engineering Task Force, organismo de normalización de protocolos de Internet], compatible con numerosos fabricantes de routers y cortafuegos, así como con sistemas operativos como Linux. El protocolo VRRP, al ser un protocolo abierto, está más extendido que otros protocolos similares o propietarios (como el HSRP, propiedad de Cisco).
[imagen 1]
2. Funcionamiento del protocolo VRRP
El VRRP funciona mediante un conjunto de routers y utiliza el concepto de router virtual, al que se le asigna una dirección IP virtual (VIP) y una dirección MAC virtual (IP-Tie Breaking). Las funciones de router maestro y router de respaldo se utilizan y se asignan a los routers de un grupo VRRP.
El router maestro está asociado a la dirección IP virtual del grupo. Es él quien responderá a las solicitudes ARP de los clientes en esa dirección IP (y quien enrutará las solicitudes de red).
Uno o varios routers de respaldo podrán asumir la función de router maestro en caso de que este falle.
Cabe señalar que el protocolo VRRP funciona en la capa 3 del modelo OSI y que, por lo tanto, no utiliza los protocolos de red TCP ni UDP. Por defecto, el VRRP utiliza la transmisión unicast para la comunicación entre los routers, aunque también puede utilizar la transmisión multicast.
a. Funcionamiento en condiciones nominales
En condiciones normales, el router maestro es aquel que tiene la prioridad más alta (valor entre 0 y 255). Si las prioridades son iguales, se elegirá el router con la dirección IP más baja.
Por su parte, los routers de respaldo escuchan los mensajes «HELLO» que envía (normalmente cada segundo) el router maestro, y esperan a que este sufra un posible fallo.
Los mensajes HELLO contienen la siguiente información: dirección IP VIP, prioridad del router maestro, el ID único del grupo VRRP y la versión del protocolo VRRP utilizado.
b. Fallo del router maestro
Cuando uno o varios routers de respaldo dejan de recibir paquetes HELLO durante el periodo configurado (por ejemplo, 3 segundos), estos consideran que el router maestro está desconectado y, por lo tanto, inoperativo.
El VRRP inicia una nueva elección del enrutador maestro utilizando el mismo método descrito anteriormente (selección del enrutador con la prioridad más alta); este último recuperará la dirección IP virtual (VIP) para hacerse cargo del enrutamiento del tráfico.
Cuando el router que era maestro inicialmente vuelve a estar en línea, este puede (dependiendo de si la configuración del grupo VRRP lo permite o no) retomar su función si su prioridad es mayor que la del router que es actualmente maestro.
3. Principales diferencias entre la versión 2 y la versión 3 del protocolo
| Criterio | VRRPv2 | VRRPv3 |
| Especificaciones | RFC 3768 | RFC 5798 |
| Compatibilidad con direcciones IP | Solo IPv4 | IPv4 e IPv6 |
| Encapsulación | Directamente en IP (protocolo 112) | Lo mismo, pero con un formato de paquetes modificado |
| Autenticación | > Sin autenticación > «Contraseña en texto sin cifrar» (contraseña en claro) > IP AH (HMAC-MD5-96) | Eliminada (sin autenticación integrada) |
| Seguridad | Débil, fácil de eludir | Depende de la seguridad de la red subyacente |
| Tamaño del campo de prioridad | 8 bits | 8 bits (igual) |
| Compatibilidad con varios grupos | Limitado (1 grupo por interfaz) | Sí (varios grupos en la misma interfaz) |
[Imagen 2]
Trama VRRP V2
[Imagen 3]
Trama VRRP V3 1
Cabe señalar que la principal diferencia entre las dos versiones del protocolo, más allá de la compatibilidad con IPv6, es que la versión 3 del VRRP elimina por completo cualquier mecanismo de autenticación, dando por sentado que la seguridad queda garantizada por mecanismos externos (como IPSec, segmentación VLAN o ACL).
Keepalived... y el descubrimiento de una vulnerabilidad en el RFC
La herramienta utilizada es Keepalived, un programa de enrutamiento para Linux que permite implementar el protocolo VRRP en este sistema operativo.
1. Ejemplo práctico con Keepalived
Durante esos numerosos estudios y auditorías, Geoffrey se dio cuenta de que la mayoría de los entornos VRRP carecen de seguridad o tienen muy poca.
Para montar una maqueta que cumpliera con las recomendaciones (uso de un ID 255 y de la IP más alta posible de la red en el router designado, uso del modo unicast), utilizó varios equipos Linux con Keepalived.
Dado que la red no estaba segmentada, o no lo estaba lo suficiente (los equipos de los usuarios se encontraban en la misma VLAN que
Una vez montado el entorno de prueba, añadió un «router pirata» con el ID 255 y, mediante este router pirata (rogue router), difundió tramas VRRP, con lo que logró tomar el control de la red (se convirtió en el router maestro).
Se han probado varias configuraciones y, en todos los casos (incluso con un router secundario con una prioridad inferior a la del maestro), este se ha convertido en el maestro de la red.
La pregunta es, pues, la siguiente: ¿Se trata de una vulnerabilidad (CVE) de Keepalived?
2. Detección de una vulnerabilidad crítica y corrección mediante una nota de corrección
El fallo no es un CVE, ya que Keepalived cumple al pie de la letra con el RFC 9568 (que define el protocolo VRRP).
No obstante, Keepalived ha publicado un parche para corregir el fallo, pero afirman que cumplen con el RFC.
Una vez aclarada la duda con el IETF, queda claro que el RFC es el origen del fallo
Además, el fallo no se produce en los equipos de Cisco, ya que estos aún no han implementado la última versión del RFC.
En realidad, los paquetes VRRP con prioridad 255 no se descartaban realmente («se ignoraban antes de su procesamiento»), lo que impedía el funcionamiento de los mecanismos de desempate IP y tenía como consecuencia que el router con prioridad 255 escuchara los paquetes y redujera su prioridad.
La errata 8298 fue validada por el IETF pocos días después de su publicación por parte de los equipos de Keepalived.
Conclusión y recomendaciones
La conferencia puso de manifiesto una grave vulnerabilidad en el protocolo VRRP, demostrada mediante Keepalived, con un impacto concreto: un atacante local puede suplantar fácilmente la puerta de enlace predeterminada. Aunque las buenas prácticas de red (segmentación, filtrado, supervisión) reducen este riesgo, esto pone de relieve una debilidad conceptual de VRRP que los ingenieros de redes deben tener en cuenta.
Se pueden dar las siguientes recomendaciones:
En primer lugar, si se utiliza VRRP V2, se recomienda utilizar la autenticación IPSEC (si es posible).
Al igual que en VRRP V2 y V3, es importante configurar el protocolo en modo unicast para evitar que se intercepten los mensajes de red y para poder reconstruir una configuración VRRP no autorizada.
También es necesario respetar un sistema de direccionamiento y un orden de prioridades VRRP estrictos para todos los routers.
También es importante segmentar adecuadamente la red para evitar ataques de tipo «man-in-the-middle».
