Behavior of the firewall related to HTTPS inspection when adding “Any” in the service field

[patones1]

Hello,

First of all, have a happy year 2024

I am showing you the result of the test I did in my LAB.  It looks like the behavior of the firewall related to HTTPS inspection is not normal when adding “Any” in the service field of the access control rule base.

NOTE: here I am not looking if the rule is logical but only the behavior of HTTPS inspection.

FIRST PART: I started setting the base for the test. I tried to do it in the simplest way:

• I let the default rule for HTTPS inspection. I just change the source to a PC inside the LAN

• I activated App control & URL filtering at the layer level (and on the firewall) and using the object “Social Networking”
• I used the following inline layer for the Access Control rule.

• For testing if HTTPS inspection worked, I just let the PC_Windows without the firewall certificate.

RESULTS part 1:

Once the policy above installed, from the PC_Windows, I tried to connect to Facebook. Then I tried to connect to any other web site. The result is the expected one for any site:

We can see in the logs the categorization is working OK.  Facebook is matching the 5.1 rule with “Social Networking” at the service field. Then the other traffic are treated by the 5.2 rule (cleanup) with “Any” at the service field. All https traffic were inspected as expected.

         

         

For the moment, everything worked as expected. Next part, in my opinion, didn’t work as expected:

SECOND PART           

• Just for HTTPS inspection purposes, I removed “Social Networking” from the Access Control rule and let “Any” in the 5.1 rule. I installed the policy successfully.

RESULTS part 2

• Then from the PC_Windows (without firewall certificate), I try to connect to Facebook. The connection was successfully

• It looks like the HTTPS inspection were not working at all  

• Looking at the logs, I was confirmed that HTTPS inspection was not working for Facebook as well as for all the HTTPS traffic which was now matching the 5.1 rule.

• Later I tried adding the group “HTTPS default services” to the services field. The result was the same than with “Any”
• Later I added back “Social Networking” to the services field in the 5.1 rule. HTTPS inspection came back.

CONCLUSIONS:

In this specific test using App. Control & URL Filtering, if we don’t add at least one specific object from the blades such as “Social Networking” , the HTTPS Inspection is not going to work.
I think (maybe I am wrong), that “Any” should cover any object, but in the test it is not the case. Replacing “Social Networking” by “Any”, makes the whole HTTPS inspection fail for all the traffic. As “HTTPS default services” didn’t work neither, it looks that in the services field it is necessary to add at least an object specific from the blade (App. Control in our case), to make work HTTPS inspection for all the HTTPS traffic

[the_rock]

I can 100% confirm all you said. I recall testing this when R81.20 became public more than a year ago and results were the same. As a matter of fact, using any as service is probably not recommended for https inspection policy and Im sure its documented in an sk somewhere.

Best,

Andy

[Tobias_Moritz · Accepted solution]

In the second part, your access rulebase can do the final match in firewall blade, so AppCtrl/URFL is never invoked for your traffic. Your HTTPS Inspection Policy is defined in a way, where AppCtrl/URLF blade is needed.

You can try to change the destination field in your HTTPS inspection policy line from Internet (which is an AppCtrl/URLF object) to a network object which matches internet and then redo your tests:

https://community.checkpoint.com/t5/Management/Properly-defining-the-Internet-within-a-security-poli...

I'am interested in the result, as I never tested that myself 🙂

As you already said, this is a special scenario you created for this test. In a real world scenario, you would have an access rulebase which invokes AppCtrl/URLF blade to be able to make a final decision.

You can force this by creating a new tcp object for port 443, setting the protocol to HTTPS, enabling protocol signature in advanced settings and using this object in the service column of you access rule 5.1.

[patones1]

Hello Tobias,

I know that "Any" is not a good choice for production. But here I am just testing.
As long App. Control & URL Filtering are activated on the blade, all https traffic (set to inspect in the https rule) should be inspected because "Any" is everything including AppCtrl/URLF objects; but it is not the case.

For the tests you asked me:

• I replaced the Internet object on the HTTPS rule base by the All_Interntet. --> NO https inspection
• I also replaced the Internet object on the Access Control rule base by the All_Interntet. --> NO https inspection
• Then, without changing what I just did, I tested again adding the HTTPS default services” at the services field on 5.1 rule --> NO https inspection
• Finally I put back the previous values at the destinations and created a new HTTPS service with default port but I enabled protocol signature. I added the service in the 5.1 rule

It worked. HTTPS Inspection is working with the service HTTPS_clone.

Finally using the HTTPS service with the protocol signature enable, allows all the HTTPS traffic to match the rule 5.1 and to be inspected. "Any" should do that but it is good to know that we can manage it by using the service.

Cheers

Miguel

[Tobias_Moritz]

You said "As long App. Control & URL Filtering are activated on the blade, all https traffic (set to inspect in the https rule) should be inspected because "Any" is everything including AppCtrl/URLF objects".

As far as I understand the way, Check Point Unified Policy works, this is not true.

See sk120964 for explanation.

Simplified: When the matching algorithm can determine the final first match for a rule in rulebase without need of higher blades, it will do.

Maybe someone can confirm this.

[PhoneBoy · Accepted solution]

If you want to ensure App Control is invoked for a specific rule, you need to do one of two things (in addition to enabling in the relevant layer):

• Use a Custom Application/Site (not a simple TCP service)
• Use the track "Detailed" or "Extended" (instead of Log)

[patones1]

Thanks PhoneBoy,  👍

It works changing the log to "Detailed log", and this with "Any" on the "Service & Applications" column. ; even if "Detailed log" concerns information about applications on connections, I would never imagine that it was going to invoke App Control on a rule.

This way all https traffic can be inspected  without doing "App. control and URL filtering". It must only be activated at the layer level steel think l to make possible the https inspection. (I know that inspecting all https traffic take a lot of resources).

Making inspect all https traffic, It is as simple as that:

I  still think that  a "Custom Application/Site" or an object such as "Social Networking", should be part of "Any" so It will possible to make the https inspection without changing to "Detailed log".
It is not matter of technique but common sense.

Cheers

Miguel

[patones1]

Hello PhoneBoy,

When you say "If you want to ensure App Control is invoked for a specific rule, you need to ....", I realized that doing what you indicated, will invoke AppControl to the entire layer rather than for a specific rule.

Probably when you are talking about "rule", you mean all sub-layers together (that conceptually, is also a rule). But the natural reflex is looking at each line as a rule even if it they are sub-rules.
All those concepts, can create confusion to people: inline layer, ordered layer, sub-layer, rule, sub-rule, security policy, policy package,....

We can see at my original post (https://community.checkpoint.com/t5/Management/Behavior-of-the-firewall-related-to-HTTPS-inspection-...), that adding the object "Social Networking" to the 5.1 sub-rule, will invoke the AppControl blade in the 5.1 and 5.2 sub-rules. We can confirm that with the logs that show that HTTPS Inspection is working on both.

Best regards

Miguel

[PhoneBoy]

Yes, if there are other "potential match" rules before that have these features, it will have the same effect.