Block Psiphon 2023

[RS_Daniel]

Hi CheckMates!

Wanted to ask if someone has been able to block psiphon on 2023. I have read all posts related to psiphon, provided solutions worked a couple of years ago. But now, i guess the app was updated and firewalls are not able to block Psiphon anymore. Tried to block on 3 different enviroments with same results, also have a rule meeting the last requirements i found:

1. Block Psiphon
2. Block Quic Protocol
3. Block SSH Protocol (using the service in R80.10 or the application in R77.X)
4. Block Unknown Traffic
5. Full https inspection on the client machine without exceptions

I also added Uncategorized category with same results.

We already opened a case with TAC and provided debug and packet captures that were already sent to RnD. My experience with RnD is that it will take some time to get a solution. Just wanted to ask meanwhile if someone already was able to do this.

For reference, the enviroment with most updated versions have Management R81.10 with Jumbo 87, and gateways clusterXL R81.10 jumbo 82. 

 Regards

[the_rock]

This is all I see in R81.20

Andy

 

[Sorin_Gogean]

Hello @RS_Daniel ,

Can you provide some logs on connections that are Psiphon related and you see them happening ?

I would really want to see/understand what triggers it and maybe I'll get an ideea.

Thank you,

[RS_Daniel]

Hello, these logs are for one connection with the app.

Regards

[the_rock]

Here is something important to remember, IF you use content wareness blade, which appears you do...I had call with escalation guy once and customer and he showed us in the lab perfect example why that blade did not function as intended. So, you literally have to remove all bypass objects in https inspection policy, allow them in say urlf layer and only then will content awareness blade block traffic as expected.

Now, since this strictly appears to be appc blade related, if blocking built in app does not do anything, then I believe the only way to make this work is find out ranges/IP addresses/fqdns related to Psiphon and block it that way.

Just my 2 cents.

Andy

[Sorin_Gogean]

Hello @RS_Daniel ,

So, you say that this connection to netball.net is an actual tunnel for the Psiphon application ? Or the netball.net is accessed through the tunnel that was done against 196.245.172.67 ?
Because according to "https://otx.alienvault.com/indicator/ip/196.245.172.67" and "https://otx.alienvault.com/indicator/domain/netball.net" I don't see those two having anything in common,

Thank you,

[RS_Daniel]

Hello @Sorin_Gogean,

Yes, these two logs were generated from a connection that psiphon app used to stablish the tunnel. At the beginning, logs show application psiphon and another IP address with action block, but the app keeps "thinking" and at the end it is able to stablish the tunnel with the sites/IP's you can see in the logs. I confirmed the logs are rigth checking "TCP connections" inside "Rosurce Monitor" tool on windows. The service is "psiphon-tunnel-core.exe" and that service stablished the tunnel with the IP's showed in the logs. Also doing a tcpdump for the internal IP address, all web traffic is directed to that IP's, so 100% sure.

Yes, looking for them on internet shows nothing related to psiphon, that makes it very hard to block psiphon. Sometimes psiphon connects to sites categorized as education, religion, web browsing, etc. Things that we can't block.

Regards

[Sorin_Gogean]

Hello @RS_Daniel ,

Thank you for the explications 🙂.

In regards to "At the beginning, logs show application psiphon and another IP address with action block" can you show those logs - just the standard firewall log view where we can see the action, the source and destination, the port and the application would be enough.

So "service is "psiphon-tunnel-core.exe" and that service stablished the tunnel with the IP's showed in the logs" shows a connection to 196.245.172.67 , Understood .

From CheckPoint perspective, if it's detecting Psiphon and blocks it, then I would say it's doing it's part, but partially, so we have to see if we can detect that particular tunnel encryption.

Can you also show your rules that are set to block stuff, like psiphon and others, as example ours are like the screenshot:

As I understood while researching online, in order to get an psiphon tunnel, you have to know an tunnel end that you connect to. Otherwise, the application connects to some "index" portal and from there it's getting a list that it could possibly connect to. Did I understood correctly or ?

One way I would recommend, if you manage those workstations, have a policy that would block "psiphon-tunnel-core.exe" to be started, but only in an managed environment, like enterprise or so.

Thank you, 

[RS_Daniel]

Hello @Sorin_Gogean,

I am attaching the logs with action block, one with Psiphon app and the second a firewall blade log, they are from the same attempt as yesterday. Also attaching the rule that we are using to try dropping this traffic.

Yes, it is a managed enviroment, we already tested this with Harmony Endpoint that works perfectly. The customer just want a definitive answer from CheckPoint to know if the firewall is able to block this app or not.

Regards

[the_rock]

I think your best bet is to open an official TAC case to get that answered in writting. As I posted in my first response, all I could find was that one app listed. Is that enough, I have no idea, sorry.

[PhoneBoy]

