Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
superd
Contributor

Checkpoint Policy Optimization / Review

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

0 Kudos
13 Replies
the_rock
Legend
Legend

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
Contributor

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?

0 Kudos
the_rock
Legend
Legend

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
Admin
Admin

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
Employee Employee
Employee

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

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

CCSM R77/R80/ELITE
superd
Contributor

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?

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
the_rock
Legend
Legend

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

PhoneBoy
Admin
Admin

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

Hugo_vd_Kooij
Advisor

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

<< We make miracles happen while you wait. The impossible jobs take just a wee bit longer. >>
the_rock
Legend
Legend

@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.

0 Kudos
eliadtech
Explorer

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
Contributor

Great response, much appreciated.

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events