View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005000 | unreal | ircd | public | 2017-09-07 09:03 | 2017-11-01 10:02 |
Reporter | PeGaSuS | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | no change required | ||
Platform | Unix | OS | Ubuntu | OS Version | 16.04 LTS |
Summary | 0005000: Tweak flood protection (possible enhancement) | ||||
Description | I've been playing around with flood protection parameters on a testnet. Right now, my channel modes are the following: +f [3c#C1,5j#i1,3k#K1,10m#m1,3n#N1,3t#b]:3 The problem? Flood protection will just act if any of the [params] are hit in 3 seconds. Otherwise it won't act, wich can still lead to some users/bots being able to flood the channel. Idea? I was wondering if it woud be possible to make each parameter have his own time, so each of them will act in different time settings. How? The idea that came across my mind was: +f [3c@3#C1,5j@4#i1,3k@5#K1,10m@5#m1,3n@120#N1,3t@4#b] Explanation With my idea, this means "+f [param@time#action] and will make us able to set different times for each flood params and drop the global "hit time". Is this feasible in any way, or it's probably some kind of non-sense? Best regards. | ||||
Tags | channel, CHMODE, protect | ||||
3rd party modules | |||||
|
When I designed/invented +f it was a possibly to have per-item time. I thought about it but considered "one time" sufficient. To be honest, I still do. Your example with a time of 3 (seconds) is really short. That's not going to work. If you then set the limits low then a network or load hickup of 2 seconds and you hit many of those limits. Similarly, it can easily lead to an unfortunate situation where a few users did something (eg: type) at the same time causing a hit. That's probably why you had to set the messages so high (10 in 3 seconds). IMO the current +f is sufficient in practice. I suggest using a time of at least 10 seconds. This allows you to set reasonable limits and still allow some bursts. Actually I'm surprised it allows a :3, I should probably have made it reject <5 seconds or something. Ah well.. guess I won't touch that one :D |
|
I do understand your point of view but, still, i think having each flood parameter with its own time would be good in certain scenarios. In example, we could allow bigger message bursts but still "lock down" the channel in case of notice attack flood from some botnet spam bots. Or even almost disallow nick change flood in a specific channel instead having to set it network wide. Or even prevent users to send too many notices into the channel but allow them to type messages Those are three of the possible scenarios and, imho, i think it makes some kind of sense. Still, keep this little issue open, so you can think about it another time. ;) |
|
Edit: "Or even prevent users to send too many notices into the channel but allow them to type messages" -> Or even prevent users from joining too fast (also useful on botnet attacks |
|
You write "In example, we could allow bigger message bursts but still "lock down" the channel in case of notice attack flood from some botnet spam bots." But that's exactly what a (shared) time of 10 seconds can do as well. In those 10 seconds you could: * Allow 10-15 messages * Allow only 2 or 3 ctcps * Allow only 2 or 3 notices * And so on... It allows messages to be set to a reasonable rate while still being restrictive (more restrictive than your example) and allows the rest / uncommon events (ctcps, notices) to be more restrictive as well (3 per 10 is more restrictive than 3 per 3) Think about it, a :10 is actually much better and more restrictive than :3 :) |
|
Yes, that makes sense. Still I have an enhancement idea. Right now the flood protection bans a single user if it hits 3t in 3s. Would it be possible to add a kick option? so, that could be used as a warning. |
|
If you use 3t instead of 3t#b then it will only kick the user. |
|
having a time frame per item allows for more flexibility. You can set it up to where a user can use either or depending on what they want to do. |
|
This will not be done. The amount of compatibility problems for UnrealIRCd, mixed versions, services (!), and so on is definitely not worth it. You can have a perfectly good +f line without this feature, see previous comments. This makes it an easy decision :) |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-09-07 09:03 | PeGaSuS | New Issue | |
2017-09-07 09:03 | PeGaSuS | Tag Attached: channel | |
2017-09-07 09:03 | PeGaSuS | Tag Attached: CHMODE | |
2017-09-07 09:03 | PeGaSuS | Tag Attached: protect | |
2017-10-09 18:15 | syzop | Note Added: 0019909 | |
2017-10-09 22:36 | PeGaSuS | Note Added: 0019910 | |
2017-10-09 22:38 | PeGaSuS | Note Added: 0019911 | |
2017-10-10 07:19 | syzop | Note Added: 0019913 | |
2017-10-10 10:03 | PeGaSuS | Note Added: 0019914 | |
2017-10-11 10:19 | syzop | Note Added: 0019919 | |
2017-10-31 10:18 | marco500 | Note Added: 0019933 | |
2017-11-01 09:50 | syzop | Assigned To | => syzop |
2017-11-01 09:50 | syzop | Status | new => closed |
2017-11-01 09:50 | syzop | Resolution | open => no change required |
2017-11-01 09:50 | syzop | Note Added: 0019934 | |
2017-11-01 10:02 | syzop | Note Edited: 0019934 |