Install default maxperip/connect-flood exception for IRC platforms
that are so big that they are known to trip default maxperip restrictions
(per IPv4 IP or per IPv6 /64: 3 local users, 4 network-wide users)
on dozens of networks and that publish a stable list of IP ranges.
Currently only IRCCloud qualifies for this.
IRCCloud is in example conf since May 2023 (commit 82dbc4a297) as:
except ban { mask *.irccloud.com; type { maxperip; connect-flood; } }.
Unfortunately DNS sometimes fails to resolve. We have seen this happen
during an outage or server restart. People then mass-connect, but DNS
is not fully working (yet), leading to unresolved hostnames.
Recent stricter maxperip treatment for /64 IPv6 and the new /56, /48
and /32 restrictions in connthrottle make this problem worse. Without
these IP exceptions it would cause unwanted rejections.
If you don't want this, use: set { known-cloud-services no; }
(And then presumably you also don't want the except ban block
that example conf has been shipping since 2023)
(connect-flood). Those users are exempt and not counted towards new users.
And the new ipv6-unknown-users-limit in connthrottle (which has nothing
do with rates, but counts, similar to maxperip, but only on unknown-users)
now checks tkl type 'm' (maxperip). Those are counted as "except unknowns".
This is more of what the admin would expect.
was stated in docs at https://www.unrealircd.org/docs/Connthrottle but
if this item was not there then the default was actually zero (0).
Now, that isn't too common, since we ship with example.conf with the
connthrottle block as shown there, so lots of users have the proper
default, but just in case someone hand-writes or removed that connthrottle
settings block ("because they are the default)"... :)
And ship with these by default (no need to copy this set block):
set {
log-throttle {
CONNTHROTTLE_IPV6_LIMIT 100:60;
MAXPERIP_LIMIT 100:60;
};
};
You can do the same for other events, or even override existing ones,
and use the special value "unlimited" to turn default set ratelimits off:
set {
log-throttle {
CONNTHROTTLE_IPV6_LIMIT 50:60;
MAXPERIP_LIMIT unlimited;
};
};
Suggested in 2020 at https://bugs.unrealircd.org/view.php?id=5523
(and keeping it simple)
When a client is rejected by maxperip (not new) or connthrottle
ipv6-unknown-users-limit (that one is new), a notice to +s +x will be sent.
maxperip ipv4 example:
*** Client testuser4 with IP 1.2.3.4 rejected: maxperip limit exceeded (4 global, max 3)
maxperip ipv6 with /64 example:
*** Client testuser4 with IP 2001:dbe:0:0:0:0:0:4 rejected: maxperip limit exceeded for 2001:dbe::/64 (4 local, max 3)
connthrottle example where /56 limit is exceeded:
*** Client testuser5 with IP 2001:db8:cafe:abcd:0:0:0:5 rejected:
connthrottle ipv6-unknown-users-limit (cidr-56, max 4) exceeded for
2001:db8:cafe::/56 (5 unknown / 0 excepted / 0 known)
Oh and this commit also fixes a typo in existing CONNTHROTTLE events,
which previously were CONNTHROTLE (a missing T).
Changed "Too many connections from your IP" to have "[maxperip]" at the end.
Also create new setting and swap it with existing-one-during-development.
Long story short, we now have 3 different messages for these limits:
set::reject-message::too-many-connections
"Too many connections from your IP [maxperip]"
set::reject-message::too-many-connections-ipv6-range
"Too many connections from your IPv6 range ($prefix_addr/$prefix_len) [maxperip]"
set::reject-message::too-many-new-connections-ipv6-range
"Too many new connections from this IPv6 range ($prefix_addr/$prefix_len) [connthrottle]"
So we explicitly mention whether it is maxperip or connthrottle limiting the
user, that should provide enough clue to the IRCOp if the user pastes the
message to them.
connect-flood and maxperip module. This so they actually take
set::default-ipv6-clone-mask into account.
This also changes the maxperip module to a more simple method of
just freeing all entries and rebuilding the hash table on load.
That's necessary since now set::default-ipv6-clone-mask can change.
We previously upgraded to 1.0.21 and then downgraded to 1.0.20.
Benefit of 1.0.22 is that they also claim to have fixed a warning flood
i am getting with clang 22.
uses their pkg.m4 which made pkg-config a hard requirement.
Such a hard requirement is probably fine later, but.. i don't want
to suddenly require that of users during UnrealIRCd 6 series.
The OOB write did not happen on file-backed downloads, such as remote
includes. It only happened for memory-backed requests, which are only
these 4 in standard UnrealIRCd: centralblocklist, central spam report,
other spamreport blocks (eg to dronebl) and the log block with
destination webhook. All those 4 cases are very likely to be trusted
web servers, given the nature of the data you are sending to them.
The fix was to extend the size fields everywhere to 64 bits. It was
applied to both URL backends: url_unreal.c and url_curl.c.
The new API feature is a 'max_size' in OutgoingWebRequest, which
defaults to 1MB. This is only used for memory-backed responses,
so not for real file downloads. This fixes not only the reported
bug but also the case where a rogue webserver was unbounded in
terms of what response it could send back, potentially filling
up gigabytes of server memory.
Reported by Link420.
This does two things:
* We now only compile src/openssl_hostname_validation.c on
really old OpenSSL's. This was already unused/dead code
for most OpenSSL's but we always compiled it in until now.
* Added 'const' to please OpenSSL 4.0.0 while not breaking
OpenSSL 1.0.x. And yeah i'm happy to drop OpenSSL 1.0.x
support real soon... but not this month yet.
The "not setting +F" stuff didn't work, as due to netmerge - which
can even happen without a split when joining clients on both sides -
this would revert to +F normal basically.
So we just explicitly exempt in the join and msg code.
All this is for unrealircd-tests.
This XML code is only used for DroneBL submission with no user-
controlled variables (except $ip). Still, silly mistake to make
and who knows what other XML stuff will happen in the future.
Version 1.0.21 which we shipped with 6.2.3 has this bug, reported
by PhotoJim at https://bugs.unrealircd.org/view.php?id=6615.
And yes, libsodium also has this weird -stable thing, which does
have the fix, but that's basically just a snapshot of their git
version, it's a .tar.gz that gets updated every X time and it does
not have a GPG signature, while I have the policy nowadays to
verify GPG signatures for libraries we ship. So I am option to just
downgrade a version, for now, which is fine since we shipped with
1.0.20 for quite some time until recently.
There is no hard cap on batch reference length, so we had to make one up.
It is now a clear #define MAXBATCHREFLEN 48, which should be plenty.
No sane client is going to use like a 64 byte batch reference :D
So we did use 48, but we also accidentally used BATCHLEN at another
place. BATCHLEN is 22 and refers to how many bytes we generate, so
that is not appropritate.
Thanks to Valware for spotting this.
This wasn't done before, because optimizing stuff can always introduce
nice new issues. But is kinda necessary now since the previous way was
very inefficient. This now builds all the necessary buffers for multiline
clients and for non-multiline clients. And then iterates through both
types of clients, sending what they need. Instead of doing it the other
way around.
I had the dillema to either expose the linecache API and have everything
in multiline.c. Or, i do not expose linecache, and we do everything in
send.c. The downside of the latter is that if there is mistake then we
can't simply reload (or unload) the module to solve it. So, I have chosen
to expose the linecache API (sure, less clean) since that leaves us with
options if we screw up, plus it means everything related to multiline
sending is nicely in multiline.c, which is i guess just as good as an
argument as well ;)
Add a little fake lag based on history result: 400ms for 50 lines
under normal conditions where 50 lines = 50 lines. But this can go
up to 5000ms for worst-case amplification attacks where requesting
50 lines actually returns 50*15=750 lines when each line is a multiline
with max-lines, which gets you close to 350k+. This would only happen
if someone on the channel is doing evil stuff (with presumably consent
of the ops).
Also guard against hiting max sendq. If we are too close, then we
reject the CHATHISTORY request rather than quiting with "Max SendQ
exceeded". This protects against an attack where someone would be
tricked into joining a channel with amplified history (as explained
in previous paragraph), their client would do an automatic CHATHISTORY
request and then the victim would exceed max sendq and thus be killed.
And yes, this and maaaaany other multiline + history interactions
and many "buts" and security/flood concerns are why this implemtnation
took (and still takes) a lot of hours to get right :D.
For +H we now temporarily allow overshooting. This only matters for low limits.
Multiline batches are atomic so we have to choose to keep them as a whole
or remove the complete batch. So if +H 5:1h and the last message was a 15-line
multiline event, what do we do? We allow temporary overshooting to store the
15 lines. As said, the alternative would be to store 0 lines which would be
worse in terms of functionality, and the small overshoot is defensible.
For higher limits (where the +H line limit is bigger than multiline max-lines),
we always stay under the +H limit. Eg if all history in a channel consists
of 15 line multiline events and we have +H 100 then we will store 90, not 105.
It's only for +H linelimit < max-lines that this matters, because there the
zero-lines consequence sucks too much ;)
Bram Matthys