Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Moudar
Advisor
Jump to solution

Blocked Porn is getting through!

Hi

porn.JPG

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:

porn-rule.JPG

porn-block.JPG

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?

 

0 Kudos
3 Solutions

Accepted Solutions
Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE

View solution in original post

Tom_Hinoue
Advisor
Advisor

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?

 

View solution in original post

Tom_Hinoue
Advisor
Advisor

Just to share with the community... it looks like a SK was published regarding this issue with chrome "TLS 1.3 hybridized Kyber support". For those who are experiencing this issue with HTTPS categorization, and like to resolve this without activating Full SSL INS, I would recommend to open a ticket to TAC to receive a hotfix, both for Gaia and Gaia Embedded 🙂

"Categorized HTTPS Sites" stopped to classify specific websites
https://support.checkpoint.com/results/sk/sk182318

View solution in original post

61 Replies
Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE
Moudar
Advisor

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

0 Kudos
the_rock
Legend
Legend

You need to make an exception in https policy.

0 Kudos
Moudar
Advisor

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!

0 Kudos
emmap
Employee
Employee

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. 

0 Kudos
Moudar
Advisor

it is enabled!

Should I add something to the blocked list?

0 Kudos
Moudar
Advisor

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!

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE
0 Kudos
Peter_Lyndley
Advisor
Advisor

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

0 Kudos
the_rock
Legend
Legend

@Peter_Lyndley I would agree with that statement, correct.

Best,

Andy

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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.

 

CCSM R77/R80/ELITE
0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE
0 Kudos
the_rock
Legend
Legend

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

Best,

Andy

the_rock
Legend
Legend

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

Andy

0 Kudos
the_rock
Legend
Legend

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

 

Screenshot_1.png

0 Kudos
Tom_Hinoue
Advisor
Advisor

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
Employee
Employee

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

0 Kudos
Moudar
Advisor

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

0 Kudos
emmap
Employee
Employee

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

0 Kudos
Moudar
Advisor

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

0 Kudos
shais
Employee
Employee

The recommendation in that case is USFW.

In general, we recommend USFW over KMFW

0 Kudos
Moudar
Advisor

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?

0 Kudos
the_rock
Legend
Legend

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...

0 Kudos
Tom_Hinoue
Advisor
Advisor

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...

0 Kudos
Moudar
Advisor

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
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
Moudar
Advisor

I did blocked QUIC:

blocked.JPG

Chris_Atkinson
Employee Employee
Employee

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.

CCSM R77/R80/ELITE
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events