Wednesday, July 20, 2011

How to Encrypt Your Cisco VPN Pre-Shared Keys

If you are like me and you take the time to harden your network gear you have probably noticed that your VPN pre-shared keys stay in plain text even after applying password encryption. I never liked that. Why bother hardening your router when one of your most important credentials remain in clear text.

Here's what I mean:

VPN config before encryption:
******************************************************************

crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key S3cr3tK3y! address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
******************************************************************

VPN config after encryption:
******************************************************************
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key 6 V\OfYXeLVIdCaeS`HHQINQMBf\UDiG address 0.0.0.0 0.0.0.0

crypto isakmp invalid-spi-recovery
******************************************************************

Now when you look at your config, you can't see the actual key. It is very simple to configure. Here's how:

Go into "configure terminal"

key config-key password-encryption [master key]
password encryption aes

The "master key" is what the router will use to encrypt your pre-shared keys. If you do not enter this when you submit the rest of the command the router will prompt you.

The passwords are not actually encrypted until you enter the second command. After the passwords are encrypted they cannot be unencrypted on the router. You can change the master key if you want to by re-issuing the first command. The router will require you to enter the original key.

You can remove the master key by running:
no key config-key password-encryption

However, any current passwords will be rendered useless. Since the master key is no longer available the router cannot decrypt the password.

That's pretty much all there is to it. Now go out and harden your routers!

Here's a Cisco document on this procedure:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801f2336.shtml




Cisco Access List Using Established Parameter


The above diagram is a rough drawing of my situation. I have two Cisco routers at my headquarters. Each router is on a separate ISP. The store router will create a DMVPN tunnel to each router and use it for failover. That way if we have a problem with a provider at our headquarters the stores can keep doing business as usual.

The store only needs access to a few things at headquarters. I need to keep the traffic from the store network into my headquarters as limited as possible.

I could apply an access list to the store router, but if the store router's physical security is compromised an attacker could perform a password reset and remove my access list. That means I need to apply my access list to the routers at headquarters. I can control their physical security and they would be much more difficult to gain access to.

I asked myself, how can I keep my store access very limited, but still allow any traffic originating from headquarters to get to the stores?

That is when I found out about the "established" parameter for an access list. Here's how it works:

This access list is applied to the outbound direction of the inside interfaces on the headquarters routers.


access-list 110 remark APPLIED TO INSIDE INTERFACE OUTBOUND
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.197
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.161
access-list 110 permit icmp 192.168.10.0 0.0.0.255 host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq snmp host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq 1645 host 172.16.1.203
access-list 110 permit tcp any 172.16.1.0 0.0.0.255 established

Let's break it down:


****Use remarks so you can easily see the purpose of the ACL****
access-list 110 remark APPLIED TO INSIDE INTERFACE OUTBOUND

****Allow traffic from my store to get to the reporting servers****
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.197
access-list 110 permit ip 192.168.10.0 0.0.0.255 host 172.16.1.161

This is the most important to keep up. This section is what keeps my stores doing business.


****Allow SNMP traffic between my server and the store****
access-list 110 permit icmp 192.168.10.0 0.0.0.255 host 172.16.1.183
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq snmp host 172.16.1.183

The SNMP server only needs ICMP traffic and SNMP traffic. This will allow me to know if the router goes down. Now you may say, why do you need these lines in the ACL if the SNMP server is polling the router and the ping is initiated from the server. I thought the same thing and I will explain it in just a minute.


****Allow RADIUS traffic from the store router to my server****
access-list 110 permit udp 192.168.10.0 0.0.0.255 eq 1645 host 172.16.1.203

This line allows my router to send authentication requests to my RADIUS server.


****Allow return traffic for any traffic sourced from headquarters.
access-list 110 permit tcp any 172.16.1.0 0.0.0.255 established

This line checks to see that the traffic headed to the headquarters was previously established from the headquarters.


Now that we have the ACL broken down let's look at the mechanics. Remember this ACL is applied on the OUTBOUND side of the headquarter inside interfaces. On the INBOUND side I am allowing any traffic from headquarters to go to the store. Since this is not a stateful firewall I must account for the return traffic.

The last line in the ACL uses the parameter "established". Basically, this will look at the TCP packet and see if there is an ACK or RST bit set. If the traffic coming is trying to create a new connection it will be denied, but if it is responding to a connection that was initiated from the headquarters network it will be allowed.

Now, back to the lines used for SNMP. While it is true, that the connection for SNMP originates on my headquarters network, this traffic will not be allowed back through without explicitly allowing it. This is because ICMP and UDP are connection-less (SNMP uses UDP ports). In other words, it does not use TCP and it does not have an ACK or RST bit to set.

This is sort of like a stateless firewall. It allows traffic that has already been connected. The difference is we don't know what the traffic is and we are assuming that the traffic is a legitimate response. This is not a replacement for a firewall by any means, but it is a nice enhancement for your access lists.