On 6/22/12 3:02 PM, Ed - 0x1b, Inc. wrote: > 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
Sure, but I assume that only server admins will be able to trigger incident reports. Peter -- Peter Saint-Andre https://stpeter.im/
