# 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.
>
> Canonical: https://xdp.network/docs/attack-mitigation/during-an-attack · Updated 2026-08-09

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.

:::warning
Do not null-route the server or restart its networking during an attack. Taking your own
IP offline does the attacker's job for them — and you lose the console's view of the
incident while it continues.
:::

## Next steps

- [Reading attack logs and forensics](/docs/attack-mitigation/reading-attack-logs)
- [Tuning profiles](/docs/openshield-xdp/tuning-profiles)
- [Common errors](/docs/troubleshooting/common-errors)