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. Can't everyone just play
nicely so we don't need to care about managing bad actors? :(

/K

Reply via email to