View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005794unrealircdpublic2020-12-06 17:572023-05-31 07:52
Reportersyzop Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Fixed in Version6.1.0-rc2 
Summary0005794: New trusted-users distinction and channel anti flood stuff
DescriptionFirst in the config we add:
set {
        trusted-users {
                webirc yes;
                identified yes;
                reputation-score 24;
        }
}

This will make the distinction between trusted users and untrusted users that will be used elsewhere.

Change modes +R and +M:
* +R to allow trusted-users (so also reputation >=24)
* +M too (same)
* Alternative proposal: add two new channel modes (I don't like this and think it is a waste)
* Alternative proposol 2: make them parameter modes (this is really not fun with regards to compatibility with unrealircd and services!)
* Alternative proposal 3: still change +R and +M, but allow existing behavior via extbans, eg allow +b ~a:0 or something (or like k4be's unreg extban +b ~I:*), and similarly +b ~m:~a:0 / ~m:~I:*.

Channel mode +f:
* Existing types cjkmntr apply to everyone, like now
* New types CJKMNTR will be applied to UNTRUSTED users
* Alternative proposal: the reverse, but it is not backwards compatible and thus confusing.

New channel mode +F that works with 'profiles':
* "+F normal" is the default (or no +F at all)
* There is also an "+F strict" and an "+F loose"
* "+F off" to turn it off (yes, explicitly)

The profiles are then defined in the configuration file. For example "+F normal" corresponds with say [5J#R5]:10, so 5 joins of untrusted users in 10 seconds, and will set +R for 5 minutes. This is only a partial example illustrating the 'J' type. The actual normal profile will not only contain 'J' but also 'j' and 'M' and 'm' etc.

Think about interaction with +f. The most easiest and straightforward would be that +f overrides any settings from +F profiles. Eg if type 'J' exist in the +F profile like in the example above, and you have an +f with type 'J' then it overrides that setting.

Background:
* +f is really underused now, lots of people don't set this mode because it is too complex
* reputation is underused, we can do so much more with it (like here)
* expand +R and +M use

TagsNo tags attached.
3rd party modules

Activities

k4be

2020-12-12 09:41

developer   ~0021847

I think the +R/+M modes should be configurable individually to allow not altering their old behaviour.
I wanted to create a new usermode which basically would work like your idea of +R with parameter that defines a minimum score to bypass the restriction. I started to implement this as an extban, but this was flawed and the channel mode is better. We shouldn't add parameters to +R though to avoid said compatibility problems, so this would have to be a new mode.
The parameter can be a minimum reputation score (so channel ops would be able to choose threshold themselvels), and that means channel operators would need to somehow understand the scores. Maybe think about a way to allow chanops to view scores of users that have joined their channels.
(Unrealircd is still not using digits as mode characters, so we have 10 more!)
I like the idea about having separate +f triggers that would ignore "trusted" users. This will likely find use.
Do i understand correctly that the +F idea creates a "hidden" +f with pre-set arguments to work on the channel?
On our network +f is enabled on most of the channels as I've set services to create a default "mlock" with it for every registration. I think there's a better way to set it with u5 but i have not looked into it. But maybe something like that can be included in the configuration help or examples too?

syzop

2020-12-12 11:49

administrator   ~0021848

Right, so, after input from k4be and Gottem: don't change +R / +M.

The +F to +f idea is unchanged, but... the rest is:

In case of a flood detected by +f/+F we need either a new channel mode (not what I want) or an extban... we will go with the latter.
Say we call it ~X (letter to be decided later)... and we, for now, allow the class "trusted" or "!trusted".
+b ~X:!trusted -- this will ban all clients that do not match any requirements from set::trusted-users

For +f this then translates like:
+f [10j#i10,5J#X5,20m#m1,10M#X5]:10
* on 10 joins per 10 seconds it would set +i, then remove it after 10 minutes
* on 5 joins of users not matching trusted-users (eg: low reputation users), it would set +b ~t:5:~X:!trusted
* on 20 messages per 10 seconds it would set +m and remove after 1 minute
* on 10 messages per 10 seconds from users not matching trusted-users (eg: low reputation), it would set +b ~t:5:~q:~X:!trusted

syzop

2020-12-12 11:50

administrator   ~0021849

Also, keep in mind that this will look much nicer after U6 would have extban names instead of extban letters.
Then +b ~t:5:~q:~:!trusted becomes like:
+b ~time:5:~quiet:~something:!trusted
which is much more readable.

syzop

2020-12-12 12:09

administrator   ~0021850

Now as to what letter to use for the ~X example...

It is some kind of classification system, so like class but that is confusing since it has nothing to do with class { } blocks.
Something with trusted but both ~t and ~T extbans are in use...
Synonym and related search results: analysis, designation, grade, group, order, category, pattern, rank.
I know, "group" sounds nice but I think we should avoid it... since it has meaning with regards to users and groups in services or other authentication systems.
We can also use one of those words in combination with something else: xxx-yyy.

I think category or grade sounds closest... we are putting users in a category and/or grading them.. we can use those words directly or with a combination of another word:
trusted-grade, trusted-category, etc.

Hmmmm.

syzop

2020-12-12 12:32

administrator   ~0021851

Perhaps ~G meaning trusted-group, leaving ~g free for later use.
So: ~G:!trusted
the G also fits nicely in +f anyway, since it makes no sense to set an +G or -G channel mode from +f, so we can use G to mean the extban :)

Not so sure about the "long name" yet... ~trusted-group:!trusted looks ugly.
classification-group
security-group
hmmm.

syzop

2020-12-12 12:46

administrator   ~0021852 

# These security groups can be used from the ~G extban
# and referred from elsewhere in the config.
# This goes NOT in set { } but has it's own block,
# just like class { } and allow { } etc:
security-group trusted {
        webirc yes;
        identified yes;
        reputation-score 24;
}

# Then for the CJKMNTR actions we have to define to what it applies.
# And, the same is used for +b ~G:xxxxx
set {
        modef-untrusted-group !trusted;
}

# Then as for the +F profiles, what they mean in +f:
set {
        anti-flood {
                channel {
                        default-profile normal;
                        profile strict { flood-mode "[5j,3J]:10"; }
                        profile normal { flood-mode "[10j,5J]:10"; }
                        profile loose  { flood-mode "[20j,10J]:10"; }
                }
        }
}
# Or we can use some extended alternate form which is more readable:
set {
        anti-flood {
                channel {
                        default-profile normal;
                        profile normal {
                                flood-mode {
                                        period 10;
                                        trusted {
                                                joins 10 { action "J"; remove-action 5; }
... etc... nahhhhh.... no.... admins better learn +f syntax i think... since they are admin they should be able to :D

syzop

2020-12-12 12:56

administrator   ~0021853

Last edited: 2020-12-12 12:58

 Oh and related to what something k4be said, it would be useful to know the +f strings of the +F that are available (the profiles).
And perhaps we could combine that with some +f explanation thingy.
Like if you run:
MODE #channel +F
MODE #channel F
MODE #channel +f
MODE #channel f
Then it will output some long text explaining:
1) The currently effective settings
2) The available +F profiles

And with regards to the 1st... show both the effective f line line [5j,3J]:10 and then a verbose explanation like "10 joins: set .... and remove after ..." etc... so to make it quite readable.

This helps in several ways:
* Users can see the effective flood protection string, so don't have to "guess" which settings are inherited from +F and which are taken from +f
* Also the more readable format can explain it to noobs too.
* Users can see the different profiles that are available

syzop

2020-12-12 16:20

administrator   ~0021854

In terms of rollout, I am thinking:
1) The ~G mode, and thus also security-group { }
2) The mode +f for untrusted users, and thus also set::modef-untrusted-group
3) Mode +F, the set::anti-flood::channel profiles, etc. etc.

The 1st should be no problem to put that in the Christmas release of UnrealIRCd.
The 2nd, I can code it in 1 day that is probably no problem, but there's probably not sufficient time to test it.
The 3rd is for later for sure.

syzop

2020-12-30 13:02

administrator   ~0021867

(There was no Christmas release)
I have done phase 1 (of 3). I'll probably make it a release candidate very soon now, called 5.0.8-rc1.

syzop

2020-12-30 13:06

administrator   ~0021868

Some small changes with the implementation i made and what was written/proposed here earlier:
A) call it not 'trusted' but 'known', so: 'known-users'
B) an internal auto group called 'unknown-users' which is the same as '!known-users'
As for B... this matters only slight for bans, making them more readable: +b ~G:!known-users vs +b ~G:unknown-users, but even more when things get more complex like: ~t:5:~q:~G:!known-users would then be ~t:5:~q:~G:unknown-users.
But it is mostly for the config stuff, if we later split like set::anti-flood into set::anti-flood::known-users / set::anti-flood::unknown-users (rather than set::anti-flood::!known-users which may not even be valid to the parser).

syzop

2021-03-07 09:04

administrator   ~0021899

> Think about interaction with +f. The most easiest and straightforward would be that +f overrides any settings from +F profiles. Eg if type 'J' exist in the +F profile like in the example above, and you have an +f with type 'J' then it overrides that setting.

Just realized that if you do it this way... two problems come up with this overriding stuff:
1) You would have to allow 0 for events, eg 0j (zero joins) if you want to disable the joinflood protection. <- this one is easy to permit, though it looks a bit silly
2) You can have a +f with a different time period than the +F profile, eg one is for :10 seconds and the other is :15. <- that is a problem, it's not really possible to merge that.

