Resources for the Check Point Community, by the Check Point Community.

Tim Hall has done it again! He has just released the 2nd edition of "Max Power".Rather than get into details here, I urge you to check out this announcement post. It's a massive upgrade, and well worth checking out. -E

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Organizing a messy rule base

Hi guys,
I need your advice and I hope this is the suitable place for this thread, if not please guide me.

I've inherited the management of a Checkpoint R77.30 rule base with about 600 rules.
The rule base is badly organized and has no specific methodology
Some rules are service-oriented, some are source-oriented and some are destination-oriented.

For example:
There's a specific section dealing with DS (port 445) access which is service-oriented - rules here define all communication that allow DS servicesbetween vlans.
However, there are other sections which are VLANs-oriented - rules here define all communication allowed to/from this vlan on different ports, including 445.
So when I want to define a new rule that allows port 445 for example I don't know under which section should I put it.
Also, objects sometimes belong to several groups which on their part belong to similar rules throughout the rule base.
This creates confusion and mess in the rule base and obviessly there are duplicate or overlapping rules for same servers.

What would you say is the best way to define a rule base? by networks/vlans? by services? by destinations?
And where do I start with organizing the current rule base?
to it.

Re: Organizing a messy rule base

Hi, I am by no means an expert but, the way I try to do this:

Firewall communication rules at the top of the rule base - SSH allows, admin access etc.
Followed by your highest hit rules - more than likely browsing allows http/https
Then as the rule base goes on I try to group services together so they are easier to manage.
Add a section title - File Share rules, SSH Allow rules, FTP allow rules etc.

The further down the rulebase would be your more specific rules like HR to external system.

Re: Organizing a messy rule base

There are only two hard problems in computer science. Cache invalidation, naming, zero-indexed arrays, and off-by-one errors.

This is a subset of the naming problem. One of my policies is about 1400 rules long. It currently has around 230 categories, and many are effectively useless. There is no single "right way" to do it, of course. I'm slowly moving towards organization by function.

I have some extremely broad global rules for internal traffic at the top. Things like access to the domain controllers. The only rules allowed in this "global" section are ones with all of RFC 1918 as one of the endpoints. The idea is I don't want anything accidentally overriding these rules.

Second, I have a rule section per "service". This isn't per TCP or UDP port, but rather per application or product in my environment. These sections are for internal communications within the application/product. All the rules in them are effectively host-to-host.

Third, I have rules hooking up the various applications. Product X application servers talking to product Y to use its services, for example. I try to group these based on line of business, but that doesn't always work. I put them below the within-application rules so things here can't accidentally break an application's internal connectivity.

Finally, I have some end-of-policy "global" rules I want things to be able to opt out of. A rule to allow ping from RFC 1918 to RFC 1918, for example.

The goal of this model is to organize the rules like you might organize datacenter cabling. Blue cabling for the servers which belong to this business unit. Green cabling for that one. Red cabling for a third. Purple cabling for out-of-band management. The policy is effectively a layer 4 patch panel, so we can use a lot of the same general techniques.

A lot of my organization is geared towards armoring against misconfiguration. This is because I have a relatively large team (around 35 people spread across the world have write access), and we want to make it hard for one person to make extra troubleshooting work for the rest of the team. The firewall running this policy is cruising at around 10% of one core of processor usage passing ~700 megabits of traffic at any given time. As a result, we are less concerned about technical performance optimization than we are about saving admin time.

As for how to get from where you are to where you're going, I like starting with very coarse categories like I listed above. I build some visually-distinctive rule categories ("##### APPLICATION INTERNAL RULES #####", for example), then start sorting things into them. Once I have the rules sorted down into just a few, extremely large categories, I start making smaller categories between the big ones ("## PRODUCT_X INTERNAL RULES ##") and pulling things out of the big categories and into the smaller ones.

Over time, I'm trying to replace all of the hosts and networks and anything else in my rules with groups. This also helps guard against misconfiguration. When you have ten rules with the same three hosts in the source, and you need to add a fourth, it's easy to miss one. Doing it with groups lets you make the change one time, and it just works everywhere. Seems obvious, I know, but the previous admins here did everything by putting host objects directly in rules. An added benefit is if you name your groups well, your rules start reading like plain English. Makes audits almost comically easy.