View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005107unrealircdpublic2018-06-18 15:542019-12-28 09:43
ReporterPeGaSuS Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformUnixOSUbuntuOS Version18.04 LTS
Product Version4.0.18 
Target Version4.2.0Fixed in Version4.2.0 
Summary0005107: more flexible 'require-sasl' requirements
DescriptionI have a few allow blocks in my config file.
i have a specific allow block for IRCCloud users to force them to use SASL.
Unfortunately that doesn't seem to happen, and IRCCloud users are still able to join even if they don't have the nickname/account registered.
Steps To Reproduce1) Create a few allow blocks like this example: https://pastebin.com/4DS11PZf

2) Connect with any IRCCloud user to the network

3) The user will be able to connect, despite the second block have allow::options::require-sasl enabled for the hostname *.irccloud.com
Tagsbug, conf
3rd party modules

Activities

PeGaSuS

2018-06-18 17:19

reporter   ~0020164

So, i decided to try another approach and use IP instead hostname, using the IPs provided by IRCCloud here: https://www.irccloud.com/networks

My allow blocks look like this now: https://pastebin.com/kmY3kyfJ

I must assume with my little knowledge that this is most probably a bug, and if not I can't figure it out where I'm doing things wrong

syzop

2018-06-18 17:31

administrator   ~0020165

I suppose the 'require' in 'require-sasl' is a bit confusing.

If an allow block doesn't match (eg: you do not use SASL) then the next allow block is tried, and so on... So yeah, it doesn't work this way.

The same is true for the option 'ssl'.

PeGaSuS

2018-06-18 17:35

reporter   ~0020166

So, in this case probably the allow blocks requiring SASL should be BEFORE the general ones?

syzop

2018-06-18 17:36

administrator   ~0020167

So basically sasl and ssl are 'selectors' in the allow block and not 'enforcers', so to say.
If you change that behavior then you may break other people's setups:
For example you may want to have an allow block with require-sasl with maxperip 5, and then next generic allow block *@* with maxperip 2 (without require-sasl). That is something that currently works.

I had a similar request as to what you want to be doing via email. So I'm sure there's a need.
Does make you wonder if the allow block is the right place to do all this, though.

syzop

2018-06-18 17:45

administrator   ~0020168

I suppose I could give them a different meaning:
sasl / ssl: just a selector
require-sasl/require-ssl: reject the user if not using this
Hopefully users will understand.

PeGaSuS

2018-06-18 18:14

reporter   ~0020169

I might be understanding all completely wrong. I've moved the IRCCloud alow blocks to the top and I can still connect via IRCCloud without being asked to use SASL.

My allow blocks looks like this: https://paste.ubuntu.com/p/ptM4kHb6nz/

But if I enable the allow::options::require-sasl, the connection is denied with the reason that I've specified:
You need to identify to a registered nick via SASL to connect. If you don't have a registered nick, go to https://somesite and register one. If you have already registered, configure your IRC client to use SASL.

PeGaSuS

2018-06-18 18:16

reporter   ~0020170

I've made a typo in the last note: But if I enable the allow::options::require-sasl in the general block (allow::ip *@*), the connection is denied with the reason that I've specified:
You need to identify to a registered nick via SASL to connect. If you don't have a registered nick, go to https://somesite and register one. If you have already registered, configure your IRC client to use SASL.

syzop

2018-06-18 18:52

administrator   ~0020171

Last edited: 2018-06-18 18:54

 I don't see how I can point it out more clearly: an allow block will not reject the user, it will either accept it or will continue to next allow block.
If no allow blocks match at all, then yeah.. the user is rejected.

For the rest, see previous comments :D

PeGaSuS

2018-06-18 18:58

reporter   ~0020172

Then probably we could use a deny block instead? If the user doesn't use SASL then we'd deny the connection.
Just my 2 cents on this idea

syzop

2018-06-23 08:18

administrator   ~0020178

Last edited: 2018-06-23 08:18

 I have removed 'require-sasl' and 'require-ssl'. Only 'ssl' and 'sasl' is accepted now in allow::options. See previous discussion from above.

I will use this bug report for deny { } block and conditional gline/kline's. This will not be in 4.0.18, however, as I don't to get that version out of the door without introducing additional issues :)

syzop

2018-06-23 08:28

administrator   ~0020179

Have renamed the bug report to "more flexible 'require-sasl' requirements". See previous comment.

syzop

2018-06-23 09:46

administrator   ~0020181

Have updated the allow block docs https://www.unrealircd.org/docs/Allow_block#Syntax to clarify what happens if no allow block matches. Similarly, have clarified the allow::options stuff.
This after the confusion it caused to The_Myth and others :]

