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. ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




Reply via email to