Tip of the day: If you still have users on plaintext port 6667, consider enabling Strict Transport Security to gently move users to SSL/TLS on port 6697.

Set block

From UnrealIRCd documentation wiki
Jump to navigation Jump to search
This page contains changes which are not marked for translation.
Other languages:
  • English

The set block is used to tweak and configure the server settings.

Sharing settings

If you (already) run multiple IRC servers then have a look at Sharing settings between servers to ease the burden when updating settings. The set block is an ideal candidate to be shared.

Syntax used in this documentation

As described in Configuration file syntax we will refer to settings like set::options::hide-ulines or set::auto-join. You should NOT write set::options::hide-ulines in the configuration file! It's just a shorthand, an abbreviation. What we actually mean is that you should write them out like this: 

set {
        options {
                hide-ulines;
        };
        auto-join "#something";
};

Or you could put them in separate set blocks like this: 

set {
        auto-join "#something";
};

set {
        options {
                hide-ulines;
        };
};

Or even just: 

set { options { hide-ulines; }; };
set { auto-join "#something"; };

If the above is unclear, then maybe have another read at the Configuration file syntax article.

It is perfectly fine to have multiple set { } blocks! In fact it's quite normal to have one block with network-wide settings, and another set block with server-specific settings. We generally don't recommend having more than 2 set blocks because then it is too easy to loose track of them ("what settings is where?"), but technically it is perfectly possible and permitted.

Set block for a security group

Normally you have something like: 

/* This is the general set block */
set {
        maxchannelsperuser 10;
}

In UnrealIRCd 6.1.1 and later you can also have a set block with a name of a security group, like: 

/* This overrides the setting for unknown-users */
set unknown-users {
        maxchannelsperuser 5;
}

In the example of above the settings in the set unknown-users { } block will "override" the set { } setting, if the user is in the security group unknown-users.

You can also define your own security groups and then give these users MORE rights: 

security-group trusted-bots { account { Bot1; Bot2; Bot3; } }

set trusted-bots {
        maxchannelsperuser 50;
}

In the Security-group block you can read all about security groups, how to define your own, and the two important standard groups known-users and unknown-users.

There is a limited list of settings that you can override in a set xyz { }:

See also the Special users article on how to give trusted users/bots more rights or higher flood rates than regular users (also for things other than set { } blocks).

Available settings

set::kline-address

Syntax: set::kline-address <email-address>

The email address that K:line questions should be sent to. This value must be specified. See also set::reject-message::kline if you want a more custom disconnect message on KLINE/ZLINE.

set::gline-address

Syntax: set::gline-address <email-address>

The email address that G:line questions should be sent to. See also set::reject-message::gline if you want a more custom disconnect message on GLINE/GZLINE.

set::modes-on-connect

Syntax: set::modes-on-connect <+modes>

The modes that will be set on a user at connection.

In UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group.

set::modes-on-oper

Syntax: set::modes-on-oper <+modes>

The modes that will be set on a user when they /oper.

set::snomask-on-oper

Syntax: set::snomask-on-oper <+modes>

The snomask (server notice mask) that will be set on a user when they /OPER. See Snomasks for the full list.

The default value is +bBcdfkqsSoO

set::modes-on-join

Syntax: set::modes-on-join <+modes>

The modes that will be set on a channel when it is first created. Not all modes can be set using this command.

set::level-on-join

Syntax: set::level-on-join <none|voice|halfop|op|protect|owner>
Alternate syntax: set::level-on-join <letter>

The mode that a user will get when he's the first to join a channel. The default is "op" (channel operator). You can also specify a letter such as "o".

set::restrict-usermodes

Syntax: set::restrict-usermodes <modes>

