Re: [Operators] Reporting DDoS attack, the idiot responsible of the attack and the server range which the drones come from.

[Marco Cirillo]

Il 04/09/2012 09:40, Mathias Ertl ha scritto:

Thats a load of crap, and believe me, I wish it weren't. Most JIDs you gave
only had one JID per server. No matter how far registration is restricted,
you will always get a couple of JIDs on a server, if you want to use it.

Hardly a load of crap, when it cuts the ability to automate registrations by 85%, but still that's a fraction of the job.

Even if you have no IBR, only CAPTCHA based web-registration and email
confirmation, your server will still see registrations for botnets and/or
SPAM. You can sit there all day and watch out for registrations that you
consider "suspicious" and delete them right away, if you have no problems
with deleting accounts purely based on suspicion. If you are that bored, good
for you, but most server admins understandably won't be.

Gosh... Not all day,



Also...





Hardly "all day".

... and the statement you're not forced to "host a public service" remains Mati. It mostly requires 20-40 minutes a day but speculating a guess, I doubt most of the servers in that list are dedicated 10 minutes in a week. Time to retrieve the list of users which registered 10 seconds (even supplying a time frame), Time to retrieve, first the roster size, second the whole traffic profile of an user which meets the "suspect criterias" 10-15 seconds, the verification screening through it doesn't go beyond 2 minutes 95% of times. So, instead of using adjectives like "bored" and wordings like "deleting accounts purely based on suspicion" since somebody (not my case) may even take offense at. I'd use based on "Experience", "Good practice" and what's needed is "just the right tools".

E-Mail has the same characteristics and way less safe-guards. That doesn't
make it a good system, of course. But you won't get a free and open
IM-network with blocking every server that has a single SPAM adress.

Not really, intermediates E-Mail wise aren't a needed aspect in "both ways", that's how it was concepted and that's why it hasn't the same characteristics as XMPP. Of course if you mean the jid address format... in that case, that's undeniable.

You are partially right on this one. Everyone should care, I at least do
care. I actively fight spam registrations. If I see obviously automated
registrations, I even remove accounts. I went through my server-software's
documentation again and again to find settings that might make my server
less usable for SPAM. But I could have never guaranteed you that a JIDs from
my server wouldn't have been on that list - you can't, on any system.

When it comes to Jabber the situation is however not really glorious. I
don't know about Prosody, but Ejabberd has very few settings to actively
fight SPAM and DDOS attacks. There are still way to many ways to abuse an
Jabber server, at least if its based on Ejabberd. The XSF hasn't helped
either (as far as I can tell), since few finalized XEPs help fight spam on
the protocol level.

There are two points to this mail:
1. Blocking servers (or whole lists of servers) is wrong and not compatible
    with any open communication network.
2. Neither the XSF nor server software developers take the SPAM/DDOS
    seriously enough.

You can never give out a 100% guarantee on anything computing related, but at least you can make sure the least of it comes out of the pot. If you roll through this mailing list archives you will see the same drones (jids following the pattern) and a good chunk of the very same servers in the list have been used at least once or even twice in similar muc attacks. Meaning the said admins didn't take an appropriate action in this regard.

Marco.

The XSF, provides a protocol, mitigation/nilling of denial of servicing goes beyond its scope. Finally I disagree that << Blocking servers (or whole lists of servers) is wrong and not compatible with any open communication network. >>, for one I blocked the access to components (for now), secondly why it's wrong and incompatible? That's simply illogical, I'll make a silly example: << A class group (the server) goes to visit public museum (which could be another server), some of the kids in that group begin being asses, seeing the molest attitudes the museum rep. (which could be the 2nd server admin) comes down and reprimand primarily the teacher (1st server admin) about what's going on, the teacher can't or fails at moderating the kids, consequentially the museum rep. can't do anything but ward off the whole group. >> The semantics are the same, being "open" doesn't mean you have to be passive to what's going on. It's perfectly legit to limit or revoke the right to access a resource, it's also very effective to gain the attention of _certain server admins_.

smime.p7s
Description: Firma crittografica S/MIME