topic Re: BEST PRACTICES HTTPS INSPECTION R81.10 in Firewall and Security Management

BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Tue, 14 Jun 2022 15:59:07 GMT

Hello guys,

We are having problems with HTTPs Inspection in R81.10 Take 55. We are having an alert in HTTPs Inspection in internal traffic. This is the log: The probe was unable to establish a TCP connection to the destination.

I would like to know if anymore has had problems with HTTPs Inspection in R81.10. And what are the best practices to this version.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

matangi — Wed, 15 Jun 2022 09:18:19 GMT

Hi @Julian_Sanchez
It might be some general connectivity issue

Please open a ticket to Check Point Support

Thanks,
Matan

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Ruan_Kotze — Wed, 15 Jun 2022 12:32:07 GMT

These are my notes, shamelessly copied mostly from various posts and snippets shared by @Timothy_Hall

HTTPS Inspection Rulebase Order

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

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 (This is possibly not in line with current best practices, please see @_Val_ 's post below mine. Use <Internal NETS> - <Internet>-<HTTPS>-BYPASS instead)

Notes:

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

Re: BEST PRACTICES HTTPS INSPECTION R81.10

_Val_ — Wed, 15 Jun 2022 12:18:14 GMT

I am not sure position 7 is recommended. Regardless of whether you are doing the inbound or outbound inspection, the cleanup rule as described will cause ALL HTTPS connections to be tagged by wstlsd daemon, and this might cause memory and performance issues.

This point was widely debated both internally and outside of Check Point, and my personal understanding is, that it is best to limit the explicit cleanup rule to other than ANY for destination and potentially source as well.

For example, if you are doing outbound inspection only, and only for your internal networks, you can use <Internal NETS> - <Internet>-<HTTPS>-BYPASS. That would significantly reduce work for wstlsd with tagging anything HTTPS crossing your GW.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Ruan_Kotze — Wed, 15 Jun 2022 12:27:58 GMT

That makes sense - thanks - will update my post!

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Marcel_Gramalla — Wed, 15 Jun 2022 12:36:09 GMT

I think a year ago we had a TAC case because of some problems with HTTPS inspection and they confirmed the any/any-bypass rule to be good. Maybe a SK with such a Rulebase Order would be a great idea 😉

Re: BEST PRACTICES HTTPS INSPECTION R81.10

_Val_ — Wed, 15 Jun 2022 13:59:11 GMT

As I said, there is a long discussion. For small and medium-sized environments, any-any can be okay. However, we have indications from actual field deployments with lots of HTTPS traffic, that under certain conditions any-any can lead to excessive and unnecessary tagging, hence my note.

Just to clarify, it is quite hard to define a single size fits all best practices guidance in security. For example, having a stealth rule up in your policy is considered a best practice, but it also causes breakage of acceleration templates and may lead to severe performance degradation, depending on that rule position and amount of traffic crossing your security GW.

I myself was recommending the any-any-bypass HTTPSi rule for years. I do not do that anymore, as I have seen the cases when this practice is no longer considered "the best".

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:24:12 GMT

In the case of our client, we only carry out exit inspection for its internal networks. However, we see that it is inspecting internal traffic, and is generating alerts. This is appearing to affect consumer services.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:26:38 GMT

Only 443 should be on the ports to be inspected? We also have bypass rules for specific networks but many times this fails.

Additionally, would a CoreXL configuration be needed? We are working with 15600 equipment and in version R80.10 we did not have the problems with Inpection.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Marcel_Gramalla — Wed, 15 Jun 2022 14:31:21 GMT

Do you want to inspect internal HTTPS Traffic or only external Traffic? Please share your rulebase if possible. Also note that the gateway itself has to reach the destination in order to validate the certificate etc. Maybe that's missing?

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:42:05 GMT

I only want to inspect external traffic. In R80.10 we dont have this issue, and in R81.10 with the same rules we are getting that alert and I think is inspection internal traffic.

So, we have a specific rule with OCSP service to validate the certificates.

Due to the problems of HTTPS Inspection we did a bypass to Internet, because we getting slowness in all network. We dont have inspect to Interntal traffic, and it's the strange why we are getting an alert between internal traffic.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

_Val_ — Wed, 15 Jun 2022 14:44:54 GMT

Show us the rule that says Inspect, and also the bypass rule at the bottom

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Marcel_Gramalla — Wed, 15 Jun 2022 14:45:57 GMT

Maybe the "Internet" object is broken or not correctly defined. Have you tried to work with negating a group with all RFC1918 networks? Here are some thoughts about different options: Properly defining the Internet within a security p... - Check Point CheckMates

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:46:01 GMT

And this is the configuration in HTTPs Ispection

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:49:45 GMT

The Internet object is predefined for Check Point in SmartConsole, it can be used only in App Control or URL Filtering and in HTTPs Inspection. For another rules I use a negate group with RFC1918 networks. But I am going to test.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Julian_Sanchez — Wed, 15 Jun 2022 14:56:22 GMT

In this moment we have all rules inspect disabled.

As you see the most rules are in bypass and the inspect rules are disabled due to the fact that we have slowness in all networks.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

Marcel_Gramalla — Wed, 15 Jun 2022 15:10:53 GMT

Yes, I know but the Internet object is calculated based on the Gateways topology. If for any reason your internal networks are declared as external or DMZ you can have exactly this problem.

Re: BEST PRACTICES HTTPS INSPECTION R81.10

PhoneBoy — Fri, 17 Jun 2022 00:09:53 GMT

Can you connect to the destination server on port 443 from the gateway?
That happens as part of SNI verification and if this is blocked for some reason, it would explain the error.