Felix Lindner wrote:
>
> This does not prevent remote attacks because Cisco devices do not
> validate the destination address of a HSRP packet. Unicast packets are
> accepted, which can be tested using the hrsp tool at
While technically true, HSRP does provide a basic authentication/validation
mechanism. Best practices would dictate at least the following three:
1. use "standby GROUP authentication TOKEN"
2. filter all 224.0.0.2 traffic at your egress routers
3. filter 224.0.0.2 at each interface participating in HSRP
(1) standby authentication provides a simple (clear text) token that is
shared via your participating HSRP routers. This is a **basic** form
of validating your HSRP partners. If you don't have the right token,
you don't get to play with HSRP (short of any buffer overflow exploits
against the standby auth. mechanism?). This means that someone would
have to get ahold of your Cisco router configs, or sniff the token off of
the local wire.
(2) don't let any HSRP packets into your networks from the egress
(3) each router using HSRP should have an appropriate filter only allowing
HSRP traffic from it's known HSRP partners, this logic should be applied
on a per group basis (i.e. standby group 10 should have appropriate filters,
while standby group 20 should have a different and appropriate set of
filters).
These are all very basic and simple mechanisms that cost nothing, and will
protect against (okay, I'm just throwing a number out here...) 99%+ of all
attacks against your HSRP participating routers. About the only thing I
see as a potential issue is a local resource being cracked into and used to
whack away at your HSRP routers, which would require spoofing source
IPs, etc... (eg the filters). I'm sure someone out there will correct me
if I have any flaws in my strategy here...
v/r
Shane
This archive was generated by hypermail 2b30 : Tue Jun 11 2002 - 11:27:42 PDT