Managing multiple gateways with separate policies on a single management server

[Steve_Pearson]

I'm currently creating a set of new policies for a handful Spark 1555's that are being deployed to branch offices.

Each will have it's own policy, and following what I believe is best practice the policy will define the installation target and the rules in the Access, NAT and QoS policies will have "Policy Targets" in the Install On column.

This is fine for the those policies, but the HTTPS policy are shared, so i'm thinking that these should specifically state the installation target for each rule, and have a separate section title for each "site" to keep them together.

Just wondered how everyone else does this?

Also, I was wondering if it was possible to have a shared layer for rules that are common to all policies. I think it would be possible for a set of block rules, set it as the first layer in each policy, but it wouldn't work for allow rules as it would simply allow it to continue to the next layer, which may then block it. Has anyone else tried this or should I simply stick to totally separate policies?

[the_rock]

Yep, thats EXACRLY how I did it for few customers and even TAC suggested the same. See, you cannot sadly create separate https policy for different gateways, like you can with regular rule base. I was hoping maybe that would be the case in R82, but does not look like it.

Im still hoping for hit count on https inspection policy too 🙂

Andy

[Steve_Pearson]

Thanks Andy.

A hit count on HTTPS policy would be very useful and well overdue!

[the_rock]

Yes, it is overdue, I agree. It would be super useful.

Btw, for your last question, shared layer for common rules, that would be very tricky, because as you already know, traffic has to be ACCEPTED on all ordered layers, otherwise, it would not work. 

Andy

[Steve_Pearson]

Yeah, that's where I got to and decided that as it's only going to work for drop rules, it's probably better no to bother at all 🙂

[the_rock]

Let me tell you a story about customer I used to support after they switched from Cisco to CP few years ago. So I helped them with moving everything over, we built the policy using smartmove tool after the conversion, Smart-1 cloud option was good for them (they were happy with it), showed them how policy layering worked etc, so I explained to their boss how odered layers work and I told him specifically, do NOT EVER change last layered rule to any any block, as that will block all traffic. He assured me he would not do it, well guess what, one night I get this frantic call from one of his employees and we find out guy (the boss) changed that rule from Europe, where he was on vacation and instead of enjoying his vacation, he decided to do something he was not supposed to do lol

Joys of our job, haha.

Anyway, we fixed it quick, but he felt really embarrassed about it...his reasoning? Thats how it works with Cisco. My usual comeback to that "Last year, I was year younger and now Im not" 😂😂

Andy

[Steve_Pearson]

🤣🤣🤣

The last few policies I've worked on, including the ones i'm doing now are pretty restrictive and do actually have an any any drop at the end as they prefer to allow the users as required rather than blocking certain stuff and allowing everything else!

[the_rock]

Thats okay, as long as they dont inadvertently block things at the end lol

Btw, blacklist approach is what CP recommends for URLF layer as well and I do find it works better.

Andy

[the_rock]

@Steve_Pearson 

This is sk Im talking about.

Andy

https://support.checkpoint.com/results/sk/sk112249

blacklist vs whitelist section

[PhoneBoy]

Pretty sure you can assign a separate HTTPS policy to a Policy Package, which should be applicable for SMB.
This has been supported for a while. 

[the_rock]

But I dont believe that was ever possible for regular Gaia, was it?

Andy

[Tal_Paz-Fridman]

An alternative—though typically not ideal for a small environment—would be to use an MDS.

This approach allows you to create a Global Policy that can be applied either before or after the local Domain rulebase. Additionally, it enables separate HTTPS Inspection policies for each Domain and Security Gateways.