Hi. I think we are in the same country and I know what you want to achieve. Well, I guess you already know a lot about this, but in my opinion you are using too much resources to achieve it (I guess including your phone for psiphon). It is up to you, but if I may suggest you could use another method such as wireguard in the router. For me, I only need 4G modem and this AR300M for all devices to have internet at good speed, without need of proxy setup, and very much stable.
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:
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.
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.
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.
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 " " I don't see those two having anything in common,
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.
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.
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 ?
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.
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.
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:
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.
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.
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.
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).
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.
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)
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:
If it turns out we can't, then TAC should be able to provide a statement/SK to that effect.
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.
Let me ask some helps from you all, i'm facing some case that i'm trying to block vpn application at our fortigate firewall, cloudflare and psiphon vpn apps:. It does not work using p2p and proxy to deny these apps:. Cloudflare is ok to deny by blocking cloudflare used ip address and ports. But, psiphon is not ok to block by choosing psiphon at application.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
I work with a High School and some of the students are using Psiphon to get around our web filter. So I believe we were having a similar issue. We found that A third party managed firewall and web filter filled our needs better than closing so many ports that have important services running on them. We used iboss for our web filter and firewall and we were able to curtail the problem with Psiphon.
Psiphon can mount proxy HTTP/SOCKS via tunnels. All the traffic of this application will bypass the port TCP 80 by default. So you must to have a firewall capable to inspect your packets to see which packets are real HTTP packets and HTTP proxy packets.
To be Honest, with my experience using and testing Psiphon, As long as the user has any kind of internet, no matter the block (even if though), Psiphon seems to manage it's way in anyway. It's lightweight setup make you able to use on a flashdrive (so it doesn't need to be installed on the PC at all, just need to plug in thumbdrive) and versatility makes it very hard to block, even temporally. not to mention that if it even get a ping from any open sever, it automatically updates itself, makes a backup copy, and gets new sever list. The reason why it's like this is because, it's designed to allow you access even in a another country where blocks are really strict... Basically, you're trying to march though the jungle but, up against an army that specializes in guerrilla warfare...
c80f0f1006