Tuesday, February 27, 2007

Making firewall ruleset details available to system administrators

In many environments, firewall configurations are a mystery to the administrators whose machines are protected by them. Often, firewall admins and operators receive questions like "Can machine X talk to protected machine Y, and on what ports?" or "Should my traffic get through from A to B?". The black box approach to firewalls can drive a wedge between systems administrators who are told to make the application work right now, and security folks who want to lock it down and keep it clean.

How can we fix this?

Most firewall systems can provide a text based rule dump. With some cleverness, and a reasonably sharp programmer, this text based rule dump can be built into a rule checking application and made available with appropriate authentication. Firewalls also generally include a useful syslog utility that includes information such as details ofblocks.

What does this do?

Now systems administrators can check if traffic is passed by a rule, or if it is blocked. They can also make more intelligent requests for changes based on what they already have open. If you add the ability to see blocked traffic from the firewall's syslog, administrators can also check to see what their systems are doing that they aren't aware of, or if a badly behaved application is doing something that the documentation (or lack of documentation) doesn't mention. This is great when that new application or appliance is dropped off and something mysteriously isn't working, or you want to see how chatty the box is.

Rulesets can also benefit from the increased transparency by becoming more accurate, and can require less time from the firewall operator when they no longer have to track down requests for "whatever ports the new system is trying to use".

Does this decrease the security of your organization? That depends on the mode that your firewalls operate in and what your local security policies are. If rulesets are considered highly confidential information, and administrators operate in a black box, yes, having this information available means that they can see what you have built. Security via obscurity rarely does more than delay the inevitable however, and the benefits can easily outweigh the negatives. If your firewalls operate through a standardized change system, or if you have a relatively ad-hoc process, making the rules visible can make all the difference in how sysadmins think about firewalls and firewall rules - and about those pesky security guys.

I've worked with a number of administrators with varied degrees of security knowledge, and every one of them has been delighted to have this information available to them. Simply plugging two IP addresses into a form and seeing what ports are open, or checking if port 80 TCP traffic can get to a system, and where it can come from means that their troubleshooting process can be greatly simplified. This puts control back into their hands, rather than making the network a mysterious black box.

If you build it, they will come. When they do, here are a few suggestions:

  • Limit access to the rulesets or machines to the appropriateadministrators. If you have an Active Directory environment, limit access to the rules for it to those administrators who actually manage it.
  • Make sure your users understand how and when updates to the systemare made. If you pull rulesets once a day and parse them at midnight, let them know that. Hours can be spent troubleshooting something that was fixed during a change window which your system hasn't picked up.
  • Test the system: look for ways it can fail. A bi-directional firewall ruleset might allow traffic in but block it on the way out, and if your application can't display that, issues will abound.
  • Ask your administrators what they need to get their jobs done. Giving then input into the tool can make it much more effective.
  • Make the tool generic - a plug-in architecture helps make your life easier when you change firewalls, syslog formatting, or your vendor updates a field in a patch bundle.

No comments: