sentinel does not ban flooder after channel locked.

mog · Post by **mog** » Fri Dec 17, 2004 12:43 pm

Hello,

I have been experiencing problems with sentinel not baning anyone after it has detected a flood and locked the channel.

A few days ago I had a couple of users flooding a channel which triggered the channel locking mechanism of the sentinel script, thus preventing them from flooding. However, no action was taken, so the channel was unlocked again by the timers and the flooding continued.

I thought I should set up some test conditions to see if this was just a problem with my scripts; so I set up a new bot and went through the bot's eggdrop.conf and the netset.tcl configuration files setting appropriate settings. I seem to have gotten the same result though

Meaning that as it stands one or a couple of users can sit in and flood the channel, the bots then lock the channel. After which the users just wait a minute or two for the channel to be automatically unlocked and then the users continue flooding again.

Has anyone else experienced something similar to this? If anyone could shed any light on this issue, it would be very much appreciated.

With thanks,
Mog.

YooHoo · Post by **YooHoo** » Fri Dec 17, 2004 3:05 pm

Code: Select all

sl_ban  (default: 1440)
  Length of time in minutes to ban channel flooders. This makes the bot perform kicks and bans on flooders after the channel lock. For the most effective protection, you should disable this on at least one bot.
  Valid settings: 0 to disable, otherwise 1 or higher.

It would be helpful if you were to post your sentinel settings [.sentinel]. With so many different facets of floods being covered by sentinel's scripting, it is vital to carefully read components.txt from start to finish

mog · Post by **mog** » Sat Dec 18, 2004 4:35 pm

Of course... Please note that the 'text flood' setting is only set so low to make it easier to trigger the locking script when I was testing. The others are pretty much left at their defaults.

- Bot CTCP flood: 5 in 30 secs
- Bot MSG flood: 6 in 20 secs
- Channel CTCP flood: 5 in 20 secs
- Channel AVALANCHE flood: 6 in 20 secs
- Channel TSUNAMI flood: 6 in 20 secs (10 ctrl odes / line)
- Channel TEXT flood: 10 in 30 secs
- Channel BOGUS flood: 4 in 20 secs
- Channel JOIN-PART flood: 6 in 20 secs (quit detection OFF)
- Channel NICK flood: 6 in 20 secs
- Channel +i locktime: 120 secs
- Channel +m locktime: 60 secs
- Small flood short lock: Inactive
- Channel flood bans: 24 hrs
- Bogus username bans: 24 hrs
- Ban type: Channel-specific *!*nick@host.domain
- Maximum bans: 80
- Flooder ignores: 4 hrs
- Kicks per line: 1
- Maximum channel bans: 60
- Flood notification: Notifying YourNick
- Public lc/uc commands: Enabled (+o users, ops required)
- BitchX simulation: On

Alchera · Post by **Alchera** » Sat Dec 18, 2004 6:50 pm

Maximum bans: 100
Maximum channel bans: 19
Small flood short lock: Active
Flood notification: Off

Unless your network actually permits a channel ban list in excess of 19 I'd suggest setting it to just 19.

Possibly also:

Code: Select all

.chanset #chan -enforcebans +dynamicbans

mog · Post by **mog** » Sat Dec 18, 2004 7:47 pm

Alchera wrote:
Maximum bans: 100
Maximum channel bans: 19
Small flood short lock: Active
Flood notification: Off
Unless your network actually permits a channel ban list in excess of 19 I'd suggest setting it to just 19.

Possibly also:
Code: Select all
.chanset #chan -enforcebans +dynamicbans

It does permit ban lists greater than 19. Also, this configuration is just a general setup that I am using to test the problem. Thank you for your input anyway though.

Post by **slennox** » Tue Dec 21, 2004 10:37 am

A couple of people have reported a similar problem recently by e-mail; maybe one of those reports is yours. Might be coincidence or might be related to 1.6.17. Haven't had time to look into it.

Can anyone running sentinel confirm that it is setting bans with 1.6.17? I assume I'd be getting more reports if it were a general problem rather than one that appears under specific circumstances.

Alchera · Post by **Alchera** » Tue Dec 21, 2004 6:09 pm

I have 29 1.6.17's running netbots (latest version) and I've not noticed any problems with sentinel to date.

dotslasher · Post by **dotslasher** » Mon Jan 10, 2005 5:34 am

