The spamfilter::action stop ill prevent processing other spamfilters.
This would normally be a bit unusual, and potentially dangerous when you
do exclude things this way, but can be useful in some circumstances.
Stopping only affects the same type of spamfilters (general or central
spamfilters), so they don't interfere.
The tkldb write DB bug had to do with that it was processing
central spamfilters, which should be skipped just like config
based spamfilters were already skipped.
you can now configure to hide the message content in spamfilter hit
messages. Generally it is very useful to see if a spamfilter hit is
correct or not, so the default is 'always', but it also has privacy
implications so there is now this option to disable it.
Suggested by alice, quite a while ago.
https://www.unrealircd.org/docs/Set_block#set::spamfilter::show-message-content-on-hit
Also as mentioned there:
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'), the warn message will not be sent as there is no need to
inform the user in such a case.
to limit actions to limit-ban-action as the highest, and limit
ban times to limit-ban-time the highest, see
https://www.unrealircd.org/docs/Central_Spamfilter
This also changes highest_spamfilter_action() to highest_ban_action().
* This means we always run spamfilters, even if users are exempts
* This way we can gather hits for exempted users on individual
spamfilter entries, and possibly detect false positives
(which relies on the assumption that those users are innocent)
* The hit counters are shown in in RPL_STATSSPAMF and also
exposed via the JSON-RCP API.
* This commit also adds set::central-spamfilter::except but more
on that later since i still want to set a default for that in
a future commit.
* This also changes take_action() to take flags and adds the
option TAKE_ACTION_SIMULATE_USER_ACTION which i intended to
use but didn't in the end... not sure if i should keep it :D
This uses the RPC2 API. Tested with staging.
Note that there are likely some bugs here or there, like memory leaks,
but the functionality is there.
Also still need to implement various stuff, including spamreport::rate-limit
`PROTOCTL BIGLINES` is set. This will allow us to do things more
efficiently and possibly raise some other limits in the future.
This 16k is the size of the complete line, including sender,
message tags, content and \r\n. Also, in server-to-server traffic
we now allow 30 parameters (MAXPARA*2).
The original input size limits for non-servers remain the same: the
complete line can be 4k+512, with the non-mtag portion limit set
at 512 bytes (including \r\n), and MAXPARA is still 15 as well.
* I chose 16k because I don't want to first raise it to like 8k
and then realize later that 16k would be better and raise it again.
* To receive BIGLINES in a command, you need to `CommandAdd()` with
flags `CMD_BIGLINES`, without it you still get regular 512 max.
This is so, because a lot of the code does not expect longer than
512 bytes lines or in parameters, so we can gradually change that
(where needed).
depending on what we get from the proxy, so it can be used later
in the websocket module for setting the user secure or not
(the latter similar to what k4be already did in the old code).
It is now possible to override some set settings per-security group by
having a set block with a name, like `set unknown-users { }`
* You could use this to set more limitations for unknown-users:
```
set unknown-users {
max-channels-per-user 5;
static-quit "Quit";
static-part yes;
}
```
* Or to set higher values (higher than the normal set block)
for trusted users:
```
security-group trusted-bots {
account { BotOne; BotTwo; }
}
set trusted-bots {
max-channels-per-user 25;
}
```
* Currently the following settings can be used in a set xxx { } block:
set::auto-join, set::modes-on-connect, set::restrict-usermodes,
set::max-channels-per-user, set::static-quit, set::static-part.
the default set::max-channels-per-user (also called set::maxchannelsperuser).
This way you can give known-users a higher max-channels-per-user,
or even a special security group for trusted users (that you may
already have given a more lax flood setting and lower lag-penalty
etc. etc. so that fits in nicely)
And yeah this also:
* Makes it both in set and the anti-flood block accept both
maxchannelsperuser and max-channels-per-user.
* Removes old MAXCHANNELS= in 005, as we already have CHANLIMIT=
This does not:
* Re-announce the 005 CHANLIMIT= if someone transitions from a security
group with a different max-channels-per-user. We don't do that for
IRCOps either, and I think no IRCd does that actually...
To be honest i wonder if sending the limit in 005 is useful at all,
do client really track this and limit their GUI based on it?? Doubt it!
This so you can use throttling exceptions (eg in ELINE) on hostnames.
That is, the above is during normal circumstances. Similar to previous
commit we will turn this feature of during high connection rates.
That is a TODO item.
This is the start of "be more friendly to TLS users with disconnect
error messages" from https://bugs.unrealircd.org/view.php?id=5532
As that bug explains:
Consider doing the SSL/TLS handshake even for throttling errors and such
when the (reject) connection rate is below a certain amount per second. If
it is higher than a certain rate, then fall back to the original behavior to
reject the user instantly without handshake or looking at any data.
Rationale: the current/original behavior is there so the ircd can handle
floods, both in terms of traffic and in terms of CPU usage (the SSL/TLS
handshake is quite costly after all). The downside of the current behavior
is that TLS users don't see the error message, usually. This feature
request tries to find a middle ground.
Still a TODO item:
* We don't detect high rates yet, so we only do this new behavior atm
and not yet the old behavior during high connection rates.
* Verify that error messages/behavior hasn't changed (too) much,
like the throttling and the banning disconnect messages.
When sending to channel members this will cache full IRC protocol
lines, including message tags and \r\n, for similar clients.
This avoid the need for many mtags_to_string() calls and also
entire parts of sendbuf_to_one() can be skipped as well.
The "Similar clients" cache entries are defined as clients that:
1) Are of the same type: normal local client, ircop local client
or remote client.
2) Have the same CAPs set, that is: we only look at CAPs that actually
have anything to do with message tags ('clicaps_affecting_mtag')
3) Optionally there can be an explicit line_opts. It is not used yet
but could be used when there are different type of lines sent
depending on other criteria, such as chanop status or something
else that doesn't fit in #1 and #2.
(so listen::file). This way you can override the IP address that users come
online with when they use the socket (default was and still is `127.0.0.1`).
Add a new guide https://www.unrealircd.org/docs/Running_Tor_hidden_service_with_UnrealIRCd
which uses the new listen::spoof-ip and optionally requires a services account.
for the add, like: nick-change, quit, server terminating. Add logon time.
I also think i will move from user.get_whowas to a whowas.XXX since the
returned object is not a user object and getting more different each commit :D.
This is an integer which decides the amount of details in the response object.
For the channel.* calls the object_detail_level is one of:
0: only return the channel name, nothing else
1: basic channel information only
2: this adds bans, ban_exemptions, invite_exceptions
3: also show members, but only level/name/id
4: also show members, level/name/id/hostname/ip/details/geoip
5: also show members, level and full user details like user.get
When no object_detail_level is specified, the following defaults are used:
For channel.list the default is 1 (matches current 6.0.6 behavior)
For channel.get the default is 3 (matches current 6.0.6 behavior)
Using channel.list with object_detail_level=5 is forbidden because
it would cause way too much output (and processing time).
for OpenSSL 1.0.2 anymore, 1.0.2 will use the fallback version.
This changes the include file.
(OpenSSL 1.0.2 is out of support since Jan 1 2020 so one may wonder
why care at all, but i'm trying not to break that during minor
UnrealIRCd releases)
This also adds the MAXLINELENGTH define which is set to 4K+4K+512,
it can be used when you are dealing with complete lines (quite rare
in the code, mostly in socket code and labeled response).
And now also #define READBUFSIZE MAXLINELENGTH
but it is used beyond read buffers, als in write buffers of course.
Reported in https://bugs.unrealircd.org/view.php?id=6100
Actually this only works if you have a:
blacklist-module geoip_classic;
in your conf and that conf is read before modules.default.conf
This is true if you have that blacklist-module line in your
unrealircd.conf, so should cover most cases.
Reported by 9pfs in https://bugs.unrealircd.org/view.php?id=6248
This is completely untested (other than ./unrealircd start), so
feedback from people who actually use crule like in deny link { }
is very much welcomed.
Thanks to Noisytoot for https://github.com/unrealircd/unrealircd/pull/227
who suggested displaying account and provided a partial patch, and
armyn in https://bugs.unrealircd.org/view.php?id=6153 suggesting IP.
I chose to use the existing RPL_WHOIS* numerics that we also use for
returning WHOIS data. We already use RPL_WHOISSERVER in WHOWAS for
ages and the use of it is mentioned in RFC1459, so seems like that
was the idea right from the beginning of times. The only change I did
was from "is" to "was" in like "was logged in" and "was connecting from"
in the text of the numerics.
remote server does not have the JSON-RPC module(s) loaded.
Internally this uses the "rrpc" moddata property that each server will
now set on themselves if the rpc/rpc module is loaded.
Actually I am going to make this more verbose and better later...
(Required RPC modules to be loaded on the remote server, tho)
This adds support for remote async RPC requests that take a little longer,
in such a case we don't call free_client() upon return of rpc_call().
Bram Matthys