Ultra Surf 8.8 How to block?

We have had several students find this new filter work around. It's called Ultra Surf from www.wujie.net

It comes from Ultrareach and has been very hard to stop. Has anyone run into this Anonymous proxy?
We have found the the program runs on port 9666.
We blocked all outbound traffic on 9666. Still will not stop it.
Found a forum that says to block server 67.15.183.30. Still will not stop it.
It has to be some sort of bot that has servers all over the place that it changes ports and server IP's.

Anyone, Anyone?

just about every proxy software and p2p client will now do an internal portscan against your firewall if it finds itself blocked.  I bet it is falling back to port 80 and/or 443.  Other than routing them through a standard proxy(instead of transparent) and locking it down that way there's no easy way to block traffic like this.  Make a strong policy that includes removal of network access and strictly and rapidly enforce it.

Even better would be an IPS rule (one that we could either add manually, or be able to select as a "Policy" rule, like in Version 6) that could detect a pattern of traffic that indicates that particular app is being used.

ultra surf uses https port 443 to connect to its parent proxy. Find the IPs of the proxies that it is connecting to and create a packet filter rule to deny the connection.

There is another possibility now with the advent of the new AFC engine in 7.200 ... perhaps Astaro may use it in the future to analyze and block programs like these as well...

Ultra Surf have tons of IP addresses.
So it's impossible to add the IP.
Every time Ultra Surf making a connection, the log (Content Filter) would appears url="X.X.X.X:443" with randomize IP addresses.
After that, the client become invisible (not recorded by Astaro) and they can browse to any sites.

So I tried with Regular Expressions in Content Filter:

