I’ve used Spam Karma 2 on this blog forever, as it’s an effective and glorious piece of software that does its job well, as evidenced by the ~90,000 comment spams eaten. It’s elegantly designed unlike most of my plugins, and actually built to be extended by others with its plugin architecture.

I’ve been playing around with mod_security recently — though I’ve pined over it for quite longer — as it provides some rather hefty and glorious functionality for smacking spammers. I didn’t do this before because Dreamhost didn’t provide mod_security access. A Small Orange does, so I’ve converted most of my referral spam handling over to mod_security. That’s nice, but doesn’t do much over what mod_rewrite offers.

So I set about experimenting with fighting comment spam with mod_security since it’s capable of scanning POST payloads. It should be faster than Spam Karma 2 as it’s a compiled and linked module running in Apache rather than a interpreted — even though PHP and Zend do happy things with byte code compiling PHP code — script. I had a whole post written up similar to my original article based on mod_rewrite discussing what mod_security does, how to use it and how to keep up with the spammers.

Sharing resources

But then I had a sudden flash… why should I manually keep up with spammers? I’ve got some hot software that does it for me in Spam Karma. If I could leverage SK2’s blacklisting and moderation handling and automatically generate mod_security rules for me, wouldn’t that be much easier? I mean, SK2 has a ready list of over 4,800 domains that it has quite aptly determined are used for no good. Wouldn’t it make sense to scan all POST requests to my blog and screen out all of them that contain those domains? It does to me.

Thanks to a truly wonderful plugin architecture, it was a relatively painless endeavor. I have a working plugin in place now that keeps my mod_security rules in sync with my SK2 domain blacklist. It is relatively naive right now as, though he had great foresight in most of his plugin architecture, DrDave provided no hook into the blacklist insertion triggers. To his credit, I’m sure there was no evidence of need. But it would be helpful in this case.

Concerns

I do have some concerns and they’re all security-related. In order to allow the plugin to do its work the .htaccess file has to be writable by Apache. Most people do that anyway so WordPress can install permalink rewrites, but I typically don’t. I’m truly interested to hear what others think of the idea and the security implications. I don’t much care about false-positives… at all. I’m more interested in the merit of the idea and any possible downsides, before I release it for even limited release. I don’t mind being a Guinea pig on my own site, but it’s a whole separate thing when it’s in public release.

Any comments welcome.

This entry was posted 1 year, 10 months ago and is filed under Blogging, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.