How to Blocking ULtrasurf?

if the port is no longer 443, which is quite unlikely but I have small suspicion on StartTLS else it is not doing standard SSL if there is no Hello as expected. Cant we assume them to negotiate SSL with F5 instead to break their direct SSL with the proxy server (option in Ultrasurf config?). Else block them in their DNS request to known Ultrasurf DNS server ... Remove the Ultrasurf cache files in user temp directories, if there is automated way to always do discovery req that can be blocked

 

 

Some past info, not usre for now on v10, in Ultrasurf versions 6.6 and 6.7, the connection travelled to port 443 but was not SSL. Beginning with version 8.8, Ultrasurf began to use what appears to be an anonymous SSL connection, where the server side does not respond with a certificate.

yes, i think ultrasurf use stange ssl, still dont know how to block it.

Great seems like the different btw IP::local_addr and IP::remote_addr?

 

 

Noted previously IP intelligence as shared did not detect that anonymous proxy.

 

Just wondering will (now) IP::remote_addr be detected by iprep_lookup or still as before shared?

 

 

And if IP intelligence works then iRule for that will also works..something like this

 

 

when CLIENT_ACCEPTED {

 

set ip_reputation_categories [IP::reputation [IP::remote_addr]]

 

set is_reject 0

 

if {($ip_reputation_categories contains "Proxy")} {

 

set is_reject 1

 

}

 

if {($ip_reputation_categories contains "Web Attacks")} {

 

set is_reject 1

 

}

 

}

 

We cannot use IP Reputation because [IP::local_addr] is not detected by IP Intelegence database, i tested by cli iprep_lookup.

 

 

ok thanks. You tried that with remote_addr also right?

 

 

If you wanted, you can try the brightcloud lookup [1] globally to see if it does detect.

 

Brightcloud which the IP intelligence is based on can even request for change [2]

 

[1] http://www.brightcloud.com/support/lookup.php

 

[2] http://www.brightcloud.com/support/iprepchangerequest.php

[IP::local_addr] called in a clientside event like CLIENT_ACCEPTED will return the client's destination IP address (the VS IP for a host VS). As BT says, you'd want to use [IP::client_addr] or [IP::local_addr] which both return the client IP in CLIENT_ACCEPTED.

 

 

Aaron

We previously try to block the ultrasurf , by destination ip address [IP::local_addr] using ip intelegence . The VS use wildcard 0.0.0.0:443.

 

We log the [IP::local_addr] on event when CLIENT_ACCEPTED , but when we check the log and check the ip addrss with ipreplookup and also from brightcloud, it's is not detected as malicious ip.That's why i cannot use the ip intelegence to block ultrasurf.

 

-Petruk

 

[IP::remote_addr] will fit your case as this is the actual address to be submitted for IP intel checks as well in the quarantine IP blacklist maintained in session. local_addr either give you the VS ip or the SNAT src (if enabled) in client and server respectively. I know previously the IP intel did block the Ultrasurf hence why I am asking why not for your case ... unless Ultrasurf has changed in v10 or later. Will you be able to share that Ultrasurf Dest IP you used for checking?

Thanks for sharing. Seems like Brightcloud is not having any flagging on those IP.

 

I tested it in other site like robtex and domain dossier. looks like there is blacklist (below) taking the 65.49.14.78 as example.

 

 

if need be, you can make request at Brightcloud to include these IP :)

 

http://www.brightcloud.com/support/generalchangerequest.php

 

 

LISTED IN BLACKLIST!

 

scanned ,working ,abusive

 

opm.tornevall.org

 

cbl.abuseat.org

 

pbl.spamhaus.org

 

zen.spamhaus.org

 

problems.dnsbl.sorbs.net

 

safe.dnsbl.sorbs.net

 

b.barracudacentral.org

 

rbl.efnetrbl.org

 

xbl.spamhaus.org

 

dnsbl.sorbs.net

 

web.dnsbl.sorbs.net

 

spam.dnsbl.sorbs.net

 

sbl-xbl.spamhaus.org