One of my favorite security measures here at Perishable Press is the site’s virtual Blackhole trap for bad bots. The concept is simple: include a hidden link to a robots.txt-forbidden directory somewhere on your pages. Bots that ignore or disobey your robots rules will crawl the link and fall into the trap, which then performs a WHOIS Lookup and records the event in the blackhole data file. Once added to the blacklist data file, bad bots immediately are denied access to your site. I call it the “one-strike” rule: bots have one chance to follow the robots.txt protocol, check the site’s robots.txt file, and obey its directives. Failure to comply results in immediate banishment. The best part is that the Blackhole only affects bad bots: normal users never see the hidden link, and good bots obey the robots rules in the first place.
In five easy steps, you can set up your own Blackhole to trap bad bots and protect your site from evil scripts, bandwidth thieves, content scrapers, spammers, and other malicious behavior.
The Blackhole is built with PHP, and uses a bit of .htaccess to protect the blackhole directory. The blackhole script combines heavily modified versions of the Kloth.net script (for the bot trap) and the Network Query Tool (for the whois lookups) (404 link removed 2012/07/08). Refined over the years and completely revamped for this tutorial, the Blackhole consists of a single plug-&-play directory that contains the following four files:
.htaccess– basic directory protectionblackhole.dat– server-writable log file (serves as the blacklist)blackhole.php– checks requests against blacklist and blocks bad botsindex.php– generates blackhole page, performs whois lookup, sends email, and logs data
These four files are all contained in a single directory named “blackhole”.
Installation Overview
I set things up to make implementation as easy as possible. Here are the five basic steps:
- Upload the
/blackhole/directory to your site - Ensure writable server permissions for the
blackhole.datfile - Add a single line to the top of your pages to include the
blackhole.phpfile - Add a hidden link to the
/blackhole/directory in the footer of your pages - Prohibit crawling of the
/blackhole/by adding a line to yourrobots.txtfile
It’s that easy to install on your own site, but there are many ways to customize functionality. For complete instructions, jump ahead to Implementation and Configuration. For now, I think a good way to understand how it works is to check out a demo..
One-time Live Demo
I have set up a working demo of the Blackhole for this tutorial. It works exactly like the download version, but it’s configured to block you only from the demo, not from the entire site. Here’s how it works:
- First visit to the Blackhole demo loads the trap page, runs the whois lookup, and adds your IP address to the blacklist data file
- Once you’re added to the blacklist, all subsequent requests for the Blackhole demo will be denied access
So you get one chance to see how it works. Once you visit, your IP will be blocked from the demo only – you will still have full access to this tutorial (and everything else). That said, here is the demo link: Blackhole Demo. Visit once to see the Blackhole trap, and then again to observe that you’ve been blocked. If I were to include the blackhole.php in the header of my theme files, you would be banned from pretty much the entire site.
Implementation and Configuration
Here are complete instructions for implementing and configuring the Perishable Press Blackhole:
Step 1: Download the Blackhole zip file, unzip and upload to your site’s root directory. This location is not required, but it enables everything to work out of the box. To use a different location, edit the include path in Step 3.
Step 2: Change file permissions for blackhole.dat to make it writable by the server. The permission settings may vary depending on server configuration. If you are unsure about this, ask your host. Note that the blackhole script needs to be able to read, write, and execute the blackhole.dat file.
Step 3: Include the bot-check script by adding the following line to the top of your pages:
<?php include($_SERVER['DOCUMENT_ROOT'] . "/blackhole/blackhole.php"); ?>
The blackhole.php script checks the request IP against the blacklist data file. If a match is found, the request is blocked with a customizable message. See the source code for more information.
Step 4: Include a hidden link to the /blackhole/ directory in the footer of your pages:
<a style="display:none;" href="http://example.com/blackhole/" rel="nofollow">Do NOT follow this link or you will be banned from the site!</a>
This is the hidden link that bad bots will follow. It’s currently hidden with CSS, so 99% of visitors won’t ever see it. To hide the link from users without CSS, replace the anchor text with a transparent 1-pixel GIF image.
Step 5: Finally, add a Disallow directive to your site’s robots.txt file:
User-agent: *
Disallow: /*/blackhole/*
This step is pretty important. Without the proper robots directives, all bots would fall into the Blackhole because they wouldn’t know any better. If a bot wants to crawl your site, it must obey the rules! The robots rule that we are using basically says, “All bots DO NOT visit the /blackhole/ directory or anything inside of it.” More on this in the next section..
Further customization: The previous five steps will get the Blackhole working, but the index.php requires a few modifications. Open the index.php file and make the following changes:
- Line #54: Edit the path to your site’s
robots.txtfile - Line #56: Edit the path to your contact page (or email address)
- Lines #140/141: Edit email address with your own
- And in
blackhole.php, edit line #53 with your contact info
These are the recommended changes, but the PHP is clean and generates valid HTML5, so feel free to modify the source code as needed. Note that beyond these three items, no other edits need made.
Caveat Emptor
Blocking bots is serious business. Good bots obey robots.txt rules, but there may be potentially useful bots that do not. Yahoo is the perfect example: it’s a valid search engine that sends some traffic, but sadly the Yahoo Slurp bot is too stupid to follow the rules. Since setting up the Blackhole several years ago, I’ve seen Slurp disobey robots rules hundreds of times. Bottom line: the Blackhole will block any bot that disobeys the Update: By default, the Blackhole no longer blocks any of the popular search engines. See the next section for more information.robots.txt directives. Proceed accordingly.
Whitelisting Search Bots
Initially, the Blackhole blocked any bot that disobeyed the robots.txt directives. Unfortunately, as discussed in the comments, Googlebot, Yahoo, and other major search bots do not always obey robots rules. And while blocking Yahoo! Slurp is debatable, blocking Google, MSN/Bing, et al would just be dumb. Thus, the Blackhole now “whitelists” any user agent identifying as any of the following:
- googlebot (Google)
- msnbot (MSN/Bing)
- yandex (Yandex)
- teoma (Ask)
- slurp (Yahoo)
Whitelisting these user agents ensures that anything claiming to be a major search engine is allowed open access. The downside is that user-agent strings are easily spoofed, so a bad bot could crawl along and say, “hey look, I’m teh Googlebot!” and the whitelist would grant access. It is possible to verify the true identity of each bot, but as X3M explains in the comments, doing so consumes significant resources and could overload the server. Avoiding that scenario, the Blackhole errs on the side of caution: it’s better to allow a few spoofs than to block any of the major search engines.
License and Disclaimer
The Perishable Press Blackhole is released under GNU General Public License. Check the Creative Commons for a summary and/or see the Blackhole source code for additional information. Also note that by downloading the Blackhole, you agree to accept full responsibility for its use. In no way shall the author be held accountable for anything that happens after the file has been downloaded.
Blackhole Download
Here you can download the current version of the Blackhole:
Blackhole - version 1.2 - 8KB ZIP
178 Responses
RS – July 22, 2010
So, seems to work, but seeing a couple errors in my apache logs.
[Thu Jul 22 13:23:01 2010] [error] [client 119.63.198.97] PHP Notice: Undefined variable: buffer in /var/www/htdocs/blackhole/index.php on line 78
[Thu Jul 22 13:23:01 2010] [error] [client 119.63.198.97] PHP Notice: Undefined variable: extra in /var/www/htdocs/blackhole/index.php on line 98
Also seeing occasionally:
[Thu Jul 22 13:56:21 2010] [error] [client 64.40.121.187] PHP Notice: Undefined variable: nextServer in /var/www/htdocs/blackhole/index.php on line 91
The first one looks like it’s just because you’re trying to append to a variable that isn’t defined in the first place…
The second… is just because extra isn’t being defined all the time.
The last one… just needs to be something more like if(isset($nextServer)) { because if returns an error on unset variables. if($variable) is not kosher for a while now.
Frank – August 3, 2010
Getting a weird return from the arin WOIS lookup.
I’ve been through it several times now, and tried several fixes but Arin continues to find an ‘n’ character (presumably from a ‘n’) on the front of the IP. Can’t pinpoint where its getting that, or how to fix it.
Jeff Starr – August 3, 2010
Frank, I’m also trying to resolve that issue, but so far without success. I’m not sure if there is anything that can be done from within the script.
If anyone has further info on this it would be appreciated! :)
darrinb – August 4, 2010
ARIN Changed its protocol for directory lookups which is why you’re seeing that weird message. They recommend changing to their new RESTful protocol.
You can read more about it here:
https://www.arin.net/resources/whoisrws/index.html
In my WP plugin version of this script (in process) I’m looking into switching to the RESTful query protocol they recommend and styling the returned XML.
Frank – August 4, 2010
@RS: The two PHP Notices you’re getting are an easy fix. Make a new line after
global $msg, $target;and add the following 2 lines:$buffer = '';$nextServer = false;@ Jeff and darrinb: Thanks for the backup. Based on my tests I was pretty certain the problem existed outside the Blackhole code.
ノートパソコン比較 – August 6, 2010
Okay this might sound stupid to most of you, but why should I ban bad-bots? Obviously they access content I don’t want them to access, but banning them from the site would have pretty bad consequences (google).
I know nothing about this topic, but wouldn’t it be a good idea to blacklist the bots who went into the trap, not from the domain, instead update the .htaccess file to block them only from the pages I don’t want those bots to crawl?
Well I really don’t know a thing about .htaccess or blocking bots, so this might be a rather silly idea.
Lazza – August 6, 2010
One reason: bandwidth.
Jeff Starr – August 7, 2010
@ノートパソコン比較:
Great questions.
In addition to bandwidth, blocking bad bots helps conserve server resources, which are a commodity on non-shared environments. Also, many bad bots are malicious, so blocking them also improves the security of your site, which benefits everyone.
Custom blocking via htaccess is also a good idea. There are many (many) articles here at Perishable Press on the topic of using htaccess to protect your site (including blocking bad bots).
Soren – August 9, 2010
You are writing that this script should be on top of the pages
So if I put this script on my header.php that will be correct?
Or do I need to put it on “single.php, page.php, archive.php etc etc”?
Just a little confused here…
Thanks
Soren
Jeff Starr – August 9, 2010
@Soren: Yeah, the include snippet just needs to be placed at the top of your
header.phpfile. Then, because that file is included with each page view, the Blackhole script covers your entire site.Rune Jensen – August 16, 2010
I have succes putting a small form in a HTML remark with the action attribute to the honeypot. Fields are named with attactive words like email, post, blog and message. Since Google are actually running HTML, they will not see the HTML remark and not follow it.
Another is to use an if statement to check if a request accepts GZIP in accept-encoding. Since bots do almost never have access to the compression library, they will not accept GZIP. Then put in the form if GZIP is not accepted, and use af post method. Google and other search engines do never follow post, since if they did, they would themselves be spambots.
I use a mix of these two methods, works great, and takes almost all spambots as well as harvesters. My blacklist is constantly around 30-50 malicous bots. When blocking, use 404 or (eventually) 410 status errors, do not indicate you have accepted the request.
The blacklist, the honeypot creates, mine is dynamic, since I do not want an IP banned for life and the blacklist to be too long. Generelly, unban an IP if it has not made a request for some time and keep the list on a max of around 70 IPs, My experiense is this is enough even for large attacks.
Rune Jensen – August 16, 2010
Some additional tips, that might or might not be usefull – these are more advanced, and focused on blog spambots more than the blackhole, but quite effective wellknown techniques:
You might want to use HTTP header information to make a “fingerprint” (fx. an MD5 checksum) of the request. The reason is, a lot of spambots are only posting to, not getting the page. They will get their information about your page instead from harvester bots, which are scraping your site. And a lot of times, the header are not the same between bots.
I use useragent, accept-encoding, accept-language, accept-charset, connection and protocol for value. To make it page-dependent as well, I put in the URL.
Use of a stardate (look it up on Google) is effective to simulate a session without using cookies, so that you have to post within (say for example) 4 hours of getting a page. Combine it with the fingerprint, put it in an HTML input hidden field in the form, and recalculate at post time to verify that the fingerprint match, and that stardatePOST-stardateGET<timelimit.