[c-nsp] securing a vrrp setup

Paul Cosgrove paul.cosgrove at heanet.ie
Fri Dec 28 15:39:13 EST 2007


Joerg mentioned that syslog traps will be activated if the master 
changes, however both routers will see themselves as the master and 
neither will relinquish that status for an apparently misconfigured 
neighbor.

If an attacker configures a rogue VRRP server with the same virtual IP 
as the legitimate server, but different authentication, they may use the 
same or a different VRRP group number.
With the same group number the switch would alternate between directing 
traffic to the legitimate server and to the rogue server, as its CAM 
entry was changed by packets being sent by each device (such as VRRP 
hellos).  I guess that if the rogue server uses a different VRRP group 
as well then the ARP entries on other devices for the VRRP virtual IP 
address may also change.  On occasions I think this can cause the two 
routers to continue repeating arp replies in an attempt to override the 
other router's response, resulting in flapping in the arp table of the 
client which originated the arp request.

If I understand you correctly then the attack would really be aimed at a 
Virtual IP/MAC address, so it is a generic attack aimed at the layers 
underneath VRRP.  Similar effects would be seen if you targeted an OSPF 
next hop or HSRP address instead.

As Joerg mentioned, if you want to stop this you could apply mac and ip 
access-lists to switch access ports, e.g.

ip access-list standard 1
    deny   <vrrp ip address>
    permit any

mac access-list extended DENY-ARP-FROM-VRRP
    deny   0000.5e00.0100 0.0.00FF any 0x806 0x0
    permit any any

int range fa0/1
  ip access-group 1 in
  mac access-group DENY-ARP-FROM-VRRP in

You could instead use IP Source Guard and Dynamic ARP inspection, which 
would offer broader protection.


Paul.


More information about the cisco-nsp mailing list