During an attack: what to do
A calm runbook for a live attack: confirm mitigation in the console, keep agent state, verify real traffic passes, whitelist critical IPs, and escalate.
Last updated
On this page
Your server row just turned amber. This runbook gets you through a live attack without breaking your own mitigation.
1. Confirm the attack in the console
Open the server's Live metrics tab. A server under attack shows amber with the attack
state active. Compare attack.current_pps against attack.spike_pps_threshold — a
current rate above the threshold confirms detection fired. Check attack.baseline_pps to
see how far above normal you are.
2. Don't restart the agent or flush bans
The agent holds exactly the state you want right now: the ban map, the learned baseline,
per-source stats. Restarting openshield or flushing bans throws that away and lets
banned sources straight back in. Leave it running.
3. Check that mitigation works and real traffic passes
Confirm the recorded attack shows mitigated: true once it closes, and watch the pass
rate (pass_rate) for legitimate traffic. Drop counters climbing while the pass rate
stays healthy means the agent is doing its job. If legitimate users complain, note their
source IPs for the next step.
4. Whitelist critical IPs
If you need guaranteed access — your office, a monitoring probe, a partner API — add those
sources to the whitelist from the console's Control tab or in
/etc/openshield/openshield.yaml, then run openshield reload. Whitelisted sources pass
before any drop logic runs.
5. Escalate big or long attacks
If the flood is large or outlasts your patience, open a ticket and include the attack
number and its forensics_dir — support pulls the forensics directly. Pro customers
receive campaign signature pushes when an attack matches a known campaign.