Well the point of using a ssl-proxy or a vpn service for that matter is to hide the true srcip. This way the target will only see the ip of the ssl-proxy/vpn-service. If its a bad server then x-forwarding-for, x-client-ip and similar http headers might "leak" through. There are various "counterattacks" one can use to in some situations still identify the true ip (or other data such as mac address etc). You can for example inject a java applet that will gather local data and post it back to the server (that is if you have a webpage where you can inject such things - the question is if this is a good thing to do or not ethically). Another method is if the vpn service is badly setup you can figure out at least the ISP (if lucky) by forcing the client to request random subdomains - which when you at the same time monitor your authoritive dns servers for this zone could pick up from where in the world the request for this particular "one time subdomain" originates from. When it comes to public services such as tor you can use these lists to dynamically import the contents into PA and have for example all TOR exit nodes (well most of them) blocked from accessing your site: http://torstatus.blutmagie.de/ip_list_all.php/Tor_ip_list_ALL.csv http://torstatus.blutmagie.de/ip_list_exit.php/Tor_ip_list_EXIT.csv Unfortunately I doubt that appid would be of any help here regarding ultrasurf because appid will in that case only be useful when the PA sits such as client <-> PA <-> Ultrasurfproxy and not client <-> Ultrasurfproxy <-> PA <-> server. So if this is a problem for you I still believe that the best option for you would be to use a whitelist for which srcip's are allowed to access your, for example, webservers. That is a blacklist first to block known bad ip's followed by a whitelist of allowed ip's - the easy way here would be to use the builtin geoip function of PA (which is somewhat accurate - I guess PA uses the Maxmind databases for this).
... View more
