What to do in case of a DDoS attack on a website?

Manuel Schulz · 31.10.2025 · IT security · 7 min

Recently, was confronted with a DDoS attack. Zerlo.net with a DDoS attack confronted. We were interested: How do we handle it, how do we recognize such a thing – and how could we prove it conclusively? In this post I show our steps, what lies behind DDoS, and how Cloudflare as a protective layer helps. If you have similar problems, you can find practical tools on our Zerlo-Toolseite and other posts in the Zerlo-Blog.

Feature banner: DDoS attack – stock image

Source: Original illustration

Explanation: What is a DDoS?

A Distributed-Denial-of-Service-Angriff (DDoS) is the attempt to disable an online service through massively distributed requests. 'Distributed' means: The attack comes simultaneously from many, often automated sources ( (CISA-Leitfaden). One roughly distinguishes between attacks at the network level (e.g. UDP/ICMP floods) and the application level (Layer 7), such as (HTTP-Floods). A good, practical introduction is also provided by OWASP ( (Denial of Service).

How do you recognize it?

A single metric is rarely enough. Typical patterns are: sharply rising origin load, but unchanged real sessions/conversions; suddenly many requests to expensive endpoints (Login, Search, /api, forms); suspicious or empty User-Agents; unusual peaks from new ASNs; high CPU/IO load without code changes. Clean logs are helpful, which you can analyze, for example via Cloudflare Logpush/Log Explorer or server-side analyzed. A compact checklist can be found in the Zerlo-Blog for similar incidents.

Detection via Cloudflare

In Cloudflare these patterns can be neatly broken down:

Security → Events/Analytics: Peaks by path, country, ASN, method, User-Agent ( (Security Analytics).
Traffic/Analytics: Many edge requests with a simultaneously high origin-quote → indicator of L7 floods ( (Traffic Analytics).
WAF/Firewall: "Challenged/Blocked" counts mitigations; fine-tune rules ( (Cloudflare WAF).
HTTP-DDoS/Rate Limiting: Identify IP-/path hotspots ( (Rate Limiting Rules, HTTP DDoS Managed Rules).

Conclusion: For websites with many users, an upstream protection layer like Cloudflare Application Services is practically mandatory – telemetry and tools help distinguish between legitimate load and an attack and respond quickly. Internally we refer to foundational articles on the Zerlo-Blog and for tooling to the Zerlo-Tools.

Personal

We at Zerlo had to notice an unusually high load on 31.10.2025 – at times the website was offline several times. At first I assumed a technical problem. Then I checked the visitor numbers: nearly identical to the previous day, which was odd since our counter only measures human interactions (JavaScript).

The classic counter-test: start everything locally (localhost). Result: local 0% load – so the external load had to be artificial. In Cloudflare the increase was clearly visible. I experimentally activated the Under-Attack-Mode (UAM); ; the server load fell to about 5% on average.

Cloudflare statistics: strong increase in incoming requests

Source: Original illustration

In short: We were DDoSed. We share more insights continuously in the Zerlo-Blog.

Cloudflare

If the web host already has good network-layer protection, that is often enough for volumetric attacks, especially if the provider mitigates. We operate at Zerlo however we have a larger network with multiple services and need central, upstream interfaces that terminate and filter traffic intelligently before it reaches our origins. This is exactly where a global edge network like Cloudflare helps: Anycast, Caching, WAF, Bot Fight Mode, Rate-Limiting and detailed telemetry.

Cloudflare is usable at the base level for free and can be temporarily turned up during attacks. It does not automatically recognize every scenario perfectly – you must observe patterns – but with the right rules it is very effective. For setups and benchmarks we also document best practices on zerlo.net/de/tools.

Cloudflare protection mechanism explained

So simple yet genius: Before the actual page load Cloudflare can perform a JavaScript-based check ( Challenge) ) to gate in and evaluate signals from the browser. For real users this happens once and is barely noticeable; bots and scripts fail or must devote massively more resources. Result: Backend load drops immediately and you gain time for fine-tuning ( (WAF, Rate-Limits, Caching).

❝ DDoS cannot be prevented – you manage it. The art is to make attacks invisible to humans but expensive for bots. ❞

Manuel Schulz

Zerlo.net

Source: Brief overview of botnets and DDoS.

What can you do about it?

Nothing. You cannot prevent a DDoS – anyone on the net may send you packets. But you can make the effect so small that the site remains available for real users. The point is: dampen intelligently rather than endure.

Short-term: Under-Attack-Mode (UAM) activate to immediately dampen Layer-7 load.

Long-term: WAF-Regeln for POST/APIs/expensive GETs, Managed-Challenges for suspicious user agents, Rate-Limiting per IP. For public pages Cache Everything , for logins/admins Bypass on Cookie. Secure forms with Turnstile securing.

Operations: Security Analytics monitor, set alerts, Logs secure. A small script can pull UAM automatically when pings fail – and notify you. We document examples and snippets on zerlo.net/de/blog.

Cloudflare: sensible WAF/Rate-Limit rules

(len(http.user_agent) = 0
 or lower(http.user_agent) contains "python"
 or lower(http.user_agent) contains "curl"
 or lower(http.user_agent) contains "bot"
 or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge

(http.request.method eq "POST"
 or starts_with(http.request.uri.path, "/api/")
 or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge

# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/

cloudflare_uam_toggle.sh

#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"

# UAM EIN
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer " \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer " \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level

nginx_rate_limit_example.conf

# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;

server {
  location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
  }
}

# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

Further resources

Foundations and deeper dives: NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. More practical articles and tools can be found on zerlo.net and specifically under zerlo.net/de/tools.

Conclusion

DDoS is not an exceptional state, but an operating case. Those who quickly detect anomalies, dampen briefly and then harden accordingly stay online. For growing websites, is Cloudflare as an upstream protection layer highly recommended: visibility, immediate actions and building blocks for robust continuous operation. For individual setups, checklists and snippets we refer to the Zerlo-Blog and the Zerlo-Tools.