Hi,
I was developping a bot but due to a bug, it has flooded in a muc room with no limit. Is there any solution to protect the room against a flood attack ?
I noticed too that after stoped the bot, I continue receiving messages… Lag ? (I’m linked with the server at 10 Mbit/s)
I’ve read something about ejabberd which can limit the flow of messages. Is there already a feature request for this ? If yes, where can I vote for it ? If not, can we add it ?
Thank you .
I’m not aware of such JIRA ticket. This is my old thread with some interesting ideas about this: http://www.igniterealtime.org/community/thread/17633?tstart=180
I think the solutions are not the best… The problem is that I can send a lot of messages and make freeze several clients. The problem is not the number of characters but the number of packets.
An option to disconnect people flooding to one jid appears to me important (for a muc). In 5mn I can write you a code which flood a room and make crash clients. For me it’s a real vulnerability which is not used just because there’s not crackers interested.
A first solution might be to watch the traffic flow of messages destinated to one jid. Then on a muc : disconnect it and for a chat : delay the message.
These were not propositions, just a few ideas of users about anti-flood protection. This was just to inform, that this problem was discussed some time ago, but no answer from developers so far.
Having flood control is still a main feature I’d like. So if we are able to get the voting going again to add this, I say yes!
The plug-in “Content Filter” with a simple line (.*) keeps the post of more than eight lines from hitting the room. Used to do a fine job many versions of Wildfire, now it bombs my Openfire so I don’t use it anymore.
ugh silly web post, how would I show syntax when it converts them, any way to have a simple text box that will not convert syntax?
remote wrote:
any way to have a simple text box that will not convert syntax?
yes, just enclose your code between two tags
without spaces
btw, i have understood your content filter’s regexp, it’s seen clearly in email notification and in plaint text message editor
Any news ?
Ok. We have to summarize what features should be in antiflood control. So then i can create feature request ticket in JIRA and you can vote for it. Though this doesnt mean this feature would be implemented very soon.
Options of antiflood control:
n messages in a row from one username is allowed. What should happen after that? Kick, Ban, unvoice for x minutes?
n messages per minute from one username is allowed. What should happen after that? Kick, Ban, unvoice for x minutes?
It’s easy to create restrictions, but this should be flexible and shouldnt disturb normal users.
P.S. just in case, i’m not a developer
To my mind, there are two antiflood system to implement :
n messages per minute
n words per minute
Because there are two way of flooding :
Sending a lot of small messages (for example 100msg/s). Or sending a very big message.
I think the best solution is to stop the message and send an error message because if you send a too big message, your client must handle it.
Maybe we should examine how the others jabber servers do. They’ve already thought about it.
Maxime81 wrote:
- n words per minute
Maybe n chars per message? because it could be disturbing for some users if they’ll spend all their words fast and will have to wait. But this will restrict all to some message length. As i said this system could bring more inconvinience than advantages
I think the best solution is to stop the message and send an error message because if you send a too big message, your client must handle it.
With error messages it depends on the client also. Like with the Packet Filter plugin, it supports packet denial message, but not every client can show this.
Maybe we should examine how the others jabber servers do. They’ve already thought about it.
Yeah. Though i havent found any documentation about this so far.
Are there any updates to this ticket? We will need something like this implemented. Basically allows a certain amount of data transferred, and if over the limit will truncate the message. I imagine the ContentFilter/ClientControl plugin could be used as a starting development plugin to work with.
I dont remember a ticket was ever filed, because the discussion stopped. I can create one, but as i said, this won’t make it happen automagivally. Someone will have to implement that.
Hmm, maybe the Raptor Plugin (http://www.igniterealtime.org/community/docs/DOC-1644) or PacketFilter Plugin (http://www.igniterealtime.org/community/docs/DOC-1370) could help to achieve flood detection.