PeGaSuS

2018-07-05 12:15

reporter   ~0020183

I came across a small idea, to allow TOR users to connect in a easier way to a network.

Right now if we want to a allow a TOR user to connect, we need to use a except blacklist {}; block with the specific IP.

I was thinking if would be possible to extend the 'sasl' requirement to a blacklist <name> {}; block, with an option perhaps like blacklist::options::except-sasl.

This would make allowing TOR users much easier than it currently is.

Any thoughts about this?

syzop

2018-09-02 13:20

administrator   ~0020253

12:57 < The_Myth> also, there's another question that arises. to easy the way to allow TOR, perhaps
                  would be great to have a way to automatically exempt users connecting using SASL from
                  DNSBL ckecks (don't know if that's even possible).
12:59 < The_Myth> I assume that in order to that work properly we'd have to set the DNSBL action to
                  'kill' instead gline, i.e
13:00 < The_Myth> any thoughts/ideas regarding this?

Koragg

2018-09-02 19:39

reporter   ~0020254

The idea itself is a good way aan except blacklist {} may be inconvenient if multiple people use the same TOR IP and one is an abuser but the others are not.
In case this gets implemented one could simply suspend/drop an offending SASL user*s account so they can no longer use SASL.
Unfortunately though if the user has many emails they could consistently re-register and thus get an account again to use for SASL.
This is the only consideration that I would see, any ideas on how to counter such a potential abuse?

PeGaSuS

2018-09-02 19:54

reporter   ~0020255

Here's what's coming into my mind.
The actual Blacklist syntax is the following:
blacklist <name> {
        dns {
                name <blacklist hostname>;
                type <record|bitmask>;
                reply { <permitted replies> };
        };
        action <action>;
        reason <reason>;
        ban-time <time>;
};

I was thinking in adding an option like:
options {
    except-authed "yes|no";
    };

The main problem that arises, in my POV (and kinda discussed in IRC already), is that if we set blacklist::action to "gline" the exempting of authed users would be useless.
There's 2 options imo: 1) set manually blacklist::action to "kill" (only users not connecting using SASL will be killed), 2) OR if blacklist::options::allow-authed is set to "yes" then force blacklist::action to be "kill" despite off any manual setting.

syzop

2018-09-05 10:06

administrator   ~0020263

I added a new feature called soft bans:
* Next two new features have to do with SASL. More information on SASL
  in general can be found at https://www.unrealircd.org/docs/SASL
* New "soft kline" and "soft gline". These will not be applied to users
  that are authenticated to services using SASL.
  These are just GLINE/KLINE's but prefixed with a percent sign:
  Example: /GLINE %*@10.* 0 Only SASL allowed from here
* New "soft" ban actions for spamfilter, blacklist, antirandom, etc.
  Actions such as "soft-kline" and "soft-kill" will only be applied to
  unauthenticated users. Users who are authenticated to services (SASL)
  are exempt from the corresponding spamfilter/blacklist/antirandom/..
  See https://www.unrealircd.org/docs/Actions for the full action list.
* WARNING: before using any global soft bans (such as soft gline or
  any spamfilter with soft-xx actions) your IRC network should only
  consist of servers running UnrealIRCd 4.0.19 or later.
  If one or more servers on your network is below that version then such
  bans are not effective network-wide and/or will not be properly
  propagated to other servers. There won't be havoc, but the bans simply
  won't be effective on the rest of the network.


This deals with the blacklist suggestion and likely a lot of other requests (even before they are submitted :D).

syzop

2018-09-05 10:09

administrator   ~0020264

So, you can now use something like /GLINE %*@hostmask to force all users on that hostmask to authenticate using SASL.
I'll have a look at how to do achieve the same in the configuration file, like via a ban user { } block.

syzop

2018-09-05 10:19

administrator   ~0020265

Last edited: 2018-09-05 10:23

 What do you guys think about the .conf request of this bug report.
I'm not sure how often it will be needed and when, especially with the dnsbl in place with soft-xxx actions you may not need to put a specific soft action in the conf anymore, but.. presumably it will still happen...

A 'Ban user' is our current way to put a kline in a conf, so if we apply the same %hostmask logic as in klines then it becomes:
ban user {
    mask %*@1.2.*;
    reason "Please authenticate using SASL. See http......";
};
But.. that may seem cryptic.
Another option:
ban user {
    mask *@1.2.*;
    reason "Please authenticate using SASL. See http......";
    options { unauthenticated; };
};
.. which I don't like either.

