RE: NIDS/NIPS implications on HSRP

["Murtland, Jerry" <MurtlandJ () Grangeinsurance com>]

Another event that may trigger HSRP to send out packets outside of your
primary and secondary router is another router coming online.  This will
then cause an HSRP 'hello' to be sent to the 3rd router.  One issue that I
have recently uncovered is that if a 3rd party router was brought online
(non-cisco) HSRP then sends an MD5 hash to the 3rd party router with the
default password (Cisco).  If you have an IDS sensor in this subnet, this
will obviously trigger an event.  However, this can also be seen as a man in
the middle attack if someone from that subnet were vpn'd or connecting from
some other alternative method and compromised to this subnet.  Obiously the
likelyhood of this is exponentially reduced.  The attack can only occur on
the subnet from which the routers reside.  However, the false positive of
seeing a DoS attack with HSRP default password compromised isn't a fun
exercise.

Jerry


-----Original Message-----
From: Jason Wright [mailto:jason () nfr net]
Sent: Tuesday, August 24, 2004 3:56 PM
To: focus-ids () securityfocus com
Subject: Re: NIDS/NIPS implications on HSRP


In-Reply-To: <20040823170917.M24933 () packetinfo net>

> From what I have been reading, HSRP Hello packets are what determines a 

> failover, and that those should only be flowing between the routers through


> the switch.  This would work fine.  Cisco says that if a device (such as an


> IDS/IPS) inline keeps the line protocol up, HSRP will not failover. 

>

Your theory is right, HSRP/VRRP/whatever packets should be the determing
factor.  Cisco is doing something wrong of they depend on the line protocol
failing as well as the "hello" packets being dropped.



Similiar technology is used in 802.1D spanning tree.  If the topology
packets show a loop or a different path, the topology map in each device is
changed.  If packets don't make it, the network graph is redrawn.



As to what we do:  We have a daemon that monitors the link status for silly
problems like this.  In the event link is lost on interface A, we power down
interface B, and poll for link to come back on A.  Powering down an
interface has the obvious effect of making whatever is off of that interface
lose line protocol.



A little bit of hysteresis is necessary because line protocol negotiation
can take a significant amount of time.  Also, line protocol integrity on
some line cards can "flap" when there is not, in fact, any valid link.



--Jason Wright

  NFR Security

--------------------------------------------------------------------------
FREE Network Security Webinar - How to implement IPSec security into VPN
appliances 
 
New threats and vulnerabilities require new high-performance IPSec VPN
solutions for network protection.
Join the security experts from SafeNet on August 26 at 1:00 PM (Eastern),
and learn how to successfully integrate IPSec security into VPN processors
and appliances to provide powerful yet cost-effective VPN solutions for your
customers. 
Register now:

http://www.securityfocus.com/sponsor/SafeNet_focus-ids_040817
--------------------------------------------------------------------------

--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
--------------------------------------------------------------------------