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

[Steve_Pearson]

This certainly makes sense as it lowers the management overheads significantly.

The approach i've been using was one I picked up off colleague years ago and that is to have a list of group of employees (directors, managers, IT, general users, etc) then create a block list of the categories that each group is not allowed to access.

Then for each user group, a rule that matches AD group membership and has inline rules below it. These rules block the critical risks first, then allow specifics from the categories that are going to be blocked (for example remote control may be blocked as a category but maybe we allow just Teamviewer), then block the category list and finally finish with an accept all clean up rule.

After all of these rules for the groups, the main policy clean up rule would be a drop, which has the effect of dropping all unknown traffic for unknown users or devices.

[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

[Tomer_Noy]

Yup, you can definitely create separate HTTPS Inspection layers for different gateways, if you want.

The default is a shared layer for all policies, because that is the most common use-case. But, if you do want separation (beyond the Install-On column), you can open the "Manage Policies and Layers" dialog and under "Layers" => "HTTPS Inspection" create a new layer.

Then, you can go to your policy package and modify it to use the new HTTPS Inspection layer, instead of the "Default" one.

** You can also select the "New Layer..." button in the Layer selection dialog (instead of going to the "Manage Policies and Layers" dialog).

It's supported on GAIA as well.

[the_rock]

Will try this in my lab, I must have done it a different way past time, hence option was "missing". Thanks @Tomer_Noy 

[the_rock]

Just tested it and yes, works fine...well, learned something new, thank you!

Andy

[Steve_Pearson]

Me too, works great, it's a pity you can't clone an existing)

Every day's a school day!

Thanks!

@Tomer_Noy Thanks for the info!

[the_rock]

I agree @Steve_Pearson , super valid point about cloning!

I know you can clone whole policy package, but just wondering @Tomer_Noy , any idea if there are plans to make it work for cloning specific layer?

Andy

[Tomer_Noy]

Hmmm...

We don't have "clone" for layers, but we do have "copy+paste" for rules, so it's pretty easy to get the same functionality with a few clicks.

Go to your original layer, press "Ctrl+A" to select all rules, right-click and select "Copy": 

Then go to your new layer, right-click and select "Paste -> Above":

After pasting, you'll probably want to delete the last rule, which is the cleanup from the original layer and is now duplicated.

I hope this helps 😀

Copying & pasting rules is of course very useful for Access rules as well (not just HTTPS Inspection). Not all customers are familiar with the capability.

[the_rock]

It helps, and its easy, yes 🙂

Thanks!

Andy

[Steve_Pearson]

I use this all the time on access rules, and can't believe I never thought about it on the HTTPS rules!

Thanks again!

[the_rock]

I know, same here lol

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.