[Operators] DDoS attacks against jabber.org

Simon Tennant simon at buddycloud.com
Fri Feb 7 09:21:24 UTC 2014


If you want to go down the rate limiting route, this is very easily doable
using existing Linux tools (
https://serverfault.com/questions/384132/iptables-limit-rate-of-a-specific-incoming-ip
).

My preferred tool is:

ip route add blackhole <offending-ip>/32 (used this against a few very old
ejabberd servers that wouldn't release s2s connections resulting in 1000s
of s2s connections to the same machine (naturally after trying to contact
the admins))

S.


On 7 February 2014 09:54, Mathieu Pasquet <mathieui at mathieui.net> wrote:

> On Fri, Feb 07, 2014 at 08:05:12AM +0000, David Banes wrote:
> > On 6 Feb 2014, at 18:11, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> > > Folks,
> > >
> > > The jabber.org IM service has experienced an ongoing DDoS attack over
> the last several days. The attack occurs over XMPP (not TCP) and has
> originated from JabberIDs registered with a broad cross-section of servers
> on the public XMPP network. As far as we have been able to determine, most
> of these servers offer In-Band Registration (XEP-0077) with few if any
> restrictions (such as CAPTCHAs, although we know those are easily thwarted
> anyway).
> > >
> > > The jabber.org admins have taken a number of steps to limit the
> impact of these DDoS attacks. Unfortunately, among those steps, we have
> been forced to disable server-to-server communication from the servers that
> host the accounts that are attacking jabber.org. We really don't like it
> that legitimate users of these servers are thereby prevented from
> communicating with users at jabber.org, but at this point we have no
> choice.
> > >
> > > The list of servers we are currently blocking can be found at the end
> of this message. We will update this list as needed, because we are
> continuing to discover more servers with DDoS accounts on them.
> > >
> > > If you run one of these servers, please let us know when you've added
> > > additional protection against registration abuse, along with details
> about what you've done, so that we can re-enable federation with your
> server.
> > >
> > > Thanks!
> > >
> > > Peter (for the jabber.org admin team)
> > >
> > > ###
> > >
> > > bal-s.ru
> > > bks-tv.ru
> > > debianforum.de
> > > footter.com
> > > games.onego.ru
> > > im.apinc.org
> > > im.hadrien.eu
> > > iraqtalk.org
> > > jabber.com.ua
> > > jabber.fr
> > > jabber.mipt.ru
> > > jabber.murom.net
> > > jabber.nln.ru
> > > jabber.no
> > > jabber.snc.ru
> > > jabber.stream.uz
> > > jabber.totel.ru
> > > jabber.tsk.ru
> > > jabber.wiretrip.org
> > > jabber-br.org
> > > jabbernet.dk
> > > kofeina.net
> > > linux.pl
> > > octro.net
> > > oneteam.im
> > > talk.mipt.ru
> > > talkers.im
> > > zsh.su
> > >
> > > ###
> >
> > In my view this is the correct approach (block s2s communication) and
> mirrors the behaviour in the SMTP world. It's the way I run SMTP/XMPP
> platforms so I'd expect others to do the same.
> >
> > Quite simply if you see a badly behaving server/IP you block it until
> the owner has rectified the situation.   Yes this upsets some users on the
> server(s) that is blocked but that's fine, they can apply pressure on the
> owner to fix it or take their 'business' elsewhere.
> >
> > Doing this will weed out the problem operators and clean up our network.
> >
> > David.
> >
> >
>
> The issue here is that there is no real solution. SMTP has been coping
> with spam and bad behavior for a long time, and has tools to manage it.
> Here, there is simply no good solution for preventing abuse, at least
> with ejabberd or prosody.
>
> Captcha is no good for a public service (kills accessibility), SMS
> validation is not always easy to deploy and there is a high trust
> requirement (at least, I would not be willing to give my number to
> subscribe to an IM service), email validation is more or less the same,
> additionally with being only a quickfix before the bots are fixed to use
> it as well. Disabling IBR is the same, that will work… for the first
> days.
>
> And while I am not all for open registration services, I believe they
> are necessary if we want normal users to be able to register to a
> service without going through a lengthy registration process.
>
> Another point that I believe is not mentioned is that here, jabber.org
> is not the only victim of these attacks, and the nature of XMPP makes it
> so that the originating service gets also harmed (either in performance
> drops, or plain crashs because of too much activity). That is why I find
> it quite unfair to behave as if the server admins weren't having a
> problem with the rogue activity.
>
> Ultimately, the best thing would first be to have better rate-limiting
> tools. It is no silver bullet, but being able to rate-limit outgoing
> connections individually and globally would be a great improvement over
> what there is today (and mod_limits in prosody is a start in this
> direction).
> Next, it would be having better dedicated admin tools for XEP-0133,
> because administrating a server through ad-hoc commands is simply not
> sane. Once your server has rate-limiting techiques in place, then the
> spammer mostly becomes your problem and only yours, so you can take
> more time to fix it. I have developed a small graphical tool for showing
> online users, their resources, the country it is connecting from, with
> the possibility to delete a set of accounts in one click. However, this
> is very incomplete and right now I think a command-line tool would work
> better, especially wen managing offline users.
>
>
> mathieui
>



-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20140207/e06a21e4/attachment.html>


More information about the Operators mailing list