iv ran it on 2 of my 1.6.17 eggies and they dont ban.

i have also a question:

after the channel is being locked (+mi) why doesnt it kick or ban the people who TEXT-FLOODED the channel?

settings:

[10:32:09] [Beholder]: This bot is protected by sentinel.tcl by slennox
[10:32:09] [Beholder]: Current settings
[10:32:09] [Beholder]: - Bot CTCP flood: 5 in 30 secs
[10:32:09] [Beholder]: - Bot MSG flood: 6 in 20 secs
[10:32:09] [Beholder]: - Channel CTCP flood: 5 in 15 secs
[10:32:09] [Beholder]: - Channel AVALANCHE flood: 6 in 25 secs
[10:32:09] [Beholder]: - Channel TSUNAMI flood: 6 in 25 secs (10 ctrl codes / line)
[10:32:09] [Beholder]: - Channel TEXT flood: 20 in 30 secs
[10:32:09] [Beholder]: - Channel BOGUS flood: 4 in 20 secs
[10:32:09] [Beholder]: - Channel JOIN-PART flood: 6 in 20 secs (quit detection OFF)
[10:32:09] [Beholder]: - Channel NICK flood: 6 in 20 secs
[10:32:09] [Beholder]: - Channel +i locktime: 300 secs
[10:32:09] [Beholder]: - Channel +m locktime: 90 secs
[10:32:09] [Beholder]: - Small flood short lock: Active
[10:32:09] [Beholder]: - Channel flood bans: 60 mins
[10:32:09] [Beholder]: - Bogus username bans: 60 mins
[10:32:09] [Beholder]: - Ban type: Global *!*@host.domain
[10:32:09] [Beholder]: - Maximum bans: 100
[10:32:10] [Beholder]: - Flooder ignores: 4 hrs
[10:32:10] [Beholder]: - Kicks per line: 1
[10:32:10] [Beholder]: - Maximum channel bans: 19
[10:32:10] [Beholder]: - Flood notification: Notifying dotslash
[10:32:10] [Beholder]: - Public lc/uc commands: Enabled (+o users, ops required)
[10:32:10] [Beholder]: - BitchX simulation: Off

and whats the difference between avalance and tsunami flooding? they hardly ever get triggered.

Alchera · Post by **Alchera** » Mon Jan 10, 2005 8:21 am

[22:16] <Enfield> [07:16] #Alchera# sentinel
[22:16] <Enfield> This bot is protected by sentinel.tcl by slennox
[22:16] <Enfield> Current settings
[22:16] <Enfield> - Bot CTCP flood: 5 in 30 secs
[22:16] <Enfield> - Bot MSG flood: 6 in 20 secs
[22:16] <Enfield> - Channel CTCP flood: 5 in 20 secs
[22:16] <Enfield> - Channel AVALANCHE flood: 6 in 20 secs
[22:16] <Enfield> - Channel TSUNAMI flood: 6 in 20 secs (10 ctrl codes / line)
[22:16] <Enfield> - Channel TEXT flood: 80 in 30 secs
[22:16] <Enfield> - Channel BOGUS flood: 4 in 20 secs
[22:16] <Enfield> - Channel JOIN-PART flood: Off
[22:16] <Enfield> - Channel NICK flood: 6 in 20 secs
[22:16] <Enfield> - Channel +i locktime: 120 secs
[22:16] <Enfield> - Channel +m locktime: 60 secs
[22:16] <Enfield> - Small flood short lock: Active
[22:16] <Enfield> - Channel flood bans: 24 hrs
[22:16] <Enfield> - Bogus username bans: 24 hrs
[22:16] <Enfield> - Ban type: Channel-specific *!*nick@host.domain
[22:16] <Enfield> - Maximum bans: 100
[22:16] <Enfield> - Flooder ignores: 4 hrs
[22:16] <Enfield> - Kicks per line: 1
[22:16] <Enfield> - Maximum channel bans: 19
[22:16] <Enfield> - Flood notification: Off
[22:16] <Enfield> - Public lc/uc commands: Enabled (+o users, ops required)
[22:16] <Enfield> - BitchX simulation: On

The above settings work 100% on DALnet (bahamut) and under UltimateIRCd. DALnet is prone (more than most networks) to tsunami/avalanche channel floods.

dotslasher · Post by **dotslasher** » Mon Jan 10, 2005 10:43 am

