[c-nsp] securing a vrrp setup

[bangky]

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/
>