Il 28/05/2012 11:31, Mathias Ertl ha scritto:
Hi,

On 2012-05-28 00:19, Peter Viskup wrote:
we are experiencing some strange situation on MUC on our jabber server.
There were quite a lot of MUC created and most of them from Syria. These
MUCs were moved from other jabber server on which they were blocked.

Does somebody of you have experience with bots flooding MUCs and users
asking for granting them admin rights for specific MUCs? How do you
'clean' persistent MUCs not used anymore?

Main issues:
  - listing of registered conferences take some minutes
  - muc_room Mnesia table is about 58MBs large
  - ejabberdctl doesn't provide commands for administering MUCs
We (jabber.at) have the very same problem. Two things are important to note:

1. These rooms are created en masse automatically. If you destroy them
all,>100 will be created within a few seconds. (but that does not occur
until some time after that)
2. While much of it appears to come from Syria (i.e. Room names are
those of Syrian cities) no *real* chat is happening there. I have given
chatlogs to a few arab-speaking persons and the "chat" is just
gibberish. I have tried several times to chat with MUC-admins and their
intelligence has been similar to that of Eliza[1].

We have taken some steps to stop that epidemic:
(1) Only local users may create MUCs.

When MUCs are created, the creator is usually the same over all rooms.
because of (1), we know what IP registered and used that acccount.

(2) All accounts registered/used from that IP-address are deleted,
usernames blocked, IP-addresses blocked on an IP-Level.
(3) We use a munin-plugin[2] to monitor the number of MUCs. If a large
number of MUCs is created, we get a notification by Munin.

Using these measures, this now only happens rarely. If it happens, MUCs
are removed very fast by our admins.

Another thing to note: The first time I started destroying MUCs using my
regular account, I received a DOS-attack in the form of thousands of
automated private messages. I now use a dedicated account that I can
just log of from to destroy MUCs, as a precaution.

greetings, Mati
(jabber.at)

[1] http://en.wikipedia.org/wiki/ELIZA
[2] http://git.fsinf.at/fsinf/munin/blobs/master/muc_count

Or better replace IBR (since xep-158 support in clients is about unexistant) with an appropriate safe OOB method. That leaves only s2s as the possible threat source, then begin identifying remote rogue services (probably still a server with IBR enabled) and aggressively filter 'em. Problem 1000% solved, with the most ease.

Attachment: smime.p7s
Description: Firma crittografica S/MIME

Reply via email to