Anyone ported Bad Behavior?

[ewall]

Hey devs! I've been happily using phpBB 3.x for several years now, and am generally impressed at the strength of the design. In the past few months, however, I am getting more frustrated with spammers' registration attempts. With my board set to require administrator approval, I get dozens of emails a day... you know the drill. (And so far banning IP ranges hasn't helped much either. I must've blocked half the ISPs in Russia by now!)

Anyway, I'm wondering if anyone has tried using Bad Behavior with phpBB 3.x. Someone had done a port for phpBB v2.x but never got around to finishing a phpBB 3.x version. And it's only been mentioned a couple times in these dev boards.

I'm not very good with PHP, but I can code and it looks like Bad Behavior can be added into many PHP apps with only a little fuss... so I'm willing to give it a try. (Maybe out of laziness I might just edit it into my own installation, without taking the time to learn how to code a real mod.)

Anyone else tried this recently? Have any tips or warnings for me?

[naderman]

I don't know of anyone who's done this. But it sounds like a great idea. Let us know if we can help you somehow. I'll move this topic to 3.2 discussion because that is the next 3.x version this could go into. Would love to see some improvements in spam handling in phpBB

[Stallyon]

I see another forum software has already got it's grubby little mits on it too...

[Ger]

As I see it, it's just a matter of including a 1 PHP file from functions.php or common.php and editing that file (for contact email in case of false positive).
That's enough to make it work. The only downside is that you don't have any logs. If you do want those, than you'd have to incorporate a bit more (mostly database connections).

[AmigoJack]

A 30min view on how it works (along with orange comments by me):

• Analyzes HTTP headers:
  • Recognizing a (known) browser or crawler as user agent it then either expects other headers aswell or yields on those which the agent would never send. For crawlers also uses IP lists. Good idea; the IP lists need maintenance, not superoptimal approach.
    
  • Recognizing HTTP 1.0 or 1.1 it then yields on headers which are out of the specification. Very good
    
  • Enforcing the RFC on cookies, otherwise yields (including hack for broken Kindle implementation). Very good
    
  • Blocks when Range is discovered with the value 0 (including hack for broken Facebook and others). Good idea, but specification allows 0 nonetheless.
    
  • Blocks when Content-Range is discovered. Very good, as this doesn't exist at all.
    
  • Blocks when via is discovered (including hack for Clearswift and Coral). Seems to be a major indicator for spammers, but who knows which crawlers do also use these...
    
  • Blocks when Te is discovered. Same as above.
    
  • Blocks when both Connection and Keep-Alive are found. Very good (mutually exclusive by specification).
    
  • Blocks when Keep-Alive or close are found more than once. Very good (as multiple occasions of these make no sense although being allowed by specification).
    
  • Blocks when Proxy-Connection is discovered. Very good (doesn't exist in specification).
    
  • Blocks when Referer is discovered and its value is either empty or misses a colon. Suboptimal: desktop firewalls can modify these to increase anonymization which here can lead to false positives.
• Checks for whitelists and blacklists. Always useful, although always a performance hit.
• Skips any further analyzing if Blackhole says it's a search engine. Can't comment on how accurate Blackhole is.
• Sets cookies with JS to trace form submits. Bad idea: think of all script disablers.

All in all nice ideas, which should be really effective. The downside is the specialization: new browser or crawler generations can always have a new behaviour, not to speak of new crawler types at all. To make the clients rely on specifications is an idealistic approach - in reality almost every software violates specifications, and there aren't few who refuse to fix anything.

[michield]

Hi all,

I haven't ported Bad Behaviour, but in the last few days I've been working on using the StopForumSpam API to reduce spam in my (phpBB3) forum. It's been quite successful. I'm now blocking over 50% of posts to the forum. Yesterday there were 1400 good posts and 1800 bad ones.

I'm still keeping an eye on it, to see how many false positives there are, but the "error" I give when the spam block kicks in contains a message to contact me, in case they think they've been blocked incorrectly. So far nobody has contacted me, which seems to indicate it's working well.

Also, my moderators (who had been keeping the forums clean of all that crap for years) tell me that very few spam posts have slipped through.

I'm wrapping it up in a PHP class. Once it's ready, I'll publish it. I'm trying to make it fairly generic, because I want to use it in other places as well, not just phpBB.

[michield]

Actually, my numbers in the previous post are not entirely correct. I'm basing them on the logfile I keep of activity, and I found I was graphing spam as ham, which means the 50% will be even more. I've corrected it, and I'll leave it for a little while, and then I'll report on the results (if anyone is interested of course), but basically in the beginning I was blocking 90% of POST requests to my forums due to the API calls to stopforumspam. And that all without any false positives. I think it's quite promising, but it needs a bit of tweaking to finish it off. Just in case you're interested, the forum is at age-tea-tea-pea forums.phplist.com.

Yesterday the SFS calls blocked 1400 posts to my forums. I'm only doing an SFS check on POST requests (as those are the only ones that need blocking). In the very early stages I accidentally did an API call on every single request, and ended up going over the 20.000/day limit that SFS have put in their API (somewhere around noon).

The class I'm writing is using three sources for anti-forums spam: stopforumspam.com, projecthoneypot.org and akismet.com. At the moment, I only use SFS as the active component, but I'm also checking honeypot and found that it adds a few entries that SFS misses, but not many. I haven't finished with akismet yet, but my impression is that it's not going to contribute very much. Akismet is probably too focused on Wordpress type comment-spam, as opposed to forum spam.

If anyone knows of any other creative commons sources of anti-spam data, please let me know and I'll add support for the service in the class. I guess I should also look into Bad Behaviour, the original subject of this thread.

[bonelifer]

Have you checked with the people running SFS? My understanding is that they don't won't people using it for anything other than checking registration. Right now it sounds like you are using it like a firewall for posts/topics(not allowed by SFS's Terms of use), there was a word press author who's plugin got blocked because of this type of usage.

[AmigoJack]

a message to contact me, in case they think they've been blocked incorrectly. So far nobody has contacted me

Never ever take that as an indicator. People are either too lazy to go on or they're fed up with it already or they just don't know computers that well to understand it or they're not understanding it by the language at all. Error/performance checks based on user feedback will never work - I suspect 1 out of 100 people getting any error message would really send you an e-mail.

[bonelifer]

I've found this: https://github.com/philnate/phBadBehave3 Not sure how good it is, but it is being actively developed, as of typing this they'd done a commit about an hour before.