1. ([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\:443

2. [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\:443

The result Ultra Surf cannot connect anymore.
I'm not add packet filter rule for blocking.

Good day!  Has anyone made progress in defeating Ultrasurf?

Just give up.  IT at my school has tried and failed to beat us.  You cannot win.

7.400 will be including a new HTTPS proxy... which can scan content... this may help.

As Bruce mentioned, 7.400 includes the ability to decrypt https at the gateway for inspection.  There will certainly be a few issues to consider in implementing this function, but it will provide a substantially improved a level of control.

Just give up.  IT at my school has tried and failed to beat us.  You cannot win.

Technology alone can't fully address the issue.  At some level people in supervisory positions have to be involved- whether teachers, administrators, managers, etc.

Hi guys, 

i just tried the latest version of Ultrasurf 9.2 to be able to go through the new web security package of ASG 7.400 BETA.

and the result is ...  yes, Astaro Security Gateway can block ultrasurf without a problem.
see the attached image and logfile excerpt.

2008:11:21-23:13:22 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="61224 ms" request="0xb18ede98" url="91.109.241.179" error="Connection to server timed out"

2008:11:21-23:13:22 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="60195 ms" request="0xada5c1b0" url="91.121.65.41" error="Connection to server timed out"

2008:11:21-23:13:22 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="63229 ms" request="0xb2edada8" url="91.127.203.140" error="Connection to server timed out"

2008:11:21-23:13:22 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="60194 ms" request="0xadafd900" url="88.203.6.227" error="Connection to server timed out"

2008:11:21-23:13:24 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="400" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="2079" time="1 ms" request="0xada5c1b0" url="" error="Received invalid request from client"

2008:11:21-23:13:27 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="64191 ms" request="0xad8a6170" url="91.111.95.31" error="Connection to server timed out"

2008:11:21-23:13:32 (none) httpproxy[6663]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="10.254.3.239" user="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Proxy)" filteraction=" ()" size="0" time="65138 ms" request="0xb1a5abb0" url="91.55.221.219" error="Connection to server timed out"

regards
Gert

As Bruce mentioned, 7.400 includes the ability to decrypt https at the gateway for inspection.  There will certainly be a few issues to consider in implementing this function, but it will provide a substantially improved a level of control.

yes you do a man in the middle attack on the https connection....not sure how i feel about this because you are intercepting what is supposed to be a direct secured connection between two points now.  I can see the utility on the network admin side..but this can also be used to a very detrimental affect by rogue it operators waaaay to easily.  Luckily the option to NOT use it exists..so that's the choice i'll make..

As Bruce mentioned, 7.400 includes the ability to decrypt https at the gateway for inspection.  There will certainly be a few issues to consider in implementing this function, but it will provide a substantially improved a level of control.

yes you do a man in the middle attack on the https connection....not sure how i feel about this because you are intercepting what is supposed to be a direct secured connection between two points now.  I can see the utility on the network admin side..but this can also be used to a very detrimental affect by rogue it operators waaaay to easily.  Luckily the option to NOT use it exists..so that's the choice i'll make..

yes you do a man in the middle attack on the https connection....not sure how i feel about this because you are intercepting what is supposed to be a direct secured connection between two points now.  I can see the utility on the network admin side..but this can also be used to a very detrimental affect by rogue it operators waaaay to easily.  Luckily the option to NOT use it exists..so that's the choice i'll make..

The use of MitM decryption is optional, and needs to be used wisely- but the failure to protect systems and employees from the dangers of the Internet can be a crime.  This isn't easy, Astaro is trying to provide the tools to help companies secure their infrastructure, but competent personnel making informed decisions are a key to making it work.  That's not to downplay the danger of rogue admins- but if you have rogue admins, you have a serious problem regardless of the technology.

I've been deep in compliance issues lately (specifically Massachusetts 201CMR17.00), so I see tools to help companies "cover their assets" as very timely.

BTW, there are new anonymization tools to help protect user identities scheduled for inclusion in 7.400.

The use of MitM decryption is optional, and needs to be used wisely- but the failure to protect systems and employees from the dangers of the Internet can be a crime.  This isn't easy, Astaro is trying to provide the tools to help companies secure their infrastructure, but competent personnel making informed decisions are a key to making it work.  That's not to downplay the danger of rogue admins- but if you have rogue admins, you have a serious problem regardless of the technology.

I've been deep in compliance issues lately (specifically Massachusetts 201CMR17.00), so I see tools to help companies "cover their assets" as very timely.

BTW, there are new anonymization tools to help protect user identities scheduled for inclusion in 7.400.

And there are two additional laws that will be in effect in California starting in 2009 about medical record privacy (as if the ones we have arent' enough).  SB541 and AB211 if you want to read them.  Up to $250,000 in fines for violations.  And for the first time, individuals can be fined too - not just institutions.

Jack, a question about the anonymization tools:  Is that to anonymize identities in reporting?  I've now run up against public sector problems where by union rule IT depts can track the traffic but not the user's ID (except in cases of illegal activity - where the user can be tracked, but still only within "the rules". Aaaaaaarrrrrrggggghhhhhh).

Jack, a question about the anonymization tools:  Is that to anonymize identities in reporting?  I've now run up against public sector problems where by union rule IT depts can track the traffic but not the user's ID (except in cases of illegal activity - where the user can be tracked, but still only within "the rules". Aaaaaaarrrrrrggggghhhhhh).

The new anonymizing features are designed to provide the functionality you mention- allowing traffic to be monitored by an anonymized user ID which can't be associated with an actual user unless proper authorization is given.  I'll try to get some more details out when I get my beta system running.

I believe the EU privacy laws were the original impetus for the feature, but the need is growing rapidly.

yes you do a man in the middle attack on the https connection....not sure how i feel about this because you are intercepting what is supposed to be a direct secured connection between two points now.  I can see the utility on the network admin side..but this can also be used to a very detrimental affect by rogue it operators waaaay to easily.  Luckily the option to NOT use it exists..so that's the choice i'll make..

Hi William,

Yes we do HTTPS filtering by inspecting the traffic in the middle while preserving the trust chain along the client-server communication. Have you seen a different way this can be done on the gateway?  The only way to answer our users many requests for control over HTTPS (with other benefits such as blocking Ultrasurf and other proxy-avoiding programs), is to somehow be able to peer inside such encrypted connections. We cannot brute-force the encryption on the fly, and this is the method of HTTPS filtering that virtually all existing solutions use today. I'm asking in case we missed something in our research on implementing this feature.