well it bans on nick, ctcp and join floods, but it doesnt kick/ban on TEXT flood, it only locks the channel. Or is it designed to do that?

Alchera · Post by **Alchera** » Mon Jan 10, 2005 10:53 am

It's supposed to kick/ban them. The order (from memory) is setting +im and then setting the bans while kicking them out. I also have the repeat section of netbots enabled (which also helps). From your settings, all should be working properly.

dotslasher · Post by **dotslasher** » Mon Jan 10, 2005 11:01 am

well it isnt kicking :p on TEXT floods

example:

[15:56:25] [sdf618]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf5919]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf7056]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf6250]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf7651]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf3587]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [a7868]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:25] [sdf6636]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] [sdf3301]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] [sdf554]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] [sdf5831]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] [sdf7777]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] [sdf863]: bsdgfsdfsqsd qsd qsdqsdqdlkqskl
[15:56:26] ::: Mode: (Sarevok) sets (+mi)
[15:56:27] -Sarevok@#pfft- Channel locked temporarily due to flood, sorry for any inconvenience this may cause

and thats it

Post by **slennox** » Mon Jan 10, 2005 11:30 am

Hmm, is that what this non-banning issue is about? sentinel can get away with banning every non-op who does a CTCP, join-part, and so on during a flood because that's relatively uncommon. Non-flooders sending text during a flood happens a lot, so banning in that case would result in a lot of "collateral damage". The TEXT flood detector was only implemented to detect any type of flood sentinel.tcl wouldn't otherwise watch for by putting a cap on the total number of messages that can be sent to the channel.

mog · Post by **mog** » Tue Jan 11, 2005 7:24 pm

slennox wrote:Hmm, is that what this non-banning issue is about? sentinel can get away with banning every non-op who does a CTCP, join-part, and so on during a flood because that's relatively uncommon. Non-flooders sending text during a flood happens a lot, so banning in that case would result in a lot of "collateral damage". The TEXT flood detector was only implemented to detect any type of flood sentinel.tcl wouldn't otherwise watch for by putting a cap on the total number of messages that can be sent to the channel.

I see what you mean, and sure, I wouldn't want it to ban the people who happen to be talking while there is a flood; although in my experience, innocent chatters only usually get one or two lines of text in during a flood (I'm not sure, perhaps the script could take this into account to help distinguish between then flooders and innocent users).

However I would expect it to have some way of being able to identify who the user was that caused the flood, even if it was only ever able to detect one person that caused the flood at a time. It would at least slowly weed out the flooders that were still in the channel as the script was triggered again.

Having the script lock the channel, and then unlock the channel again without taking any action seems ineffective to me. As there will just be a vicious cycle of channel locks and floods. I have seen a number of occasions when flooders have exploited this fact in order to flood a channel. I wonder if there maybe some kind of solution to this?

With thanks,
mog

Post by **slennox** » Fri Jan 14, 2005 1:32 am

mog wrote:I wonder if there maybe some kind of solution to this?

Proper human monitoring; perhaps it's my fault for not making it clear enough that sentinel is not a panacea and doesn't replace real people keeping an eye on the channel, something I'd written a few times in drafts years ago but never added to the already long-winded documentation.

The sentinel method for tracking flooders and kicking/banning was conceived six years ago, and subsequent versions are basically refinements of it. It was never intended the script would deal with merely "annoying" floods like plain text, but respond to "dangerous" floods that previously would have caused users and bots to disappear from the channel en masse, which were often a prelude to a takeover. Having the script automatically kick and ban users wasn't originally intended either; that convenience feature was added because it could be done and would be kind of neat, in violation of my own view that reactive scripts weaken the bot's defence. Most floods, at least those of yesteryear, relied on client reactions for their effectiveness (tip: you can completely disable the kicking/banning system by setting sl_ban to 0, though most people can't resist the convenience).

Some might have expected by now that a budding scripter would have created a more advanced script, probably based on much more detailed tracking of individual users, but if such an implementation exists it hasn't been made public. My own expectation was that, by now, ircd developers would have implemented solutions on their side, making scripts like sentinel redundant. Since that doesn't appear to have happened yet, there is room for a redesigned flood protection script. But creating a good flood protection script requires everyday experience with real-world floods, something I haven't had in years, so you'll need to look to some new motivated and altruistic scripter to do it. The best I can do is tweak sentinel around the edges, when I get around to it