What was the nature of the DDoS attack in February 2026?

It was a massive Layer 7 HTTP flood targeting the main blog application, peaking at an unprecedented 233,780 requests per IP address.

How did the attackers bypass standard security?

They used a highly targeted approach with legitimate-looking HTTP requests from rapidly rotating IP addresses, avoiding detection by basic rate limiters.

What mitigation strategy worked against the Layer 7 DDoS attack?

The successful strategy involved implementing strict WAF rules, temporarily enabling Cloudflare's Under Attack Mode, and shifting defense mechanisms entirely to the edge network rather than relying on origin server rate limiting.

Infrastructure

Surviving The DDoS Wave

Holding the line against 230k requests per IP.

March 2026•4 min read•Security • Infrastructure

The Attack

It started like any other week, until the traffic graphs hit the roof. The attack began as a broad wave from South Asian botnets, averaging around 153k requests per IP. But quickly, it shape-shifted.

The attackers pivoted to highly targeted Eastern European floods. At its peak, we recorded an insane 233,780 requests/IP coming from networks like Magti-BROADBAND in Georgia. They weren't just probing; they were trying to punch a hole straight through our origin server.

IP Address	ASN / Org	Country	Total Requests
94.240.207.152	AS16010 Magticom Ltd.	GE	1.48M
95.137.180.45	AS34797 System Net Ltd	GE	1.32M
176.221.148.222	AS35805 JSC "Silknet"	GE	1.30M
223.181.10.105	AS24560 Bharti Airtel Ltd.	IN	154.08k
122.178.131.191	AS24560 Bharti Telenet Ltd.	IN	138.19k

Traffic spike on Feb 17

Why Standard Defenses Failed

Our initial reaction was to rely on built-in safeguards. We turned on Cloudflare's "I'm Under Attack" mode and deployed aggressive Rate Limiting (500 req/min). It wasn't enough.

The Rate Limit Bypass: Because the botnet was so highly distributed across tens of thousands of unique residential IPs, individual nodes stayed quietly under the 500 req/min limit. As a result, over 2 million malicious requests bled directly through the filters to our origin.
The SEO Collateral Damage: Leaving "Under Attack" mode on acted as a blunt instrument. While it caught some unsophisticated bots, it completely blocked Googlebot from fetching pages and destroyed our social media link previews (like WhatsApp). It simply couldn't be a permanent solution.

The Dilemma

When infrastructure is hit with this much traffic, the instinct is to drop the hammer: just block the entire ASN. But that's a trap. Recent large and powerful botnets are increasingly using IPs from major retail ISPs (like AT&T, Comcast, and equivalent regional providers). Because of this, it's virtually impossible to block ASNs without immediately dropping thousands of legitimate users who share those same networks.

We had to hold the line with pinpoint IP-level blocking.

Holding The Line

We leaned heavily on the Cloudflare WAF. We manually identified the top offending IPs and added them to custom block lists to drop the traffic right at the edge. By blocking at the IP level rather than the ASN level, the site stayed up and legitimate traffic flowed perfectly fine.

Cloudflare WAF Custom Rules mitigating the attack

Peak Throughput

233,780 requests per IP hitting the edge layer.

Origin Survival

Origin latency remained unaffected due to edge-level drops.

The Realization

While we survived, I realized something important: manually blocking hundreds of IPs while under fire is absolutely exhausting.

Cloudflare's real-time rate limiting is powerful, but running it on every single request gets incredibly expensive. There had to be a way to automate IP reputation checks based on analytics, dropping bad actors into custom WAF lists automatically without paying a massive premium. So, I decided to build it myself.