docs: record the auto-denylist behaviour changes
Three gaps the review missed, docs only. A hold is no longer extended by repeat detections, which is operator- visible: an address that keeps trying is now released 15 minutes after its FIRST detection rather than held indefinitely. Someone debugging why an address came back needs to know that, and that the rate limiter re-holds it on the next attempt rather than letting it through free. Nothing described what happens at maxEntries. Past the cap a detection still disconnects but is not held, so the address pays full detection cost per reconnect. Added to Known limits next to the MaxConnections ceiling, since both end in the same place: a flood past it wants upstream scrubbing, not a larger cap that only buys a longer on-loop scan. networking-packets.md listed the three shipping filters without noting the blocklist is now opt-in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
5b7304addd
commit
5501c922ca
2 changed files with 13 additions and 3 deletions
|
|
@ -511,9 +511,9 @@ Rules:
|
|||
|
||||
Core owns the question; **every implementation lives in UOContent**. The three that ship are `firewall`
|
||||
(admin-curated, mutable at runtime, persisted to `Configuration/firewall.json`), `blocklist` (file-sourced,
|
||||
millions of entries, demand-pages hits to CrowdSec) and `auto-denylist` (in-memory, short-lived, fed by the
|
||||
shard's own behavioural detections). A shard that fronts its server with an upstream proxy or edge scrubbing
|
||||
can drop all of them and register nothing.
|
||||
millions of entries, demand-pages hits to CrowdSec, **opt-in**) and `auto-denylist` (in-memory,
|
||||
short-lived, fed by the shard's own behavioural detections). A shard that fronts its server with an
|
||||
upstream proxy or edge scrubbing can drop all of them and register nothing.
|
||||
|
||||
The allowlists, ban contribution, behavioural detection and the operator process for exempting a
|
||||
false-positive address are covered separately in
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue