Jump to content

Recommended Posts

Posted

There is a feature I was researching called Always-On VPN. You can force it via MDM and force all traffic through your own VPN which could literally just be an internal server.

Students wouldn’t be able to connect over the MDM policy if you install it right.

Posted
@mcolbourn Any chance you could run a test of psiphon on a ipad/iphone?

 

https://itunes.apple.com/us/app/psiphon/id1276263909?mt=8

 

OK I have copied parts from the Watchguard logs showing it being block over port 80, 443, and 4500

Port 80

 

FWDeny

Application identified

pri=4

disp=Deny

policy=HTTP-Outgoing-Proxy-WiFi-00

protocol=http/tcp

src_ip=172.16.0.130

src_port=53779

dst_ip=45.79.204.188

dst_port=80

src_ip_nat=212.113.200.152

src_intf=2-Wifi_LAN

dst_intf=1-JPCI Leased Line

rc=101

pckt_len=1500

ttl=64

pr_info=offset 5 A 250544440 win 44290

app_id=17

app_name=Psiphon 3

app_cat_id=11

app_cat_name=Tunneling and proxy services

app_beh_id=6; app_beh_name=Access

3000-0149

 

Port 443

 

FWDeny

Application identified

pri=4

disp=Deny

policy=Wi-Fi-Outgoing-HTTPS-proxy-00

protocol=https/tcp

src_ip=172.16.0.130

src_port=41155

dst_ip=185.231.15.28

dst_port=443

src_ip_nat=212.113.200.152

src_intf=2-Wifi_LAN

dst_intf=1-JPCI Leased Line

rc=101

pckt_len=185

ttl=64

pr_info=offset 5 A 1735736843 win 28417

app_id=17

app_name=Psiphon 3

app_cat_id=11

app_cat_name=Tunneling and proxy services

app_beh_id=6; app_beh_name=Access

3000-0149

 

Port 4500

 

FWDeny

Application identified

pri=4

disp=Deny

policy=WiFi-Calling-00

protocol=4500/udp

src_ip=172.16.0.130

src_port=4500

dst_ip=162.220.220.60

dst_port=4500

src_ip_nat=212.113.200.152

src_intf=2-Wifi_LAN

dst_intf=1-JPCI Leased Line

rc=101

pckt_len=124

ttl=63

app_id=17

app_name=Psiphon 3

app_cat_id=11

app_cat_name=Tunneling and proxy services

app_beh_id=6; app_beh_name=Access

3000-0149

Posted
Our categorization team are working on this and have managed to block it, but you need to decrypt and inspect. We're working with our dpi partners to see if we can do it more efficiently
  • Thanks 1
Posted

When I last looked at this a couple of years ago Psiphon uses SSH to connect but will obfuscate this over ports you wouldn't expect, typically it was over DNS - blocking port 53 on the firewall and only allowing it out from your trusted servers typically done the trick - appreciate this may not be the case now but could be worth a punt.

 

Good luck!

Posted
When I last looked at this a couple of years ago Psiphon uses SSH to connect but will obfuscate this over ports you wouldn't expect, typically it was over DNS - blocking port 53 on the firewall and only allowing it out from your trusted servers typically done the trick - appreciate this may not be the case now but could be worth a punt.

 

Good luck!

 

This is best practice anyway. Only your internal DNS servers need access to port 53.

Posted

Just to keep you up-to-date, our current suggestions are to implement a block-then-allow policy on the firewall (most hosts don't need any open ports) as psiphon uses a wide range of existing ports. In the Guardian policy side, you will need at least "validate certificate" rather than do-not-inspect. This does NOT require your users to install a certificate, so is suitable for BYOD. Also block bare IP addresses.

 

We're currently reverse engineering the latest phsiphon to see if we can work with less restrictive firewall rules.

  • Thanks 1
Posted

Block bare IP addresses.....this is in Guardian? ...because all other traffic will be just IP addresses once they have done the DNS lookup....

 

So this would cause a problem with any web site which has links that just contain IP addresses...but I agree that is probably not very often...and specific ones can presumably be allowed later...(not quite sure how that would be done if block all as precedence...)

 

Don't understand what "validating" a certificate would ensure for the client or SW....except that their https traffic might be potentially monitored....

Posted
Block bare IP addresses.....this is in Guardian?

 

I think this is the "All HTTPS URLs containing an IP" and "All URLs containing an IP" categories that you would need to be in a Guardian Web filter policy under what...

  • Thanks 1
Posted

Yes, blocking bare IPs is a guardian feature - we then won't allow a web connection that isn't to a host via DNS (as in "someone's got a list of IPs from elsewhere).

 

Validating certs does a lot of good - largely because one of Psyphon's tricks is to make an HTTPS CONNECT to sites that have self-signed certs for domains that don't exist. Guardian's cert validation blocks this, so it is an effective part of the defence against psiphon without needing decrypt and inspect.

Posted

- Blocking IP based traffic helps

- locking down firewall rules helps

- MITM decrypt and inspect helps

 

But set the location feature in Psiphon to Japan and it still connects.

 

I have locked down ALL ports on my BYOD network. The only way out is via 80 & 443 through guardian. I force all my users to install the MITM cert and have full decrypt and insect on all SSL traffic. Psiphon still connects! So while the guidance from smoothwall does make life a little more difficult for the users it didn't take our students long to cotton onto setting the location to Japan to make it work.

Posted

And this is ipad, yes?

 

From our reverse engineering of the Http traffic (which this MUST be, as your firewall ports are blocked), it never responds with a valid HTTPS certificate.

Are you seeing any successful connections to psiphon-y domains? (they usually look like 4 dictionary words with a .com, and don't resolve in public DNS)

Posted
And this is ipad, yes?

 

From our reverse engineering of the Http traffic (which this MUST be, as your firewall ports are blocked), it never responds with a valid HTTPS certificate.

Are you seeing any successful connections to psiphon-y domains? (they usually look like 4 dictionary words with a .com, and don't resolve in public DNS)

 

Yes iPad. Yes you see the URL's in web filter made up of random words join together.

 

@tom_newton see NYNM post for more details

Posted
Block bare IP addresses.....this is in Guardian? ...because all other traffic will be just IP addresses once they have done the DNS lookup....

 

So this would cause a problem with any web site which has links that just contain IP addresses...but I agree that is probably not very often...and specific ones can presumably be allowed later...(not quite sure how that would be done if block all as precedence...)

 

Don't understand what "validating" a certificate would ensure for the client or SW....except that their https traffic might be potentially monitored....

 

 

i have blocked bare IP addresses for the past few years - ive had very few issues

Posted
OK - but how do you block IP addresses? In Guardian's "Core Blocked Content" ? How do you specify a general numeric IP format?
Posted
OK - but how do you block IP addresses? In Guardian's "Core Blocked Content" ? How do you specify a general numeric IP format?

 

theres a category for it just make a new rule or add it to an existing block rule

 

Screen Shot 2018-03-29 at 12.58.48.png

  • Thanks 2
  • 2 months later...
  • 1 year later...
Posted
Most of these VPNs do not use HTTPS which means the web filter won't have an effect. For most you will need to look at firewall rules. If your Smoothwall is also the firewall, implement the layer 7 blocks for VPN signatures in the firewall section. If this is mainly on BYOD networks and those can be isolated, block all out going traffic - web traffic will still be allowed via the transparent proxy and then open up only essential ports.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...