Flood Bot Filtering Discussion

[Dyndrilliac]

The way I have mine setup is to delay the events by about 100ms, record all the data about the flood bot the ops bot can(including interval of joins, number of rejoins, number of reconnects, and reconnect/spam/rejoin pattern), then store the information in a temporary text file, then calculate the time at which the bot will reconnect down to the millisecond, then send the ban exactly on that millisecond.

This works exceptionally well - because it not only keeps track of how many different kinds of attacks are attempted, but also responds based on the type of attack. I usually have a flood bot banned by it's 2nd or 3rd reconnect.

It's the closest thing to an AI Ops Bot i've been able to come up with.

[Eric]

The way I have mine setup is to delay the events by about 100ms, record all the data about the flood bot the ops bot can(including interval of joins, number of rejoins, number of reconnects, and reconnect/spam/rejoin pattern), then store the information in a temporary text file, then calculate the time at which the bot will reconnect down to the millisecond, then send the ban exactly on that millisecond.

This works exceptionally well - because it not only keeps track of how many different kinds of attacks are attempted, but also responds based on the type of attack. I usually have a flood bot banned by it's 2nd or 3rd reconnect.

It's the closest thing to an AI Ops Bot i've been able to come up with.

And if the floodbot had random reconnect intervals or even if the floodbot's connection lagged a little?
The millisecond difference would screw up your entire banning system, atleast on that ban attempt.

[MyndFyre]

The way I have mine setup is to delay the events by about 100ms, record all the data about the flood bot the ops bot can(including interval of joins, number of rejoins, number of reconnects, and reconnect/spam/rejoin pattern), then store the information in a temporary text file, then calculate the time at which the bot will reconnect down to the millisecond, then send the ban exactly on that millisecond.

This works exceptionally well - because it not only keeps track of how many different kinds of attacks are attempted, but also responds based on the type of attack. I usually have a flood bot banned by it's 2nd or 3rd reconnect.

It's the closest thing to an AI Ops Bot i've been able to come up with.

And if the floodbot had random reconnect intervals or even if the floodbot's connection lagged a little?
The millisecond difference would screw up your entire banning system, atleast on that ban attempt.

Although, Lord, the calculation "down to the millisecond" that Dyndrilliac discusses *should* take into account differences due to lag, since it's based on lagging in the first place.

Not only that, but since he claims it works exceptionally well, and not having seen it, you shouldn't be so quick to pass judgement.

[Eric]

Although, Lord, the calculation "down to the millisecond" that Dyndrilliac discusses *should* take into account differences due to lag, since it's based on lagging in the first place.

How would you calculate someone elses lag?

Not only that, but since he claims it works exceptionally well, and not having seen it, you shouldn't be so quick to pass judgement.

Most programmers (atleast the one's I know, myself included) use floodbot as a stepping stone to lead them in to future programming so they don't always have the best methods of getting around things such as filters and automatic bans, but if that's reversed ... it would be very simple to get past Dyndrilliac's method such as using random reconnect delays as I mentioned in my previous post or they can even make it harder for you by using random accounts along with the random delays.

[Dyndrilliac]

Considering most of the ones I see are remakes of your old Floodbot, Lord, or Turtles, and they aren't smart enough to realize it's the predictability that gets them banned, then I'd say it works very well, because those who attack, to be quite honest, aren't exactly the best and the brightest.

If some show random intervals of reconnecting and rejoining, then ill simply go back to the drawing board and cross that bridge when I get to it - but seeing as though it works, I'm not complaining...

<edit>

Also, I think to clear up one point, should the ban fail, it continues to collect data and try again on the next 2 intervals, to take into account for the natural lagging of connections. Also, because of natural network latency,  you must take into consideration my ban request will be lagged slightly being sent to the server, causing the little extra lag in the connection to be acounted for.

[MyndFyre]

Although, Lord, the calculation "down to the millisecond" that Dyndrilliac discusses *should* take into account differences due to lag, since it's based on lagging in the first place.

How would you calculate someone elses lag?

You don't calculate someone else's lag; but by using statistical regression you should be able to reliably predict, assuming they are using the same connection, when the next join will be.

Example:

MyndFyre connects at 22:30:00.100 and leaves immediately.
MyndFyre#2 connects at 22:30:00.600 and leaves immediately.

Now, the bot should predict that at 22:30:01.100, MyndFyre#3 or MyndFyre will connect and leave immediately.  Accounting for the lag seen on your own connection. the bot should be able to initiate a send from some number of milliseconds before when the join should occur.  IIRC, Battle.net recognizes you as "logged on" at 0x53 or 0x3a, so you have a little bit of time before SID_ENTERCHAT, SID_JOINCHANNEL, and SID_LEAVECHANNEL to send the ban commands.

It isn't necessary to calculate someone else's lag; their lag is factored into the average distance between join attempts.

As far as random rejoining, you're right; Dyndrillac's method would fail.  But how many people are that l33t?

[Tuberload]

I don't think assuming people are dumb, is a very effective means of protecting against flood bots. Based off of this thread, I should be able to go out and create a bot that will defeat your flood bot protection scheme.

I think there are a lot of smart, fully capable people out there that would love to create a bot to defeat this means of protection. Plus you just described how it works, identified a problem in the scheme and made it publicly available. That now drops the level of intelligence required to make a bot capable of defeating this protection scheme to that of being able to create a program that has already been designed for you. A protection scheme is only a good one if it can be made publicly available and still not be broken. Grok explain this in this post. I know that post was about encryption, but the same principles apply.

Please note that I am not shooting anyone down, because I believe this is one of the best publicly available flood bot protection schemes I have seen. I just think that making a protection scheme based on assumptions is a very bad idea. I mean how "l337" do you have to be, to create a bot that pauses a random amount of time before rejoining?

Keep this protection scheme in place because as you stated it will filter out the morons, but I think what Grok suggested in a previous post (scroll to post 26) is a far superior method of protecting against flood bots created by someone with half a brain.

[tA-Kane]

you have a little bit of time before SID_ENTERCHAT, SID_JOINCHANNEL, and SID_LEAVECHANNEL to send the ban commands.

SID_LEAVECHANNEL? You mean SID_LEAVECHAT, no?

Also, why send that packet even at all, if disconnecting will get you the same effect (leaving the channel)?

[Lenny]

IIRC, I believe all the floodbots today change their accounts upon a reconnect, which has already been a way around Dyndrilliac's flood protection........

And, there's no fullproof way of banning floodbots because they essentially have every advantage over the ops during an attack....

The best way I believe is to filter them  out, why bother spending the effort to ban it when it wont be seen at all...
But even then, one must make compromises by delaying the display of chat and events or even filtering out a few non-flood events.....

There is a simple action that Battle.net itself could take on ending floodbots, they could make a key still bannable for 1 or 2 seconds after a disconnect, giving the ops plenty of time to ban it....But I guess they decided to create Clan channels instead

[MyndFyre]

I don't think assuming people are dumb, is a very effective means of protecting against flood bots. Based off of this thread, I should be able to go out and create a bot that will defeat your flood bot protection scheme.

I think there are a lot of smart, fully capable people out there that would love to create a bot to defeat this means of protection. Plus you just described how it works, identified a problem in the scheme and made it publicly available. That now drops the level of intelligence required to make a bot capable of defeating this protection scheme to that of being able to create a program that has already been designed for you. A protection scheme is only a good one if it can be made publicly available and still not be broken. Grok explain this in this post. I know that post was about encryption, but the same principles apply.

Please note that I am not shooting anyone down, because I believe this is one of the best publicly available flood bot protection schemes I have seen. I just think that making a protection scheme based on assumptions is a very bad idea. I mean how "l337" do you have to be, to create a bot that pauses a random amount of time before rejoining?

Keep this protection scheme in place because as you stated it will filter out the morons, but I think what Grok suggested in a previous post (scroll to post 26) is a far superior method of protecting against flood bots created by someone with half a brain.

This is a well-reasoned post.  Note 1.) that it isn't my protection scheme, and 2.) I wasn't saying that the scheme was flawless (in fact I believe that I said that it would fail with random rejoins).

Yes Kane, I did mean SID_LEAVECHAT.  My mistake.

As for the lag -- a random, programmed time between the times a bot connects is not "lag", it is a programmed delay.  Random lag will typically stay within +/- 50ms, whereby statistical regression will be able to compensate.  I'm not "going off on you", Lord; I'm simply pointing out the problem isn't in the lag, it's in a programmed delay.  You don't change lag, because you can't determine the TTL between your computer and that Battle.net host; it's changed on its own, but like I said, statistical regression will correct for it over time (by finding the mean).

Ultimately, IMHO, the best protection against flooders is not pissing off other people.  In 6 years (as of this May), my clan has only ever dealt with flooders once, the Blood Angels, about 4 1/2 years ago.  It lasted for about two weeks, and then they moved on.  If you own a clan channel, and you're an operator, you can set the channel to be restricted by using Bnet's /clan private command or the like, so that it only lets your WC3 clan members in.

Don't get me wrong, Lord -- you're correct in stating that the algorithm is flawed.  My point is -- it works for him.  That's really all that matters, and for some groups, that's enough.

Anyway...

[o.OV]

Yes.. someone stated earlier that floodbots make random names.. that alone would defeat Dyndrilliac's proposed solution and many of the recent flooders do.

Plus.. many floodbots use proxies so timing it isn't as easy as one may think.
If it were that easy.. I'm sure others would have thought of it by now AND implemented it into their ops bot if it had actually yielded positive results versus any recent flooder.
I don't believe Dyndrilliac has ever tested this..
So back to the drawing board for Dyndrilliac I guess.

[FuzZ]

