## Why An Argon2 verify is **~8.9 ms of frozen world per login attempt** — more than half a 16 ms frame. Failed attempts cost exactly the same as successful ones, by design, so a credential-stuffing flood is a full-cost stall per packet without needing valid credentials. `SetPassword` derives a hash too, so `[password`, the admin gump and account creation each pay the same. ## What the measurement says Off-loading does not delete the cost, it relocates it. Three things stay on the loop: | Component | Measured | |---|---:| | Inline verify (today) | **8.92 ms** | | Dispatch to the worker | 210 ns | | Drain the continuation off `LoopContext` | 13 ns | | Loop's own work slowed by shared-L3 eviction | **0.05 – 5.44 ms** | Net gain **3.5 – 8.9 ms** of on-loop time per login. Harness in `ModernUO-Benchmarks` (`Benchmarks/Argon2OffLoop/`): it models the loop as a dependent-load pointer chase swept across working-set sizes, which is an upper bound on cache-latency sensitivity, and copies `EventLoopContext` so the hand-off cost is the real one. Two results shaped the design: - **The contention tax peaks in the middle of the working-set range**, not at the top — 5.44 ms at 8 MiB (a quarter of this chip's L3), but 0.76 ms at 30 MiB and 0.10 ms at 256 KiB. A tiny hot set has nothing in L3 to lose; a huge one is already DRAM-bound. - **Per-login tax falls as concurrency rises** (5.44 → 2.56 → 1.60 ms at 1/2/4 hashers) while *total* loop damage rises. Contention is shared, not additive, so a login rush is not the disaster case — a single login is. ## Why exactly one worker It is load-bearing three times over, which is also why it must not quietly become a pool: - **Cost bound.** Off-loop loses to inline only if a hash steals ~82% of the loop's throughput. One hasher contending for one core leaves the loop ~50%. **A single background hasher cannot cost the loop more than the inline verify under any scheduling regime**, which is what lets the measurement hold on hardware we cannot inspect — AMD, VPS, oversubscribed VM. Four hashers drop the loop to ~20% and break it. - **Memory.** Exactly one hashing arena is live at a time whatever the login volume. - **Ordering.** Writes apply in dispatch order *only* because a single thread drains FIFO. A second worker would need ordering reintroduced; `WritesApplyInDispatchOrder` fails if that happens. Throughput is ~110 verifies/sec. Only loop time matters, not login latency, so head-of-line blocking during a rush costs nothing. ## Making every protection safe off-thread The worker was initially Argon2-only. That was the right call for the wrong reason — it was blamed on Argon2's salt RNG, which is a stateless syscall wrapper and was never a problem. The real blockers were elsewhere, and both are fixed at the source: | Protection | Was | Now | |---|---|---| | MD5/SHA1/SHA2 | shared `HashAlgorithm.ComputeHash`, which carries the running digest across `HashCore`/`HashFinal` through process-wide singletons | static `HashData` into a `stackalloc` span — no state, no allocation, identical bytes | | PBKDF2 | `Utility.RandomMinMax` → shared `System.Random`, thread-unsafe *and* game state | `RandomNumberGenerator.GetInt32`, matching the salt beside it | | Argon2 | already safe (`Verify` is static + stackalloc) | unchanged, singleton reused | Literal digests are pinned in a test **before** the change and still pass after it. These are compared as strings against every account database, so any casing or encoding drift would lock out every SHA and MD5 account at once. With all three safe, the worker no longer knows which algorithm it runs and the dispatch conditions collapse to "is off-loop available". ## Correctness - **Phrase derivation** moves to `AccountSecurity.DerivePhrase`, so verification (stored algorithm's rule) and rehash (target algorithm's rule) cannot disagree. Deriving with the wrong one is the shape of the lockout fixed in #2562. - **Liveness** is checked at dequeue *and* at apply — a connection can drop while queued or while the result sits in the loop queue. A job with no connection attached, such as an admin password change, runs regardless. - **Queue overflow rejects** a login rather than verifying inline; steering work back onto the loop is what a flood wants. A password change instead falls back to hashing inline, because unlike a login it must not be dropped. - **Shutdown and crash** both just stop the thread, and pending jobs are dropped. No save is initiated once shutdown begins — saving is the operator's choice up front, via the admin gump's save/no-save variants, and `WaitForWriteCompletion` honours one already in flight — so a write applied during teardown would reach no disk. The crash path needs its own subscription because `HandleClosed` skips `InvokeShutdown` when crashed. ## Bounding `MaxPending` is 4096 — a backstop, not a flood defense. `SentFirstPacket` holds a connection to one pending verify and the engine caps connections at 4096, so the queue is already bounded by construction and this can only trip if that invariant breaks. A cap low enough to blunt an attack would reject real players first; during a mass reconnect they *are* the queue. Flood defense belongs at the connection layer. The real DoS improvement is elsewhere: today every attempt stalls the world, and after this a flood occupies one core while the loop keeps ticking. ## Gate Release builds on 4+ cores. Below that there is no spare core to move work to, so off-loading buys nothing by construction; `DEBUG` is excluded because dev boxes and test shards have few logins. Both modes call the same code — the gate only chooses where it runs. ## Engine change One property, `AccountLoginEventArgs.Deferred`, so a subscriber can say "no verdict yet". `EventSink.AccountLogin` is `Action<...>` with no continuation, and the packet handler replies in the same call. Approved separately since it touches `Projects/Server/`. ## Docs `dev-docs/threading-model.md` and the threading skill gain a vetted-workers section. The forbidden-patterns table bans `new Thread`, `ConcurrentQueue<T>`, `Interlocked` and `volatile` in `UOContent`, and its exceptions covered only `Projects/Server/` — the existing Advanced Search fan-out already sat outside it. The new section leads with proving the need (measure on-loop time, not wall-clock; gate on core count; record the measurement), keeps game logic on the loop via chunking, and documents the hand-off protocol in both directions. ## Testing 698 UOContent tests, 810 Server tests, Release build clean. Covered: verify and rehash outcomes, phrase rules for SHA1/SHA2 vs Argon2, stored-format stability for MD5/SHA1/SHA2, jobs with no connection attached, and dispatch ordering through the real queue. The liveness and ordering guards are mutation-verified.
214 lines
7 KiB
C#
214 lines
7 KiB
C#
/*************************************************************************
|
|
* ModernUO *
|
|
* Copyright 2019-2026 - ModernUO Development Team *
|
|
* Email: hi@modernuo.com *
|
|
* File: AutoDenylist.cs *
|
|
* *
|
|
* This program is free software: you can redistribute it and/or modify *
|
|
* it under the terms of the GNU General Public License as published by *
|
|
* the Free Software Foundation, either version 3 of the License, or *
|
|
* (at your option) any later version. *
|
|
* *
|
|
* You should have received a copy of the GNU General Public License *
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>. *
|
|
*************************************************************************/
|
|
|
|
using System;
|
|
using System.Collections.Generic;
|
|
using System.Net;
|
|
using System.Threading;
|
|
using Server.Logging;
|
|
using Server.Network.Bans;
|
|
|
|
namespace Server.Network;
|
|
|
|
/// <summary>
|
|
/// A short-lived, in-memory denylist of addresses the shard itself just caught misbehaving.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// The local half of promotion. Contributing to CrowdSec only helps once an OS bouncer reacts; until then
|
|
/// every reconnect costs a socket, a buffer and a <c>NetState</c> slot — and the verdicts that matter most
|
|
/// are reachable only after reading bytes, like a zero seed. It is also the whole defense on a shard running
|
|
/// no bouncer, which is the default. Not persisted, by design: a holding pen that survives restarts is a ban
|
|
/// without a ban's review. Only <see cref="BanReasons.IsBehavioral"/> verdicts are held.
|
|
/// </remarks>
|
|
public static class AutoDenylist
|
|
{
|
|
private static readonly ILogger logger = LogFactory.GetLogger(typeof(AutoDenylist));
|
|
|
|
// Address (normalized v6 bits) -> Core.TickCount at which the hold lapses. Loop-only.
|
|
private static readonly Dictionary<UInt128, long> _held = [];
|
|
|
|
private static bool _enabled;
|
|
private static long _durationMs;
|
|
private static int _maxEntries;
|
|
private static bool _warnedFull;
|
|
|
|
public static int Count => _held.Count;
|
|
|
|
public static void Configure()
|
|
{
|
|
AutoDenylistConfiguration.Load();
|
|
var s = AutoDenylistConfiguration.Settings;
|
|
|
|
_enabled = s.Enabled && s.Duration > TimeSpan.Zero && s.MaxEntries > 0;
|
|
if (!_enabled)
|
|
{
|
|
return;
|
|
}
|
|
|
|
_durationMs = (long)s.Duration.TotalMilliseconds;
|
|
_maxEntries = s.MaxEntries;
|
|
|
|
ConnectionFilters.Register(new AutoDenylistFilter());
|
|
BanChannel.Register(new AutoDenylistReporter());
|
|
}
|
|
|
|
/// <summary>
|
|
/// Holds an address for the configured duration. Ignores non-behavioural verdicts and refuses to grow
|
|
/// past the cap: the flood this exists for must not become a memory leak.
|
|
/// </summary>
|
|
public static void Hold(IPAddress address, string reason) => Hold(address, reason, Core.TickCount);
|
|
|
|
internal static bool Hold(IPAddress address, string reason, long nowTicks)
|
|
{
|
|
if (!_enabled || address == null || !BanReasons.IsBehavioral(reason))
|
|
{
|
|
return false;
|
|
}
|
|
|
|
var key = address.ToUInt128();
|
|
|
|
// An address already held is just extended, so no cap check is needed.
|
|
if (!_held.ContainsKey(key) && _held.Count >= _maxEntries)
|
|
{
|
|
Sweep(nowTicks);
|
|
|
|
if (_held.Count >= _maxEntries)
|
|
{
|
|
if (!_warnedFull)
|
|
{
|
|
_warnedFull = true;
|
|
logger.Warning(
|
|
"Auto-denylist is full at {Max} addresses; further detections are disconnected but not held",
|
|
_maxEntries
|
|
);
|
|
}
|
|
|
|
return false;
|
|
}
|
|
}
|
|
|
|
_held[key] = nowTicks + _durationMs;
|
|
return true;
|
|
}
|
|
|
|
public static bool IsDenied(IPAddress address) => IsDenied(address, Core.TickCount);
|
|
|
|
/// <summary>The pure decision, split out so the accept-path policy can be tested without a clock.</summary>
|
|
internal static bool IsDenied(IPAddress address, long nowTicks)
|
|
{
|
|
if (!_enabled || address == null)
|
|
{
|
|
return false;
|
|
}
|
|
|
|
// Decided on read, so a lapsed hold cannot deny even before the sweep. Subtraction: TickCount wraps.
|
|
return _held.TryGetValue(address.ToUInt128(), out var expires) && expires - nowTicks > 0;
|
|
}
|
|
|
|
/// <summary>Releases an address early, e.g. when an operator retracts a ban.</summary>
|
|
public static void Release(IPAddress address)
|
|
{
|
|
if (_enabled && address != null)
|
|
{
|
|
_held.Remove(address.ToUInt128());
|
|
}
|
|
}
|
|
|
|
internal static void Sweep(long nowTicks)
|
|
{
|
|
if (_held.Count == 0)
|
|
{
|
|
return;
|
|
}
|
|
|
|
var lapsed = 0;
|
|
|
|
foreach (var (address, expires) in _held)
|
|
{
|
|
if (expires - nowTicks <= 0)
|
|
{
|
|
_held.Remove(address);
|
|
lapsed++;
|
|
}
|
|
}
|
|
|
|
if (lapsed > 0)
|
|
{
|
|
_warnedFull = false;
|
|
}
|
|
}
|
|
|
|
internal static void LoadForTesting(bool enabled, long durationMs, int maxEntries)
|
|
{
|
|
_held.Clear();
|
|
_enabled = enabled;
|
|
_durationMs = durationMs;
|
|
_maxEntries = maxEntries;
|
|
_warnedFull = false;
|
|
}
|
|
}
|
|
|
|
/// <summary>Accept-path gate for <see cref="AutoDenylist"/>.</summary>
|
|
public sealed class AutoDenylistFilter : IConnectionFilter
|
|
{
|
|
public string Name => "auto-denylist";
|
|
|
|
public void Register()
|
|
{
|
|
}
|
|
|
|
public void Start(CancellationToken token)
|
|
{
|
|
// Only an optimisation: IsDenied expires on read.
|
|
Timer.DelayCall(TimeSpan.FromMinutes(1), TimeSpan.FromMinutes(1), () => AutoDenylist.Sweep(Core.TickCount));
|
|
}
|
|
|
|
public void Stop()
|
|
{
|
|
}
|
|
|
|
public bool ShouldDeny(IPAddress address) => AutoDenylist.IsDenied(address);
|
|
}
|
|
|
|
/// <summary>
|
|
/// Feeds <see cref="AutoDenylist"/> from the ban channel. A reporter rather than a direct call, because the
|
|
/// detection sites live in the engine and must not reach into content.
|
|
/// </summary>
|
|
public sealed class AutoDenylistReporter : IBanReporter
|
|
{
|
|
public string Name => "auto-denylist";
|
|
|
|
public bool CanRetract => true;
|
|
|
|
public void Register()
|
|
{
|
|
}
|
|
|
|
public void Start(CancellationToken token)
|
|
{
|
|
}
|
|
|
|
public void Stop()
|
|
{
|
|
}
|
|
|
|
/// <summary>
|
|
/// The contributed <paramref name="ttl"/> is ignored: how long a bouncer should ban an address is a
|
|
/// different question from how long this shard holds it at accept.
|
|
/// </summary>
|
|
public void Report(IPAddress address, TimeSpan ttl, string reason) => AutoDenylist.Hold(address, reason);
|
|
|
|
public void Retract(IPAddress address) => AutoDenylist.Release(address);
|
|
}
|