Tuesday, January 12, 2010

ASA, ASDM, and longevity

I have spent the last several day cleaning up firewall configurations. These were brand new, out of the box firewalls and in less than a year their configuration was utter crap. I blame this on two things the administrator and the ASDM gui.

I blame the administrator, for relying soley on the GUI and operating under the impression that it doesn't matter how the changes are made. Let me assure you...it does.

I blame the ASDM GUI for all of the extraneous crap that it puts in the configuration. Some are due to the administrator not using it correctly, and some of it is just the way the GUI works.

Let me just give a few do's and don'ts to ASA management:

  1. DO use object-groups in rules. Let's face it, it's easier to update one object-group than multiple rules.
  2. DO use descriptive names for object-groups and access-lists. When troubleshooting it's much easier when you know what things are.
  3. DO NOT accept the default names the GUI assignes for anything. It is for this reason that I have object-groups like DM_INLINE_NETWORK_1, interfaces name OUTSIDE_VPN_VLAN999, and access-list named OUTSIDE_VPN_VLAN999_access_in

Now, there are few other tips I have, these are really dependent on your site...but I find them to be pretty standard:

DO NOT use interface access-lists for your VPNs:

I've seen this done at several places, and honestly I don't know why. This actually introduces a new risk..especially if public IPs are used on both ends of the tunnel.What happens if the tunnel configuration is removed, but the ACL is not? The traffic will go out the interface unencrypted.

DO use VPN filters to apply ACLs to VPNs:

group-policy tunnel-name-filter internal
group-policy tunnel-name-filter attributes
vpn-filter value access-list-name

tunnel-group peer-ip general-attributes
default-group-policy tunnel-name-filter

Now, if we use descriptive names...we can tell which ACLs pertain to which tunnels.

DO NOT use names in the configuraiton:

no names

This is really just a preference, but when troubleshooting I like to be able to run the command 'sh access-list | in 12.234.45.6' and get all rules associated with that host. If I have names, I would first need to resolve that host to the name configured and then search for the name.

What happens if the hostname has changed or the host is known by several names?

DO AUDIT your firewall periodically:

Now, if you've followed the tips I've laid out auditing should be able to breeze. Simply capture the output from 'show access-list'. It's in cvs delimited format with the [space] as the delimiter. You can easily import into EXCEL.

Now if your object-group names are descriptive...you should be able to tell what each rule is for and since the object-groups are expanded..you can verify all of the IPs that have access. You can annotate the excel with the any POC information for a set of rules, justifications, etc.. that you will need during your audit.

In my experience by following these tips, you will have a firewall that is easy to manage for years to come. Troubleshooting issues is simpler, since you can visually distinguish what ACLs and object-groups apply.

I have to thank my mentor at Sun Sam Munzani, who casually mentioned these tips to me as he handed off some ASA firewalls. It was immediately clear the genius behind it the first time I had to audit the firewall. It was also amazingly simple to troubleshoot issues.

No comments: