Using Timers to ban flood bots!

[iago]

The best way to get around floodbots is to not interact (display, ban, etc.) any user who is in the channel for less than a time limit; say, 300ms.  I find it works quite well when implemented properly.

This works beautifully in StealthBot.

What do you use as a time limit, by default? I think I used 300ms, but I have very little experience with flootbots (that, or my protection is so good I don't see them..)

[Kp]

300ms is a little low, in my experience.  I recommend at least 500ms.

[Stealth]

300ms is a little low, in my experience.  I recommend at least 500ms.

300ms is StealthBot's default, but it is customizable (or can be disabled entirely) through a config.ini hack. The only complaint that I have received about it is that it eats whispers at times because the threshold is applied to incoming whispers without taking into account the originating account name on the whisper -- two whispers from two different users within 300ms of each other will cause the second one to be dropped. This is, as Microsoft says, "by design", to prevent "whisper flooding" -- but I may change it in the near future.

[Kp]

While I can see the value of an anti-whisper-flood mechanism, it sounds like a bug that your anti-floodbot code is serving that purpose.   If you redesign it, I'd suggest separating out the logic so that users can have an anti-whisper-flood configured (or even disabled) independently of the anti-floodbot logic.

[Stealth]

While I can see the value of an anti-whisper-flood mechanism, it sounds like a bug that your anti-floodbot code is serving that purpose.   If you redesign it, I'd suggest separating out the logic so that users can have an anti-whisper-flood configured (or even disabled) independently of the anti-floodbot logic.

Not so much a bug as the wrong kind of laziness. I'll do that.

[iago]

On mine, I keep a hashtable of all the users who are on their 300ms delay.  If a user enters the channel, whispers me, and leaves, I won't see it because it queues the whisper to be seen (after the user has been in the channel past the delay).

Which brings up another question, if somebody enters the channel and says something within 300ms, then remains in the channel, do you eventually see what he says? It took me awhile to get that working right (and I don't really like the logic I used to do it).

[Kp]

I settled on letting events get slightly reordered, so my logic is that events from users who're visible to me are passed through immediately, and all events from users who aren't yet displayed (that is, have joined within the delay window), are queued.  If the user stays in channel long enough, all events for him are dequeued and I see his join + any talks he's made.  If he leaves within the window, I wipe all his events and never process them.

[MyndFyre]

If the join event contains the latency of the user, why stick with a set constant number as opposed to the latency of the user?

Also, for modular design, do you think it's better to have these users filtered through the connection mechanism or through the user interface?

[Blaze]

Which brings up another question, if somebody enters the channel and says something within 300ms, then remains in the channel, do you eventually see what he says?

Nope, not on stealthbot.

[Arta]

Also, for modular design, do you think it's better to have these users filtered through the connection mechanism or through the user interface?

Neither. I'd have something inbetween to do it. If that's not possible, then UI: the connection mechanism shouldn't hide things from your application logic, imo. I'd have something like Connection -> Processing -> UI, and do filtering in Processing.

[iago]

For plugin stuff, I have two levels for events, RawEvent which takes care of filtering and delays, and then Event, which is things like talk(), whisperFrom(), etc.  Some Raw handler has to explicitly call the Event handler.

And I do mine the same as kp -- I settle for re-ordering and broken timestamps.

[Yegg]

I'm pretty sure FaDeS is the person I'm thinking of, because that technique of banning floodbots is the exact same thing I recently told someone. Of course it still isn't going to catch anything unless the floods are lagging. I had another idea, if a user is flooding on either their own IP (I know it won't last long) or very fast proxies, then if you were to determine the interval between each flood, and send a ban message at the proper time (of course they would need to be using only one account for the flood), could you then ban them? I'm asking this because I once banned a floodbot by sending a ban message for that name right before it connected. Does anyone think this is capable of working successfully?

[Eric]

I'm pretty sure FaDeS is the person I'm thinking of, because that technique of banning floodbots is the exact same thing I recently told someone. Of course it still isn't going to catch anything unless the floods are lagging. I had another idea, if a user is flooding on either their own IP (I know it won't last long) or very fast proxies, then if you were to determine the interval between each flood, and send a ban message at the proper time (of course they would need to be using only one account for the flood), could you then ban them? I'm asking this because I once banned a floodbot by sending a ban message for that name right before it connected. Does anyone think this is capable of working successfully?

http://forum.valhallalegends.com/phpbbs/index.php?topic=3231.0