Blocked Porn is getting through!

[Moudar]

Hi

As you can see the web page www.superporn.com     only as an example, many other porn websites bypassing the same!

was blocked only for 2 logs and then it was accepted all the way!

I wonder why would that happen

The blocking rule is app/url rule:

as you can see above sex and pornography are blocked, but still can be accessed. I have tested 3 different computers and all got some drops by that rule but then they could bypass it!?

Any ideas?

[Chris_Atkinson · Accepted solution]

Atleast part of the answer is in the log output provided.

QUIC traffic is allowed in your environment and this cannot be inspected.

For now you can block it and it will force it to use HTTPS instead.

[Moudar]

what about all other websites that use Quic protocol? If I block it ?

[the_rock]

You need to make an exception in https policy.

[Moudar]

what if HTTPS inspection is not active. How to check if our appliance is able to do it or not?

The porn websites still open through HTTPS.

I did add QUIC protocol to the blocked list as you mentioned but now porn websites are using HTTPS instead!

[emmap]

Do you have 'Categorise HTTPS sites' enabled in the URLF blade settings? 

If you aren't doing HTTPS inspection, the gateway can't see the HTTP header to see the URL in it, so we have to rely on the CN in the cert. I don't know how many porn sites put their full URL in the cert but you might have to check and see what it says if it's still getting through. 

[Moudar]

it is enabled!

Should I add something to the blocked list?

[Moudar]

So, how could my gateway detect and block traffic that's included in the block list before the new Chrome/Edge update (124)? I mean, we've never used HTTPS before!

[Chris_Atkinson]

It's not specific to the sites rather QUIC more broadly, there is an SK that describes the need to mitigate this (see sk108202 / sk112249 / sk111754).

In R82 and above we will introduce support for QUIC / HTTP3 inspection.

[Peter_Lyndley]

Hi All,

Having read this thread , i would like a little clarity on this please.

So since v124 of Chrome / Edge... blocking QUIC and using HTTPS categorisation is not enough for these browsers traffic to get correctly handled by URL filtering blade etc ?

The only solution - without modifying the browser settings so far is to use R81.20 and HTTPS Inspection ? or have I mis-read some of the replies ?

Please clarify so we can implement the best solution going forward

thanks

Peter

[the_rock]

@Peter_Lyndley I would agree with that statement, correct.

Best,

Andy

[Chris_Atkinson]

There is no general change in recommended best practice.

The only variable is the experimental setting recently introduced in Chrome based browsers. I'm sure once TAC has a position on this an SK will be published if deemed appropriate.

R82 introduces support for QUIC inspection, recommendations will likely be updated then with that in mind.

[the_rock]

Hey Chris,

Correct me if Im wrong when I say this, but Im sure even in R82 people will need to use https inspection to properly block QUIC protocol?

Andy

[Chris_Atkinson]

I've not yet been fortunate to experience the EA for R82 so can't comment on how the configuration of the QUIC inspection looks.

[the_rock]

Fair enough...if you find out and are allowed to share, please do.

Best,

Andy

[the_rock]

Just add custom category *superporn* and that will fix it, for sure.

Andy

[the_rock]

K, I was wrong, wont be first or last time lol

@Chris_Atkinson is 100% right. I tested in the lab and as soon as I added quick udp and quic protocol to be blocked, worked as expected, just restarted my browsers and page was blocked, but BEFORE I added quick in the rule below, it was allowed.

Andy

 

[Tom_Hinoue · Accepted solution]

By any chance the issue is occurring only on Chrome/Edge browser just recently?

We have a similar issue with HTTPS categorization since last week right after the Chrome/Edge version was upgraded to 124, where TLS1.3 handshake is not detected by URL Filtering, and sites are somehow not blocked. This does not occur with Firefox or other browsers.

The issue didn't occur in Chrome ver.123
Usually HTTPS categorization should work with TLS1.3, but somehow its not working since the browser update.

As a workaround, we have disabled the following option in chrome, and sites are able to be blocked by the access policy as before.

chrome://flags or edge://flags
 -> TLS 1.3 hybridized Kyber support

