HTTPS Inspection Setup

[NeilDavey]

Hello

I am looking for some advice/guidance on HTTPS Inspection Setup.

Currently we use a 3rd party product for our web filtering but we want to look at trialing the Check Point URL/Application Control to replace this.

So far, I have enabled the following blades to work for this, Application Control, URL Filtering, Identity Awareness, Content Awareness, IPS, Anti-Bot & Anti-Virus.

Next on the list to look at is HTTPS Inspection. I want to be careful that when I enable this, I don't want to effect our current filtering with decrypting the traffic. We also have 5 Gateways that I would look at enabling over a few days. I have listed a few steps that I think would work and was seeing if these would make sense?

• On my first GW, enable HTTPS Inspection.
• Create a new certificate and enable HTTPS Inspection. It's my understanding, that this certificate could then be used on my 4 other GW's?
• Check HTTPS inspection Policy and amend the rule I have here for Action - Change to Bypass
• Push Policy

These steps, it would enable HTTPS Inspection but as I have set the policy rule to Bypass Inspection, it should not effect my current filtering solution.

I could then follow the same type of steps for my other 4 GW's.

Once this has been enabled across my FW estate, I could look at either using Identity Awareness with users or provide IP's to perform some testing. The certificate I generated on the GW for HTTPS Inspection, I would deploy to my test group.  I would also create HTTPS Inspection rules using the source as either my user or IP as above.

I have also watched this video that also suggests some other things like Hold v Background etc

https://community.checkpoint.com/t5/Member-Exclusive-Content/HTTPS-Inspection-Best-Practices-TechTal...

Would this roll out make sense or am I missing some steps here?

Thanks

[PhoneBoy · Accepted solution]

What you're creating is the Certificate Authority that the gateway will use to generate "on the fly" site certificates.
I believe this can be shared among gateways.

If you want HTTPS Inspection to occur you need to have at least one rule in the HTTPS Inspection policy with the action Inspect.
Note your last rule should be an Any Any Bypass rule.

But yes, in general, what you're suggesting makes sense.

[Nikolai_Borhart · Accepted solution]

A little tip from me, so I was recently affected.

When building the policy, note the order: Top to down

- Bypass IP base (non application / catogorie)

- Bypass with IP and applications / catogories

- Inspected rules

- Clean Up Rule (any any bypass)

Dont put a Bypass Rule with  application/catogories on the top.

best regards

Nikolai

[Timothy_Hall]

Hi @Nikolai_Borhart thanks for your post, would you say this slightly more detailed writeup below for the preferred order for HTTPS Inspection policy rules is accurate:

1. Rules specifying an Action of "Bypass" that are matching only specific source and destination IP addresses/networks (no domains) with a Category of "Any"

2. Rules bypassing sites known to not work with HTTPS Inspection via the Check Point-provided ‘HTTPS Services – bypass’ updatable object; see the next bullet point mentioning sk163595 for further explanation.

3. Rules specifying an Action of "Bypass" that are matching specific source and destination IP addresses/networks (and/or domains) with a Category of "Any".

4. Rules specifying an Action of "Bypass" that are matching specific source and destination IP addresses/networks (and/or domains) with specific categories set.

5. Rules specifying an Action of "Bypass" that are matching specific source and destination IP addresses/networks (and/or domains) with specific categories or a Category of "Any" set.

6. Rules specifying Inspect actions.

7. A "cleanup rule" consisting of "Any Any ‘HTTPS default services’ Any Bypass

Tips: 

• NEVER use “Any” in the Destination of the HTTPS Inspection policy unless you are intending to perform HTTPS Inspection on internal traffic not interacting with the Internet. Setting a Destination of Any will throw a huge load on the firewall’s CPU as it attempts HTTPS Inspection on traffic traveling at LAN speeds which is highly inadvisable.

• NEVER use "Any" in the Services field of the HTTPS Inspection policy as this can draw large amounts of traffic into active streaming on the firewall when it is not necessary, substantially increasing CPU usage and even breaking some things as described here: sk118574: FTP/SSH/SFTP Traffic fails when HTTPS Inspection and Application Control are enabled