Checkpoint Policy Optimization / Review

[superd]

Hi all,

Ive to peform a policy streamlining / optimization for a client, which will be carried by eye. Its quite a large rule set.

Apart from the obvious checking like rule hits, logs etc, are there any recommendations / tips which might not be that obvious, that could improve or speed up the process, and also reduce risk of impact?

Thanks.

Dave

[the_rock]

Hey Dave,

The best I can think of would be export the whole rulebase into CSV and then have a look at rules with services "any", hits, stuff like that. 

Andy

[superd]

Thanks Andy. Is there a quick way to script the changes back into the FW, or does it have to manually edited from smart console GUI?

[the_rock]

Hm, there might be, but I apologize, scripting has never been my stronger side, sorry brother : - (

I am sending you what TAC sent me couple of years back, though this is little different and via api:

--->To add address-range via API:
mgmt_cli add address-range --batch address-ranges_full.csv

#cat address-ranges_full.csv
name,ip-address-first,ip-address-last
range1,10.0.0.0,10.0.0.100

---> To add a network via API:
mgmt_cli add network --batch networks.csv

#cat networks.csv
name,subnet,subnet-mask
network1,10.10.10.0,255.255.255.0
network2,20.20.20.0,255.255.255.0
network3,30.30.30.0,255.255.255.0

---> To add a host 
mgmt_cli add host --batch test.csv

#cat test.csv
name,ip-address
obj1,192.168.1.1

[PhoneBoy]

Assuming all gateways are R8x versions, rulebase order is less relevant than it was in earlier versions.
However, some services do still disable SecureXL templating.
Check the output of fwaccel stat on the gateway to ensure this isn't happening.

[Chris_Atkinson]

Compliance Blade & SmartOptimize literature may give you some additional hints.

Also be on the lookout for non-FQDN objects and regex using wildcards. 

[superd]

A quick follow up query here - is there any way to export the VPN configs to a readable format so I can observe ciphers / gateways etc?

[_Val_]

I would rather make a new post about it if I were you...

[the_rock]

Good question. personally, Im not aware of it being possible, but lets see what others say.

[PhoneBoy]

In a simple way? No.
The data is available through the API, though.

[Hugo_vd_Kooij]

I find that on a gateway the command `vpn tu tlist` gives a good deal of information to start with.

[the_rock]

@Hugo_vd_Kooij brings up a good point actually! I never thought of it, but you could so something like below from expert mode:

vpn tu tlist > /var/log/vpn.txt

Then file would show you the whole output, yes, its not in csv format, but I guess it could be converted once its off the firewall.

[eliadtech]

Hi Dave.

I've recently gone through something similar.
It's quite hard to articulate all the considerations, but I'll try my best.

I found that creating inline layers was most helpful.

The logic was that I can frame the types of communications (both with ingress and egress):

1. Between internal networks inside my DC.
2. Between external networks and my internal networks.

So, i created an inline layer for incoming traffic for each subnet.
This way, I didn't need to address explicitly egress traffic from one internal network to another.

As for external networks, I've created an ingress and egress inline layers.
Usually, you'd have NAT facing external networks, which should receive traffic only from external networks.
So this NAT subnet is the ingress of course.

Each inline layer ended with an explicit "drop all" rule.
At first I've usually set it to allow all, so I won't cause any downtime by accident.
That was acceptable, because we had an explicit "allow all" rule...

Also, at the top of the policy, I've set a few global rules:

1. Administrative access - not just to the FWs, but also for technicians and sysadmins (they were all inside specific administrative subnets).
   That because they need access to many places around the network, and it would be ineffective to create a specific rule in each inline layer.
2. DHCP rules (they need special attention as per some SK...)
3. All the known drops that I need, e.g. multicast, igmp, etc.
4. Probably a couple more rules which I can't remember now...

One last thing, we had remote braches networks.
I've decided to configure their policies with bare minimum rules.
Meaning, blocking east-west traffic inside the branch and allowing all traffic heading the DC (so the main FW handle it).
That way, I've made the branches FWs policies almost immutable.

So, in summary, this enabled me to contain the changes to specific networks each time.
That's one incoming inline layer per internal subnet, and 2 inline layers per external network (ingress+egress).

But be warned, it took up about 4-5 months for 2 policies with a total ~200 rules...
Although, I did gave it to a junior team member, so he also learned during the process...

Hope that helps.
Feel free to contact me if you have any questions.

[superd]

Great response, much appreciated.

Apologies I am only picking up on this now, Ive been consumed with other projects.