Using Strong Authentication
The easiest way to partly mitigate an HSRP attack is to use strong authentication. Cisco routers and switches running 12.3(2)T and above can use a message digest algorithm 5 (MD5) Hash Message Authentication Code (HMAC) to authenticate all HSRP packets without ever sending the key in the clear. Example 9-1 shows the syntax when you use a chain of preshared keys: Each key has a send lifetime (when this key sends HSRP messages) and an accept lifetime (when this key checks the validity of received HSRP messages).
Why Key Chain?
If a hacker compromises a router, he can recover the current preshared key used for HSRP and forever use this key. Therefore, it is a good security practice to change the preshared key every year. This limits the time span when the hacker can use the stolen key. This key change is called a key rollover.
The rollover requires good synchronization among all participating routers so that they all start to use the new preshared key at the same moment. This synchronization can be difficult to achieve when Network Time Protocol (NTP) is unavailable. Key chain is an interesting alternative: It does not require accurate timing, and the configuration change can be prepared days in advance.
The key chain allows for flexibility. If the accept lifetime range is larger than the send lifetime range, such as in Example 9-1, the key 2 is used since January 1, 2007, to send the authenticated HSRP message and all other routers will accept the HSRP message since December 31, 2006. So, even if the clocks between routers are not synchronized (like 1 or 2 hours of difference), the key 2 is accepted by all other routers in the HSRP group.
|
key chain MYCHAIN |
|||||
|
key 1 |
|||||
|
key-string TheOldKey |
|||||
|
accept-lifetime local 12:00 |
00 Dec |
31 2005 |
12:00 |
00 Jan |
1 2007 |
|
send-lifetime local 00:00:01 |
Jan 1 |
2006 23 |
59:59 |
Dec 31 |
2006 |
|
key 2 |
|||||
|
key-string TheNewKey |
|||||
|
accept-lifetime local 12:00 |
00 Dec |
31 2006 |
12:00 |
00 Jan |
1 2008 |
|
send-lifetime local 00:00:00 |
Jan 1 |
2007 23 |
59:59 |
Dec 31 |
2007 |
|
interface FastEthernet0/0 |
|||||
|
ip address 192.168.0.3 255 |
|||||
|
standby 2 ip 192.168.0.254 |
|||||
|
standby 2 authentication md5 key- |
chain MYCHAIN |
||||
With this configuration in place, an attacker has no way to discover the preshared key that's currently in use. Therefore, an attacker cannot send forged HSRP messages that the real HSRP routers accept and process.
NOTE Rather than using the configuration in Example 9-1, where a key chain is used, use a simpler method by directly specifying the preshared key. But, if you ever have to roll the keys, this simplicity complicates your life.
Mitigating HSRP Attacks 153
As shown in the third line at the top of Figure 9-5, when MD5 HMAC is used (in this case, messages sent by 192.168.0.3), Yersinia can no longer access Authentication Data and is unable to launch any attack. The same applies for the hsrp tool from the IRPAS package.
Figure 9-5 Yersinia Cannot Decode Authentication Data with MD5 HMAC
The information in Figure 9-5's middle rectangle is the hexadecimal dump of the second HSRP packet. The key was also SeCrEt (as for messages from 192.168.0.7 and 192.168.0.9) but it appears nowhere in the displayed packet because Yersinia was unable to recover it.
Is this MD5 HMAC alone enough to secure HSRP? Actually, no, because it does not stop a replay attack. Here is how to mount a replay attack: If an attacker can sniff a copy of an HSRP packet with high priority, he can replay this packet by resending it unchanged (including the virtual source MAC address), and the attacker immediately becomes the active router. Therefore, the port security feature described in Chapter 2, "Defeating a Learning Bridge's Forwarding Process," must also make the MD5 HMAC secure.
Continue reading here: Discovering VRRP
Was this article helpful?