Well, I had remembered someone suggesting clumped packets.
So if you seperated these (if they were indeed together) in your arrival handler and checked to see if it was JOIN/TALK or JOIN/LEAVE to send a ban before you even parsed it further.

For example:

Code Select Expand


pseudo code
ArrivalHandler
 sData = DataArrived
 if length of sData is greater than length of first event
    If first event is Join and second event is Talk then
       if Join Name = Talk Name then
          Ban that whore
       /
    /
 /
end Handler

shitty example but you should get the idea.
I'll probably try to test this out myself later.

[Dyndrilliac]

IIRC, I believe all the floodbots today change their accounts upon a reconnect, which has already been a way around Dyndrilliac's flood protection........

And, there's no fullproof way of banning floodbots because they essentially have every advantage over the ops during an attack....

The best way I believe is to filter them  out, why bother spending the effort to ban it when it wont be seen at all...
But even then, one must make compromises by delaying the display of chat and events or even filtering out a few non-flood events.....

There is a simple action that Battle.net itself could take on ending floodbots, they could make a key still bannable for 1 or 2 seconds after a disconnect, giving the ops plenty of time to ban it....But I guess they decided to create Clan channels instead

Actually, if you send a squelch request upon spotting the offending flooder, you can check for users that join with the flags dictating he or she is squelched - by using this to tell the difference between users.

I don't think assuming people are dumb, is a very effective means of protecting against flood bots. Based off of this thread, I should be able to go out and create a bot that will defeat your flood bot protection scheme.

I think there are a lot of smart, fully capable people out there that would love to create a bot to defeat this means of protection. Plus you just described how it works, identified a problem in the scheme and made it publicly available. That now drops the level of intelligence required to make a bot capable of defeating this protection scheme to that of being able to create a program that has already been designed for you. A protection scheme is only a good one if it can be made publicly available and still not be broken. Grok explain this in this post. I know that post was about encryption, but the same principles apply.

Please note that I am not shooting anyone down, because I believe this is one of the best publicly available flood bot protection schemes I have seen. I just think that making a protection scheme based on assumptions is a very bad idea. I mean how "l337" do you have to be, to create a bot that pauses a random amount of time before rejoining?

Keep this protection scheme in place because as you stated it will filter out the morons, but I think what Grok suggested in a previous post (scroll to post 26) is a far superior method of protecting against flood bots created by someone with half a brain.

I am well aware that my method of banning most flood bots is far from perfect, not even close to flawless, and could be overcome by random rejoin delays and/or random reconnection delays, or even random channel join delays. However, for most bots I've seen it, DOES work very effectively, as most of the setups i've seen, the flooder in question waits several reconnects before changing delays on floodbots where random delays is a feature.

Certain people on these forums have a superiority complex. Just consider the source and move on.

I dot not have a superiority complex, or any such thing; I am simply voicing an applicable working way of filtering most common flood attacks easily that works for me, and I thought it may be worth sharing.

Yes.. someone stated earlier that floodbots make random names.. that alone would defeat Dyndrilliac's proposed solution and many of the recent flooders do.

Plus.. many floodbots use proxies so timing it isn't as easy as one may think.
If it were that easy.. I'm sure others would have thought of it by now AND implemented it into their ops bot if it had actually yielded positive results versus any recent flooder.
I don't believe Dyndrilliac has ever tested this..
So back to the drawing board for Dyndrilliac I guess.

Kind of unfair for you to assume that I have never tested this. This is like saying that because my method is unconventional and my opinion doesn't count for anything because there's no public bot I could have ripped the code from for this method that I'm instantly wrong. Have you tested it? I have achieved positive and consistent results from several floodbots, including mAdSkiLLz's WarBot(Based off Lord's earlier released floodbot source), an updated version of Lord's earlier released Floodbot, Turtlez's Open Source Floodbot, and the newest Titan I could find using both default settings and my own settings which use consistent same rejoin and reconnect delays.

I appreciate the constructive criticism(From Lord and a couple others) and thank those who made silly unneccesary comments aimed as some sort of flame *cough*o.OV*cough* ,  making themselves out as jackasses and giving me something to chuckle at.

[Soul Taker]

Is it so impossible to assume that, when a name matching common flood bot names (i.e.: something like ?#?#?#?#?#?#?#@USEast), even though it changes every time it joins, just seeing names like that in and out over a short period of time could be considered one flood bot to attempt something like this and ban it.

[o.OV]

Is it so impossible to assume that, when a name matching common flood bot names (i.e.: something like ?#?#?#?#?#?#?#@USEast), even though it changes every time it joins, just seeing names like that in and out over a short period of time could be considered one flood bot to attempt something like this and ban it.

You missed it..
His proposed solution was to have precise timing so that it bans on join.. or even before.
That isn't possible versus a random name generating bot.

Late Add-On:
Oops.
Sorry Soul Taker.
Thought you were on the topic regarding problems in Dyndrilliac's method.