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
Top comments (0)