syzop

2021-03-07 09:09

administrator   ~0021900

Last edited: 2021-03-07 09:10

 So, a few options:
1) Don't allow different :times, but that screws up with existing +f, don't think that we can do that
2) Make it so that if any +f mode is set it overrides ALL the +F modes. That would be a pitty as well, since many +f's won't be good enough or at least lacking all the new uppercase settings
3) Make them work entirely separate, thus allowing different :times, but that means the +F plus +f no longer maps to one single +f line anymore (since it may be both :10 and :15).
3a) then options with or without stopping subtypes of +F if that specific subtype is set in +f

Hmmmm. I don't know...... it sounds like all options except option 2 would be confusing to the user.

syzop

2023-03-25 13:41

administrator   ~0022807

Last edited: 2023-04-02 17:45

 2 years later i thought of a different approach and just committed to git.
It does not use the uppercase letters / different settings for unknown-users idea, but uses a simpler approach (as to not make the modeline more complex):

commit b9be185f0aae81cbe340154b70035419ebc58611 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD)
Author: Bram Matthys <[email protected]>
Date:   Sat Mar 25 13:29:17 2023 +0100

    Make channel mode +f ban "unknown-users" first on a join flood,
    if the join flood is caused by >75% of "unknown-users". This
    to see if that will take care of the flood without harming
    the "known-users" group. And naturally, do something similar
    for message floods and nick floods.
    
    If the flood persists, because they are caused by known-users,
    then the +i/+m/etc actions are still taken.

