I feel that I need to share this one because it can pose a serious threat and you may or may not aware of how much of an impact this can have.
Psiphon - it has changed recently
The reason I mentioned Psiphon is because it is REALLY brutal and very cleaver in how it gets around content filtering. Most firewalls don’t see it as a threat because of the nature of how it tunnels out. Most of its backend is hosted on paid for hosting sites/CND’s such as Amazon and some parts Akamai. Most schools are using something that is hosted on Amazon at some point (i.e. a maths website for example) and everyone usually gets something from Akamai (such as a Microsoft and Apple software etc).
We blocked Psiphon successfully in the past by the virtue of blocking URLs that use IP addresses (we also have a whitelist for things that need IP). The problem now is Psiphon can connect via registered Domains names using FQDN’s and thus makes its very hard to contain.
Also because it tries to make thousands of connection requests to one of their plethora of servers, it can effectively act like a DoS attach on your network gateway/firewall and thus cause your internet to grind to a halt. The issue is students like to share things around by UoS (USB over Sneaker-net (c) )
The good news is we have been able to block the new version of Psiphon with the fantastic support from the guys at Cyberhound - the firewall vendor that we use.
Things that we have found that can help:
-
Rate limiting. Any firewall worth its money should be able to rate limit connections. A good number we found in our environment was to drop it down to about 500 connections per client. We did drop it down to 200 for a short period but found it was a little too restrictive in certain circumstances.
-
Identify a common pattern. This one was the hardest. The Cyberhound team threw all of their resources at this one and found a common request that the Psiphon client uses to update its list of servers and were able to formulate a policy that not only blocked Psiphon successfully, but was able to blacklist the individuals (the offenders). Also blocking UDP on port 443 for (at the student policy level), and blocking access to common Psiphon domains makes for a well-rounded solution.
If anyone wants some more specifics on what to do with blocking Psiphon, please feel free to ask. For the amount of frustration this cause us and the amount of time that has cost me, I can’t help but want to share!
Going forward from here - let’s hope other Firewall vendors formulate a common methodology when dealing with Psiphon and keep tabs on its development as this is going to be an ongoing battle in the long term.
We use AppLocker to block the cert that psiphon signs their app with.
Fortigate and deep SSL inspection easily kills off Psiphon without issue. Sounds like Cyberhound makes it kind of painful… Rate limiting? Just detect and block the service/app (if the firewall isn’t able to classify it, then it shouldn’t wear the “NGFW” badge).
I’m guessing PAN, Sophos, etc can do the same thing as Fortigate.
Yeah this one has been tough. We have a smoothwall box and they worked a lot with us to get it blocked, and usually need a support call with each iteration. Currently we use our anti-virus (sophos) to use application blocking if it sees the program, by the time I pushed this out most computers won’t get the newest rules from sophos. We also have all outgoing ports disabled except those that are manually allowed by us (internet traffic, WSUS, Sophos…).
We do SSL decryption as well, which helps pick up some of the stuff on our blacklist as well and at least slow them down from getting the newest version. These all seem to stop it most of the time, though occasionally i’ll find it connecting once or twice.
The biggest thing to slow it down was getting administration to back a very strict policy if it’s found on one of our devices (we’re 1:1)
Just resubmit it to your AV company and have them update the MD Hash and push it to your application filtering.
Then wait for the program to update.
Rinse, repeat. It’s a constant issue with that program. I wish vendors were more on top of their MD hashes.
As simple as it sounds to kill its self updating and with our BYOD program we cant just kill it via a hash.
This link has some more information on how Psiphon works.
Also a lot of other schools I know off haven’t noticed the issue due to how well it hides.
One way was to block any address that has Psiphon in it. that will make it a lot harder.
The reg-expression in the fire rule is “psiphon.*server_list$”
It basically kills the initial look up of the routing servers for the client.
Then we block any kids that trigger it for 24 hours.
They have learnt pretty quick since.
Sorry for the late reply!
- Right click the executable in question (in this case, Psiphon3.exe)
- Click on the “Digital Signatures” tab, then highlight the Psiphon Inc. signature and click “Details”
- On the “Digital Signature Details” window, click “View Certificate”, then click the “Details” tab, then “Copy to File”
- The Cert Export Wizard will open. I used all the default options to export is as a .CER file to my desktop.
If you already have AppLocker working, you should be good to go, simply block this new certificate for whatever group you want. In my case, this was our first foray into cert blocking, and I used the default rule set from the Applocker setup, which also blocked all unsigned apps for non-admins, which was a not-good thing for our environment. Besides that little goof-up though, everything went swimmingly.