Firewalls are one of the most complicated devices of a network to configure, manage and troubleshoot because every action affects the entire network, its security and all processes. A firewall defines security for a business at the perimeter level. Thus, Network Administrators must be able to effectively manage the firewall to ensure the IT infrastructure is protected against unauthorized access and potential malicious traffic from outside.

The Problem

There are some challenges that might come up over time when managing Security Gateways. Common symptoms are:

• Oversized and inefficient rulebases
• Redundant objects (duplicates and unused)
• Inconsistent naming convention for objects
• Outdated rules and objects

These are bound to happen in most environments as time goes by. Keeping a security management database clean and tidy can be a very time-consuming job.

Best Practices for Well-Designed and Maintained Rule-Base

Following are some firewall management best practices that will be of benefit for all networks and network administration teams.

Strategic Decisions

Use:

• Redundancy: even if takes time, redundancy helps to avoid making mistakes and is a valuable help during troubleshooting. The pattern of Don’t Repeat Yourself is optimal for machine interaction, but here we play with humans, so: repetita iuvant.
• Readable Fields: use a human number of objects in each field. I tend to not exceed the five objects for source/destination/service.
• Standardization: creates a common understanding and avoids conflicts as different people will have different method of doing things.
• Self Documenting: object-naming contains information that helps to understand the function of the object itself. Having simpler or unstructured names for Firewall, Networks, Group, Nodes can create confusion and valuable time can be lost during troubleshooting. A good naming convention aims to give monikers so that the objects that got the name are immediately understood by everyone, be it a help desk employee, a firewall expert or an external consultant. Ideally, they understand the object just by looking at it and without having to read complex documentation. Remember: You are aiming to name things so that humans understand it.

Avoid:

• Group-in-Group: the use of nested groups has its advantages in some cases but requires a very well designed rulebase and every change must be carefully tested to avoid unintended derived accesses.
• Multi Firewall Policies: see Group-in-Group. Normally, both are used in conjunction.
• Timed Rules: every timed rule must have a very good documentation. Additionally, their impact is often underestimated.

General Guidelines to Keep in Mind

The following list shows principles to follow during the manipulation of the rulebase.

1. The firewall rulebase should be as simple as possible. The fewer rules you have the more efficient and less error prone the rulebase will be.
2. Organize the rules to reflect your documentation or your approval process. Do not follow the performance-principle; with today’s machines, in very sporadically occurring cases, performance is really an issue.
3. Configure anti-spoofing for all firewall interfaces. This is still an underestimated last line of defence.
4. Implement the Stealth rule to block and track connection attempts to the firewall module.
5. Implement the Cleanup rule at the bottom of the rulebase to block and log all traffic. Many firewalls, by default, do not log traffic that is dropped. By having the Cleanup rule, logging can be turned on for blocked connections and you can refer to a baseline of dropped connections in case of troubleshooting.
6. Implement the Clean-Log to avoid being flooded by logging of broadcast traffic such as bootp and NBT, create a rule to drop the packets without logging.
7. Do not use bi-directional rules: if a connection requires both directions, create two separate rules.
8. Investigate how an application works before implementing a rule. Example: snmp and snmp-traps normally go in opposite directions, so having both in the same rule doesn’t make sense.
9. Do not use the domain object in the rulebase. Domain objects may cause performance bottlenecks and could modify traffic matrix subtly.
10. Group objects if there are dependencies between different components (example for network objects: if the same objects are necessary for the access-policy and NAT-policy).
11. Group objects if there is a large number of objects in source/destination/service
12. Avoid Group with exception. More often than not, they are not necessary. If there isn’t any other solution, require an exception for the rule(s) using the Group with exception object. But only use this as a last resort.
13. Avoid Negated objects. More often than not, they are not necessary. If there isn’t any other solution, require an exception for the rule(s) using the Negated objects. Again, only use this when there’s no alternative.
14. Do not use multiple Negated objects in source, destination, and service at same time.
15. Use all lowercase characters (Policyname, Objectname, Comments etc.)
16. Do not use special characters (Objectname, Rulename, Comments etc.)
17. Prefer Reject to Drop for some services. Services like ident should be rejected to allow better application performance.

Rulebase Maintenance

Regularly check your objects-base for:

• Unattached objects
• Empty objects
• Duplicate objects
• Unused objects
• Unused objects within used objects

Check your rule-base for:

• Disabled rules
• Hidden rules
• Unused rules
• Non-logging rules
• Rules with empty comment

Act on your findings. Take time to analyse if the change impacts some process, and kick the process to keep operational and organizational database in sync. Do not hesitate to do this. Dependencies between dirty objects can grow rapidly and become very complex to clean the rulebase.

NAT Rules

As you probably noticed, we skipped the NAT Rules. In my experience, NAT-rules don’t need a strategy, they need just a bit of luck. You can try to organize in the typical most-to-less-stringent base, but be ready to run into problems.

Summary

Depending on the size of your rule-base, these guidelines may help or help a lot. In any case, a strategy is something you must have and it’s always a foundation to use the magical tools surrounding the standard rule-base management software. Good process and separation of duties helps to minimize errors and vulnerabilities. Naming Convention creates corporate standard, which everyone observes and understands with ease. Having only few basic principles reduces the complexity of the rulebase and helps to gain time and maintain concentration during critical events.

About the Author

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.