[Operators] chatroom flooders

Ed - 0x1b, Inc. jabberd2 at 0x1b.com
Fri Jun 22 21:02:08 UTC 2012


On Fri, Jun 22, 2012 at 1:50 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 6/22/12 2:47 PM, Kevin Smith wrote:
>> On Fri, Jun 22, 2012 at 9:27 PM, Peter Saint-Andre <stpeter at stpeter.im> 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


More information about the Operators mailing list