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:
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.
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.
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:
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).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!