|
Author: A.Degives Mas (22 Mar 10 9:56pm)
Just to be sure...
There are TWO components that are relevant to web admins of sites; the same applies to WordPress installations.
1) Checking visitors against the http:BL API which can be unnerving to set it up properly, but it's something which for self-hosted WordPress sites is a cinch, thanks to the http:BL WordPress plugin, which you can find here:
http://wordpress.org/extend/plugins/httpbl/
Of course, you DO need a valid http:BL key in order to input it in the appropriate field in the plugin's settings.
As an alternative to the http:BL WordPress plugin, there's Bad Behavior, which has been named here, and does the same thing - but with a VERY important difference: it ALSO does content / behavior checks on every visitor. Bad Behavior is, in effect, a highly efficient (and powerful) first-layer defense as well as http:BL checking solution. Because Bad Behavior also looks at the visitor's "profile" (it checks to see if e.g. the visitor shows the UA of a web browser, yet attempts to send a trackback? In that case, access is denied!) it is MUCH more complete as a defense. Having said that: the author of Bad Behavior (Michael Hampton) is adamant about complementary protection measures, i.e. using Bad Behavior as well as (e.g.) Akismet is highly recommended, because in that case whatever spills through Bad Behavior (after also checking against http:BL which could happen if we're talking about a very novel and/or low-profile comment spammer) it still has a good change of being caught by Akismet, based on its inspection of the payload's CONTENT (something which is of course helped by their enormous exposure to spam on their free hosted wordpress.com blog platform) which by the way also uses its own blacklist servers.
The Bad Behavior plugin for WordPress can be found here:
http://wordpress.org/extend/plugins/bad-behavior/
Now, if you do choose to use the great and recommendable Bad Behavior plugin I STRONGLY recommend setting Bad Behavior to "strict" checking, except when you're desperate for visitors arriving via proxies, such as AOL users - every visitor will be checked against the http:BL database, assuming they are otherwise well-behaved. The "strict" setting is indeed strict, but as far as I'm concerned, security trumps exceptional conditions that cause relaxed security. It's also for the benefit of the greater internet that I refuse people with suspect BHOs installed (you know, those cute smilie laden browser bars).
Now, this first component / aspect of using http:BL also interacts with the http:BL system, but doesn't have the "honeypot" element that you need to truly "give back the love" to the community. Still, any riff-raff caught via the http:BL check method is also flagged, so it's still contributing, albeit more passively.
2) The "core" Project Honey Pot function of having "spamtrap" links is a DIFFERENT aspect, for which the self-hosted WordPress site amin has another, different plugin available, which is plainly named WP-HoneyPot and can be found here:
http://wordpress.org/extend/plugins/wp-honeypot/
That plugin does the automatic insertion of "spamtraps" for you. It does that using one of two methods, the same that are "advertised" on this site:
a) - Using a "proper" honeypot script file, which you can generate and download from this site - just drop it in the root web folder (usually named as public_http or www folder) and you're almost done - just paste the publicly visible URI to that folder - say: www.example.com/snafugalore.php if that's the name of it) into the WP-Honeypot settings and you're ready to catch the bad guys!
b) - You can also use quicklinks, that you can generate also on this site. Paste the URI of that quicklink into the WP-Honeypot settings and you're done.
Either of the two works, of course a) is preferable. Just paste in the URI to either the script or the quicklink into the WP-HoneyPot settings, and you're ready to catch more bad guys out there.
Concluding: if you run your self-hosted (to be perfectly clear: I mean an installation of a WordPress site that is NOT hosted on the www.wordpress.com servers) and want optimal protection as well as "give back to the community" use Bad Behavior (together with Akismet) and the WP-HoneyPot plugin.
If you want "simple" checks against the http:BL blacklist and still participate, use the http:BL WordPress plugin with the WP-HoneyPot plugin. Even in this configuration, also using Akismet is still highly encouraged.
I know this is a monster post, but I thought I'd better be verbose and complete rather than brief and perhaps unclear...
ADDED PS: many WordPress admins also want caching - for that, as things stand at this moment, I recommend using WP Super Cache because it plays VERY nicely with all components I've mentioned - including Bad Behavior. You can find the WP Super Cache plugin here:
http://wordpress.org/extend/plugins/wp-super-cache/
At this moment there's a new strong contender on the caching front, named W3 Total Cache, which is hosted here:
http://wordpress.org/extend/plugins/w3-total-cache/
However, as it is still very new and growing in maturity, as well as its incredible fine-tuning options, I recommend WP Super Cache for a hassle-free simple solution. Caching and compression are VERY complex things, and every server is a universe unto itself, which is why WP Super Cache is a more recommendable and above all simple to configure option for "newbies"
Also, while the original poster's question deals with comment spammers, the plugins I have mentioned above "track and flag" ANY of the categories of bad guys, be they comment spammers, rule breakers, or otherwise "bad guys" i.e. also when they attempt to engage in RFI (remote file inclusion) type attacks, as long as they visit one of the WordPress pages, they'll be monitored.
Post Edited (22 Mar 10 10:38pm)
|
