ModernUO/Projects/UOContent/Network/AutoDenylist/AutoDenylist.cs
Kamron Batman 2dbaa87377
feat: make the blocklist and manual allowlist opt-in; cut the ban subsystem's on-loop cost (#2577)
Two features ran on every shard out of the box, each polling on its own 60s timer for files most shards never generate, neither ever asked for. Fixing that turned into untangling why they shared a config file — and then into the on-loop cost of the three lists behind them.

## Before / after

Measured on the shipped defaults. On-loop numbers are what freezes the world; the tick budget is 8 ms.

| | before | after |
|---|---:|---:|
| Blocklist poll on a shard with no list | every 60s, forever | **none** (opt-in) |
| Manual allowlist poll on a shard with no carve-outs | every 60s, forever | **none** (opt-in) |
| Promote-guard sweep timer | leaked on `Stop()` | stopped, and only started when hits are reported |
| Login allowlist flush, on-loop | O(n) walk + 2 arrays **every 60s**, LOH past ~5,300 entries | reused buffers, **hourly**, zero steady-state allocation |
| Auto-denylist, accept path | 9.1 ns/call | **6.1 ns/call** |
| Auto-denylist, sustained flood at cap (60k rejected) | 26.7 ms | **9.3 ms** |
| Auto-denylist, flood end — **worst single call** | 9.49 ms | **0.05 ms** |
| Auto-denylist cap | 65,536 (stranding 9,895 slots) | **324,449** (exact `HashSet` capacity, ~19 MB) |

The auto-denylist row that matters is the third: the on-loop stall at flood end drops **190×**, because retiring lapsed holds is now the number expiring rather than the number held.

## Why this design

It is built for the shape of attack these shards actually see: **hundreds to a few thousand connections per second**, occasionally tens of thousands, sustained over minutes rather than delivered instantly. Against that shape the cap now covers the whole observed range (50k–250k distinct sources) in memory, and the work of expiring them spreads across the accept calls that were already happening.

There is one case this design is *worse* at than the old one: if every held entry lapses within the same millisecond, retiring them costs ~10.7 ms against the old ~8.9 ms, because the ring's random-access set removals lose to a sequential dictionary scan. Reaching it requires an entire flood to arrive inside one millisecond. **A shard absorbing 324,449 connections in a millisecond is finished at the accept path no matter what this list does** — that is the point where the answer is upstream security and scrubbing (an L4 proxy, edge filtering, a bouncer at the kernel), not a data structure in the game loop. We chose the design that fits the attacks we see and degrades honestly past them, rather than over-engineering for one we do not.

## Blocklist — now opt-in

`BlocklistFilter.Start` only bailed when `_path == null`, which needs `file` to be empty. The default is `"Configuration/ip-blocklist.txt"`, so on any default install both `Task.Run(PollLoop)` and a recurring `SweepGuard` timer started unconditionally, logging *"Blocklist inert: no list at …; polling every 60s"* and then doing exactly that forever.

Adds `"enabled"`, default `false`, using the `_enabled = s.Enabled && <preconditions>` idiom already in `LoginAllowlist` and `AutoDenylist`. **Upgrade is deliberately loud**: a missing key binds to the default, so `LogWhyDisabled()` splits three cases and a shard with a list on disk but no `enabled` key gets a **Warning**, not silence.

## `FileAllowlist` → `ManualAllowlist`, with its own config

Moves to `Configuration/ip-allowlist.json` (`enabled` default `false`, `files`, `reloadInterval`) and into `Network/ManualAllowlist/`, mirroring `Network/LoginAllowlist/`.

It was never a sub-feature of the blocklist. `ManualAllowlist.Contains` has two callers:

| Caller | Could anything else do it? |
|---|---|
| `BlocklistFilter.Evaluate` | **Yes** — the generator already subtracts these files at generation time |
| `BanExemptions.IsExempt` | **No** — sole mechanism for suppressing behavioural ban contributions |

The second reaches `BanChannel.IsExempt` with no blocklist in the path. A shard running **no blocklist** still needs this so the admin's own IP isn't auto-banned by rate-limit detection, so a shared flag couldn't express it — the implication is asymmetric. They still work together via a startup warning when the blocklist is on and the allowlist is not.

On the name: "File" described the storage. The distinction from `LoginAllowlist` is **provenance** — declared by an operator versus earned by authenticating — and "Manual" matches `BanReasons.Manual`. `allowlistFiles` is removed from `BlocklistSettings` outright; blocklists have not shipped long enough for anyone to have set it.

## Login allowlist flush

`Flush()` allocated two arrays sized to the live entry count and copied the whole dictionary into them **on the game loop**, every 60s. `UInt128` is 16 bytes, so past ~5,300 entries that first array was an LOH allocation once a minute, forever. The file write was already off-loop; the walk was not.

