Manage Your Firewall Rulebase Closely

Does your firewall rulebase remind you of that drawer in your kitchen where you throw all sorts of miscellaneous junk but can't ever seem to find anything? If so, you're not alone.

A recent survey of firewall administrators revealed that 49 percent feel that it is likely their rulebases contain undetected errors. Depending upon their severity, the consequences of these errors might range from an annoyance to a serious security risk.

Firewall configuration errors come in a variety of forms, ranging from simple typos made by administrators entering the firewall rules to orphaned rules that point to decommissioned systems. It’s important to examine the classifications of firewall errors and their impact on your security posture and find ways to resolve this problem in your organization.

Common FIrewall Rulebase Configuration Errors

One of the most common errors found in firewall rulebases is the orphaned rule. These rules occur when system administrators request a firewall rule to allow access to a service and then later decommission the service without requesting the removal of the rule. This is a very common occurrence, as administrators always remember to ask for a rule when they need one (otherwise their service won't work), but often forget to request the removal of a rule when a service ends because there are no adverse consequences.

Many rulebases contain promiscuous rules that allow more access than necessary. Often, administrators create these rules as part of a troubleshooting process — to eliminate the firewall as the source of a problem, they simply create a rule that allows all traffic to pass to the affected system. This is a clear security concern, as it violates the principle of least privilege by allowing unnecessary access to the system. In fact, it's the equivalent of placing the affected system outside of the firewall.

Redundant rules perform no function whatsoever and clutter your rulebase unnecessarily. They occur when two or more rules allow the exact same access to a system. These occur frequently in large firewall rulebases when administrators fail to check whether a rule already exists before creating a new entry in the rulebase.

Similar, but more troublesome, are the shadowed rules that occur when a general rule positioned high in the rulebase (such as "allow HTTP access to all servers in the DMZ") preempts a more specific rule positioned lower in the rulebase (such as "deny HTTP access to DMZ server X"). If both rules specify activity that is allowed, shadowed rules are an innocuous annoyance. However, if the shadowed rule is meant to deny access to a particular system, the improper order creates a serious security risk by failing to implement your desired security policy.

So What?

At this point, you might ask yourself: "What's the big deal about all of these errors? Most of them just involve rules that aren't needed but don't create much risk." That's an understandable but dangerous view. In fact, erroneous rules can introduce significant risks to an organization, both directly and indirectly.

In the case of promiscuous and shadowed rules, the risk is clear. These types of errors can create significant direct risk to an organization by allowing unintentional access to systems in your environment. In the worst case, they might negate large portions of your intended security policy. The discovery of these errors is cause for significant alarm and immediate action, including a security assessment of the systems impacted by the error.

The unmanageable size of many rulebases is directly attributable to orphaned, shadowed and redundant rules cluttering their contents. One organization with a rulebase topping 700 entries recently discovered that more than 40 percent of the rules were never triggered. This makes the job of the firewall administrator much more difficult.

As a rulebase grows, the difficulty of maintaining it increases disproportionately. It's considerably more difficult to maintain a 400-rule firewall than a leaner one containing only 50 rules. In fact, the bloating presence of these errors makes it more likely that even more errors will accumulate because administrators might have a hard time determining whether a requested rule already exists and so might add redundant rules to the firewall.

Getting on Top of the Problem

Fixing problems in your firewall rulebase isn't a glamorous task, but just like cleaning out your kitchen drawer, it's certainly possible. Once you've tackled the problem, you'll be glad that you invested the time.

Unfortunately, like any spring cleaning project, scrubbing your rulebase is not a terribly exciting exercise. It can be tedious work requiring a careful eye. Some common techniques include:

• Analyzing firewall logs: Most firewalls allow you to log all activity to an external server and include a field that identifies the firewall rule responsible for allowing and/or denying each connection. If you let these logs accumulate over a long period of time, you can write a simple script that parses them and produces a list of the unique rules triggered over the course of the logs. Comparing this to a list of all rules on the firewall identifies potential orphaned rules.
• Looking at denied traffic on host firewalls: Host firewalls are an often-overlooked source of great information. If you parse through the logs and identify traffic from outside your network that should have been denied by the network firewall, it's likely that you have a promiscuous rule or shadowed rule on your hands.
• Performing regular rule reviews: In addition to these automated techniques, there's no substitute for an old-fashioned rule-by-rule review of the firewall. In addition to helping identify configuration errors, rule reviews provide a good reminder of the contents of your rulebase. It's a good idea to conduct these reviews on at least a quarterly basis.

Once you've cleaned up your rulebase, make a resolution to stay on top of it and prevent it from turning back into a state resembling that kitchen drawer. You might want to put a recurring reminder on your calendar to prompt you to perform a rulebase review and rerun your automated analysis. Good firewall rule hygiene leads to happy firewall administrators.