After my earlier post Referrer and Comment spammers are a PITA I came up with two mod_perl plugins to Apache and an "apache level" firewall.

The reason for the apache-level firewall is two-fold.  There is no direct way for the Apache user to manipulate an iptables chain (as it doesn't run as root), and second; I was not happy with suid root access or other forms of message passing to a daemon which would manipulate the firewall for me.

Architecture is thus, in httpd.conf place the following two lines:

PerlPreConnectionHandler PGREGG::httpBLBlock
PerlLogHandler PGREGG::httpBLLog

The first tells apache to run the handler in my httpBLBlock.pm module when a connection is received (before the request has been sent by the client).  In this handler, I am simply looking for a filename matching that IP in a directory that is writable by the apache user.  The contents of the file are a SCORE:httpBL_answer:[LIST].  Based on this, the module checks the mtime of the filename is in the last SCORE days, then the firewall is in effect. If so, we simply tell apache to drop the connection.  If the file has expired, we delete the file.

The second line is more interesting, and what creates the firewall filenames. In order to not impede the general speed of request handling, processing is performed in the Logging section of the Apache process. Our module is called by apache after the response has been sent, but before the access_log entry has been written.  In our module we perform the http:BL API call and compute the above SCORE based upon the Threat* level and Age* of the API response. (* both Threat and Age are octets in the DNS lookup).  We merely discount the Threat down to zero based on the Age (0-255) where an entry 255 days old reduces the SCORE to zero.
If the SCORE is larger than our trigger level (3) then we create the firewall filename, log the entry in our own httpbl.log and return Apache2::Const::FORBIDDEN.  This causes Apache to not log the entry in the normal access_log.  Otherwise, if all is ok, we return Apache2::Const::OK and Apache logs the hit as normal.

I have a bit of code tidy up, restructure the config/firewall directory and pull some common code out to a shared module before I can release to the world.

An interesting side effect to publishing the last story out through Planet PHP and other news sources along with the Project Honey Pot image is that when browsers viewed those sources, they all asked for the image off my server. In several cases, these were known spammer, Comment spammer, and other abusers. My server then created the firewall entry blocking them before they were able to follow the links back to my server.
 
I have been reading up more on Apache Bucket Brigades in an attempt to allow the firewall filter to be placed immediately after the request has been received and allow a custom response to the browser. This may help an otherwise unsuspecting user if their machine had been trojaned. I don't mind admitting I'm thoroughly confused right now :)

This shouldn't be news to anyone - but Referrer and Comment spammers are a real pain in the a*se.  Polluting my web logs and making any meaningful log analysis problematic.

So, I now have an itch to scratch and I'm going to do something about it. I would encourage you, the reader, to do something about it too.

Firstly, get yourself over to Project Honey Pot and read up on the project.  If you can, set up a Honey Pot or two yourself. Also be sure to read about the http:BL - this works along similar lines to the DNS blacklists used for Email spammers.

Next, I'm going to write a general Apache mod_perl module which will provide integration (lookup) to the http:BL and allow the user to "action"* the abusers.  Minimally, it will prevent the normal apache log files from being polluted by diverting the log entries to a httpbl logfile.

* "action" - To provide flexibility, I'm thinking of running an external script with the IP of the abuser.  The script can then perform any action you wish. The one I'm going for is an iptables firewall block.

Comments and suggestions welcome.

Project Honey Pot has implementations for several languages, including PHP and Perl (the languages that mean most to me).  There may be an implementation for your Web application so you might not be interested in what I'm doing at all :)