Strange match on inline layer

[KM1895]

hi,

Im currently investigating a bit of a strange case.

Users are able to access the internet and download a file, even though it should have gone to clean up.

This is an inline layer rule, and the users get accept on the main rule, which is basically internal nets -> external nets

but when going through the inline layer rules, there is no accept rule for the destination, so it should end up in the clean up rule.

But the users are able to download sucessfully, and in the logs, we see accept and "connection terminated before the gateway..." message. Not sure if that is relevant for this case, but thought i should mention it.

So the traffic is then accepted, on rule xxx, and not dropped in clean up rule on xxx.yy

Anyone seen anything similar like this before?

[PhoneBoy]

It's very relevant because it's the reason this is occurring.

"Connection terminated before the gateway..." means the connection terminated before the gateway could determine what application the traffic was (thus what rule applies).
Note that in most cases, it should only require a few packets to make the determination.
This is generally expected behavior.
See: https://support.checkpoint.com/results/sk/sk113479 

To troubleshoot this, we'd need to see the rules in the inline layer in question along with one of the logs where this occurred (redact sensitive details).

[KM1895]

hi,

Yeah, im familiar with the sk, and why the message is appearing in general. The strange thing here, is that the inline layer rules is not "invoked" or checked, when the traffic hits the rule. So the traffic acts as a basic access rule, with src,dst, port, instead of passing the traffic through the inline layer rules, to find a match. and the match would then be the cleanup rule.

Unfortunately, i dont think i can provide a screenshot of this, as there is too much information/naming standards etc, that can identify parts of the customer's infrastructure.

So i can try a better description of the rules.

The "main rule" is: src: internal networks dst: external networks ports: any

the inline layer rules then consist of various source nets towards url's and applications, some of them custom.

So i have checked that there isnt a match for the url in question, so if the traffic had passed normally, it would then be dropped.

So what we see, is that the users are accessing a url externally, and they are able to download files from the site they are acessing.

So the logs are showing an accept on main rule, but no entries on any inline layer rules, to summarize. hope this helps a bit.

[PhoneBoy]

Even without the exact rulebase, an example log card of such a connection being accepted (with sensitive details redacted) should be helpful.
However, I suspect you'll need TAC to troubleshoot this.

[the_rock]

It would help us if you sent a screenshot of the actual inline layer, along with "child" rule in question. Please blur out any sensitive data.

Andy

[the_rock]

I just read your issue again and I have a gut feeling I may know why this happens. I had similar problem with a client couple of years back and I can check my notes tomorrow how we made it work, but I recall customer had content awareness enabled, as they wanted to just test it out for 30 days to see how it works. 

Is content awareness blade involved here? If yes, I will be able to tell you how we made it work.

Andy

[KM1895]

hi,

No, Content Awareness is not activated. They are running full NGTX bundle and https inspection for outbound inspection.

[the_rock]

Here is the catch...you need to BLOCK that site using https inspection (or if you use urlf layer) first, cause if its not inspected, it will never get blocked. 

Andy

**********************************

see below link I had about this back in 2022

https://community.checkpoint.com/t5/Security-Gateways/Content-awareness-issue/m-p/156026/emcs_t/S2h8...

[the_rock · Accepted solution]

Hey @KM1895 

Going back to link I gave in my last response, I think even if you do NOT use content awareness, key here is to uncheck bypass option to known update servers in legacy dashboard https inspection tab and then allow the same through the ordered (or inline) policy layer. Just my 2 cents and Im saying this based on what escalation engineer told me back when I had the case with customer about this in 2022.

Andy

[KM1895]

hi,

I see that this is indeed checked in https inspection legacy smartdashboard. They also use the "recommended bypass" updatable objects in the https inspection rulebase, but according to the list in sk163595, the url they are accessing is not in one of these objects.

So we should attempt to uncheck, push policy, test, and then reactivate afterwards? guess this needs to be planned a bit, as this could cause some issues if there arent any specific rules for the update servcies.

thanks so far for the input:)

[the_rock]

You can try that. Cant guarantee it would work. Did you open TAC case for it?

Andy

[KM1895]

hi,

I ended up with creating a dedicated https inspect rule for the url they want to have inspected and dropped. So this is now working, as the traffic gets inspected, and then it ends in the cleanup rule as it should. so thanks for all the feedback!

Only mystery that remains now, is that the source traffic is not part of the https inspection rule at all, and so it shouldnt be inspected at all! as far as we can tell, there is currently only one source VLAN this is happening to, but i find it strange that a network that is not part of the https inspection rulebase gets inspected.

[the_rock]

Well, that can be little tricky, because based on the logs, you may need to bypass or inspect certain traffic to make it work, since https inspection always comes first.

See what escalation engineer told me about this back in 2022.

Andy

****************************

nspection allows the firewall to go inside the packet and view the unencrypted data thereby classifying the file type, file name etc which is downloaded/uploaded. More on content awareness, after these attributes are identified the usermode processes verify if such content is allowed or blocked. The decision/verdict is provided to the rule base execution engine and the final enforcement block/accept is enforced accordingly.