| View previous topic :: View next topic |
| Author |
Message |
mog
Voice
Joined: 17 Dec 2004
Posts: 5
|
 Posted: Fri Dec 17, 2004 12:43 pm Post subject: sentinel does not ban flooder after channel locked. |
 |
|
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. |
|
| Back to top |
|
 |
YooHoo
Owner
Joined: 13 Feb 2003
Posts: 939
Location: Redwood Coast
|
| Posted: Fri Dec 17, 2004 3:05 pm Post subject: |
|
|
| Code: | 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 
_________________
Johoho's TCL for beginners
|
|
| Back to top |
|
|
mog
Voice
Joined: 17 Dec 2004
Posts: 5
|
| Posted: Sat Dec 18, 2004 4:35 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
| Posted: Sat Dec 18, 2004 6:50 pm Post subject: |
|
|
| Quote: | 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: | | .chanset #chan -enforcebans +dynamicbans |
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
|
mog
Voice
Joined: 17 Dec 2004
Posts: 5
|
| Posted: Sat Dec 18, 2004 7:47 pm Post subject: |
|
|
| Alchera wrote: | | Quote: | 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: | | .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. |
|
| Back to top |
|
|
slennox
Owner
Joined: 22 Sep 2001
Posts: 593
|
| Posted: Tue Dec 21, 2004 10:37 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
| Posted: Tue Dec 21, 2004 6:09 pm Post subject: |
|
|
I have 29 1.6.17's running netbots (latest version) and I've not noticed any problems with sentinel to date.
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
|
dotslasher
Halfop
Joined: 10 Aug 2003
Posts: 62
|
| Posted: Mon Jan 10, 2005 5:34 am Post subject: |
|
|
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:
| Quote: | [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. |
|
| Back to top |
|
|
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
| Posted: Mon Jan 10, 2005 8:21 am Post subject: |
|
|
| Quote: | [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.
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
|
dotslasher
Halfop
Joined: 10 Aug 2003
Posts: 62
|
| Posted: Mon Jan 10, 2005 10:43 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
| Posted: Mon Jan 10, 2005 10:53 am Post subject: |
|
|
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.
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
|
dotslasher
Halfop
Joined: 10 Aug 2003
Posts: 62
|
| Posted: Mon Jan 10, 2005 11:01 am Post subject: |
|
|
well it isnt kicking :p on TEXT floods
example:
| Quote: | [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 |
|
| Back to top |
|
|
slennox
Owner
Joined: 22 Sep 2001
Posts: 593
|
| Posted: Mon Jan 10, 2005 11:30 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mog
Voice
Joined: 17 Dec 2004
Posts: 5
|
| Posted: Tue Jan 11, 2005 7:24 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
slennox
Owner
Joined: 22 Sep 2001
Posts: 593
|
| Posted: Fri Jan 14, 2005 1:32 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