I saw some discussions on other forums, that this parameter is affecting URL/content filtering for other vendors like Fortinet and SonicWall.

https://www.reddit.com/r/sysadmin/comments/1carvpd/chrome_124_breaks_tls_handshake/
https://www.sonicwall.com/support/knowledge-base/websites-randomly-gets-blocked-or-allowed-with-no-c... 

Any other people experiencing a similar issue?

[emmap]

According to the TLS support SK, TLS 1.3 is only supported in HTTPS Inspection when the gateway is running in User Space (USFW)

TLS SK: https://support.checkpoint.com/results/sk/sk178505

USFW SK: https://support.checkpoint.com/results/sk/sk167052

So enabling USFW might be worth a test for you.

If you're not doing HTTPS Inspection and just doing Categorise HTTPS sites, TLS 1.3 should work in all current versions. https://support.checkpoint.com/results/sk/sk163515

[Moudar]

What if our appliance (6500) does not support USFW?

[emmap]

All 6000 appliances support USFW and should be enabled by default in current versions. The commands to double check are in the SK there.

[Moudar]

Here are my firewall stats:

Accelerated conns/Total conns : 161/53539 (0%)
LightSpeed conns/Total conns : 0/53539 (0%)
Accelerated pkts/Total pkts : 27688409458/30831725989 (89%)
LightSpeed pkts/Total pkts : 0/30831725989 (0%)
F2Fed pkts/Total pkts : 3143316531/30831725989 (10%)
F2V pkts/Total pkts : 145057135/30831725989 (0%)
CPASXL pkts/Total pkts : 1297843673/30831725989 (4%)
PSLXL pkts/Total pkts : 24911653523/30831725989 (80%)
CPAS pipeline pkts/Total pkts : 0/30831725989 (0%)
PSL pipeline pkts/Total pkts : 0/30831725989 (0%)
QOS inbound pkts/Total pkts : 0/30831725989 (0%)
QOS outbound pkts/Total pkts : 0/30831725989 (0%)
Corrected pkts/Total pkts : 0/30831725989 (0%)

what is the recommended mode? KSFW or USFW

We are running KSFW today

[shais]

The recommendation in that case is USFW.

In general, we recommend USFW over KMFW

[Moudar]

So just for confirmation:

- HTTPS inspection is not used.

-   Categories HTTPS sites is enabled

- Firewall mode is KSFW.

If moving from KSFW to USFW would solve the problem ?

is there any known limitation of USFW that we need to know about?

[the_rock]

I am not aware of any issues, plus USFW is default anyway if I recall.

Andy

https://community.checkpoint.com/t5/General-Topics/R80-x-Performance-Tuning-Tip-User-Mode-Firewall-v...

[Tom_Hinoue]

We only have HTTPS categorization enabled on R80.20.XX and R81.10.XX on locally managed SMB firewalls.
The issue does resolve with latest Chrome version if we enable Full SSLINS, but the majority of our customers do not use SSL Inspection.

Btw, there is no way to enable USFW on Gaia Embedded currently(I believe its not supported...) Force setting kernel parameters did not work for us either.

As I mentioned, this issue does not occur on TLS1.3 handshakes in the old Chrome/Edge version 123, I'm assuming the behavior changed in version 124 which the site could not be detected by URLF blade for some reason, unless we disable the problematic option in the browser.

I'm not sure if this behavior is something to be reviewed on the browser side (like a bug?), or something firewall vendors may need to follow to support the default behavior on the new chrome/edge version...

[Moudar]

I think you have right here:

I tested Firefox and all porn websites are blocked.

Tested also Edge and Chrome and both are allowing porn websites

Edge version:  124.0.2478.51

Chrome version: 124.0.6367.92 

[Chris_Atkinson]

The issue will likely persist to a degree if you don't also handle the QUIC traffic.

[Moudar]

I did blocked QUIC:

[Chris_Atkinson]

Great, just validate that you see the UDP/443 traffic blocked in the logs.

Depending on your policy structure you may benefit from service level blocking in the access policy.