Well before starting doing this i want to c whats the best way for doing this, well any suggestion?

Or just don't connect to battle.net at all.

Seriously though, you could try keeping a count of the number of users that join your channel(or the number of messages that are said). Decrease the number over time. If the number goes to high, temporarily ignore all joins or talks.

[quote author=The-FooL link=board=17;threadid=6211;start=0#msg55023 date=1081904866]Seriously though, you could try keeping a count of the number of users that join your channel(or the number of messages that are said). Decrease the number over time. If the number goes to high, temporarily ignore all joins or talks.[/quote]That might work for inactive channels, but for channels that get a lot of activity, that could easily get whacko.

Instead, a better way would be to delay the parsing of the join event for half of a second (or even a quarter of a second if you wish... but most users who "channel surf" on Battle.net are in a channel for around a second before moving on). If the user leaves before that time is up, then they're considered flooding.

This is quite useful because in that short amount of time, it's (or should be) VERY easy for the bot with ops to ban them. So it would be hard to get around the flood protection and still not get banned.

Another thought: wait for your own ping time to pass and then process. That way, you know there's time to send a ban.

Shouldn't you wait for the op bot's ping time?

I assumed we were talking about an op-bot

Couldn't an op bot just not display the data of any user it was going to ban? :)

I didn't say displaying data, I said sending a ban. I'm talking about not letting modbots get bogged down by bans. I don't care whether or not it's displayed.

hmm, perhaps the person who started this thread could clarify if we're talking about mod-bots or chat-bots, but in any case, you would wait till your own ping time before taking any actions

Wouldnt you also have to account for the server's own ping to relay the ban command to the other server, unless you're connected to the same server that the floodbot connected to...

Enqueue all inbound events -- then you have control over which ones are displayed. Duplicate or similar events, as well as messages sent too close to each other, can be dropped.

[quote author=Lenny link=board=17;threadid=6211;start=0#msg55109 date=1081969751]
Wouldnt you also have to account for the server's own ping to relay the ban command to the other server, unless you're connected to the same server that the floodbot connected to...
[/quote]

Not if you ARE the ops server. I don't care about chat clients, the people using them can suffer, I'm talking about the actual bot looking after the channel.

But if you always delay the ban by that amount, they can redesign their bots to account for that and spam a bit more...

[quote author=Adron link=board=17;threadid=6211;start=0#msg55121 date=1081971885]
But if you always delay the ban by that amount, they can redesign their bots to account for that and spam a bit more...
[/quote]

I was thinking that, actually. Perhaps you can send the ban, but check back in [ping] to see if it's still there; if not, it doesn't bother with it anymore. As long as you have apt flood protection, that wouldn't hurt.

When I say not bother with it anymore, I mean displaying the event/updating log/etc.

What I meant was, doesnt the server the floodbot is connected to perform the ban?

If the ops weren't on the same server, the ban would be relayed to the server which the floodbot connected to in order to ban.

[quote author=Lenny link=board=17;threadid=6211;start=0#msg55126 date=1081975867]
What I meant was, doesnt the server the floodbot is connected to perform the ban?

If the ops weren't on the same server, the ban would be relayed to the server which the floodbot connected to in order to ban.
[/quote]
Bans are by CD-Key though, so the damage would be done, I think.

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.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=15#msg55132 date=1081980883]
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.
[/quote]

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.

[quote author=LoRd[nK] link=board=17;threadid=6211;start=15#msg55133 date=1081982988]
[quote author=Dyndrilliac link=board=17;threadid=6211;start=15#msg55132 date=1081980883]
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.
[/quote]

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.
[/quote]

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.

[quote author=Myndfyre link=board=17;threadid=6211;start=15#msg55134 date=1081983141]
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.
[/quote]

How would you calculate someone elses lag?

[quote author=Myndfyre link=board=17;threadid=6211;start=15#msg55134 date=1081983141]
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.
[/quote]

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.

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... :P

<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.

[quote author=LoRd[nK] link=board=17;threadid=6211;start=15#msg55138 date=1081984130]
[quote author=Myndfyre link=board=17;threadid=6211;start=15#msg55134 date=1081983141]
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.
[/quote]
How would you calculate someone elses lag?
[/quote]

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?

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.

[quote author=Myndfyre link=board=17;threadid=6211;start=15#msg55175 date=1081992973]you have a little bit of time before SID_ENTERCHAT, SID_JOINCHANNEL, and SID_LEAVECHANNEL to send the ban commands.[/quote]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)?

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

[quote author=Tuberload link=board=17;threadid=6211;start=15#msg55182 date=1081995493]
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.
[/quote]

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...

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.

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]
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
[/code]
shitty example but you should get the idea.
I'll probably try to test this out myself later.

[quote author=Lenny link=board=17;threadid=6211;start=15#msg55196 date=1081999315]
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
[/quote]

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.

[quote author=Tuberload link=board=17;threadid=6211;start=15#msg55182 date=1081995493]
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.[/quote]

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.

[quote author=Tuberload link=board=17;threadid=6211;start=15#msg55188 date=1081997788]
Certain people on these forums have a superiority complex. Just consider the source and move on. ;)[/quote]

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.

[quote author=o.OV link=board=17;threadid=6211;start=15#msg55227 date=1082020155]
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.
[/quote]

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.

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.

[quote author=Soul Taker link=board=17;threadid=6211;start=30#msg55390 date=1082108393]
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.
[/quote]

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.

[quote author=o.OV link=board=17;threadid=6211;start=30#msg55392 date=1082111900]
[quote author=Soul Taker link=board=17;threadid=6211;start=30#msg55390 date=1082108393]
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.
[/quote]

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.
[/quote]

I think you missed it... He was asking a separate question altogether.

Soul Taker: Yes that could be a good means of protection. I believe you could just have the bot recognize when it is under attack, and then have it just automatically start banning non-members that match certain profiles.

I have not tested this method, but it is one that I planned on working on as soon as I get my bot to that point. Maybe someone with a little more knowledge on the situation can give some better details.

[quote author=o.OV link=board=17;threadid=6211;start=30#msg55392 date=1082111900]
[quote author=Soul Taker link=board=17;threadid=6211;start=30#msg55390 date=1082108393]
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.
[/quote]

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.
[/quote]

You should obviously reread my post, or get hooked on phonics ;).

I responded to this. Using wildcards, assumptions, and squelch flags, you can EASILY differintiate between randomly named flood bots. Also, using commonly used public floodbot algorithms as references to situations the bot can make a default decision on would easily fix this. For example, say you set the bot to ban any account in the method I described that is made up of nothing but integers and is the same length everytime.

There are several ways of defeating this one feature, as random names can only be so random; Those random name flooders that use the random number names or random letter names can be defeated using the methods I just described rather effectively.

The key is to make the bot learn more about the flooder in question each time it rejoins. Think of this as searching and sieving(researching) in memory locating applications for cheating games - they search for a value, then search for a new value only out of the pool of values found by the previous search. It's quite simple really.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=30#msg55436 date=1082143249]
There are several ways of defeating this one feature, as random names can only be so random; Those random name flooders that use the random number names or random letter names can be defeated using the methods I just described rather effectively.
[/quote]

I don't see how this could possibly work out. How could you ever predict a random name at a random time and ban that?

[quote author=Adron link=board=17;threadid=6211;start=45#msg55440 date=1082146274]
[quote author=Dyndrilliac link=board=17;threadid=6211;start=30#msg55436 date=1082143249]
There are several ways of defeating this one feature, as random names can only be so random; Those random name flooders that use the random number names or random letter names can be defeated using the methods I just described rather effectively.
[/quote]

I don't see how this could possibly work out. How could you ever predict a random name at a random time and ban that?
[/quote]

It works on assumptions Adron. Basically, if my bot sees rapid reconnects and rejoins, it squelches that IP, and if the offending flooder is squelched on all cases, or comes back several times, the bot then logs what characters make up the name and how many characters long it is, and if it is the same length and same type of charactrs each time, etc, etc, etc. - it uses these qualifiers to assume whther it is a flood or not, and then issues the appropriate action.

Basically is a certain number of certain attirbutes are true or untrue about a user then it decides to ban or not ban depending on the situation.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=45#msg55446 date=1082148212]
Basically is a certain number of certain attirbutes are true or untrue about a user then it decides to ban or not ban depending on the situation.
[/quote]

I can agree with that: OK, you know whether you want to ban or not. But now how will you succeed in banning the bot if it's on a new random name each time and disconnecting before you can ban it? I thought your algorithm was about predicting on what name and at what time the bot would appear the next time to time the ban right?

Battle.net should let ops ban people even after they've signed off. Also, being able to have server-side banlists (perhaps using a usermask instead of a specific user) would also be very helpful.

To Adron:

No, I do not predict the name that the flooder will appear on next; Instead, I set it up to fill in a sort of Police Sketch Artist type system. Every time the bot notices a flood type activity, it gathers as much information it can on a user, and once it has decided an apporpriate action to take it bans all users entering the channel fitting that description. However, that is only for flooders it has detected are not on the same name - for those who use repeated accounts, it predicts the exact instant as clsoe as it can approximate and sends 3 rapid ban requests for that user as soon as it thinks the user is reconnecting. It depends on what method it believes the flooder is using before deciding what criteria to look for.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=45#msg55457 date=1082154559]
No, I do not predict the name that the flooder will appear on next; Instead, I set it up to fill in a sort of Police Sketch Artist type system. Every time the bot notices a flood type activity, it gathers as much information it can on a user, and once it has decided an apporpriate action to take it bans all users entering the channel fitting that description. However, that is only for flooders it has detected are not on the same name - for those who use repeated accounts, it predicts the exact instant as clsoe as it can approximate and sends 3 rapid ban requests for that user as soon as it thinks the user is reconnecting. It depends on what method it believes the flooder is using before deciding what criteria to look for.
[/quote]

Ah. So there are two parts to your algorithm. One is defeated by using random names and the other is defeated by disconnecting quickly.

Wouldn't it be possible to fool your bot into banning legitimate users by using similar names?

Ok, I'll throw in my two cents here. How about just using a database to store the data?

CurrentStat -Table
Username -Field
TimeJoined -Field
LastChatMsgTime -Field


BanList -Table
Username -Field

Since user names are unique, then you can check the system time when a player joins. And for each chat, store the system time in the database. Then if CurChatMsgTime - LastChatMsgTime >= TimeLimit, ban them, other wise store LastChatMsgTime. Then after the user leaves, just delete them from the database.

[Edit] To clarify to everyone - this is exactly what it does [/Edit]

Many floodbots I have seen use set lengths of names for random name creation, even though this could be very easily set to be random as well, the ones that I have seen attacking me most often(FloodBots called "WarBot") use the set name length and it is configurable. So, yes, name length can easily be used.

Also note, that never once did I mention using the users profile or ping to calculate which user to ban. That would be silly considering lots of people use the 0/-1 ping spoof nowadays, that would end up in many misplaced bans.

I never contradicted myself, and in this thread, I was never wrong. I can say that without ego. however, I admitted before your first post here there was a flaw in my method, making your entire argument on reconnects invalidated. The random name thing I have answered, but apparently you did not understand. Allow me to clarify.

I don't calculate the name of a flooder, on flooders the bot has detected to change its name when reconnecting/rejoining. It tells the difference or similarities using squelch flags, and a profile type system. If the user is still squelched but the user name is different, it knows not to waste time recording the name, and move on to more useful criteria. If it is the same name, it records it and begins recording other criteria. Criteria the bot uses to decide a ban includes but is not limited to:

Reconnection Delays/Times
Rejoin Delays/Times
Names(On some cases only, remember)
Name Length
Squelch flags(for telling if a user has random names enabled)
Other Flags(I.E., whether it has the plug icon everytime it rejoins, etc)
Number of rejoins before reconnecting

Now, using that system, there are only 2 cases which I would not be able to stop: Random Names /w Random Proxies on Reconnect, or, Random Reconnect Delays. However, I do not use this system alone. I use this in conjunction with other methods as a back up.

In the end there is no real way to ban every floodbot, it's not possible, I know that; But my "SmartBan", does a damn good job, considering it has stopped every flood attack on my channel within the past 5 months. Maybe I was just lucky, maybe the idiots flooding me weren't smart enough to use their bots properly, I don't know, nor do I care - it works for me. Nuff Said.

To Adron:

I dont know if it would be possible to trick the bot into banning people that are supposed to be there, because more than just name information must be correct before it bans.

Note that I do not use this system alone, this is just the default method; If it fails several times(which has only occurred in testing, also this is configurable) then it defaults to a Stealthbot Style EFP type action. However, this only if the bot after several attmpts cannot get enough information to ban effectively.

Can you squelch a user after it's disconnected? Otherwise, why would you squelch flooding users instead of just banning them?

[quote author=Adron link=board=17;threadid=6211;start=45#msg55553 date=1082227084]
Can you squelch a user after it's disconnected? Otherwise, why would you squelch flooding users instead of just banning them?
[/quote]

I'm assuming by squelching the user and having an autoban for squelched users it's an effective ipban for the proxy or user flooding.

Edit> Added quote.

[quote author=Adron link=board=17;threadid=6211;start=45#msg55553 date=1082227084]
Can you squelch a user after it's disconnected? Otherwise, why would you squelch flooding users instead of just banning them?
[/quote]

No, you cannot - however, the squelch has many purposes. As FuzZ mentioned, it can be used for IP Ban. Also, it works into my SmartBan system to differentiate between flooders and recognize if a flooder is randomly changing names and such. It also is used to protect legitimate channel users from being caught up in the bans by helping the bot sort through flooders and non flooders.

Are the criteria for who a squelch applies to different from the criteria for who a ban applies to? Did it always use to be that way? I had a feeling they used to work the same..

If squelch and ban have different criteria, I suppose I understand the idea of squelching to trace spammers.

I still don't understand the name pattern matching. If a spammer was picking names like Dyndrilliaa, Dyndrilliab, ..., would the bot ban Dyndrilliac? :)

[quote author=Dyndrilliac link=board=17;threadid=6211;start=45#msg55514 date=1082210072]
Maybe if you believe me to be so wrong, you could contribute a system that you approve?
[/quote]
[quote author=o.OV link=board=17;threadid=6211;start=45#msg55469 date=1082160140]
In my opinion your best bet is speed efficient coding.
That is why I didn't really approve of the name evaluation idea.
[/quote]

I don't believe there is any client side system anyone can design to defeat a floodbot so what is the point of asking me to come up with one?

How do you analyse the attacker if you have more then one IP that is squelched?

[quote author=Adron link=board=17;threadid=6211;start=60#msg55577 date=1082231968]
Are the criteria for who a squelch applies to different from the criteria for who a ban applies to? Did it always use to be that way? I had a feeling they used to work the same..

If squelch and ban have different criteria, I suppose I understand the idea of squelching to trace spammers.

I still don't understand the name pattern matching. If a spammer was picking names like Dyndrilliaa, Dyndrilliab, ..., would the bot ban Dyndrilliac? :)[/quote]

No, because I would not be rapidly rejoining and sending several messages, therefore it would automatically do a temporary safelist type measure.

Analyzing is done one attacker at a time. All the criteria is logged in a text file, and all my bots use the same log file, so in this way I prevent doubling up and keep a speedy ban system going using several ops bots, for a cooperative banning system.

Note: The same person is not squelched on all ops bots. So in my clan channel, if I have 4 ops bots running, I can use this system on 4 attackers at once.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=60#msg55591 date=1082238190]
[quote author=Adron link=board=17;threadid=6211;start=60#msg55577 date=1082231968]
Are the criteria for who a squelch applies to different from the criteria for who a ban applies to? Did it always use to be that way? I had a feeling they used to work the same..

If squelch and ban have different criteria, I suppose I understand the idea of squelching to trace spammers.

I still don't understand the name pattern matching. If a spammer was picking names like Dyndrilliaa, Dyndrilliab, ..., would the bot ban Dyndrilliac? :)[/quote]

No, because I would not be rapidly rejoining and sending several messages, therefore it would automatically do a temporary safelist type measure.

Analyzing is done one attacker at a time. All the criteria is logged in a text file, and all my bots use the same log file, so in this way I prevent doubling up and keep a speedy ban system going using several ops bots, for a cooperative banning system.
[/quote]

Could reading/writing to the same file cause i/o errors, like if somebody was flooding with iagokasfdlasfdkj and it read the file while it only said "iago"? Or do you have a check against that?

I've never experienced that, but, I don't have a check for it either; The way I did it is, all the bots information is outputted to a text file, then all the bots input the other bots' text files and compare data, double information is removed and appended to the single log file, the other files are wiped clean and the bots reset their information and progress normally.

It seems like it might have a problem with partially written data/io getting in the way of itself, but if it works it works :)

[quote author=Dyndrilliac link=board=17;threadid=6211;start=45#msg55514 date=1082210072]
If the user is still squelched but the user name is different, it knows not to waste time recording the name, and move on to more useful criteria. If it is the same name, it records it and begins recording other criteria. Criteria the bot uses to decide a ban ..
[/quote]

What if the username was the same but the ip was different?
[quote author=Dyndrilliac link=board=17;threadid=6211;start=60#msg55591 date=1082238190]
Analyzing is done one attacker at a time. All the criteria is logged in a text file, and all my bots use the same log file, so in this way I prevent doubling up and keep a speedy ban system going using several ops bots, for a cooperative banning system.

Note: The same person is not squelched on all ops bots. So in my clan channel, if I have 4 ops bots running, I can use this system on 4 attackers at once.
[/quote]
So one of your bot manages to squelch one somehow..
what if the squelched flooder fails to show up?

[quote author=o.OV link=board=17;threadid=6211;start=60#msg55601 date=1082246040]
[quote author=Dyndrilliac link=board=17;threadid=6211;start=45#msg55514 date=1082210072]
If the user is still squelched but the user name is different, it knows not to waste time recording the name, and move on to more useful criteria. If it is the same name, it records it and begins recording other criteria. Criteria the bot uses to decide a ban ..
[/quote]

What if the username was the same but the ip was different?
[quote author=Dyndrilliac link=board=17;threadid=6211;start=60#msg55591 date=1082238190]
Analyzing is done one attacker at a time. All the criteria is logged in a text file, and all my bots use the same log file, so in this way I prevent doubling up and keep a speedy ban system going using several ops bots, for a cooperative banning system.

Note: The same person is not squelched on all ops bots. So in my clan channel, if I have 4 ops bots running, I can use this system on 4 attackers at once.
[/quote]
So one of your bot manages to squelch one somehow..
what if the squelched flooder fails to show up?
[/quote]

1) The bot will squelch the new IP, record the name, and proceed normally.

2) If the flooder does not return within the next 90 seconds the ban attempt is aborted, and it begins searching for other attackers.

[quote author=Dyndrilliac link=board=17;threadid=6211;start=60#msg55607 date=1082250331]
1) The bot will squelch the new IP, record the name, and proceed normally.
[/quote]

So if the attacker were to use the same name
but different ip EVERY reconnect..
your bot would continue to squelch them?

[quote]
2) If the flooder does not return within the next 90 seconds the ban attempt is aborted, and it begins searching for other attackers.
[/quote]

So 135 seconds later you found yourself a new target..
What if the flooder that failed to return fast enough..
returns after you found that new target?

In both cases you could have more then one squelched IP assuming that you were able to catch them.
Is the analysis still useable?

[quote author=o.OV link=board=17;threadid=6211;start=60#msg55615 date=1082257858]
[quote author=Dyndrilliac link=board=17;threadid=6211;start=60#msg55607 date=1082250331]
1) The bot will squelch the new IP, record the name, and proceed normally.
[/quote]

So if the attacker were to use the same name
but different ip EVERY reconnect..
your bot would continue to squelch them?

[quote]
2) If the flooder does not return within the next 90 seconds the ban attempt is aborted, and it begins searching for other attackers.
[/quote]

So 135 seconds later you found yourself a new target..
What if the flooder that failed to return fast enough..
returns after you found that new target?

In both cases you could have more then one squelched IP assuming that you were able to catch them.
Is the analysis still useable?
[/quote]

The bot would continue to squelch them yes. I don't think I ever gave it an action for that scenario.

Upon banning of the new target, if the previous target returns to the channel before another new target is found, it will resume it's analysis of the previous one. Once the 90 seconds is up the bot does an auto reconnect to reset squelches, meaning that in this case, there wouldn't be a second IP squelched.

You would also reset all the bans (if any) that were successful.