diff --git a/docs/features/under_attack_mode/README.md b/docs/features/under_attack_mode/README.md index 210cad7d..991db3cb 100644 --- a/docs/features/under_attack_mode/README.md +++ b/docs/features/under_attack_mode/README.md @@ -6,7 +6,7 @@ **Under Attack Mode (UAM)** is a WebShield feature that lets a server administrator put one or more **domains** (optionally scoped to specific URL paths) "under attack". While a domain is under attack, every matching HTTP request is first served a lightweight **JavaScript splash challenge** instead of being passed straight to the site: -- Regular browsers solve the challenge transparently and receive a short-lived cookie; subsequent requests carrying a valid cookie flow through normally. +- Regular browsers solve the challenge transparently and receive a clearance cookie (its lifetime is configurable per rule); subsequent requests carrying a valid cookie flow through normally. - Simple bots that cannot run the challenge never reach the application. UAM is a **server-wide administrator feature**. It is distinct from the per-IP GreyList / Anti-bot Challenge: UAM decisions are keyed on the request's `(domain, path)` and are configured explicitly by the administrator, rather than being driven by the state of an IP list. @@ -21,14 +21,14 @@ UAM is not available on every environment WebShield supports. Before relying on ## How it works -- A domain is placed under attack by creating a **UAM rule**. A rule is a `(domain, optional path-set)` tuple. +- A domain is placed under attack by creating a **UAM rule**. A rule pairs a `domain` (optionally narrowed to a path-set) with the clearance-cookie lifetime to grant once a visitor solves the challenge. - When a request matches an **active** rule, WebShield returns the JS splash challenge and does not forward the request to the backend until the visitor passes. - UAM is **fail-open**: if the feature is disabled, the request has no `Host`, the rule store cannot be read, or no active rule matches, the request simply proceeds through the normal WebShield flow. UAM never blocks a request outright — it only inserts a challenge. - The feature is gated behind a single on/off toggle that is **off by default**, and all UAM state is stored on the server itself. ## Prerequisites -- WebShield version >= 1.44.2 installed and running in an environment where UAM is available (see the note above). +- WebShield version >= 1.45.0 installed and running in an environment where UAM is available (see the note above). The core rule commands and the service toggle have been available since 1.44.2; the per-rule challenge-cookie lifetime and the `uam test` command described below were added in 1.45.0. - Root access to the server. UAM is managed with the `imunify360-wsctl uam` command, which must be run as `root`. ## Enabling and disabling UAM @@ -49,16 +49,25 @@ Disabling the feature stops all challenges immediately; your rules are preserved ## Managing rules -A rule is created from a small JSON payload. Only `domain` is required; `label` (a free-text note) and `paths` (path scoping) are optional. A new rule is active as soon as it is created. +A rule is created from a small JSON payload. The fields are: + +| Field | Required | Description | +|-|-|-| +|`domain`|yes|Exact hostname to put under attack (up to 253 characters).| +|`cookie_ttl`|yes|How long a visitor's clearance cookie stays valid after they solve the challenge, before they are challenged again. A Go-style duration string using the units `s`, `m`, `h` (compound values such as `1h30m` are allowed), between **10 seconds and 3 days**.| +|`label`|no|Free-text note (up to 128 characters).| +|`paths`|no|Path-scoping block (see [Path scoping](#path-scoping) below). Omit it to cover the whole domain.| + +A new rule is active as soon as it is created.