The 75% is not set in stone by the way. And several of these values will made configurable. It's work in progress.

So this scratches the idea of different like uppercase/lowercase, where you have like 'm' for all users and 'M' for unknown-users.
We could still offer different values for known-users/unknown-users for the individual user actions, though, so for 't' (text) and 'r' (repeat). Although i think the use of that would be limited, it could be.

This also still leaves the +F profile idea for later:
1) I'm thinking about making +F opt-in for UnrealIRCd 6 and then some major version we can make it a sticky/always-on channel mode or something like that (where all channels are +F normal or +F standard by default).
2) Make any +f that is set override the entire +F (possibly even set the channel -F when someone sets +f, to make it totally clear that +F profiles don't apply then)
3) When defining flood profiles, presumably default in the source and optionally changed in the conf, we have to deal with different values on servers. I mean, admins may change them on servers and there will likely be different defaults from one version to another even if we try to avoid touching it too much. So we would have to deal with syncing the values over the network, or at least have all servers decide on a mutual single value for each profile. If we would NOT do that, then different servers think different flood limits apply to a channel which leads to mysterious "why does +F not work, why does it not use said limits" kind of problems :D

syzop

2023-04-02 17:40

administrator   ~0022813

private -> public

syzop

2023-04-02 17:41

administrator   ~0022814

Last edited: 2023-04-02 17:43

 The +F profile idea has also been done now, in current git which will become 6.1.0.
There's also the option to set a default profile. It is not the default yet, but this could change in a later version.
An +f mode will override the subtypes that are listed in +f of the +F profile, so basically option 3 from https://bugs.unrealircd.org/view.php?id=5794#c21900

Basically all that has been said has been done now.
(Except network-wide checking if flood profiles differ)

syzop

2023-04-02 17:45

administrator   ~0022815

There's one important TODO item still to be done:
// TODO: if flood profiles change during REHASH (or otherwise) they are not re-applied to channels that have +F

syzop

2023-05-31 07:52

administrator   ~0022889

That final TODO item was done before 6.1.0 release, actually (6.1.0-rc2, i believe).

Issue History

Date Modified Username Field Change
2020-12-06 17:57 syzop New Issue
2020-12-06 17:58 syzop Description Updated
2020-12-06 17:58 syzop Description Updated
2020-12-12 09:41 k4be Note Added: 0021847
2020-12-12 11:49 syzop Note Added: 0021848
2020-12-12 11:50 syzop Note Added: 0021849
2020-12-12 12:09 syzop Note Added: 0021850
2020-12-12 12:32 syzop Note Added: 0021851
2020-12-12 12:46 syzop Note Added: 0021852
2020-12-12 12:56 syzop Note Added: 0021853
2020-12-12 12:58 syzop Note Edited: 0021853
2020-12-12 16:20 syzop Note Added: 0021854
2020-12-30 13:02 syzop Note Added: 0021867
2020-12-30 13:03 syzop Assigned To => syzop
2020-12-30 13:03 syzop Status new => assigned
2020-12-30 13:06 syzop Note Added: 0021868
2021-03-07 09:04 syzop Note Added: 0021899
2021-03-07 09:09 syzop Note Added: 0021900
2021-03-07 09:09 syzop Note Edited: 0021900
2021-03-07 09:10 syzop Note Edited: 0021900
2023-03-25 13:41 syzop Note Added: 0022807
2023-03-25 13:41 syzop Note Edited: 0022807
2023-03-25 13:42 syzop Note Edited: 0022807
2023-03-25 13:44 syzop Note Edited: 0022807
2023-04-02 17:35 syzop Note View State: 0021849: public
2023-04-02 17:40 syzop View Status private => public
2023-04-02 17:40 syzop Note Added: 0022813
2023-04-02 17:41 syzop Note Added: 0022814
2023-04-02 17:43 syzop Note Edited: 0022807
2023-04-02 17:43 syzop Note Edited: 0022814
2023-04-02 17:45 syzop Note Added: 0022815
2023-04-02 17:45 syzop Note Edited: 0022807
2023-05-31 07:52 syzop Status assigned => resolved
2023-05-31 07:52 syzop Resolution open => fixed
2023-05-31 07:52 syzop Fixed in Version => 6.1.0-rc2
2023-05-31 07:52 syzop Note Added: 0022889