Block Tough Proxies
If you want to block tough proxies like hidemyass.com, my previously posted .htaccess methods won’t work. Those methods will block quite a bit of proxy visits to your site, but won’t work on the stealthier proxies. Fortunately, we can use a bit of PHP to keep them out.
Block Tough Proxies with PHP
To stop tough proxy visits from sites like hidemyass.com, add the following slice of finely crafted PHP to the top of your header.php
file:
<?php if(@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1))
die("Proxy access not allowed"); ?>
If you’re not using WordPress, just place the code at the top of your web page(s). No editing is necessary, so just add the code, upload the file, and done. You can check that it works by visiting your site via your favorite proxy service. If it works, access will be denied.
This method works for me on a Linux server running Apache 2.2.3, MySQL 5.0, and PHP 5.2.6. It should work on similar setups as well, but your results may vary depending on your server configuration.
Block Tough Proxies with WordPress
For WordPress, the technique basically is the same. Only packaged a bit differently to work optimally via WordPress hooks. Here is the code snippet to add via simple plugin or theme functions.php
file:
// block proxy visits @ https://m0n.co/01
function shapeSpace_block_proxy_visits() {
if (@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1)) {
die('Proxy access not allowed');
}
}
add_action('after_setup_theme', 'shapeSpace_block_proxy_visits');
Again, you shouldn’t need to add this code unless you specifically are having issues with out-of-control proxy visits. The code works great, but does cost a bit in terms of processing power and other server resources. So use wisely.
Bonus! Conditional blocking
Just a quick bonus snippet for you. Continuing from the previous WordPress technique, here is how you would limit execution of the proxy-blocking to a specific post or page:
// block proxy visits @ https://m0n.co/01
function shapeSpace_block_proxy_visits() {
if (!is_page('chat')) return;
if (@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1)) {
die('Proxy access not allowed');
}
}
add_action('after_setup_theme', 'shapeSpace_block_proxy_visits');
Notice the only difference here is the addition of the line:
if (!is_page('chat')) return;
That tells the function to stop and not do anything if the current page is named chat
. So you can change that to any page you would like.
Update: send response headers
If you are getting incorrect response headers (e.g., getting 200 “OK” for 404 “Not Found” pages). You can resolve by sending the desired header, for example to send 403 “Forbidden” response for any blocked proxy requests:
// block proxy visits @ https://m0n.co/05
function shapeSpace_block_proxy_visits() {
if (!is_user_logged_in()) {
if (@fsockopen($_SERVER['REMOTE_ADDR'], 80, $errstr, $errno, 1)) {
header('HTTP/1.1 403 Forbidden'); // send response header
die('Proxy access not allowed');
}
}
}
add_action('after_setup_theme', 'shapeSpace_block_proxy_visits');
You can change the header to whatever response, etc. Check the PHP documentation for more details.
Block Other Proxies with .htaccess
If for whatever reason you aren’t using the above PHP method, you can still block a majority of the “lesser” proxies by adding the following block of HTAccess code to your site’s root .htaccess
file:
# BLOCK PROXY VISITS
# PerishablePress.com: http://bit.ly/12k6Uo
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:VIA} !^$ [OR]
RewriteCond %{HTTP:FORWARDED} !^$ [OR]
RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$
RewriteRule .* - [F]
</IfModule>
This proxy-blocking technique is less-effective than the PHP method, but should help reduce overall proxy traffic to your site. Using HTAccess to filter proxies requires fewer system resources than the PHP method. So if you get tons of traffic or have lots of pages, you’re better off sticking with the HTAccess technique. It’s sort of a trade-off between effective proxy-blocking and optimum performance, which will vary depending on your needs and server configuration.
My Strategy
On most of my personal sites, I allow proxy access. I understand the need for privacy, but there are situations where denying proxy visits makes sense. Most often, the .htaccess
code is a suitable solution. But for sites where anonymity isn’t an option, the PHP method is the way to go.
10 responses to “Block Tough Proxies”
Jeff,
I agree that your PHP solution is a nice little trick, but I think it is possible it will do more harm than hurt.
By blocking requests from computers (or servers) that listen to port 80 you would basically be blocking anybody who has a home testing server setup. I have a LAMP and an XAMPP setup (and expose one to the internet) so this PHP would block me and I suspect would block a majority of the web development community. This code could also block Google’s spiders because if you navigate to a Googlebot IP, it redirects you to Google’s homepage (at least it did the last time I checked).
You also add the overhead of making a request before serving content to the user. Since PHP isn’t non-blocking like Node.JS, the script would have to wait for the request to fail or timeout for computers that don’t listen to port 80.
Personally I’d stick with the htaccess rules. They won’t block everything, but with them legitimate users won’t be identified as proxies.
Cheers,
PhpMyCoder
I agree – all good points. I should’ve gone into more detail in the post. The htaccess rules work great at reducing overall proxy visits, but for those (hopefully) rare situations where visitor identity is required, the PHP snippet does the job. Hopefully it well help those who need it, and maybe inspire someone to produce a more widely applicable method. Thanks for the feedback :)
Be aware that the “Tough proxy” block will also block any visitors that have a web server set up on their own network.
Good tip – Thanks for the reminder :)
Jeff,
what about who’s using a secure VPN to avoid having their traffic unencrypted on a public WIFI network? Is this script gonna stop that traffic too?
I think it should, but don’t have anything like that set up for testing, so can’t say for sure.
I understand. I think you might setup something together with Chris Coyer to simulate this situation. You might use this little utility to setup a VPN server; then configure another machine on a different network to use that VPN server as gateway. Don’t know if I’m saying a bunch of crap and there’s actually a faster way (ie a free VPN service) to test this thing.
Actually the number of people that is getting these VPN services on untrusted WIFI is growing; moreover people living in countries with a government limitation on internet are using these services too.
Thanks for the suggestion – sounds like another great idea :)
I tried with my blog in the header.php put it at very beginning. With most
proxies it works but with proxify.com it doesnt work.
Great blog.
All the best
hi there,
comment via mail cause comments seem to be already closed – OT: definitely
NOT good (see my comments on your post over there) – so here we go:
Its plainly said dumb to let a local development server run open to the
public – thats why my local server is NOT publicy accesible; although I
sometimes open access to it using a DynDNS provider.
This also automatically solves problems like being blocked from using a site
because it “thinks” you’re homing in via proxy ;)
cu, w0lf.
ps: another question – does this block access by any proxy? Any mobile phone
provider I know of (at least in Germany) is using proxy servers – so won’t
mobile users get blocked, too?