Intoduction to ScallyWhack
The problem
Ticket comment spam has become a major pain in the ass at least for those Trac-driven websites which are listed in the major search engines. madwifi.org, for example, is hit by around 200-400 spam comments per day, with the record being 1500 spam posts in a single day.
What can be done? Well, users of Trac 0.10 and later can install the SpamFilter plugin and use that to filter out submissions by malicious users. This plugin works fine and is actively developed.
Users of older Trac versions are getting rare these days, but you still can spot them - the SpamFilter plugin is no option for them. They have to keep an close eye on user-submitted content and remove spam after it has been submitted. Depending on the frequency of spam postings this can be pretty much work, and so a common counter-measure seems to be to restrict rights of anonymous users. Those sites require users to create an account (using the AccountManagerPlugin) before they are allowed to post anything.
Personally I believe this idea is borked, for two reasons:
- This meassure not only makes it harder for spammers but also for legitimate users to contribute to the site. The more hazzle it is to contribute to a site, the less is the chance that visitors are willing to help out - which in return has a negative effect on the project, too.
- It's a well-known fact that spammers will quickly adapt their bots to work around any barriers that others set up to make their life harder. An increasing number of spam bots already is able to create an account that then is used for posting the spam.
Sooner or later either the user registration process must be made even harder (for example by requiring an administrator to review new user accounts), self-registration for users must be turned off again, or stuff like the TicketDelete plugin must be used to get rid spam that passed all the barriers. In my opinion, the "right way" to counter spam is to use a tool which blocks unwanted contributions. That's where ScallyWhack comes into play.
A possible solution: ScallyWhack
ScallyWhack is a set of rules for mod_security. mod_security is a module for the Apache webserver which allows to protect a wide range of web applications against common as well as application-specific threats and attacks.
In contrast to the SpamFilter plugin ScallyWhack does also work for older versions of Trac. In fact this is what made me start working on ScallyWhack, as back then madwifi.org was still running on Trac 0.9.x. In addition, v0.10 was not yet released and I felt uncomfortable using it for a production site.
Comparing ScallyWhack and the SpamFilter plugin
Advantages of ScallyWhack:
- based on mod_security, which is a fast and pretty flexible framework for providing additional security to all kinds of web applications
- easier to extend; you don't need to know about Python and the plugin interface of Trac
- provides protection against spamming methods that the SpamFilter plugin does not yet recognize (HTML attachments)
Disadvantages of ScallyWhack:
- requires Apache 2.x, thus does not work with tracd, LightTPD, ...
- eventually introduces new dependancies (mod_security, which in returns requires mod_unique_id)
- no WebAdmin integration for configuration and management
- no user-interaction possible; for example, it won't be possible to implement something like captchas
To say it loud and clear: ScallyWhack is not meant as replacement for the SpamFilter plugin, it's an alternative. I absolutely encourage every user to evaluate both options and then decide which of them meets his requirements the best. Last but not least nothing speaks against combining both tools in order to achieve better results compared to situations where only one of them is used.
