The PhoneBoy Blog

FireWall-1 FAQ: What Order Does FW-1 Apply The Rulebase?

Last Modified: 30 Dec 2001

Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.

I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.

If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)

Various versions of the FireWall-1 documentation state that the rules are examined in the sequence they are presented in the rulebase. This is generally correct, but you must also take into consideration what is permitted by the “Properties” screens. The “Properties” rules will be enforced appropriately with respect to your rulebase. This means Properties rules marked “First” will be applied before your rulebase, “Before Last” will be applied between rules n-1 and n, and “Last” will be applied after your last rule.

There is one case where FireWall-1 does not process the rules in order but instead uses the rule that is most permissive: when authentication for HTTP, FTP, telnet, and rlogin is used and such a rule is matched in the rulebase. If during the in-order packet processing a rule matches the packet and it uses the security server for authentication (i.e. User Authentication), the rule that ends up being enforced is the “least restrictive” one. Client Auth, Session Auth, and content security rules are processed in-order.

To give you an idea of what this means, consider the following security policy:

Based on the rules and how the rulebase rules are applied, here is how things will apply themselves:

• Everyone on the Internet will be able to access the http, smtp, and ftp server without any authentication from the firewall.
• Mail will flow between the internal and external smtp servers.
• Users in the DMZAdmins group who telnet or ftp from the internal-nets to the ftp server in the dmz-net will have authenticated access to all servers in the dmz-net. However, rule 3 appears before rule 5, so they will not be required to authenticate themselves at the firewall nor will their connection be folded into the appropriate security server. Ordering the rules differently will not solve this problem, but it would cause the connection to be folded into the security servers. If they were in different order, the more permissive rule would still apply (the current rule 3), so it wouldn’t accomplish much.
• You might think people who telnet from the internal-nets the firewall would get prompted for authentication by FireWall-1 because of rule 6. However, rule 9 is more permissive, so users are not authenticated by FireWall-1 when accessing the firewall via telnet. To fix this, you can simply change the destination field of rule 9 to read “NOT firewall”.
• When users on internal-nets attempts to access web sites via HTTP and FTP, they will be filtered according to the uri_filter and ftp_filter resources respectively. Accesses to ftp-server and web-server will not be content filtered because rules 1 and 2 also match traffic coming from internal-nets. These connections would not be folded into the HTTP Security Server, either.
• All other types of traffic should be dropped per rule 10.

So what is a good “rule of thumb” when ordering the rules in your rulebases? Here’s how I typically order my rulebase based on action types:

1. SecuRemote Encryption rules
2. FireWall to FireWall Encryption rules
3. Incoming “accept” rules
4. Outgoing “accept” rules
5. Client Authentication rules
6. Session Authentication rules
7. User Authentication rules
8. Clean-up rule