View Issue Details

IDProjectCategoryView StatusLast Update
0005000unrealircdpublic2017-11-01 10:02
ReporterPeGaSuS Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionno change required 
PlatformUnixOSUbuntuOS Version16.04 LTS
Summary0005000: Tweak flood protection (possible enhancement)
DescriptionI'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.
Tagschannel, CHMODE, protect
3rd party modules

Activities

syzop

2017-10-09 18:15

administrator   ~0019909

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

PeGaSuS

2017-10-09 22:36

reporter   ~0019910

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

PeGaSuS

2017-10-09 22:38

reporter   ~0019911

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

syzop

2017-10-10 07:19

administrator   ~0019913

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 :)

PeGaSuS

2017-10-10 10:03

reporter   ~0019914

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.

syzop

2017-10-11 10:19

administrator   ~0019919

If you use 3t instead of 3t#b then it will only kick the user.

marco500

2017-10-31 10:18

reporter   ~0019933

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.

syzop

2017-11-01 09:50

administrator   ~0019934

Last edited: 2017-11-01 10:02

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 :)

Issue History

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