Can PAN block proxy traffic originated from other country?

[JTR]

Hello guys

I'm trying to block some traffic originated from other country. PAN can block those traffics with its source address and regional info. But what if they use some kind of proxy(like ultra surf) to disguise its original source ip and change its ip to domestic ip , and what if they use ssl proxy? If that ssl server is in my country, its source ip will be change to domestic one. PAN can block proxy application originated from its internal network, but it seems hard to block proxied traffic originated from out side area. Do you have any solution for this?

Thank you very much. :smileygrin:

[rmonvon]

Hi...Yes, this is a challenge and there's no effective way to detect & control the proxy traffic.  It's like using NAT to hide the original client IP address.  If the proxy/NAT device does not forward the client's real IP address, there's no method to detect it. Some proxy will insert an HTTP header like X-Forward-For or Via: and we can write a custom sign to detect it.  However, those headers are not always present.

Maybe others on this forum may have some other ideas.  Thanks.

[mikand]

Well if its a problem that attackers use local vpn services in your country then you should change your policy model from a blacklisting one into a whitelisting one.

That is find out which ip ranges should be allowed and work your way from there - all other ranges will then by default be blocked.

[JTR]

Thanks you guys, I think it's not only the PAN's issue. Can I understand that there's no other device which can do this? White list might be a good idea, but it's too hard to sort ssl proxy ips.

[mikand]

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).

[JTR]

Thank you mikand, wish you have a good luck!!