What To Do During an Attack

If your site is under attack right now, do one thing first: go to Console → WAF → [domain] → Overview and click the Emergency Protection (Panic) button. JS Challenge is applied to all visitors instantly and cuts most automated traffic. Then narrow the attack down with the steps below.

1. Hit the Panic button. On Console → WAF → [domain] → Overview, click Emergency Protection (Panic) → Start Protection. JS Challenge is applied to all visitors immediately. You can stop it at any time from the same page with Stop Protection. If the attack bypasses the JS challenge (an advanced botnet), go to Console → WAF → [domain] → Protection and switch the Protection Mode to CAPTCHA.

2. Enable Auto-Protection. On the same page, turn on the Auto-Protection switch:

   • RPS Threshold: default 100 (10–5000) — the challenge engages when traffic exceeds this
   • Mode: JS (CAPTCHA if needed)
   • Standby Duration: 60 s · Cooldown: 600 s

   This way, even if the attack comes in waves, protection engages automatically and stands down on its own when traffic normalizes — it works while you sleep.

3. Tighten rate limits and Failban. Still on the same page:

   • Global Rate-Limit: enable it and lower the request count (e.g. tighter than 100 requests / 10 min)
   • Fail Ban: enable it; start with threshold 5 and block time 600 s, and increase the block time (up to 86400 s) if the attack persists

4. Identify the attack source. On Console → WAF → [domain] → Analytics, look at the top IPs, ASNs, and countries. If the attack comes from a specific source, add targeted rules (Rules → New Rule):

   # Block the attacking ASN
   IF   ip.asnum == 212238
   THEN block
   
   # Block the attacking IP range
   IF   ip.prefix in 203.0.113.0/24
   THEN block
   
   # If the attack comes from a single country
   IF   ip.country in XX
   THEN block

5. Monitor active IP bans. View the IPs banned by Failban at Console → WAF → [domain] → Blocked IPs. You can also block an IP/CIDR manually there via the Block field (e.g. 203.0.113.7 or 10.0.0.0/8), and release a legitimate IP that got banned by mistake with Remove.

6. Open a Waiting Room if it’s a capacity problem. If you are facing a sudden legitimate surge rather than an attack (a campaign, ticket sales), create a room at Console → WAF → [domain] → Waiting Room: enter the affected paths, capacity, and admissions per second. Excess traffic gets queued instead of blocked.

7. Roll back when the attack ends. Turn the Protection Mode card off and return the tightened limits to their normal values. Review the access logs and note the attack pattern; you can leave the targeted rules (ASN/country blocks) in place if you want them permanent.

Verified visitors are not re-challenged

Visitors who pass the challenge are exempt for a while: 30 minutes by default for the JS challenge, 60 minutes for CAPTCHA. So with protection mode on, real users see the challenge only on first entry, not on every page.

Prepare before the attack

The best emergency plan is configured before the attack: keep Auto-Protection permanently on, get notified of challenge/failban events via webhooks, and exempt your critical IPs (office, payment provider) with an IP list.

Verification

• On the WAF page’s live RPS chart, watch origin-bound traffic drop while the blocked-threats counter climbs.
• Check that your origin server’s CPU/bandwidth load returns to normal.
• Visit the site from a normal browser: after a brief verification screen you should get through without issues.
• Confirm in Analytics that legitimate traffic (requests passing the challenge) continues.

Related Pages

DDoS ProtectionThe four-layer protection architecture

Verification SettingsJS challenge, CAPTCHA, and automatic banning

Waiting RoomQueue management under heavy traffic