On Fri, Jun 22, 2012 at 1:50 PM, Peter Saint-Andre <[email protected]> wrote: > On 6/22/12 2:47 PM, Kevin Smith wrote: >> On Fri, Jun 22, 2012 at 9:27 PM, Peter Saint-Andre <[email protected]> >> wrote: >>> On 6/22/12 2:25 PM, Ed - 0x1b, Inc. wrote: >>>> 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. >>> >>> Yes, that can be done by the "home" server (the domain part of the >>> flooder's JID), as long as we have a reporting mechanism, which is XEP-0268. >>> >>> So at this point we just have some work to do. ;-) >> >> At which point the recipient of the complaint has his/her work cut out >> trying to validate the claims and...urgh. > > By "recipient", do you mean example.com when jabber.org reports to that > server an attack on a chatroom at conference.jabber.org? > > I sure hope we'll have fairly high levels of trust between servers. If > there are low-trust servers out there, we'll just decrement their > reputation scores. > >> Can't everyone just play >> nicely so we don't need to care about managing bad actors? :( > > Sorry, utopia is not an option. ;-) > > Peter >
An unresponsive home server is one kind of problem, but if a public list of tar-pitted IP addresses develops - you don't want malicious additions to be a problem, there should be something of an audit trail for those listed IP addresses (signed IPs?). If a servers reputation falls far enough, their tar-pitted IP addresses in the list should also be ignored. All this should be doable at the 'away' server - jabber.org
