Another Flood Bot Prevention Discussion

Tuberload · February 14, 2004, 01:32 AM

You wouldn't have to delay the chat input that much... I think most programming languages out their could execute a simple filter relatively fast.

Lenny · February 14, 2004, 01:39 AM

Wouldn't the speed depend on how fast the floodbot actually is?

Would you want to only filter fast floods or both slow and fast?

o.OV · February 14, 2004, 05:29 AM

A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packets/name (or remove the packets from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.

And..

To help reduce Error in channel listing.. you shoud setup the bot to refresh the channel list by idling "/unignore (theNameYouAreUsing)" .. that should give you a list of inchannel users to compare it against the current list..

Soul Taker · February 14, 2004, 05:33 AM

Quote from: o.OV on February 14, 2004, 05:29 AM
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packet/name (or remove the packet from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.

I'd make it depend on the event, since I'd think in certain situations people could certainly send multiple events in one packet, such as someone joining a channel and having their flags changed, and a statstring update perhaps if it's laggy.

o.OV · February 14, 2004, 06:58 AM

Quote from: Soul Taker on February 14, 2004, 05:33 AM
Quote from: o.OV on February 14, 2004, 05:29 AM
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes. My thought on this is.. Extract the username from each packet (do not process packet yet) and store it temporarily in a variable somewhere .. as you extract a username from each packet from the clump you check against the list of already present usernames in the list. If any matches are found. Flag the packet/name (or remove the packet from buffer) .. So when you actually do process the packets it won't process any packets that has a username that is flagged as showing up more then once in the clump. It takes more work and processing but if this is for a chat bot.. it doubt it would matter.
I'd make it depend on the event, since I'd think in certain situations people could certainly send multiple events in one packet, such as someone joining a channel and having their flags changed, and a statstring update perhaps if it's laggy.

You are right. It should only check Join Leave Talk and Emote.
Grabbing the channel event is certainly not hard. its just a checking a single byte.
Of course.. People can be laggy and it would filter them out if they sent messages too fast.. but.. sacrifices have to be made.
But then again, they might be a bot sitting in channel spamming or something.. So it could be a good thing.
Slap this idea together with the one I provided above and you have got yourself a so called filter.

Spht · February 14, 2004, 09:02 AM

You could just support the SVP (short visit protect) method which Skywing's BinaryChat and some other clients use.

The logic behind this is for join/leave/talk/flagschange/emote, check if the user is in channel, if so then process event normally. If they're not in channel and it's a leave event, delete the user's chat event queue. If it's not a leave event, push the chat event into the user's chat event queue. If the user's queue is "old enough," (we use a little over 1 second) then process all events in the queue and delete the queue.

This method has proved to work very well.

Kp · February 14, 2004, 10:38 AM

Quote from: o.OV on February 14, 2004, 05:29 AM
A packet clump from a flood consists of about um. about 9 packets. or so and the amount of buffer that comes in is always limited to about 1024 bytes.

Without regard to the other problems in your idea, this sounds much more like a client limitation than something inherent in the server. The server can potentially send you far more data very rapidly. It's your TCP receipt implementation that's capping it at one kilobyte.

Quote from: o.OV on February 14, 2004, 05:29 AMTo help reduce Error in channel listing.. you shoud setup the bot to refresh the channel list by idling "/unignore (theNameYouAreUsing)" .. that should give you a list of inchannel users to compare it against the current list..

Unless the filter is extremely braindamaged and inconsistent about when and how it filters, there will be no desynchonization of the channel list.

Skywing · February 14, 2004, 11:27 AM

I would use the in-same-message idea to filter out users that could not possibly be banned from an operator bot, and the delay-events idea for a chat bot to block out as much spam as possible, even if users may be banned as a result.

iago · February 14, 2004, 11:43 AM

Something Grok said made me think: ANYBODY who joins the channel, talks, and leaves within about 10 seconds isn't worth my time, regardless if he's a floodbot or legit

o.OV · February 14, 2004, 01:27 PM

Sorry Kp it was an assumption.
When I use to packet log data coming from winsock controls
during a flood.
It was always seperated into limited chunks
of data consisted of a number of packets.
And that was the first time I have encountered Packets
coming in incomplete pieces.

Quote
Without regard to the other problems in your idea, this sounds much more like a client limitation than something inherent in the server. The server can potentially send you far more data very rapidly. It's your TCP receipt implementation that's capping it at one kilobyte.

A single flood is about 500 to 600 in length.
A person who is flooding usually isn't running that many floodbots
and I say again its about 1024 because I never noticed
any particularly large chunks of data that might be over 1024 bytes.
That is why I made this assumption for winsock controls.

This deduction was made back when floodbots were still
able to pull off over 50 rejoins before getting ipbanned.

Quote
Unless the filter is extremely braindamaged and inconsistent about when and how it filters, there will be no desynchonization of the channel list.

The idea was to begin evaluation of the packets as soon as the clump arrives.
So that you wouldn't have any noticeable delay of incoming data
when waiting it out even if for just 500 milliseconds.
What I was worried about is a bot that joins channel and idles for a while
and decides to flood off or a bot that comes in flooding but sits.
It would drop the packet that says user has left/joined the channel.
But ok.. Fine.
It should drop all BUT the last (join/leave) packet of the flagged username.