So I'm thinking maybe a whole new block:

require sasl {
    mask *@1.2.*;
    reason "Please authenticate using SASL. See http......";
};
.. which would be a great name, but.. we don't have any "require" blocks so it's a bit strange.

Possibly more in-line would be something like:
ban unauthenticated {
    mask *@1.2.*;
    reason "Please authenticate using SASL. See http......";
};

As you can see I'm leaning to the 'ban unauthenticated' since it fits in with the rest of the system but I also do like 'require sasl' because of the perfectly clear name.

Opinions?

syzop

2018-09-05 11:37

administrator   ~0020267

https://github.com/unrealircd/unrealircd/commit/107d8ccf6a0ed2534e8882c3c5e987215a02919c

commit 107d8ccf6a0ed2534e8882c3c5e987215a02919c (HEAD -> unreal40, origin/unreal40, origin/HEAD)
Author: Bram Matthys <[email protected]>
Date: Wed Sep 5 11:34:48 2018 +0200

    * A new require sasl { } block which allows you to force users on the
      specified hostmask to use SASL. Any unauthenticated users matching
      the specified hostmask are are rejected.
      See https://www.unrealircd.org/docs/Require_sasl_block
    Feature suggestion: https://bugs.unrealircd.org/view.php?id=5107

syzop

2018-09-05 11:38

administrator   ~0020268

Let me know if any functionality is still missing after all the many commits from above. The only outstanding issues I have (and which will be resolved) are for /STATS and some stuff about banning that is not specific to SASL.
I'll leave the issue on 'feedback' for a short while.

syzop

2018-09-07 10:56

administrator   ~0020284

I may be releasing an RC or test release in the weekend.

syzop

2018-09-07 12:20

administrator   ~0020288

Marking as done. Feedback still welcome :)

Like I said, will probably release an -rc1 or -whatever very soon.

Issue History

Date Modified Username Field Change
2018-06-18 15:54 PeGaSuS New Issue
2018-06-18 15:54 PeGaSuS Tag Attached: bug
2018-06-18 15:54 PeGaSuS Tag Attached: conf
2018-06-18 17:19 PeGaSuS Note Added: 0020164
2018-06-18 17:31 syzop Note Added: 0020165
2018-06-18 17:35 PeGaSuS Note Added: 0020166
2018-06-18 17:36 syzop Note Added: 0020167
2018-06-18 17:45 syzop Note Added: 0020168
2018-06-18 18:14 PeGaSuS Note Added: 0020169
2018-06-18 18:16 PeGaSuS Note Added: 0020170
2018-06-18 18:52 syzop Note Added: 0020171
2018-06-18 18:54 syzop Note Edited: 0020171
2018-06-18 18:58 PeGaSuS Note Added: 0020172
2018-06-23 08:18 syzop Note Added: 0020178
2018-06-23 08:18 syzop Note Edited: 0020178
2018-06-23 08:18 syzop Note Edited: 0020178
2018-06-23 08:28 syzop Status new => acknowledged
2018-06-23 08:28 syzop Summary allow::options::require-sasl seems not to work with several allow blocks in the config => more flexible 'require-sasl' requirements
2018-06-23 08:28 syzop Note Added: 0020179
2018-06-23 08:38 syzop Product Version => 4.0.18
2018-06-23 08:38 syzop Target Version => 4.2.0
2018-06-23 09:46 syzop Note Added: 0020181
2018-07-05 12:15 PeGaSuS Note Added: 0020183
2018-07-14 16:35 syzop Sticky Issue No => Yes
2018-09-02 13:20 syzop Note Added: 0020253
2018-09-02 19:39 Koragg Note Added: 0020254
2018-09-02 19:54 PeGaSuS Note Added: 0020255
2018-09-05 10:06 syzop Note Added: 0020263
2018-09-05 10:09 syzop Note Added: 0020264
2018-09-05 10:19 syzop Note Added: 0020265
2018-09-05 10:21 syzop Assigned To => syzop
2018-09-05 10:21 syzop Status acknowledged => feedback
2018-09-05 10:23 syzop Note Edited: 0020265
2018-09-05 11:37 syzop Note Added: 0020267
2018-09-05 11:38 syzop Note Added: 0020268
2018-09-07 10:56 syzop Note Added: 0020284
2018-09-07 12:20 syzop Status feedback => resolved
2018-09-07 12:20 syzop Resolution open => fixed
2018-09-07 12:20 syzop Fixed in Version => 4.2.0
2018-09-07 12:20 syzop Note Added: 0020288
2019-12-28 09:43 syzop Sticky Issue Yes => No