This article helps you to obtain the right track towards a sensible, correctly organized policy that is easy for you and other administrators you may work with.
USEFUL RULE TITLES AND COMMENTS
Do not think that you are the only person to ever have to review or administer your policy. Rule comments are even more useful, because you can use far more characters in this field. If you have a ticketing system that is associated with change control, put ticket numbers here along with a brief, helpful description of the function of the rule. Write something that you would want to read if you troubleshoot the policy with no prior knowledge of it.
SENSIBLE RULE SECTIONS
This especially applies to larger policies. You may want to divide your Firewall policy into sections based on the type of access, if it is management access, outbound, inbound, or anything else including VPN rules and temporary rules.
There is nothing worse than trying to hunt down a particular rule in a 500+ rule policy and having no idea where to start looking. It will also help with ability to quickly identify the best location for a new rule when it is being written.
USE STEALTH AND CLEANUP RULES
A stealth rule is a rule that should be located as early in your policy as possible, typically immediately after any Management rules. The purpose of this is to drop any traffic destined for the Firewall that is not otherwise explicitly allowed.
You normally do not want anyone on the Internet to be able to directly interact with your Firewall in any way outside of VPN client access and a few other special cases. A cleanup rule is simply a rule at the end of your policy to drop any traffic that is not explicitly allowed.
Ideally, both your stealth and especially your cleanup rule should be set to log for troubleshooting purposes. If there are especially chatty services that are quickly filling up your logs, you can create additional drop rules above the stealth rule to drop them without logging them.
USE DATABASE REVISIONS
Database revisions are your best friend, but they are often forgotten. If you perform anything that can be considered a major change, create a fresh database revision before beginning. A good example of this would be deleting unused rules or any changes such as staging an IP cut over or deleting old VPN communities.
On the other hand, there is an option in the policy installation dialog to automatically create a database revision every time that policy is installed. If your organization’s policy does not require this, it may fill up disk space faster than expected and cause issues down the road during upgrades.
Database Revisions can be removed manually in SmartConsole, File -> Database Revision Control or you can configure them to be removed automatically.
For details on how to delete database revisions automatically, see sk94047 - How to set configure automatic deletion of Database Revision Control versions with 'dbedit' tool
TAKE ADVANTAGE OF RULE HIT COUNTS
If both your Security Gateway(s) and Security Management server, ensure that the Hit count function is enabled. It is customizable as to how long of a period you want the counter to show, and it is invaluable for identifying and disabling or removing unused rules. This is another technique that is extremely useful for keeping larger policies down to a more manageable size.
If you have rules that haven't had hits in 3-6 months, disable them and move them to a section of the policy that you have designated so that they can subsequently be removed.
RULEBASE INSTALLATION PERFORMANCE
Unused objects and duplicate objects will increase the policy verification time. Avoid creating duplicate objects and delete unnecessary objects. Cleaning up these objects can greatly improve the overall policy installation time.
Check Point Professional Services can assist with identifying the unused and duplicate objects and can create a custom scripts to clean-up the objects.
Related Solutions
sk106597 - Best Practices - Rulebase Construction and Optimization
