# On-call quick reference card Source: https://humanymous.net/reference/on-call-quick-reference.html Project: humanymous — defensive anti-bot / browser-automation detection (Apache-2.0). --- # On-call quick reference card > **Quadrant:** Reference — a one-screen cheat sheet. **Audience:** SOC on-call, during and between incidents. Fast lookup for a shift on humanymous Gate (the reverse-proxy enforcement layer, "Gate" after first mention). Scan it; do not read it. This is the reference build, not a production-hardened one. When you need the full procedure, jump to [Incident runbooks](../runbooks/incident-runbooks.md) and [Kill switch & bans](../runbooks/kill-switch-and-bans.md). --- ## Verdict legend — what each does at the edge | Verdict | Edge action | Origin contacted? | |---------|-------------|-------------------| | **ALLOW** | `pass` | Yes | | **CHALLENGE** | `challenge_pow` — accessible proof-of-work (PoW) interstitial from the control plane | No | | **DENY** | `block` | No | | **none** (Unknown, no evidence yet) | fail-**closed** on strict routes or unsafe methods (POST/PUT/PATCH/DELETE) → challenge; fail-**open** only for safe GET/HEAD on non-strict routes | Depends on the fail rule | Score bands (policy 1.0.0): `0–29` ALLOW · `30–69` CHALLENGE · `70–100` DENY. Hard rules override the score. A score-based CHALLENGE upgrades to ALLOW on `l7.pow.solved`; PoW never clears a hard rule. Every decision is written to the audit log before it takes effect. --- ## Top hard rules to recognize All DENY are high-confidence (FP~0): a spike means automated traffic is arriving — reading it as an attack is safe. | Rule | Fires on | Action | Read a spike as | |------|----------|--------|-----------------| | **HR-1** | Automation artifact (Selenium / Puppeteer / Playwright) | DENY | Attack | | **HR-9** | CDP leak + automation hint | DENY | Attack | | **HR-19** | One fingerprint across many subnets (residential-proxy rotation) | DENY | Attack | | **HR-20** | AI browser-agent (teleport click + LLM cadence) | DENY | Attack | | **HR-21** | Destructive flood / HTTP/2 DoS / rate-limit ban | DENY | Attack | | **HR-30** | Decision-probing sweep: many sessions from one fingerprint | DENY | Attack | | **HR-12** | No interaction over the observation window | **CHALLENGE** | **Heuristic — can catch some real humans. Investigate before treating as attack volume.** | Full table and signal-ID drill-down: [Hard rules & verdicts](hard-rules-verdicts.md). --- ## The three levers — and who commits | Lever | Endpoint | Committer | |-------|----------|-----------| | **Unblock** (lift temp ban) | `POST /__hmn/admin/bans/lift` | Single **Operator** | | **Temp ban** (`1h`/`6h`/`24h`) | `POST /__hmn/admin/bans` | Single **Operator** | | **Permanent / CIDR ban** | `POST /__hmn/admin/bans` → `POST /__hmn/admin/approvals/` | **Distinct Approver** (dual-control) | | **Kill switch** (fleet-wide) | `POST /__hmn/admin/killswitch` → `POST /__hmn/admin/approvals/` | **Distinct Approver** (dual-control) | | **Erasure** (crypto-shred) | (control plane) | **Distinct DPO** (dual-control; generic Approver cannot) | The requester never self-commits a dual-control action, in either direction (placing or lifting). Actor identity is server-derived from the bearer token; body actor fields are ignored. > **Warning:** The **kill switch is fleet-wide.** It demotes hard-rule enforcement to monitor across every node — detection still scores and logs, manual bans still enforce, but traffic hard rules would DENY now reaches origin. Pull it for a customer-hurting false-positive storm, never to calm a real attack. Roll it back (also dual-control) the moment the cause is fixed. --- ## Ban ladder & key choice Auto-bans climb on repeat strikes, with strike decay downward: ``` 1h → 6h → 24h → permanent ``` `Source=auto` = ladder placed it; `Source=manual` = you placed it. Active set: `GET /__hmn/admin/bans`. - **`fp:`** — use for residential-proxy rotation (HR-19). The IP moves; the fingerprint is the stable handle. - **`ip:` / `cidr:`** — use for a fixed hostile source (many fingerprints, one IP/range). Dual-control for CIDR. - **Avoid `ip:` / `cidr:` against shared egress** — CGNAT and corporate egress put real humans behind the same address. Prefer `fp:`-scoped action or let rate metering absorb it. --- ## 20-second: attack vs false-positive 1. **Which verdict spiked?** DENY → lean attack. CHALLENGE → could be humans. 2. **Which rule?** A high-confidence DENY rule (HR-1/9/19/20/21/30) firing → attack; act with bans. **HR-12** (CHALLENGE, heuristic) climbing → suspect humans first. 3. **Are real users complaining?** User reports of blocks/challenges on a legit path = false-positive signal. No reports + rising DENY = attack. 4. **Shared handle?** Spike keyed to one `fp:` across subnets = HR-19 rotation (ban the `fp:`). Spike behind one NAT/carrier `ip:` = likely shared-egress false positive (do **not** IP-ban). 5. **Verdict:** Attack → escalate bans, keep enforcement on. False-positive storm locking out customers → route-table demote + restart, or the fleet-wide kill switch. Unsure → run the triage in [Incident runbooks](../runbooks/incident-runbooks.md) before touching the switch. --- ## Endpoints you'll actually hit | Action | Endpoint | |--------|----------| | Read decision feed / filter | `GET /__hmn/admin/audit` (`?verdict=&host=&route=&rule=&minRisk=&before=`) | | Verify chain integrity | `GET /__hmn/admin/integrity` | | Place a ban | `POST /__hmn/admin/bans` | | Lift a ban | `POST /__hmn/admin/bans/lift` | | Request kill switch | `POST /__hmn/admin/killswitch` | | Commit a dual-control request | `POST /__hmn/admin/approvals/` (find id: `GET /__hmn/admin/approvals`) | Console: `https://localhost:8445/__hmn/admin/console` (separate admin listener; 404 on the public edge). Bearer auth on every call — a missing/invalid token returns `404`, which is deny-by-default, not a bug. > **Note:** Bodies — `POST /bans` `{"Key","Reason","Incident","DurationSec"}`; `/killswitch` `{"On":true}`; `/bans/lift` uses a **`?key=` query parameter, not a body**. Full shapes: [CLI, config & policy reference](cli-config-policy.md#request--response-shapes). --- ## KPI & alert thresholds — a framework, not numbers The Overview view surfaces KPIs computed from the audit stream (`GET /__hmn/admin/audit`), and the Integrity view re-verifies the chain. **The reference build hardcodes no alarm thresholds.** Set your own from a monitor-mode baseline; do not copy numbers from another deployment. Watch three signals: - **CHALLENGE / DENY mix** — the ratio of verdicts over a window. A shift toward DENY leans attack; a shift toward CHALLENGE (especially HR-12-driven) leans false-positive. - **DENY-rate deltas** — change against your own baseline matters more than any absolute rate. Alarm on the delta, not a fixed count. - **False-positive signal from user reports** — blocks/challenges reported on legitimate paths. This is the counter-signal to a rising DENY rate and the trigger to suspect a misfire. > **Note:** Healthy vs alarm bands are **operator-set**. Establish them from your own monitor-mode baseline and tune per route. > **TODO(verify):** specific numeric healthy/alarm ranges for CHALLENGE/DENY mix and DENY-rate delta — none exist in the reference and none may be invented; each operator must derive them from their own baseline. The Overview surfaces five KPI tiles, each a count over the recent window: **Allow**, **Challenge**, **Deny**, **Ban actions** (auto + manual), and **Records** (total events sealed into this node's chain). --- ## Related - [Incident runbooks](../runbooks/incident-runbooks.md) — symptom-indexed procedures and the attack-or-false-positive triage. - [Kill switch & bans](../runbooks/kill-switch-and-bans.md) — blast radius, dual-control, apply / escalate / lift. - [Hard rules & verdicts](hard-rules-verdicts.md) — the full rule set, verdict bands and signal-ID drill-down.