PDA

View Full Version : PHP Script that automatically bans an IP address


the_pm
April 28th, 2006, 04:23
Hey everyone,

I decided it was time I built myself a spider trap. For those who are not aware, a spider trap is a script that automatically bans bots from a site that do not follow instructions given to them in a robots.txt file. This will stop email harvesting bots, log spammers, bulk downloading software and search engines that are programmed to misbehave.

I'm looking for a script that will automatically ban the IP of the offending visitor the instant that page is hit. Bonus if it causes some sort of evilness on the bot.

Basically, it will work like this. Every page of [insert site here] will have a 1x1 pixel link before any other links on the page. The robots.txt file will contain explicit instructions for bots not to use the link. Should the bots use the link, the next page will contain a simple warning and a second link (this intermediary page is in the extremely remote event a real live visitor stumbles upon the trap). The warning will make it clear no one is to proceed. The link will activate the script, which will instantly blacklist the IP of the offending visitor.

So, how does one go about creating this script, or do you have a favorite script of your own you've tried? I know there are spider traps out there already built, but having no experience with them, I'd like input from IWDN :)

Anoop
April 28th, 2006, 13:45
The basic idea is something like this :
Use apache rewrite rules to forward the request for the 1 px image link to our blocking script. If you want to block the IP immediately, then you need the blocking script to executes commands which requires root privilege. For this purpose, we need a set uid program which switch to root user to execute the
command to block the IP (either using IP tables or by modifying apache configuration file).

I haven't used any such scripts. I'll update here if I find any such scripts. (or I would write one when I get time :D )

-Anoop

the_pm
April 28th, 2006, 14:36
Thanks for the response Anoop :) Does it need to be root server access, or can it be virtual account access? I always feel a little uneasy about allowing an automated script to "log in" to root, especially when triggered by a public action.

Anoop
April 28th, 2006, 14:44
Not necessarily "root" access. That depends on the method we use to block the IP. If we use .htaccess (deny from IP), then we need the privilege of the virtual host user only.

the_pm
April 28th, 2006, 14:46
What do you think of the method used here? http://www.webmasterworld.com/forum88/3104.htm

I'm trying to figure out how the .php file in this example actually writes to the .htaccess file.

Anoop
April 28th, 2006, 15:04
That is what I mentioned about a setuid program. php script has only permission of "nobody" (or what ever user apache run as). .htaccess file is under the ownership of virtual host user, with permission 644. So the script doesn't have write permission to .htaccess. In order to write to .htaccess, we should use a setuid program to switch to the virtual user.

the_pm
April 28th, 2006, 15:16
So I take it setting permissions to 666 on the .htaccess file, as was done in the example I posted, will allow anyone to write to it?

Anoop
April 28th, 2006, 15:32
Yes, 666 means read and write permission to all.

the_pm
April 28th, 2006, 15:52
Well then, knowing nothing about this, how would one go about authenticating the user and doing the write without opening up the .htaccess file for anyone to muck with?

Anoop
April 28th, 2006, 16:55
The problem here is identifying the user :) Any other user script will be running as "nobody" like our IP blocking script. And I don't think password protecting .htaccess is a solution.
Setuid program works such that it switches to the user for writing to the file and switch back to it's original user id after writing to the file. Since we don't give write permission to that program, any user accessing the program can only execute the bit of code we write. They won't be able to modify the code and thus execute something else with the virtual user's permission. But we need to be careful while writing setuid programs.
http://nob.cs.ucdavis.edu/bishop/secprog/index.html