What To Do When Your Website Is Under a DDoS Attack

Zerlo.net — Sat, 11 Apr 2026 15:53:03 +0000

A little while ago, Zerlo.net was hit by a DDoS attack.

At first, I assumed it was just a technical issue. But after checking our traffic and infrastructure, it became clear that this was not normal user activity. In this post, I’ll show how we identified the attack, how Cloudflare helped reduce the impact, and what actions are worth taking when your website suddenly starts collapsing under artificial load.

What is a DDoS attack?

A Distributed Denial of Service (DDoS) attack tries to make a website or service unavailable by overwhelming it with traffic from many different sources at the same time.

In practice, this often means:

huge spikes in requests
abnormal load on the origin server
suspicious user agents
repeated hits on expensive endpoints like login pages, APIs, search, or forms

There are different forms of DDoS:

network-level attacks such as UDP or ICMP floods
application-layer attacks (Layer 7) such as HTTP floods

Layer 7 attacks are especially annoying because they can look more like “normal” traffic at first glance.

How do you recognize it?

A single metric is usually not enough.

Typical warning signs are:

sharply rising server load without a corresponding rise in real users
many requests hitting expensive endpoints
strange or empty user agents
unexpected request peaks from unfamiliar ASNs or regions
high CPU or I/O load even though you didn’t deploy anything new

One of the biggest clues in our case was this:

our own counter tracks human interactions through JavaScript, and those numbers were almost identical to the previous day — while the infrastructure load was massively higher.

That mismatch is a huge red flag.

Our first practical test

The classic test was simple:

run everything locally.

If the application itself is broken, you usually see the problem locally as well.

In our case, local load was basically 0%, while the public system was struggling hard.

That was the moment it became obvious that the pressure was external.

What Cloudflare showed us

Once we checked Cloudflare, the pattern became much clearer.

Useful places to look at:

Security Events / Security Analytics
Traffic Analytics
WAF activity
Rate limiting and challenge data

In Cloudflare, you can break traffic down by:

path
country
ASN
method
user agent

That makes it much easier to distinguish real traffic from garbage.

When we enabled Under Attack Mode, the average server load dropped to around 5%. That was the clearest confirmation we needed.

What Cloudflare is actually doing here

This is the simple version:

Cloudflare sits in front of your origin and can challenge suspicious traffic before it ever reaches your infrastructure.

That means:

bots have to solve extra work
cheap flood traffic becomes more expensive
real users usually pass with minimal friction
your backend gets breathing room immediately

This does not “prevent DDoS forever”, but it buys time and drastically reduces the damage.

What should you do immediately?

You can’t stop people on the internet from sending packets to your system.

So the goal is not “prevent everything forever”.

The real goal is:

reduce the impact enough so that real users can still use the site.

Short-term actions

enable Under Attack Mode
challenge suspicious requests
put rate limiting on sensitive paths
protect forms and login-like endpoints
increase caching where possible
monitor security analytics closely

Good candidates for immediate protection

/api/
form endpoints
login pages
search
mail handlers
expensive POST requests
dynamic pages with heavy backend processing

What should you do long term?

Short-term mitigation is not enough.

After the incident, hardening should include:

proper WAF rules
Managed Challenge for suspicious traffic
Rate Limiting per IP and per path
caching public pages aggressively
bypassing cache only where needed
protecting forms with Turnstile
collecting and reviewing logs
setting alerts for unusual spikes
identifying “expensive” endpoints before the next attack

A practical rule approach

Here is a simple example of the type of logic that makes sense:


txt
(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 example
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

DEV Community: Zerlo.net