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 <[email protected]> wrote: > On Fri, Feb 07, 2014 at 08:05:12AM +0000, David Banes wrote: > > On 6 Feb 2014, at 18:11, Peter Saint-Andre <[email protected]> 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