Static buffers grown geometrically; the writer owns them until it posts completion back through `Core.LoopContext`, so `_writing`/`_dirty` stay loop state (rule #10). Interval → 1 hour against a 90-day TTL. Clean shutdown writes synchronously via `EventSink.Shutdown`; `HandleClosed` skips `InvokeShutdown` when crashed, so the crash path subscribes separately and only writes when it is actually on the loop thread. Also fixes a pre-existing hole where `_dirty` was cleared *before* the write, so a failed write dropped entries despite the comment promising a retry.

## Auto-denylist: expiry ring

Reclaiming lapsed holds was O(entries held) — every cap-triggered reclaim during a flood walked the whole dictionary to find the few that expired, and `_warnedFull` suppressed the log, not the work.

A hold is **never refreshed** now: the first detection sets the expiry, later ones leave it. That makes insertion order equal to expiry order, so a ring of the same keys is sorted by construction and retiring stops at the first live record. Nothing is lost — the rate limiter runs *ahead* of the connection filters (`NetState.Network.cs`) and reports to the ban channel, so a flooder whose hold lapses is re-held on its next attempt.

Because the ring carries the expiry, the membership side only answers "present?", so it is a `HashSet` — measured at **36 B/slot against the dictionary's 52**. `HashSet` and `Dictionary` share `HashHelpers`, so the from-empty capacity progression is identical (36,353 → 75,431 → 156,437 → 324,449 → 672,827) and the cap still lands on one exactly. The ring is parallel `UInt128[]`/`long[]` rather than an array of structs — `UInt128` forces 16-byte alignment, so a packed pair costs 32 bytes where these cost 24, and the drain reads only the `long[]`.

Rejected after measuring: splitting the drain into a scan loop plus a removal loop (inside noise — both issue N hash removes, and the pointer math was never the bottleneck), and `Dictionary<UInt128,bool>` with tombstoning instead of removal (10% slower *and* unbounded, which breaks the cap).

## Testing

Build clean, 0 warnings. **1,530 tests pass** — 708 UOContent, 822 Server.

Tests were reworked rather than patched: the refresh test inverts to `Repeat_detection_does_not_extend_the_hold`, the obsolete sweep-throttle test is deleted along with the throttle, and four were added for the ring — set/ring parity, release-then-re-hold not being retired by the stale record, exact fill of a non-power-of-two cap, and the moved allowlist config's casing contract. The throttle test added mid-PR was verified to fail without its fix before being deleted.

One commit is comments only (verified: a diff filtered of `//` lines is empty), removing development narration — a `"(Task 2)"` plan reference, `"matching the per-feature JSON config pattern used by X"` across four loaders, a duplicated threading note — and repointing `Firewall` at `dev-docs/ip-bans-and-allowlists.md` instead of a "ban-channel design doc" that does not exist.

Note `Distribution/Configuration/blocklist.json` is gitignored (`.gitignore:14`) and generated from the record defaults on first boot, so the record default *is* the shipped default.
2026-08-13 23:22:35 -07:00

343 lines
12 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>
/// <remarks>
/// A hold is never refreshed, so every expiry is <c>insertion + duration</c> and the ring is sorted by
/// construction. Retiring lapsed entries is therefore the number expiring rather than the number held, which
/// is what lets the cap be sized for the flood instead of for a scan.
/// </remarks>
public static class AutoDenylist
{
private static readonly ILogger logger = LogFactory.GetLogger(typeof(AutoDenylist));
// Membership only (normalized v6 bits). Loop-only. The expiry lives beside the key in the ring, so
// there is exactly one copy of it and the two cannot disagree.
private static readonly HashSet<UInt128> _held = [];
// The same keys in expiry order. Parallel arrays rather than an array of structs: UInt128 forces
// 16-byte alignment, so a packed (key, expiry) struct costs 32 bytes where these cost 24 -- and the
// drain reads only the long[], 8 sequential bytes per entry.
private static UInt128[] _ringKeys = [];
private static long[] _ringExpiry = [];
private static int _ringHead;
private static int _ringCount;
private static bool _enabled;
private static long _durationMs;
private static int _maxEntries;
private static bool _warnedFull;
public static int Count => _held.Count;
// Test seam: the ring and the set hold the same entries, and nothing else may assume it.
internal static int RingCount => _ringCount;
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;
}
Drain(nowTicks);
var key = address.ToUInt128();
// Deliberately not refreshed: the first detection sets the expiry and later ones leave it alone.
// That keeps insertion order equal to expiry order, which is why the drain can stop at the first
// live record. A flooder whose hold lapses trips the rate limiter on its next attempt -- which
// runs ahead of the connection filters -- and is held again.
if (!_held.Add(key))
{
return true;
}
// Drain already reclaimed everything reclaimable, so being over now means genuinely full.
if (_held.Count > _maxEntries)
{
_held.Remove(key);
if (!_warnedFull)
{
_warnedFull = true;
logger.Warning(
"Auto-denylist is full at {Max} addresses; further detections are disconnected but not held",
_maxEntries
);
}
return false;
}
Push(key, nowTicks + _durationMs);
return true;
}
public static bool IsDenied(IPAddress address) => IsDenied(address, Core.TickCount);
/// <summary>
/// The accept-path decision, split out so the policy can be tested without a clock. Drains first: the
/// expiry lives in the ring, not beside the membership, so a lapsed hold has to be retired here rather
/// than expired on read. One array read when nothing has lapsed.
/// </summary>
internal static bool IsDenied(IPAddress address, long nowTicks)
{
if (!_enabled || address == null)
{
return false;
}
Drain(nowTicks);
return _held.Contains(address.ToUInt128());
}
/// <summary>Releases an address early, e.g. when an operator retracts a ban.</summary>
public static void Release(IPAddress address)
{
if (!_enabled || address == null)
{
return;
}
var key = address.ToUInt128();
if (_held.Remove(key))
{
// The ring record has to go too. Nothing records that this key was released, so if it were
// detected again before the old record lapsed, that record would retire the new hold early.
// O(n), but this is an operator retraction, not the accept path.
PurgeRing(key);
}
}
/// <summary>
/// Retires everything that has lapsed. Expiries only ever increase along the ring, so the first live
/// record ends the scan and the cost is the number actually expiring, not the number held.
/// </summary>
internal static void Drain(long nowTicks)
{
var before = _ringCount;
// Subtraction, never a direct compare: tick counts wrap. See dev-docs/tick-counts.md.
while (_ringCount > 0 && _ringExpiry[_ringHead] - nowTicks <= 0)
{
_held.Remove(_ringKeys[_ringHead]);
_ringHead = _ringHead + 1 == _ringKeys.Length ? 0 : _ringHead + 1;
_ringCount--;
}
if (_ringCount != before)
{
_warnedFull = false;
}
}
private static void Push(UInt128 key, long expiry)
{
if (_ringCount == _ringKeys.Length)
{
Grow();
}
var tail = _ringHead + _ringCount;
if (tail >= _ringKeys.Length)
{
tail -= _ringKeys.Length;
}
_ringKeys[tail] = key;
_ringExpiry[tail] = expiry;
_ringCount++;
}
private static void Grow()
{
// Capped at the entry cap: Push only runs below it, so the ring never needs more, and doubling
// past it would reserve roughly twice the slots it can ever use.
var size = Math.Min(Math.Max(64, _ringKeys.Length * 2), _maxEntries);
var keys = new UInt128[size];
var expiry = new long[size];
for (var i = 0; i < _ringCount; i++)
{
var from = _ringHead + i;
if (from >= _ringKeys.Length)
{
from -= _ringKeys.Length;
}
keys[i] = _ringKeys[from];
expiry[i] = _ringExpiry[from];
}
_ringKeys = keys;
_ringExpiry = expiry;
_ringHead = 0;
}
private static void PurgeRing(UInt128 key)
{
var capacity = _ringKeys.Length;
for (var i = 0; i < _ringCount; i++)
{
var at = _ringHead + i;
if (at >= capacity)
{
at -= capacity;
}
if (_ringKeys[at] != key)
{
continue;
}
// Close the gap so the ring stays contiguous and expiry-ordered.
for (var j = i; j < _ringCount - 1; j++)
{
var to = _ringHead + j;
if (to >= capacity)
{
to -= capacity;
}
var from = to + 1 == capacity ? 0 : to + 1;
_ringKeys[to] = _ringKeys[from];
_ringExpiry[to] = _ringExpiry[from];
}
_ringCount--;
return;
}
}
internal static void LoadForTesting(bool enabled, long durationMs, int maxEntries)
{
_held.Clear();
_ringKeys = [];
_ringExpiry = [];
_ringHead = 0;
_ringCount = 0;
_enabled = enabled;
_durationMs = durationMs;
_maxEntries = maxEntries;
_warnedFull = false;
}
}
/// <summary>Accept-path gate for <see cref="AutoDenylist"/>.</summary>
public sealed class AutoDenylistFilter : IConnectionFilter
{
private Timer _sweepTimer;
public string Name => "auto-denylist";
public void Register()
{
}
public void Start(CancellationToken token)
{
// Only reclaims memory: Hold and IsDenied both drain, so this matters on a shard that has gone
// quiet after a flood and would otherwise hold the ring until someone next connects.
_sweepTimer = Timer.DelayCall(
TimeSpan.FromMinutes(1),
TimeSpan.FromMinutes(1),
() => AutoDenylist.Drain(Core.TickCount)
);
}
public void Stop()
{
// Recurring, so an uncancelled sweep survives Stop and the next Start adds a second one.
_sweepTimer?.Stop();
_sweepTimer = null;
}
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);
}