It seems that many of those who run multi-user chat services have >>>>>>>> experienced chatroom flooders. What best practices do people have for >>>>>>>> fighting this? It seems the best we can do in real time is change the >>>>>>>> room to moderated so that new flooders can't send messages, but that's >>>>>>>> not a very good solution and we should be able to come up with >>>>>>>> something better. I've been thinking about ways to use entity >>>>>>>> reputation (XEP-0275), but other suggestions are welcome. :) >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>> How about tar-pitting the flooders - like OpenBSD's spamd? (and not >>>>>>> the spam filter spamd) >>>>>>> It has a good feature set. I like that it works out at the firewall. >>>>>> >>>>>> Tarpitting sounds good, the problem I can see that in heated >>>>>> discussion this could also trigger. >>>>>> >>>>>> Another Problem I see with tarpitting is when the flooder joins with >>>>>> 10 or more bots tarpitting would not be very effective. >>>>> >>>>> And that's what happens. >>>> >>>> Does spamd work by blocking IP addresses? >>>> >>>> One challenge we have is that we can't block a flooder's JID based on IP >>>> address. All we can do is report the flooder to its "home" server and >>>> ask that server to disable the account or block future registrations >>>> from that IP address. For this we need an incident handling protocol >>>> <http://xmpp.org/extensions/xep-0268.html> and we need it to be widely >>>> implemented and deployed. >>> >>> Just chipping in here, speaking from many years experience in the anti-spam >>> industry, it's perfectly acceptable to block the IP address in the even if >>> it impacts other users. The general thought process is that the domain or >>> IP range 'owner' is the responsible party because often it's not actually a >>> 'user' but a trojan or bot causing the problem so they need to clean up >>> their network. >> >> We do this all the time on the IRC servers I help run for communities. >> A flooder is taken thru 3 levels of blockage and a lot manage to get >> thru 3 levels in under 5 minutes :) >> >> 1st violation - kicked from the server with a warning message >> 2nd violation - kicked from the server and an entry is added to the >> ban list - this keeps them from reconnecting for N days/hours >> 3rd violation - all of the above and their IP address is added to the >> ban list for good. The message the get when refused connection >> includes a link on how/why >> >> requires custom changes to get the different pieces interacting but >> it's the only way to deal with it IMO > > XMPP isn't IRC. At jabber.org, we don't know the IP address of a user > from example.com and even if we did the blockage would need to happen at > example.com, not jabber.org. > > Distributed technologies are great, except when they're not. > > Peter > > -- > Peter Saint-Andre
I think the idea would be to report the flooder's JID to their home server, who could confirm & sign the IP and add it to a public IP list that are then tar-pitted from becoming clients at all XMPP servers - example.com, jabber.org etc - get that Distributed mojo workin' again :) a peer that doesn't help with your flooding, isn't all that great a peer. Still a XMPP server should be able to tar-pit a JID's messages - at least send them to the end of very long slow line. http://www.openbsd.org/spamd/ shows a couple public lists of IP addresses that can then be feed into your PF firewalls - XMPP could piggyback/mirror in the tar-pit function if it can translate a JID into a IP.
