💥 How I Defeated a Restaurant Website DDoS Attack in 30 Minutes — With Zero Prior Experience

By Olga Svitli

Saturday evening. The busiest hour for a local restaurant. Orders are coming in — or they should be.

Instead, the website is down. Every 3 minutes, it crashes with a 503 error.
The client is in panic. Real orders = real money = real loss.

The website runs on OpenCart via Docker, hosted on DigitalOcean, protected only by a free Cloudflare plan. CPU is at 100%, php-fpm is suffocating.
The logs? An absolute storm of traffic.
I’m the only one from the tech team available.

And I have zero experience fighting DDoS attacks.

But I’m stubborn.

Here’s how I brought the site back to life in 30 minutes — and what I learned on the way ⬇️

🛠 Step-by-step Fix

Diagnosed the Load
- Opened top and docker stats.
- Confirmed the CPU was melting.
Scanned the Logs
- Checked access.log to spot suspicious IPs and traffic patterns.
- Saw repeated, aggressive requests — likely bots or scanners.
Activated Web Application Firewall (WAF)
- Switched to paid Cloudflare plan and turned on WAF rules immediately.
- This was crucial — free plan didn’t help here.
Implemented Rate Limiting
- Configured a rule: 30 requests per IP per 60 seconds → triggered JS Challenge.
- Legitimate users passed. Bots didn’t.
Within 60 Seconds — The Website Was Alive Again.
- The server calmed down.
- Client could breathe. So could I.

Over 17,000 requests were blocked in the following hour.

🤖 “But Was It Really a DDoS?”

Some folks pointed out: “That’s not DDoS, just DoS”, or “Cloudflare did all the work”.
Here’s the truth:

Yes, it may not have been a botnet-powered DDoS, but…
Yes, Cloudflare provided tools — but I had to manually activate, configure, and test everything.
Cloudflare doesn’t magically fix things. Humans still solve problems.

💬 Community Reaction

The post exploded with reactions:

Some offered technical advice (use nginx + php-fpm limits, try k6 for stress testing).
Others questioned rate-limiting (30 req/min too strict?), server setup, or lack of auto-scaling.
Many cheered the effort and fast response. One even called me “Dr. House of IT” 😄

The best comment?

“Post-factum, everyone knows what ‘should have been done’ — but when it hits the fan, someone has to just solve it.”

And that’s what I did.

🚀 Key Takeaways

WAF + Rate Limiting saves lives — but only when turned on.
React first, analyze later — get the system stable, then optimize.
Even without experience, you can win — if you’re willing to learn fast and stay calm.
A reliable tech partner is everything — especially when no one else is available.

💡 What’s Next?

We’ll audit the site’s architecture.
Set up proactive defenses (Geo-blocking, auto-scaling?).
Train the client on basic risk awareness.
Write a checklist for future incidents.

And me?
I’m keeping this as a trophy in my tech diary.
Because when you solve a real problem in real time, that’s worth more than theory.

💬 Inspired by real events and shared with ❤️ by Olga Svitli. Support your local tech heroes — especially when they don’t give up.

selik

See Full Bio