Connecting the world…

HSRP

HSRP and ACL’s

I added a Guest VLAN to a network environment with two multi layer switches running HSRP. To secure the internal network from the Guest VLAN, I added a ACL to the Guest VLAN SVI. The ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any
remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The ACL allows querying the DHCP server to obtain the necessary IP address. Next the ACL denies access to all RFC 1918 IP addresses, which are used on the internal LAN segment of the customer. The last two statements allow HTTP and HTTPS access to the Internet.

At first, I just applied the ACL to both the multi layer switches and thought I was ready. After configuring some other tasks and finishing my work, I always check the configuration. Looking at the show standby brief output, I noticed that the primary HSRP switch didn’t have any standby switch anymore, as show in the output below:

Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl1            1    200 P Active    local         10.1.0.3          10.1.0.1
Vl2            2    200 P Active    local         unknown         10.1.2.1

Because the only change was applying the ACL to the SVI, I already know where to search to correct the problem. Adding a deny ip any any log statement at the bottom of the ACL gave me the information I needed to know.

05:48:09.366: %SEC-6-IPACCESSLOGP: list GUEST-DENY-RFC1918 denied udp 10.1.2.2(1985) -> 224.0.0.2(1985), 360 packetsde

The ACL is blocking the multicast HSRP packets. Looking at the log output, you can see that the HSRP multicast IP address is 224.0.0.2 and port UDP/1985 is used. The multi layer switch is using his SVI IP address as source in the HSRP packet.

I changed the ACL on both multi layer switches by adding a statement to allow the HSRP packets. The new ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any

remark Allow HSRP PACKETS

permit udp host 10.1.2.[2|3] eq 1985 host 224.0.0.2 eq 1985

remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The HSRP packets weren’t blocked anymore after applying the new ACL to the SVI’s. The primary multi layer switch got his secondary switch back.

Applying an ACL to a SVI happens more often, so it is important to remember if you are running some sort of special protocol on the SVI or somewhere else in the configuration when applying an ACL.

Looking at the Internet I found a nice article on Aaron’s Worthless Words blog about multicast addresses, port numbers and associated protocols.

Secure HSRP configuration

A friend of mine works for a well known auditing and penetration testing company in the Netherlands. Recently we were talking about how he starts looking for flaws in network infrastructures. My friend told me that the first thing he does is simply starting WireShark and start looking at all the packets he receives.

By default packets like DTP (Dynamic Trunking Protocol), CDP (Cisco Discovery Protocol) and HSRP (Hot Standby Routing Protocol) are broadcasted through all the different edge ports of a switch. Tools like Yersinia can be used by hackers to exploit these packets.

Normally when I configure a switch I always stop the broadcasting of DTP and CDP on normal edge ports, at least if possible. CDP is often used in conjunction with IP phones. I prevent broadcasting DTP and CDP with the following commands:

no cdp enable

switchport nonegotiate

To be honest, I never thought about the broadcasting of HSRP packets. I created a simple test environment with one Cisco Catalyst 3750G switch and configured VLAN 1 with HSRP, like shown below.

interface Vlan1
ip address 10.10.10.2 255.255.255.0
standby 1 ip 10.10.10.1
standby 1 priority 150
standby 1 preempt
end

This is the most default way of configuring HSRP. By using a tool like Yersinia, somebody could take over the role of active HSRP router by spoofing HSRP packets with a higher priority then the current active HSRP router. So I added a simple authentication text string to the configuration with the following command:

standby 1 authentication HSRP@ICT

This is no success, because when I start WireShark the authentication string is sent in clear text. The picture below shows an example:

HSRP-auth-string

In most recent software version you can protect HSRP by using MD5 Authentication. MD5 authentication provides greater security than plain text authentication. This feature allows each HSRP group member to use a secret key to generate a keyed MD5 hash of the packet that is part of the outgoing packet. A keyed hash of an incoming packet is generated and if the generated hash does not match the hash within the incoming packet, the packet is ignored.

To configure MD5 authentication in the previous example, I added the following configuration to interface VLAN 1:

standby 1 authentication md5 key-string hsrp@ictivity=secure,Ihope timeout 60

Now, when looking at the WireShark output, the key-string is composed of a hash and cannot be easily read by an hacker.

HSRP-auth-MD5

The timeout option is important when configuring a new key-string amongst all the members in an HSRP group. The timeout value is the period of time that the old key string will be accepted to allow configuration of all routers in a group with a new key.

So HSRP MD5 Authentication is another way of making our network components and network infrastructure more secure against “evil” attacks and hackers.