Fighting groupchat SPAM with CAPTCHA in ejabberd

Posted by Mickaël Rémond on March 14, 2009

We have released an experimental module to protect Multi-User Chat access with character recognition challenge.

Following a recent attack on some visible public XMPP servers, we have just released a CAPTCHA support for chat rooms and documented the deployment on ProcessOne Wiki. See Fighting Multi-User Chat SPAM with CAPTCHA.

The deployment process is documented for the newly released ejabberd-2.0.4.

As usual, comments are welcome !



Categories: Jabber / XMPP  ejabberd  
Share article:   Tweet this   Make delicious   Stumble upon  

Comments

anonymous avatar

Wouldn’t it be useful to add some sort of longer lasting I’m-not-a-spammer authentication to a MUC server or room? So the room or server stores me in a “it’s cool” list, meaning the next time I log on to the server I don’t need to enter a CAPTCHA.

Posted by Jonas Ådahl on 16 Mar 2009 at 03:36



 
anonymous avatar

Jonas,

A spimmer may compromise that server list:

1. A spimmer proceeds with CAPTCHA.
2. A spimmer then starts a bot on the same JID.
3. A bot floods MUCs.

Posted by ekhramtsov on 16 Mar 2009 at 07:38



 
anonymous avatar

This is not a good solution.

A better solution would be to pressure jabber.org to not blindly allow any random user to register—something they should have done a LONG time ago.

Allowing any user to quickly and without verification create a new account is asking for trouble.

Perhaps this could be a part of the requirements to get a server certificate from xmpp.net. In order to receive a cert, you must verify your new users somehow… As well as check your client connections against a blackhole list.

We must be proactive about protecting the public federated jabber network. Implementing room captchas is not the right solution, IMHO.

My solution:

* Have some minimal requirements for your server for you to be offered a certificate from xmpp.org. Those requirements would be to not allow any random user to register without verification and to always check the IP of clients against a black hole list.
* Have servers check the IP addresses of other servers against blackhole lists.
* Have MUC rooms check the IP addresses of URLs posted in a room against blackhole lists
* Start migrating the network to require certs for S2S connections.

Posted by darco on 21 Mar 2009 at 20:17



 


Add comment

Name:

Email:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?