Firewalls - Rules to Rule the Rules

Firewalls

Rules to Rule the Rules

Rocco Gagliardi
by Rocco Gagliardi
time to read: 6 minutes

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:

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:

Avoid:

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:

Check your rule-base for:

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

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

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Office 365 Teams Security

Office 365 Teams Security

Rocco Gagliardi

Phishing Protection

Phishing Protection

Rocco Gagliardi

Logging

Logging

Rocco Gagliardi

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here