Last Modified: January 26, 2000
Building a solid rulebase is a critical, if not the most critical, step in implementing a successful and secure firewall. Security admins and experts all over the Internet argue what platforms and applications make the best firewalls. We compare stateful inspection tables, application based filtering, fragmentation and reassembly, etc. However, all of this is meaningless if your firewall rulebase is misconfigured. Far too often in my security audits I see $50,000 firewalls exposing organizations to great risk, all because of a misconfigured rule. That is the purpose of this paper, to help you plan, build, and maintain a solid and secure firewall rulebase. The information covered here applies to most firewalls, but I will be using Check Point FireWall-1 as an example. Regardless of what type of firewall you use, the basic concepts of rulebase design remain the same.
The Key to Success
Before we jump in, I would like to share with you the key to success, simplicity. The key to a secure firewall is a simple rulebase. Your organization's number one enemy is a misconfiguration. Why should the badguys try to sneak spoofed, fragmented packets past your firewall when you have accidentally left imap wide open? To keep your rulebase simple, keep it short. The more rules you have, the more likely you or someone else will make a mistake. The fewer rules your rulebase has, the easier it is to understand and maintain. By keeping your rulebase short and simple, you have won half the battle. A good rule of thumb is to have no more then 30 rules. With 30 rules, its relatively easy to understand what is going on. Between 30 and 50 rules, things become confusing, the odds grow exponentially that something will be misconfigured. Anything over 50 rules and you end up fighting a losing battle. I personally have witnessed organizations with over 300 rules in their rulebase, nobody (including myself) had a clue as to what was going on. When you start having this many rules, you need to take a serious look at your overall security architecture, and not just your firewalls. The moral of the story is, the fewer rules you have, the simpler your rulebase and the less likely you are to have misconfigurations (and a more secure firewall).
Fewer rules have the added bonus of improving performance. By parsing only a small number of rules, your firewall saves CPU cycles. Most firewalls are extremelly efficient, so you will see little difference. But it can never hurt.
Building Your Rulebase
So, how do we build a secure rulebase? Well, we will do just that in this paper. We will go through step by step and build a firewall rulebase. We will start with a fictional organization's security policy. Based on that policy, we will then develop a firewall rulebase. Along the way, I will cover some of the Do's and Don'ts of rulebase configuration. Also, we will cover rules that every firewall should have. Hopefully by the end of the paper you will have a better understanding of how to build a secure rulebase for your organization.
The Security Policy
Remember, your firewall (and your firewall rulebase) are nothing more then a technical implementation of your security policy. Management builds the security policy, which defines what is to be enforced. The firewall is a technical tool, which is how the policy gets enforced. So, before we start building our rulebase, we have to understand our security policy. Since this paper focuses on rulebase design, we will keep our security policy relatively simple. Fortunately for us, our organization has a simple security policy, which management has outlined as follows.
The Security Architecture
As a security administrator, our first step is converting the security policy to security architecture. Lets now go through and convert each security policy bullet into technical implementation.
Before we begin building our rulebase, there is one thing I want to cover, rule order. As you will soon learn, which rules go in what order are critical. Having the same rules, but placing them in a different order, can radically alter how your firewall works. Many firewalls (such as SunScreen EFS, Cisco IOS, and FW-1) work by inspecting packets in a sequential manner. When your firewall receives a packet, it compares it against the first rule, then the second, then the third, etc. When it finds a rule that matches, it stops checking and applies that rule. If the packet goes through each rule without finding a match, then that packet is denied. It is critical to understand that the first rule that matches is applied to the packet, not the rule that best matches. Based on this, I like to keep the more specific rules first, the more general rules last. This prevents a general rule being matched before hitting a more specific rule. This helps protect your firewall from misconfigurations. To learn more about how a firewall state table works, check out Understanding the FW-1 State Table.
Time to get to the good stuff, building the rulebase! Below I
have briefly outlined each rule, why I selected that rule, and the importance
it has. To go into more detail on the rule (including a picture of
the rulebase), follow the links.
Once you have all your rules in place, I highly recommend you update them with comments, and keep them updated. Comments help you keep track which rules do what By having a better understanding of the rules, there is less chance for misconfiguration. For larger organizations with multiple firewall admins, I recommend the following information be put into comments whenever a rule is modified. This will help you track who changed which rules, and why.
Once you have finished your firewall rulebase, it is critical that you test it. We all make mistakes its the good admins who follow up and find them. To learn more about testing your firewall rulebase, check out Auditing Your Firewall Setup.
A firewall is only as good as it's implementation. In today's
dynamic world of Internet access, it is easy to make mistakes during the
implementation process. By building a solid and simple rulebase,
you create a more secure firewall.
Lance Spitzner is an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home. Before this, he was a Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at firstname.lastname@example.org .