[c-nsp] securing a vrrp setup

[Paul Cosgrove]

The mac acl I included as an example should not have been so specific. 
The packet that the attacker sends does not need to be a VRRP IP packet. 
Any frame sent from the VRRP group mac address would cause an update in 
the switch CAM table, so the mac address acl should filter all frames 
with a source address in the VRRP range instead of just ARPs.  The IP 
information does not need to match in order for this to happen, any IP 
details could be included as the switch is only being interested in 
layer 2.  A frame sent with the VRRP group mac address as it's source, 
and another known mac address (say of a host) as the destination would 
not arrive at the legitimate VRRP router so would generate no messages.

Paul.

bangky wrote:
> Hi Paul,
>
> Thanks for suggesting IP source guard. I have previously heard of this 
> but have only just read up on what exactly it does.
> It should be a suitable solution for this problem.
>
>     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.
>
> Btw, with regards to the above, while trapping may not occur as there 
> is no change of master status, IIRC there will be notification of a 
> VRRP message received with incorrect authentication information.
>
> Once again, thanks to all who have kindly suggested solutions to my query.
>
> --
> bangky
>
> Paul Cosgrove wrote:
>> 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.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>   
>