On 22/06/2012, at 4:48 PM, Peter Saint-Andre wrote: > On 6/22/12 9:46 AM, bear wrote: >> On Fri, Jun 22, 2012 at 11:38 AM, Peter Saint-Andre <[email protected]> >> wrote: >>> On 6/22/12 9:37 AM, David Banes wrote: >>>> On 22/06/2012, at 4:32 PM, Peter Saint-Andre wrote: >>>> >>>>> On 6/22/12 9:30 AM, bear wrote: >>>>>> On Fri, Jun 22, 2012 at 11:24 AM, David Banes <[email protected]> wrote: >>>>>>> On 22/06/2012, at 4:20 PM, Peter Saint-Andre wrote: >>>>>>> >>>>>>>> On 6/22/12 6:16 AM, Peter Saint-Andre wrote: >>>>>>>>> On 6/22/12 4:01 AM, Tim Schumacher wrote: >>>>>>>>>> At Thu, 21 Jun 2012 21:00:45 -0700, >>>>>>>>>> Ed - 0x1b, Inc. wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 21, 2012 at 9:50 AM, Peter Saint-Andre >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>>>>>> Hash: SHA1 >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>>> >>>> >>>> I don't understand the problem here, email is a distributed technology as >>>> well. Just use the JID's domain part. Look up example.com's SRV records in >>>> DNS, or from the S2S connection and block it at jabber.org. Same as email. >>>> >>>> Or am I having a Friday afternoon brain fade here, I must admit I haven't >>>> hit the beer yet so it's possible :) >>> >>> So we're going to block all 50,000 users at example.com because they >>> have one bad user? I'd really really like to avoid that. >>> >> >> To avoid this operators of servers may have to agree to share >> information about JIDs then: is it a new JID, has it been email >> confirmed, how many channels has the JID joined (per hour/day), etc. >> This would allow tarpits to be very selective without having to resort >> to the "ban hammer" of IP blocking. > > Right. JID reputation: http://xmpp.org/extensions/xep-0275.html > > So if a low-reputation JID appears in a room that's under attack, we > don't give it voice. Easy enough. We just need widespread deployment of > JID reputation. :) >
That's a good idea, I wish we had email address reputation in the SMTP world. One thing we do in email is IP reputation, companies like CommTouch are very good at ramping reputation up and down quickly and domain admins soon learn to sort out 'issues' quickly to get themselves off block lists. Especially if they have 50,000 users on the domain :) David. -------------------------------------------------------------------------------------------------------- Email Filtering by Cleartext a Carbon Minimised company - www.cleartext.com --------------------------------------------------------------------------------------------------------