Restrict users to set/unset the modes listed here (don't use + or -). For example you can set +G in modes-on-connect and G in restrict-usermodes, that way you can force all users to be +G and unable to do -G.

In UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group.

set::restrict-channelmodes

Syntax: set::restrict-channelmodes <modes>

Restrict users to set/unset the channelmodes listed here (don't use + or -). For example you can set +G in modes-on-join and G in restrict-channelmodes, that way you can force all (new) channels to be +G and unable to do -G.

If you want nobody to be able to set a channel mode, because you don't need the channel mode, then consider not loading the channel mode module. You can do it via the Blacklist-module directive.

IMPORTANT: Users may evade these restrictions via the MLOCK command from Services. If you use anope, we suggest you restrict the modes there too via anope's nomlock feature, see the example below.

Example to force and restrict channel modes

This will make it so all channels are always +ntG and that users cannot set +L:

In UnrealIRCd: 

set {
    modes-on-join "+ntG";
    restrict-channelmodes "ntGL";
}

In anope, in the module chanserv block: 

    nomlock = "L"
    require = "ntG"

Remember that the channel modes on the Anope side will only be applied to newly registered channels.

set::restrict-extendedbans

Syntax: set::restrict-extendedbans <types|*>

Don't allow users to use any extended bans ("*") or disallow only certain ones (eg: "qc").

set::restrict-commands

This allows you to restrict a certain command to users depending on: how long they are connected, if they are identified to Services or if they are using WebIRC block, and their reputation score.

See Restrict commands for the documentation.

set::auto-join

Syntax: set::auto-join "<channels>"

The channel(s) a user will be forced to join at connection. To specify more than one channel use a comma separated list.

Important: don't forget to add quotes, otherwise your value is mistaken for a comment! Use: auto-join "#chan";

This setting can be overridden by tld::channel and in UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group.

set::oper-auto-join

Syntax: set::oper-auto-join "<channels>"

The channel(s) a user will be forced to join when they /oper. To specify more than one channel use a comma separated list.

IMPORTANT: Don't forget to add double quotes, like: oper-auto-join "#chan,#chan2"; because otherwise you will get a parse error.

set::oper-vhost

Syntax: set::oper-vhost "<hostname>"

This sets the default oper::vhost. Standard variables are supported. This functionality requires UnrealIRCd 6.1.8 or later.

Example: set { oper-vhost $operclass.example.net; }

set::anti-spam-quit-message-time

Syntax: set::anti-spam-quit-message-time <timevalue>

A time value specifying the length of time a user must be connected for before a /quit message will be displayed. Used to prevent spam. A time value is a numeric string with d meaning days, h meaning hours, m meaning minutes, and s meaning seconds, for example 1d2h3m means 1 day, 2 hours, 3 minutes.

set::prefix-quit

Syntax: set::prefix-quit <text-to-prefix-quit>

Sets the text that will be used to prefix a quit message. If this value is set to 0 then the standard "Quit:" is used.

set::static-quit

Syntax: set::static-quit <quit message>

Sets a static quit message that will be sent whenever a client logs off the network. This eliminates the need for anti-spam-quit-message-time, as well as the set::prefix-quit. It will NOT replace ERRORS with the static-quit message.

In UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group.

set::static-part

Syntax: set::static-part <no|yes|part message>

A value of 'yes' strips all part comments, a value of 'no' makes part just work as usual, anything else will be used as a part comment (eg: static-part "Bye!") but this can be quite annoying, so use with care.

In UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group.

set::who-limit

Syntax: set::who-limit <limit>

Sets the limit for the maximum number of matches that will be returned for a /WHO, the default is 100.

This limit does not apply for WHO requests for a specific channel, eg WHO #channel. The limit also does not apply to IRCOps.

set::silence-limit

Syntax: set::silence-limit <limit>

Sets the limit on the maximum SILENCE list entries. If this directive is not specified, a limit of 15 is set.

set::maxbans

Syntax: set::maxbans <limit>

Sets the limit on the maximum amount of bans (+b) allowed per channel. The default is 60. The same limit is applied to exempts (+e) and invex (+I) as well.

set::maxbanlength

Syntax: set::maxbanlength <limit>

This setting has been removed in UnrealIRCd 6.1.1 as it was not deemed useful and only confusing

Similar to set::maxbans, but this sets the maximum amount of characters for all bans added up together, so basically this puts up a limit on the (semi-)maximum amount of memory all channel bans on a channel can take. The default is 2048 (bytes). With the default set::maxbans of 60 this allows 2048:60=34 characters per ban on average. Note that if you change this, the same limit is also applied to excepts (+e) and invex (+I).

set::max-inherit-extended-bans

This setting only exists in UnrealIRCd 6.1.8 and higher

Unlimited use of the extended ban ~inherit (documented here) can potentially cause too much CPU, so the number of ~inherit extbans per channel are limited. The +b/+e/+I entries are all counted separately and have their own limit.

The block looks like this, with the current default limits per channel: 

set {
        max-inherit-extended-bans {
                ban 1;              /* for +b ~inherit:#chan */
                ban-exception 0;    /* for +e ~inherit:#chan -- currently not implemented */
                invite-exception 1; /* for +I ~inherit:#chan */
        }
}

NOTE: The +e ~inherit type is not functional in UnrealIRCd 6.1.8, the +b and +I are.

set::allow-user-stats

Syntax 1: set::allow-user-stats <stats-list-in-letters>
Syntax 2: set::allow-user-stats {<long-stats-flag1> <long-stats-flag2>}

Specifies a list of /STATS flags that users may also see (non-IRCOps). The default is "" (empty), which means regular users may not see any /STATS.

Be careful if you tweak this, some stats are not meant to be exposed to regular users and the information contained in them will often aid attackers / "bad guys".

set::max-stats-matches

Syntax: set::max-stats-matches <count>

If, as an IRCOp, you do STATS gline and there are thousands of glines then in the past the oper would be disconnected due to flooding ("Max SendQ exceeded"). With max-stats-matches you limit the number of *LINE entries that are outputted. The default is 1000 entries which should be sufficient protection (assuming your oper class has a sendq of 500K or more). You can set this limit higher or lower, or to zero to disable the protection (no limit).

set::min-nick-length

Syntax: set::min-nick-length <length>

Specifies the minimum required length of a nick name. This defaults to 0 which means there's no minimum. The maximum is 30 (NICKLEN) but it should still be smaller than (or equal to) set::nick-length.

set::nick-length

Syntax: set::nick-length <length>

Specifies the maximum length of a nick name. This default and maximum is 30 (NICKLEN). This setting can only be used to impose a shorter nick length than that.

set::topic-length

Syntax: set::topic-length <length>

Specifies the maximum length of a channel topic. This default and maximum is 360. This setting can only be used to impose a shorter length.

set::away-length

Syntax: set::away-length <length>

Specifies the maximum length of the away reason in /AWAY. The default is 307 and the maximum is 360.

set::quit-length

Syntax: set::quit-length <length>

Specifies the maximum length of the quit reason in /QUIT. The default is 307 and the maximum is 395.

set::kick-length

Syntax: set::kick-length <length>

Specifies the maximum length of the kick reason in /KICK. The default is 307 and the maximum is 360.

set::maxchannelsperuser

Syntax: set::maxchannelsperuser <amount-of-channels>
Also: set::max-channels-per-user <amount-of-channels>

Specifies the number of channels a single user may be in at any one time. IRCOps are exempt from this restriction.

In UnrealIRCd 6.1.1 and higher you can also override this value in a set block for a security group. This way you could set a low set::max-channels-per-user of 5 as a default, and set it to 10 for known-users.

set::maxdccallow

Syntax: set::maxdccallow <amount-of-entries>

Specifies the maximum number of entries a user can have on his/her DCCALLOW list.

set::channel-command-prefix

Syntax: set::channel-command-prefix <command-prefixes>

With user mode +d a user can mark themselves as "deaf", that is: they don't receive channel messages. But, if the first character of a message starts with a certain character (the prefix) then the message does go through. The default value is `!. which is normally a good setting. It means something like !kick Blah is received by users (bots) that have +d.

set::allowed-nickchars

Syntax: set::allowed-nickchars { <list> }

Character sets / languages to allow in nick names, see Nick Character Sets.

set::allowed-channelchars

Syntax: set::allowed-channelchars [utf8|ascii|any]

Which characters to allow in channel names. This setting must be the same on all servers.

There are 3 possible settings (utf8, ascii and any):

Setting Allowed characters Comment
utf8 All valid UTF8 characters This is the default. It should be suitable for nearly everyone since UTF8 is the de-facto standard on IRC nowadays.
ascii Only a-z/A-Z/0-9 and a few other ASCII characters This is a strict setting. It can be used if you don't want any confusion with channel names, no UTF8, etc. Technically this would be safest. Freenode uses this in their software.
any Almost all characters are permitted This is a very loose setting and was the default in UnrealIRCd 4.x. The problem is that this breaks text websocket clients. It is NOT a recommended setting.

The following characters are ALWAYS REJECTED: ASCII values below 32 (control characters), the space character, comma, colon.

set::allow-userhost-change

Syntax: set::allow-userhost-change [never|always|not-on-channels|force-rejoin]

Specifies what happens when the user@host changes (+x/-x/chghost/chgident/setident/vhost/etc). never disables all the commands, always does always allow it even when in channels (may cause client desyncs) [default], not-on-channels means it's only allowed when the user is not on any channel. Finally, force-rejoin will force a rejoin in all channels and re-op/voice/etc if needed, it will do that for all IRC clients without the chghost capability.

set::topic-setter

Syntax: set::topic-setter [nick|nick-user-host]

You can see who set the TOPIC by doing /TOPIC #channel. Via this set option you configure what information is displayed about the setter:

  • nick: show only the nick of who set the topic
  • nick-user-host: show the nick!user@host of who set the topic

Until UnrealIRCd 6.1.0 the default was nick. From 6.1.1 onwards the default is nick-user-host.

set::ban-setter

Syntax: set::ban-setter [nick|nick-user-host]

You can see who set a ban/exempt/invex (+beI) by doing /MODE #channel b (or similar). Via this set option you configure what information is displayed about the setter:

  • nick: show only the nick of who set the ban/exempt/invex
  • nick-user-host: show the nick!user@host of who set the ban/exempt/invex

Until UnrealIRCd 6.1.0 the default was nick. From 6.1.1 onwards the default is nick-user-host.

set::options::hide-ulines

Syntax: set::options::hide-ulines

If this is present, Ulined servers will be hidden in /MAP and /LINKS for regular users (non-ircops). This is a very common thing to do.

set::options::flat-map

Syntax: set::options::flat-map

If this is present, all servers will appear as directly linked in /map and /links, thus you can no longer see which server is linked to which. This is a little help against (D)DoS attacks because evil people now no longer can easily see the 'weak points'.

set::options::show-opermotd

Syntax: set::options::show-opermotd

If present the opermotd will be shown to users once they successfully /oper.

set::options::identd-check

Syntax: set::options::identd-check

If present the presence of an identd server will be checked and the returned value will be used for the username. If no ident request is returned or the identd server doesn't exist, the user's specified username will be prefixed with a ~. If this value is omitted no such check is made.

set::options::show-connect-info

Syntax: set::options::show-connect-info

If present notices showing "ident request", "hostname lookup", etc. will be displayed when a user connects.

set::options::dont-resolve

Syntax: set::options::dont-resolve

Don't do any resolving (DNS lookups) on users that connect. This can be useful if many of your users don't have a host, to speed up connecting. Note that this also means you cannot have host-based allow blocks.

set::options::mkpasswd-for-everyone

Syntax: set::options::mkpasswd-for-everyone

Makes it so the MKPASSWD command can be used by everyone. This is not recommended on production servers. Normally this command is restricted to IRCOps only.

set::options::allow-part-if-shunned

Syntax: set::options::allow-part-if-shunned

Allow shunned user to use /part.

set::options::fail-oper-warn

Syntax: set::options::fail-oper-warn

If present, a user will be notified that his/her failed /oper attempt has been logged.

set::options::allow-insane-bans

Syntax: set::options::allow-insane-bans

Allow insane broad bans like /GLINE *@*.xx. This makes it very easy to accidentally ban everyone on your network, so use with great care!

set::options::disable-cap

Syntax: set::options::disable-cap

Disable IRC Client Capabilities Extensions (CAP). Note that this makes SASL and various other features unavailable or harder for clients to use.

set::dns::bind-ip

Syntax: set::dns::bind-ip <ip>

Specifies the IP to bind to for the resolver, rarely ever needed.

set::network-name

Syntax: set::network-name <name-of-network>

Specifies the name of the network on which this server is run. This value should be exactly the same on all servers on a network.

set::default-server

Syntax: set::default-server <server-name>

Defines the name of the default server to tell users to connect to if this server is full.

set::default-ipv6-clone-mask

Syntax: set::default-ipv6-clone-mask <value>

If two clients connect from different IPv6 addresses but only the last few bits are different, there is almost a guarantee that both clients are really one person. This option affects the enforcement of allow::maxperip. For example, if you set this option to 128, then each IPv6 address will be considered unique. Because of current IP allocation policies, the default and recommended setting is 64. You probably don't need to change this.

set::services-server

Syntax: set::services-server <server-name>

Specifies the name of the server that the services bots are connected to. See also Services.

set::stats-server

Syntax: set::stats-server <server-name>

Sets the name of the server on which the stats bot is located. If stats are not run this value may be left out.

set::sasl-server

Syntax: set::sasl-server <server-name>

Sets the name of the server to which SASL authenticate messages should be sent.

set::help-channel

Syntax: set::help-channel <network-help-channel>

Sets the name of the help channel for this network. This channel name is displayed if you type HELP(OP) with an unknown topic, eg HELPOP XYZ.

set::cloak-method

Syntax: set::cloak-method [ip|host]

This sets the method to use when cloaking a user. The default is host which will use hostname-based cloaking (and fallback to IP-based if no host is available). The alternative is to set this to ip which will make UnrealIRCd always do IP-based cloaking. This results in a XX.YY.ZZ.IP cloaked host which provides more anonymity. IRCOps can still see the real hostname of the user and GLINEs and such still work as well.

set::cloak-keys

Syntax: set::cloak-keys { "key1"; "key2"; "key3"; }

UnrealIRCd has a feature called Cloaking. The keys you specify here are used to generate such a +x host. ALL servers on the same network must use the same keys and they must be kept secret.

Each key consists of 50-100 characters, the characters should contain a mixture of: lowercase (a-z), uppercase (A-Z) and digits.

On *NIX you can use ./unrealircd gencloak on the command line to generate 3 random keys.
On Windows, you can use "C:\Program Files\UnrealIRCd 6\bin\unrealircdctl" gencloak

Example: 

/* This is just an example, don't actually use these keys yourself!! */
set {
    cloak-keys {
        "g5Ea8V0j7gb3t7w8QFmFV7Qoacit6T62eOk3jlIn7Qg0YaGgBqj55";
        "mVv4uVw3306We2HvgPWTk1q0Nvnrl6uCr6Bor57c01d4eB5s60eQ3";
        "HPXLauAcFF058V4Ian7X1hlt0Yj0MGmooNqs5bALL3um5GwD3O6w0M5L";
    };
};
set::cloak-prefix

Syntax: set::cloak-prefix <prefix-value>

Defines the prefix that will be used on hidden hosts (+x). This is usually three or four letters representing the network name. Linked servers must have the same cloak-prefix for channel bans to function properly.

set::tls::certificate

Syntax: set::tls::certificate <filename>

Specifies the filename where the server's SSL certificate is located. The default is server.cert.pem.

IMPORTANT: If you want to use Let's Encrypt, then we suggest using a dual cert approach and NOT changin set::tls::certificate. Follow the Using Let's Encrypt with UnrealIRCd guide.

set::tls::key

Syntax: set::tls::key <filename>

Specifies the filename where the server's SSL private key is located. The default is server.key.pem.

IMPORTANT: If you want to use Let's Encrypt, then we suggest using a dual cert approach and NOT changin set::tls::key. Follow the Using Let's Encrypt with UnrealIRCd guide.

set::tls::trusted-ca-file

Syntax: set::tls::trusted-ca-file <filename>

Specifies the filename where the certificates of the trusted CAs are located. The default is curl-ca-bundle.crt (shipped with UnrealIRCd)

set::tls::protocols

Syntax: set::tls::protocols <list-of-protocols>

Specifies which SSL/TLS protocols are permitted. Available options are: All, TLSv1, TLSv1.1, TLSv1.2 and TLSv1.3. Prefix the protocol with a - (minus sign) to remove it.

Example: set { tls { protocols "All,-TLSv1,-TLSv1.1"; /* permit only TLSv1.2 and up */ }; };

See TLS Ciphers and protocols for more information and suggestions on a good setting.

set::tls::ciphers

Syntax: set::tls::ciphers <cipherlist>

Specifies which ciphers to be allowed for TLSv1.0, TLSv1.1 and TLSv1.2. See TLS Ciphers and protocols for more information and suggestions on a good setting.

set::tls::ciphersuites

Syntax: set::tls::ciphersuites <ciphersuitelist>

Specifies which ciphersuites to allow for TLSv1.3. See TLS Ciphers and protocols for more information.

set::tls::ecdh-curves

Syntax: set::tls::ecdh-curves <curvelist>

Specifies which ECDH(E) curves to be allowed. See TLS Ciphers and protocols for more information and suggestions on a good setting.

set::tls::renegotiate-bytes

Syntax: set::tls::renegotiate-bytes <value>

Specifies after how many bytes an SSL session should be renegotiated (eg: 20m for 20 megabytes).

set::tls::renegotiate-timeout

Syntax: set::tls::renegotiate-timeout <timevalue>

Specifies after how much time an SSL session should be renegotiated (eg: 1h for 1 hour).

set::tls::options::fail-if-no-clientcert

Syntax: set::tls::options::fail-if-no-clientcert

Forces clients that do not have a certificate to be denied. This would be an unusual setting to enable.

This option does not provide any security. A user can simply generate a client certificate and use it to connect, no verification is done.

set::tls::options::no-starttls

Syntax: set::tls::options::no-starttls

Disable STARTTLS. STARTTLS allows clients to use SSL/TLS on regular (non-SSL) ports, which is normally a good thing.

set::tls::outdated-protocols

This sets the outdated SSL/TLS protocols. It is used for set::outdated-tls-policy.

The default setting is "TLSv1.0,TLSv1.1" which marks TLSv1.0 and TLSv1.1 as outdated. In case you wonder, SSLv3 is not listed here because UnrealIRCd never allows such connections anyway.

set::tls::outdated-ciphers

This sets the outdated SSL/TLS ciphers. It is used for set::outdated-tls-policy.

The default setting is "AES*" which requires some explanation: This effectively marks all ciphersuites without Forward Secrecy as outdated. It stills allows AES perfectly fine, but only in combination with ECDHE/EECDH, which provides Forward Secrecy. For example AES128-SHA256 would be considered outdated and ECDHE-RSA-AES128-GCM-SHA256 is not.

If you use a weird ::ciphers setting, for example one that allows CAMELLIA, then you may have to tweak ::outdated-ciphers also. This is, however, an extremely uncommon configuration.

set::tls::sts-policy

This configures Strict Transport Security in UnrealIRCd.

Read SSL/TLS - Strict Transport Security for information on how to deploy this.

Example: 

/* Read https://www.unrealircd.org/docs/SSL/TLS#Strict_Transport_Security
 * before deploying this.
 */
set {
        tls {
                sts-policy {
                        port 6697;
                        duration 5m;
                };
         };
};

IMPORTANT: Invalid/untrusted SSL/TLS certificates or a non-working TLS port WILL LOCK YOUR USERS OUT if you use sts-policy!

set::tls::certificate-expiry-notification

Syntax: set::tls::certificate-expiry-notification <yes|no>

Was introduced in 6.1.7

It allows to disable the check and notification about TLS certificate expiring.

The default value is yes

set::plaintext-policy

The plaintext-policy block allows you to configure what UnrealIRCd should do with users/opers/server who are not connected via SSL/TLS. 

set {
    plaintext-policy {
        user allow; /* will allow users to connect without using SSL/TLS */
        oper warn; /* will warn oper if not connected via SSL/TLS */
        server deny; /* will deny server linking */
    };
};

An action of allow will allow the operation. The warn action will make the server send a warning notice. The deny action will reject the user/oper/server, meaning that the user cannot connect, the IRCOp cannot /OPER and the server may not link.

Optionally you can set a set::plaintext-policy::user-message and set::plaintext-policy::oper-message to change the default UnrealIRCd warn/deny text the user/ircop will receive.

set::outdated-tls-policy

The outdated-tls-policy block allows you to configure what UnrealIRCd should do with users/opers/server connecting with an outdated SSL/TLS protocol or cipher. 

set {
    outdated-tls-policy {
        user warn; /* must be one of: allow, warn, deny */
        oper deny; /* must be one of: allow, warn, deny */
        server deny; /* must be one of: allow, warn, deny */
    };
};

An action of allow will allow the operation. The warn action will make the server send a warning notice. The deny action will reject the user/oper/server, meaning that the user cannot connect, the IRCOp cannot /OPER and the server may not link.

To decide which protocol and ciphers are considered outdated, the set::tls::outdated-protocols and set::tls::outdated-ciphers settings are used.

Optionally you can set a set::outdated-tls-policy::user-message and set::outdated-tls-policy::oper-message to change the default UnrealIRCd warn/deny text the user/ircop will receive.

set::ident::connect-timeout

Syntax: set::ident::connect-timeout <amount>

Amount of seconds after which to give up connecting to the ident server (default: 3s).

set::ident::read-timeout

Syntax: set::ident::read-timeout <amount>

Amount of seconds after which to give up waiting for a reply (default: 7s).

set::handshake-timeout

Syntax: set::handshake-timeout <amount>

Amount of seconds that a connection may be in the "handshake state", that is: the period between a TCP/IP connection accept() and the user getting online after NICK/USER have been received and DNS and ident lookups have completed (if those are enabled).

The default is 30 which is a safe value for everyone. Be careful if drastically lower this. DNS lookups, ident lookups and the handshake may take more time than you may think in some cases. You can probably set this to a value like 20 if you like. However, if you set this setting too low then you risk locking everyone out when for example your DNS server is a little slow (eg: under attack).

set::sasl-timeout

Syntax: set::sasl-timeout <amount>

The maximum time for SASL to take place. Time starts at the AUTHENTICATE command. The default is 15 seconds.

This protects against misbehaving or extremely laggy SASL servers (Services). Otherwise, a misbehaving server could lead to people no longer being able to connect.

set::anti-flood

The set::anti-flood block is used to configure nearly all anti flood settings in UnrealIRCd:

set::default-bantime

Syntax: set::default-bantime

Default bantime when doing /KLINE, /GLINE, /ZLINE, GZLINE, /SHUN, etc without a time parameter (like /GLINE *@some.nasty.isp), the default is permanent (0). Example: default-bantime 90d

set::modef-default-unsettime

Syntax: set::modef-default-unsettime <value>

For channelmode +f you can specify a default unsettime, if you specify 10 for example then a /MODE #chan +f [5j]:15 will be transformed to [5j#i10]:15. The default is no default unsettime.

set::modef-max-unsettime

Syntax: set::modef-max-unsettime <value>

The maximum amount of minutes for a mode +f unsettime (in +f [5j#i

set::modef-boot-delay

Syntax: set::modef-boot-delay <timevalue>

IMPORTANT: In UnrealIRCd 6.0.1+ this setting has been moved to set::anti-flood::channel::boot-delay, see Channel anti-flood settings#config

Ignore join flood controls in channel mode +f when the server has just been rebooted. This because users are likely to quickly reconnect in such a case, causing a lot of joins which normally trigger +f, causing channels to end up being +i or +R even if there was no true attack (just a server restart).

The default setting is 75 seconds. You can specify an alternative time in seconds (eg: 120), or by timespec (eg: 2m).

The downside of this setting is that if a server is restarted in the middle of a drone attack, then when it is booted up again, drones would be able to bypass limits for the specified amount of time. One needs to weigh this against the false positives in channel mode +f that are otherwise caused by server restarts (eg: channels ending up +i due to +f, only because a server has been restarted during scheduled maintenance).

set::ban-version-tkl-time

Syntax: set::ban-version-tkl-time <value>

If you specify an 'action' like zline/gline/etc in a Ban version block, then you can specify here how long the IP should be banned, the default is 86400 (1 day).

set::spamfilter::ban-time

Syntax: set::spamfilter::ban-time <value>

Same as above but for *lines/shuns added by spamfilter

set::spamfilter::ban-reason

Syntax: set::spamfilter::ban-reason <reason>

Default reason to use for entries added by spamfilter

set::spamfilter::utf8

Syntax: set::spamfilter::utf8 <yes|no>
Default: yes, since UnrealIRCd 6.1.2

When UTF8 matching is enabled:

  • Case insensitive matches will then work better. For example, with extended Latin, a spamfilter on ę then also matches Ę.
  • Other PCRE2 features such as \p can then be used. For example with the regex \p{Arabic} to block all Arabic script. See this full list. Please do use this new tool with care. Blocking an entire language or script is quite a drastic measure.
set::spamfilter::virus-help-channel

Syntax: set::spamfilter::virus-help-channel <channel>

The channel to use for the 'viruschan' action in spamfilter

set::spamfilter::virus-help-channel-deny

Syntax: set::spamfilter::virus-help-channel-deny <yes|no>

If set to yes (or '1') it replies 'invite only' to any normal users that try to join the virus-help-channel. Only opers, people that match spamfilters and people that are /invite'd can join.

set::spamfilter::except

In UnrealIRCd 6.1.7 and later this is a Mask item that defines who/what should not be included in Spamfilter matching. This can be used to exempt destinations, like: 

set {
    spamfilter {
        except {
            destination { "#help"; "#help2"; "ReportSpamToMeBot"; }
        }
    }
}

But it can also be used to exempt security groups, IP's and everything (though you could also have used the Except ban block for that), eg: 

set {
    spamfilter {
        except {
            security-group { trusted-users; }
            ip { 192.168.*; }
        }
    }
}

See also all the (many!) items in Mask item that are available to select on, such as connect-time, reputation-score, etc.

In UnrealIRCd 6.1.6 and earlier the syntax was: except "#chan1,#chan2,nick and you could only filter targets that should be exempt from spam filtering.

set::spamfilter::detect-slow-warn

Syntax: set::spamfilter::detect-slow-warn <value>

If a spamfilter takes longer than this amount of milliseconds to execute (1000ms = 1 second), then a warning notice will be sent to all opers (default: 250). See also Spamfilter#Slow Spamfilter Detection

set::spamfilter::detect-slow-fatal

Syntax: set::spamfilter::detect-slow-fatal <value>

If a spamfilter takes longer than this amount of milliseconds to execute (1000ms = 1 second), then the spamfilter will be removed (default: 500). See also Spamfilter#Slow Spamfilter Detection

set::spamfilter::show-message-content-on-hit

Syntax: set::spamfilter::show-message-content-on-hit <always|never|channel-only>

When a spamfilter hits, IRCOps receive a notice and a message is logged. By default this includes the message content, even for private messages. The message content helps IRCOps to see if a spamfilter hit is correct or not, which can then lead to tweaking or removing faulty spamfilters, which can be very important if a spamfilter is misbehaving.

The following values are supported:

  • always: always show message contents, this is the default.
  • channel-only: only hide message contents for private messages/notices
  • never: hide message contents for both private and channel messages/notices

UnrealIRCd has the following spying countermeasure (for many years) to help that spamfilters are not abused for spying. When a spamfilter hit happens that has an action like gline or blocking, it is visible to the user that an action was taken. There is also the action 'warn', which means: take no action and only warn IRCOps, that one would be easy to use as a spy tool, so when this happens and message content was revealed, numeric 659 (RPL_SPAMCMDFWD) is sent to the client to indicate that the message is allowed through but IRCOps were informed. With this new set::spamfilter::show-message-content-on-hit feature, when the message content was hidden due to this setting (eg due to 'never' or 'channel-only' for chanmsgs), the warn message will not be sent as there is no need to inform the user in such a case.

set::central-spamfilter

See Central Spamfilter.

set::check-target-nick-bans

Syntax: set::check-target-nick-bans <yes|no>

Whenever the user changes his/her nick, check if the NEW nick would be banned. If so, do not allow the nickchange. Default is yes.

set::ping-cookie

Syntax: set::ping-cookie <yes|no>

When a client connects, send a "ping cookie" consisting of a random string that the client should respond with. All clients should cope with this and do so without bothering the user. Ping cookies are a security measure. It helps in preventing blind HTTP-POST attacks and similar security issues. It also helps against TCP spoofing on very old operating systems.

The default is yes (enabled). Changing this to no is a big security risk.

set::watch-away-notification

Syntax: set::watch-away-notification <yes|no>

Allows you to enable/disable AWAY notification in WATCH. The default is yes (enabled).

set::max-targets-per-command

This limits the number of targets in a command. For example for PRIVMSG it defaults to 4, which means you can address up to 4 targets via /MSG nick1,nick2,nick3,nick4 hello. These imposed protocol limits apply to everyone, including opers.

The following are the defaults: 

set {
    max-targets-per-command {
        privmsg 4;
        notice 1;
        tagmsg 1;
        names 1;
        whois 1;
        whowas 1;
        kick 4;
        list max;
        join max;
        part max;
        sajoin max;
        sapart max;
        kill max;
        dccallow max;
        userhost max;
        userip max;
        ison max;
        watch max;
    };
};

If you are tweaking the settings you should note that:

  • The commands NAMES and WHOWAS do not support more than 1
  • The setting for the commands USERHOST USERIP ISON WATCH can not be lowered
  • Other than the above there is no checking if the command exists or if the command itself allows multiple targets in the first place
set::hide-ban-reason

Syntax: set::hide-ban-reason <yes|no|auto>

This will hide the *LINE reason to anyone except the user being killed and IRCOps. There are 3 settings:

  • yes: always hide the ban reason to everyone else
  • no: never hide the ban reason
  • auto: only hide the ban reason to others if the reason contains the IP address of the user or an unrealircd.org URL. (Requires UnrealIRCd 6.1.3 or higher)

In UnrealIRCd 6.1.3 and higher the default is auto so that the IP address of the user is not accidentally exposed, for example via the dronebl.org ban reason which usually contains an URL with the IP.

In versions before 6.1.3, the auto option did not exist and the default is no.

set::hide-killed-by

Syntax: set::hide-killed-by <yes|no>

Hide the name of the oper in /KILL? If set to no (the default) then a KILL User Reason will result in a quit reason of Killed by OperNick (Reason). If set to yes then the quit reason will be Killed (Reason).

When set to yes, the reason will be hidden for everyone, the public and the person being killed. This can prevent oper harassment after a KILL. The IRCOps on the network can still see who did the kill via the log message / snomask.

set::antirandom

This module can automatically kill users that seem to have "random looking nicks".

This module is not loaded by default, you must load it manually: 

loadmodule "antirandom";

set {
	antirandom {
		/* THRESHOLD:
		 * This is the most important setting of all.
		 * For every randomly looking item the user gets a certain amount of
		 * 'points'. If the points reach the 'threshold' then the appropriate
		 * action is taken (killed, *lined, see later on).
		 *  lower = more randomly looking users will be caught
		 *          (but also more innocent users).
		 * higher = less chance of innocent users getting killed
		 *          (but also less chance on bots getting caught).
		 * <2:  DON'T!!
		 *  4:  Works good, probably a few more innocent kills, but if you have a
		 *      big problem with drone attacks then this might be a good setting.
		 *  5:  Works well with few innocent kills, probably good to begin with.
		 *  6:  If you want to be a tad more careful
		 * >6:  For the paranoid. Module can still be quite effective, though :)
		 */
		threshold 6;

		/* BAN-ACTION:
		 * Action to take whenever the user is caught as random, options:
		 * warn, kill, gline, gzline, kline, zline, shun, tempshun
		 */
		ban-action kill;

		/* BAN-TIME:
		 * Time to ban the user (irrelevant for tempshun/kill).
		 * Something between 1 hour and 2 days is recommended.
		 * If you set it higher than 3 or 4 days then you get quite a risk
		 * of catching innocent users due to dynamic IP, not to mention
		 * your *line list gets filled up... so choose it wisely.
		 */
		ban-time 4h;

		/* BAN-REASON:
		 * The ban or kill reason to use.
		 * Tip: you might want to put in an entry to a FAQ or an email address where
		 *      users can mail if they have been caught and don't know what to do.
		 * NOTE: One of the various reasons that "innocent users" are blocked is when
		 *       they randomly type in info for their nick, ident, or realname.
		 */
		ban-reason "You look like a bot. Be sure to fill in your nick/ident/realname properly.";

		/* CONVERT-TO-LOWERCASE:
		 * Convert nicks, idents, and realnames to lowercase before doing random checks?
		 * Useful to catch GnStA5FYhiTH51TUkf style random nicks as random.
		 * Enabled by default.
		 */
		convert-to-lowercase yes;

		/* SHOW-FAILEDCONNECTS:
		 * This will send out a notice whenever a randomly looking user has been caught
		 * during connecting. This can be pretty noisy.
		 * Especially recommended to enable during the first few days you use this module.
		 */
		show-failedconnects yes;

		/* EXCEPT BLOCK (UnrealIRCd 6.0.4 and later):
		 * Don't do antirandom checks for these users.
		 */
		except {
			/* Exempt WEBIRC gateways because these frequently
			 * cause false positives. So the default is yes.
			 */
			webirc yes;

			/* Exempt LAN users */
			ip { 192.168.*; 127.*; }

			// Or by hostname:
			//mask { *.example.net; }

			/* You can also exempt security groups: */
			// security-group known-users;

			/* For all options, see https://www.unrealircd.org/docs/Mask_item */
		}

                /* EXCEPT-HOSTS (before UnrealIRCd 6.0.4):
                 * On older versions of UnrealIRCd you should use this instead:
                 */
                //except-hosts {
                //        mask "192.168.0.0/16";
                //        mask "127.0.0.0/8";
                //};
	}
}
set::hide-list

This allows you to specify which channels should be hidden from list. Right now it only supports one option: deny-channel. This will hide channels that the user cannot join due to deny channel { } restrictions:

set { hide-list { deny-channel; }; };

Note that secret channels (channel mode +s) are always hidden and IRCOps always override restrictions (if they have sufficient access).

set::max-unknown-connections-per-ip

UnrealIRCd limits the number of connections per IP that are in an "unknown" state, that is: connections that are in a handshake. This is a security setting and it defaults to 3.

Only in very rare circumstances this may need to be adjusted. For example if you have hundreds of users coming from the same IP. If you only need to exempt a specific IP range, then it is better to use a except ban { } block with type connect-flood, or similarly an /ELINE with type 'c'.

Example: set { max-unknown-connections-per-ip 3; };

set::handshake-delay

Syntax: set { handshake-delay 2; };

This defines the MINIMUM time it should take for a user to get connected (finish the initial handshake).

This can be very useful if you have blacklist blocks, so DNSBL checking can finish before allowing the user in.

The default is 2 seconds if you have any blacklist { } block. You could set it slightly higher if your DNSBL checking is slow but for most people the default should be perfectly fine. Values of 10 or more are not permitted.

If you don't have any blacklist { } blocks then the delay defaults to 0 seconds (no delay) since it would not be useful.

set::handshake-boot-delay

Syntax: set::handshake-boot-delay <timevalue>

This setting only exists in UnrealIRCd 6.1.1 and higher

This delays the processing of incoming clients the first <timevalue> seconds that a server is booted. It can be quite messy when clients are already connected and the server is linking in other servers and/or services. This setting can potentially avoid that mess, by giving some time for linking autoconnects to kick in, before clients are allowed in.

The <timevalue>, the numbers of seconds, needs to be between 0 and 15. It can't be too high because otherwise clients will abandon their connection attempts. And it shouldn't be too low to give your servers a chance to link.

The following incoming connections are exempt from this delay:

If you link your servers NOT on a serversonly port (and they are not on localhost either), then these server connections are delayed up to <this> value as well, which is not good. We recommend linking servers to a listener::options::serversonly port. This is considered good standard practice and is also used in the example conf and in all our linking tutorials.

Note that after the specified amount of seconds has passed after IRCd startup, clients are no longer delayed during connect by this setting. They may still be delayed by set::handshake-delay which is a different setting.

set::reject-message

This allows you to change the messages that are sent to a user when their connection is rejected. This shows the defaults: 

set {
   reject-message {
        password-mismatch "Password mismatch";
        too-many-connections "Too many connections from your IP";
        server-full "This server is full.";
        unauthorized "You are not authorized to connect to this server";
        kline "You are not welcome on this server. $bantype: $banreason. Email $klineaddr for more information.";
        gline "You are not welcome on this network. $bantype: $banreason. Email $glineaddr for more information.";
    };
};

The set::reject-message::password-mismatch message is sent when the user supplied a server password but it was not matching allow::password in the Allow block.

The set::reject-message::too-many-connections message is sent when allow::maxperip is hit in the Allow block.

The set::reject-message::server-full message is sent when class::maxclients is hit in the Class block.

The set::reject-message::unauthorized message is sent when the client is not matching any Allow block.

The set::reject-message::kline message is sent to the user when disconnecting them due to a KLINE or ZLINE. The set::reject-message::gline message is sent to the user upon GLINE or GZLINE. The message is only sent to the affected user and is not seen by other users or IRCOps. In both of these configuration items (::kline and ::gline) the following variables are available:

Variable Description Example
$bantype type of the ban (past tense) K-lined
$banreason reason of the ban (*LINE reason) Stop spamming users
$klineaddr set::kline-address [email protected]
$glineaddr set::gline-address (or, if not set, then set::kline-address) [email protected]
$ip IP address of the user 203.0.113.12
set::antimixedutf8

The antimixedutf8 module will detect and stop spam containing of characters of mixed "scripts", where (for example) some characters are in Latin script and other characters are in Cyrillic script.

Note that you need to load this module explicitly (it is not loaded by default). 

loadmodule "antimixedutf8";
set {
        antimixedutf8 {
                /* Take action at this 'score' (lower = more sensitive)
                 *
                 * A score of 2 or 3 will catch a lot but also
                 * catch innocent users who are not using a pure
                 * Latin script, such as Russian people who
                 * commonly use a mix of Latin and Cyrillic.
                 *
                 * A score of 8 is a safe default.
                 */
                score 8;

                /* Action to take, see:
                 * https://www.unrealircd.org/docs/Actions
                 */
                ban-action block;

                /* Block/kill/ban reason (sent to user) */
                ban-reason "Mixed character spam";

                /* Duration of ban (does not apply to block/kill) */
                ban-time 4h; // For other types
        }
}
set::authentication-prompt

This will ask users to type /AUTH user:pass if they need to authenticate, for example if the user matches a soft ban or require authentication { } block. Technically, it does this by simulating a SASL session to Services.

The module is loaded by default with the following default settings: 

loadmodule "authprompt";
set {
        authentication-prompt {
                /* Enabled or not? */
                enabled yes;

                message "The server requires clients from this IP address to authenticate with a registered nickname and password.";
                message "Please reconnect using SASL, or authenticate now by typing: /QUOTE AUTH nick:password";
                /* As you can see you can have multiple 'message' items.
                 * It may be useful to refer to a webpage for more
                 * information and/or where users can register their nick.
                 */

                fail-message "Authentication failed";
                /* Multiple fail-message lines are also supported */

                unconfirmed-message "You are trying to use an unconfirmed services account.";
                unconfirmed-message "This services account can only be used after it has been activated/confirmed.";
        };
};
// If you use the authprompt module then you may want to raise the
// timeout in which users must complete the handshake.
// By uncommenting the following, you can raise it from 30 to 60 seconds:
// set { handshake-timeout 60s; };
set::reputation

The reputation module provides reputation scores of users. This score can then be used by various modules to counter abuse.

The default settings are: 

set {
        reputation {
                /* The database file, this will be in the 'data' subdirectory */
                database "reputation.db";

                /* Requires UnrealIRCd 6.1.2 or higher:
                 * The score bump timer bumps the reputation score every 5min,
                 * however it ONLY does it for people who meet this criteria:
                 * - user needs to be in any channel with 3 or more members
                 */
                score-bump-timer-minimum-channel-members 3;
        }
}

You can adjust the set::reputation::score-bump-timer-minimum-channel-members to meet the typical use at your network. For example, if almost all of your users are joined to at least one channel with 5 or more members (4 other members plus you) then you can set this to 5. On the other hand, if it is very normal on your network that everyone is only in channels with 1 other person and hardly ever in a bigger channel, then you can set it to 2. Set it to 0 to also do score bumping for people who are not in any channel at all, this would be the behavior in UnrealIRCd 6.1.1.1 and earlier versions.

It is also possible to encrypt all data in the reputation database, to do so you have to create a secret { } block and then refer to that secret block. In this example we refer to a secret block called reputationdb: 

set {
        reputation {
                db-secret "reputationdb";
        }
}
set::tkldb

The tkldb module saves all TKLs (kline, gline, spamfilter, etc) to a database file so these are preserved accross server restarts.

The default settings are: 

set {
        tkldb {
                database "tkl.db"; /* this file will be in the 'data' subdirectory */
        }
}

It is also possible to encrypt all data in the database, to do so you have to create a secret { } block and then refer to that secret block. In this example we refer to a secret block called tkldb: 

set {
        tkldb {
                db-secret "tkldb";
        }
}
set::channeldb

The channeldb module saves all channel settings for channels that have mode +P ("permanent") set. For these channels it saves: channel creation time, topic, topic setter (name), topic timestamp, channel modes, channel list modes (+b/+e/+I lists). These are all stored in a database file so these are preserved across server restarts. You can also optionally store the channel history on disk too (if the channel is also +H).

The default settings are: 

set {
        channeldb {
                database "channel.db"; /* this file will be in the 'data' subdirectory */
        }
}

It is also possible to encrypt all data in the database, to do so you have to create a secret { } block and then refer to that secret block. In this example we refer to a secret block called channeldb: 

set {
        channeldb {
                db-secret "channeldb";
        }
}
set::connthrottle

The set::connthrottle settings are documented at the Connthrottle page.

set::broadcast-channel-messages

Syntax: set::broadcast-channel-messages [auto|always|never]

There are 3 possible settings:

  • always: always send all channel messages to all servers, regardless of whether they have channel members or not.
  • auto (the default): don't send messages to servers if they have no channel members, except for when the channel mode +H (history) is set. In case of +H we broadcast all messages to all servers.
  • never: never broadcast channel messages to all servers, only send to servers that have channel members.
set::history

Configure settings related to Channel history.

The set::history::channel::playback-on-join block describes the behavior when a user joins a +H channel. The set::history::channel::max-storage-per-channel block sets limits on what can be set via /MODE #chan +H. Note that these are separate things: only a few lines of history are shown on-join, many more lines can be fetched via the HISTORY command (and possibly other commands in the future).

This shows the default settings: 

set {
        history {
                channel {
                        /* How many lines to playback on join? */
                        playback-on-join {
                                lines 15;
                                time 1d;
                        }
                        /* How much history to keep. These are the
                         * upper maximums for channel mode +H lines:time
                         */
                        max-storage-per-channel {
                                /* +r channels have larger maximums: */
                                registered {
                                        lines 5000;
                                        time 31d;
                                }
                                /* -r channels have less: */
                                unregistered {
                                        lines 200;
                                        time 31d;
                                }
                        }
                }
        }
}
Persistent channel history

You can also store channel history encrypted on disk. This means channel history is preserved across IRCd restarts. UnrealIRCd will only store channel history for channels that have both channel mode +H and +P set.

To enable this you need to create a Secret block like this: 

/* This is only a simple example with passwords stored directly in the
 * configuration file.
 * To get better security, read https://www.unrealircd.org/docs/Secret_block
 * on alternative ways so you don't store passwords directly in the config.
 */
secret historydb {
        password "somepassword";
}

And then refer to that secret block which we named historydb: 

set {
        history {
                channel {
                        persist yes;
                        db-secret "historydb";
                }
        }
}

UnrealIRCd has the following goals for storing channel history on disk:

  • All data within the .db's is encrypted
  • We use a well-known encryption library, a good cipher and KDF, see Dev:UnrealDB for in-depth technical details.
  • By default the log databases are stored in the data/history/ directory
  • All .db files are cryptographically hashed so a third party can't tell which .db file belongs to which channel
  • A 'master.db' file is present too, to achieve the above in a consistent and safe manner. Don't delete this file.
  • Be sure to look at Secret block to see the various ways to store the key (password) and pick one acceptable to your environment
set::part-instead-of-quit-on-comment-change

Syntax: set::part-instead-of-quit-on-comment-change [yes|no]

When a QUIT message is changed due to channel restrictions, such as stripping color or censoring a word, we normally change the QUIT message. This has an effect on ALL channels, not just the one that imposed the restrictions (eg: the QUIT reason loses color or is censored for all). We feel this is the best tradeoff and this is the default setting of no.

You can also set this setting to yes. That will change the QUIT into a PART when the QUIT comment is changed. The channel(s) with the changed comment see the user PARTing, and on all other channels that do not have the restrictions (eg: are -S and -G) they will see the user QUITting with the original message.

set::webredir::url

Syntax: set::webredir::url 'http://example.org/'

When someone (accidentally) types irc.example.org in their web browser then UnrealIRCd can send a HTTP redirect back to, say, https://example.org/. Note that this is mostly a gimmick rather than something terribly useful.

For this to work, the IRC server needs to listen on ports 443 and 80 (more information about that here!). However, nowadays more and more IRC servers listen on port 443 so users can bypass firewall restrictions that they may encounter on the regular ports 6667/6697 (and also because of websockets).

Usage example (only do this after reading the above):

Important: You must use single-quotes like 'this' instead of "this" when specifying a url. 

loadmodule "webredir";
set { webredir { url 'https://...'; } }
set::automatic-ban-target

Syntax: set::automatic-ban-target [host|userhost|..]

The IRCd may add automatic bans, for example due to a blacklist hit, a spamfilter hit, or because of antirandom or antimixedutf8. When it does, on what should the ban be placed:

  • ip: place the ban on the IP address (eg: *@172.16.8.4)
  • userip: include the ident portion in the mask (eg: [email protected])
  • host: place the ban on the hostname (eg: *@something.example.org), fallback to ip.
  • userhost: include the ident portion in the mask (eg: [email protected]), fallback to user@ip.
  • account: ban by services account name (eg: ~a:accountname)
  • certfp: ban by certificate fingerprint (eg: ~S:00112233etc)

The last two possibilities are only useful if you have a very special setup, it does not apply to most users. The most common choices are ip (the default), host, or userip (if you trust idents).

Note: if the ban is of type ZLINE or GZLINE then it will always resort to ip since all other options don't work. The reason for that is that UnrealIRCd closes the connection immediately in case of a (G)ZLINE. Therefore it only knows the IP information as it has not done a DNS lookup, ident lookup, TLS handshake, etc. In fact, that is what makes a ZLINE different than a KLINE (and a GZLINE from a GLINE).

set::manual-ban-target

Syntax: set::manual-ban-target [host|userhost|..]

Similar to automatic-ban-target, but this is used if target a nick in a *LINE, for example if you type /KLINE nick. When that happens, on what should the ban be placed:

  • ip: place the ban on the IP address (eg: *@172.16.8.4)
  • userip: include the ident portion in the mask (eg: [email protected])
  • host: place the ban on the hostname (eg: *@something.example.org)
  • userhost: include the ident portion in the mask (eg: [email protected])
  • account: ban by services account name (eg: ~a:accountname)
  • certfp: ban by certificate fingerprint (eg: ~S:00112233etc)

he last two possibilities are only useful if you have a very special setup, it does not apply to most users. The most common choices are ip, host (the default), or userhost (if you trust idents).

Note: if the ban is of type ZLINE or GZLINE then it will always resort to ip since all other options don't work. The reason for that is that UnrealIRCd closes the connection immediately in case of a (G)ZLINE. Therefore it only knows the IP information as it has not done a DNS lookup, ident lookup, TLS handshake, etc. In fact, that is what makes a ZLINE different than a KLINE (and a GZLINE from a GLINE).

set::hide-idle-time

Syntax: set::hide-idle-time::policy [never | always | usermode | oper-usermode ];

This is a privacy setting which configures the visibility of "idle time" of users:

  • never: never hide idle time, the idle time is always shown to everyone
  • always: always hide idle time
  • usermode: show idle time, but hide idle time if user mode +I is set. This setting allows all users to set this mode +I.
  • oper-usermode: same as previous, but only IRCOps can set the +I user mode to hide idle time. This is the default setting.

The default setting is: 

set { hide-idle-time { policy oper-usermode; } }

In all cases, IRCOps can still see idle time of users.

Note that even if you are allowed to see idle time, /WHOIS Nick will never show idle time for users on another server. This is a technical limitation (the idle time is not communicated actively across servers). If you want to see the idle time of a remote user you need to double whois: /WHOIS Nick Nick. Some clients do the latter by default in popups.

set::server-linking

This block configures the timeouts for outgoing servers and the linking strategy for link { } blocks with autoconnect set.

These are the defaults: 

set {
        server-linking {
                autoconnect-strategy sequential;
                connect-timeout 10s;
                handshake-timeout 20s;
        }
}

set::server-linking::autoconnect-strategy has three options:

  • parallel: connect to all link { } blocks in parallel
  • sequential: try to connect to the first link block, then to the 2nd, then to the 3rd, then back to the 1st, etc.. (this is the default)
  • sequential-fallback: similar to sequential but after a successful connection, we will restart from the beginning of the link blocks again. Can be useful for leafs.

set::server-linking::connect-timeout specifies the maximum time to wait for the outgoing connect() or TLS_connect() call to succeed. The default is 10 seconds and this should be sufficient. If you are on a high-latency/low-bandwidth satellite connection then you could raise this. Otherwise we recommend keeping it at 10.

set::server-linking::handshake-timeout specifies the maximum time to wait for the server handshake to succeed, that is: to receive the "SERVER" command. This is usually received in the first few kilobytes of data, so should be relatively soon. The default is 20 seconds here, which should be plenty for everyone.

set::whois-details

Note: this setting is only available in UnrealIRCd 6

This allows you to configure which WHOIS information should be shown to who (and in what detail).

For each item there are 3 user groups that you can configure:

  • everyone: all users
  • self: if you are /WHOIS'ing yourself
  • oper: IRC Operators

Then the possible settings for each item are:

  • none: information is not shown
  • full: all information is shown
  • limited: only a limited amount of information is shown. This is only available for a few items:
    • for item channels: full will also show hidden channels (+s), limited will not (normally used for normal users)
    • for item oper: full will show the operlogin and operclass, limited will leave these details out
    • for item secure: full will show the TLS version and cipher in use, limited will leave these details out
    • for item idle: full will show the idle time, limited means it depends on the +I user mode and the set::hide-idle-time setting.

The default settings are: 

set {
        whois-details {
                basic           { everyone full; }
                modes           { everyone none;        self full;      oper full; }
                realhost        { everyone none;        self full;      oper full; }
                registered-nick { everyone full; }
                channels        { everyone limited;     self full;      oper full; }
                server          { everyone full; }
                away            { everyone full; }
                oper            { everyone limited;     self full;      oper full; }
                secure          { everyone limited;     self full;      oper full; }
                bot             { everyone full; }
                services        { everyone full; }
                security-groups { everyone none;        self none;      oper full; }
                reputation      { everyone none;        self none;      oper full; }
                geo             { everyone none;        self none;      oper full; }
                asn             { everyone none;        self none;      oper full; }
                certfp          { everyone full; }
                shunned         { everyone none;        self none;      oper full; }
                account         { everyone full; }
                swhois          { everyone full; }
                idle            { everyone limited;     self full;      oper full; }
        }
}
set::server-notice-colors

This setting only exists in UnrealIRCd 6

Enable or disable colors in server notices (to snomasks). The default is set { server-notice-colors yes; }. You can change it to no if you don't want these colors.

This sets the (default) setting for all IRCOps on this server. You can tweak individual IRCOp settings through the server-notice-colors setting in the Oper block.

set::server-notice-show-event

This setting only exists in UnrealIRCd 6.0.2 or newer

Enable or disable showing of the subsystem.event (eg: connect.LOCAL_CLIENT_CONNECT) in log messages on IRC. The default is set { server-notice-show-event yes; }. You can change it to no if you don't want this.

This sets the (default) setting for all IRCOps on this server. You can tweak individual IRCOp settings through the server-notice-show-event setting in the Oper block.

set::staff-file

Defines the location of the file that will be shown to users when using the /STAFF command. 

set { staff-file "network.staff"; }

Or if you want to use remote files: 

set { staff-file "https://example.org/staff.txt"; }
set::geoip-classic

See GeoIP.

set::geoip-csv

See GeoIP.

set::geoip-maxmind

See GeoIP.

set::limit-svscmds

Syntax: set::limit-svscmds [ulines|servers]

Certain commands in the server protocol used to be for services only, these are commands like SVSJOIN and SVSNICK. However, now that we have JSON-RPC these commands may also be used by the JSON-RPC API, so blocking them from non-services-servers is problematic.

The old implicit default (before this setting was introduced) was ulines, which say only servers in the ULines block may use these commands. The new default is servers which allows all servers to use the SVS* commands, which is needed if at least 1 server on the network provides JSON-RPC.

We recommend to stick to the default value of servers. But, if you don't use JSON-RPC, and for some reason would like to have the old restriction, then you can change it to ulines if you really want.

set::high-connect-rate

Syntax: set::high-connect-rate <value>

This is all explained in FAQ: High connection rate detected.

This allows tweaking that setting, the value is in connects per second. The default is 1000. Use special value 0 to never have high connection rate kick in.

set::blacklist

The set::blacklist block allows finetuning rechecks:

set::blacklist::recheck-time

After a user is connected, we will keep checking DNS blacklists regularly to see if the user has been blacklisted. This way a user that is blacklisted after connect will still be killed/*lined from the network.

By default we:

  • Do a first quick check after 2 minutes
  • Then every 15 minutes

The default settings are: 

set {
    blacklist {
        recheck-time-first 2m;
        recheck-time 15m;
    }
}

If you want to DISABLE rechecks then you can use: 

set { blacklist { recheck-time never; } }

Or, you can disable rechecks individually per blacklist via blacklist::recheck.

set::blacklist::recheck-time-first

See previous item (above).

set::best-practices

UnrealIRCd 6.1.2 and higher will give (security) tips on best practices. It is usually a good idea to follow this advice, but you may not be interested in them or find them a nuisance if you are running a small test network or for other reasons. You can turn the tips off via settings in this block. The current default for everything is yes and you can change it to no if you want.

Here is the current block with all default settings: 

set {
    best-practices {
        /* Warn when an oper::password is plaintext in the config (not hashed).
         * At a later time it may also warn about plaintext passwords elsewhere.
         */
        hashed-passwords yes;
    }
}
Retrieved from "https://www.unrealircd.org/docwiki/index.php?title=Set_block&oldid=14221"