Booches.nl

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:

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.

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.

Automatic Log In Reverse Proxy with FBA

Recently I configured another ISA 2006 server as reverse proxy to publish the Exchange 2007 OWA environment on a secure way to the internet. The customer where I configured the reverse proxy is migrating from Novell GroupWise to Microsoft Exchange.

During the migration period, the customer has specific requirements when connecting to the webmail environment from the internet. The customer is using GroupWise and OWA next to each other. He build an own log in page for webmail. The user enters this credentials, which are check against a directory with the help of LDAP. Depending on the LDAP group the user is member of, he is redirected to GroupWise webmail or OWA.

The problem was that when the client gets redirected to OWA, he had to provide his credentials a second time to log in to OWA. The customer wants to use Single Sign On, so the user credentials should be automatically posted on the OWA sign in page. The customer has the option to edit his own sign in page, so specific parameters can be added when redirecting the client to the ISA 2006 reverse proxy.

I had to figure out, which URL is posted to the ISA reverse proxy after the user credentials are entered in the web browser. I started to search the internet and different forums, but the solution wasn’t found. So there was nothing else left, than starting the good old sniffer and capture the complete process. I always use WireShark as sniffer, which is a very powerful tool. I added a filter so only the traffic to and from the ISA 2006 server is captured.

I started the sniffer, logged in on the ISA 2006 server, stopped the sniffer and started analyzing the sniffer results. After some digging I found the POST statement, which is displayed below.

Looking at the POST statements, I now knew the exact URL which is posted to the ISA 2006 server. I copied the URL to notepad, changed the username and password to another account. Copied the new URL and pasted that one in my browser and HIEHOE. After hitting enter, I don’t get any sign in page, but get directly to my webmail. So exactly as the customer wants.

The default POST URL has the following format:

https://<DNS name>/CookieAuth.dll?Logon?curl=Z2Fowa&flags=0&forcedownlevel=0& formdir=1&trusted=0&username=<username>&password=<password>
&SubmitCreds=Log+On

ISA 2006 Authentication over HTTP

I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.

Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.

This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.

I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.

Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)

This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.

Wired 802.1X

The session about wired 802.1X deployment was really interesting. I was stunned about the information I already knew after my testing with MAC Authentication Bypass last week. Of course the speaker had more configuration options when configuring the switch ports.

Important for me to hear where the ways for deploying 802.1X in environments. It isn’t a good idea to just implement 802.1X with some kind of big-bang scenario. Important when implementing 802.1X is choosing the correct identity for authentication and which identity repository you are going to use.

Also good to know is that the actual authentication conversation is between the client and the authentication server using EAP; the switch is an EAP conduit, but aware of what’s going on. In normal 802.1X implementation all traffic is blocked on the port ingress and egress. This can give problems with features like DHCP, BootP, Wake on LAN and so one, like I already posted in my post about MAB.

One thing I learned from the session is using the VLAN name instead of the VLAN ID, when using RADIUS to assign the VLAN. This is because you can have a VLAN with the name Marketing, but the VLAN ID can differ per branch office. The Inaccessible Authentication Bypass feature is also useful for branch offices. IAB assigns the port to a statically configured VLAN when the RADIUS server cannot be reached. After IAB detects that the RADIUS server is online again, it starts authenticating all the ports that weren’t authenticated before.

Summarizing I guess that 802.1X will be the new authentication standard and when implementing 802.1X MAB is a good alternative for non-compliant 802.1X stations.

Cisco IOS Authentication Proxy

Today I have been playing a little with my router at home. I was looking at different websites and stumbled on a Cisco website about Cisco IOS Firewall Authentication Proxy. So I thought by myself, lets give it a try.

Cisco IOS Authentication Proxy is a feature with the following discription:

“The Cisco IOS Firewall authentication proxy feature allows network administrators to apply specific security policies on a per-user basis. Previously, user identity and related authorized access was associated with a user’s IP address, or a single security policy had to be applied to an entire user group or subnet. Now, users can be identified and authorized on the basis of their per-user policy, and access privileges tailored on an individual basis are possible, as opposed to general policy applied across multiple users.

With the authentication proxy feature, users can log into the network or access the Internet via HTTP, and their specific access profiles are automatically retrieved and applied from a CiscoSecure ACS, or other RADIUS, or TACACS+ authentication server. The user profiles are active only when there is active traffic from the authenticated users.

The authentication proxy is compatible with other Cisco IOS security features such as Network Address Translation (NAT), Context-based Access Control (CBAC), IP Security (IPSec) encryption, and VPN client software.”

I already have my router configured with RADIUS for authenticating the CLI sessions. I configured the following commands to enable the Authentication Proxy Service:

aaa authentication login AD group radius local none
aaa authorization auth-proxy default group radius local
!
ip auth-proxy auth-proxy-banner http ^C AUTHENTICATION PROXY FOR ENTERING
THE INTERNET - WWW.BOOCHES.NL ^C
ip auth-proxy name PROXY http inactivity-time 60
ip admission auth-proxy-banner http ^C AUTHENTICATION PROXY FOR ENTERING
THE INTERNET - WWW.BOOCHES.NL ^C
!
interface BVI10
 description Default LAN
 ip address
 ip access-group  in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nbar protocol-discovery
 ip nat inside
 ip auth-proxy PROXY
end

!
ip http server
ip http authentication aaa
!
radius-server host  auth-port 1812 acct-port 1813 key
radius-server retry method reorder
radius-server transaction max-tries 2
radius-server timeout 4
radius-server deadtime 2
radius-server vsa send authentication

After configuring the above configuration I opened Internet Explorer and received the following page:

After I insert the correct user credentials from the RADIUS server, which are my Active Directory credentials, I am granted access to the internet.

When I look at the Authentication Proxy feature, I would never implement it for one of my customers. Or maybe I would implement it for a INTERNET-ONLY VLAN segment or public work places. But I can image it would help in SOHO environments.