We've seen Psiphon evolve over the last few years in an attempt to evade being blocked by security products like ours.
This generally results in updated signatures that resolve the issue for a while until Psiphon evolves again.
Best bet is to work with the TAC: https://help.checkpoint.com

[RS_Daniel]

Hello @PhoneBoy and @the_rock ,

Yes we already have a case with TAC and already provided debugs and traffic captures. It is pending RnD, just asked here if someone had faced this scenario before and could provide some advice. Thank you.

Regards

[the_rock]

I see the point @PhoneBoy makes. I recall 2 years ago when helping new CP customer transition, they wanted to use https inspection and there was app they were blocking with Trend Micro, but such an option did not exist back then with CP, so best TAC could suggest was to block custom urls, as well as IP ranges. I dont suspect much has changed today, but in all honesty, personally, I cant think of better way to get around situation like that.

Andy

[Sorin_Gogean]

Hello @RS_Daniel ,

Thank you for the screenshots, so, what I understand from the rules and everything showed, is that:

- when the firewall identifies the Psiphon application, based on the signatures it has defined, it's blocking it - clearly visible in what you showed us.

- when the firewall is not identifying the Psiphon applications, it's signatures, then traffic is allowed (the first screenshots you showed us).

Your customer, should understand that in order for an appliance (firewall or other one), to be able to identify some traffic is coming from some specific application, it should match some signatures as they were defined. In this particular case, maybe Checkpoint can clarify a bit on what they ar looking in Psiphon case. In general those signatures are composed from several little pieces, like url components, client type, specific port, etc. bun in the case of psiphon, there are couple multiple random things, therefore it's not always getting appropriate detection.

Also if you look closely, the traffic was properly identified while happening on HTTPS (443 port) but when it was on port 80, it was not, and I can bet my liver, it was because the HTTPS Inspection blade does not look into other ports outside 443.

Just for the sake of tests, I would give it a try and enable HTTPS on port 80, all the previous traffic from psiphone , that we've seen it allowed, it will be blocked - most definitely. 

You need to read this post, and define/clone an HTTPS_80  from HTTPS, and user that new one in the HTTPS Inspection rules in an Inspection rule specific for that internal machine you're testing from (192.168.100.37) and repeat the tests.

What that will do, it will involve the HTTPS Inspection blade for traffic happening over port 80, and that will open-up the clear data to all the other blades, so mist likely - I really hope - it will mark earlier traffic happening over port 80 as Psiphon.

Otherwise, if the other connections, are encrypted, then the traffic is invisible for some of the blades, therefore it can;t match exactly what's what. And that is a normal behavior (please tell me if I'm wrong).

What I'm curious, the first 2 screenshots, what rule was allowing them? is that rule higher or lower than rule 14 ?

Thank you,

PS: if you are doing tcpdump on the line coming from that client (192.168.100.37) can you see that all traffic is encrypted? that would confirm my dumb logic above.

PS2: @PhoneBoy , can you or someone else from Checkpoint, confirm or infirm my above understanding 😊, ty.

[RS_Daniel]

Hello @Sorin_Gogean,

We already had service http on https inspection rulebase, but it was not clonned from https as you recommended. I just cloned the service and modified the inspection rule. It took a bit more time to the app to "think" but it ended stablishing the tunnel again.

I understand signatures involve a lot of variables about traffic. As we are able to use Harmony Endpoint to block this, all customer want is an official answer from CheckPoint saying if it is able to block psiphon or not. Thank you very much for your advices.

Regards

[Sorin_Gogean]

Hey @RS_Daniel ,

I bet that "It took a bit more time to the app to "think" but it ended stablishing the tunnel again." was on an port different than 80 and 443 that were in the HTTPS Inspection - can you confirm. (can you show the HTTPS Inspection rule and also you did not show the rule for port 80 that was allowing the first screenshots)

Also with the port 80 HTTPS Inspected, was the traffic over port 80 identified as psiphon ?

Thank you,

[PhoneBoy]

The fact we have a signature for it suggests we should be able to block it.
As stated previously, please open a TAC case on this issue: https://help.checkpoint.com 
If it turns out we can't, then TAC should be able to provide a statement/SK to that effect.

[the_rock]

Agree with that @PhoneBoy . As I mentioned in my last response, unless TAC has another way to deal with these issues now, couple of years back, best they could suggest was fqdn/IP ranges block if built in app was missing. In this case, there is one there, but not sure if thats enough.

[RS_Daniel · Accepted solution]

Hello,

Just an update to tell that RnD updated the signature and TAC provided this as an offline package to update the Psiphon signature which allows to block this app properly. Previous recommendations are still needed, block quic, https inspection, etc... But finally it works. TAC does not have an ETA to get this update released yet.

Regards

[the_rock]

Thanks for sharing @RS_Daniel