Inside a 25 Million Request L7 DDoS Attack: A CatProxies Case Study

In June 2026, catproxies.com absorbed an application layer DDoS attack that generated 25.7 million requests in a 24 hour window. I run the infrastructure behind CatProxies, and I watched most of my carefully written firewall rules match almost nothing while the flood was live. This post documents what the attack looked like, which defenses worked, which failed, and the configuration principle that came out of the incident. Every number comes from our own traffic analytics during the attack.

Quick Answer

A distributed L7 HTTP flood using spoofed real-browser user agents will pass through signature-based firewall rules untouched. In this incident, rules targeting empty user agents, scanner tools, missing host headers, and legacy HTTP versions matched between zero and two events each. The mitigation that worked was an automated, reputation-based managed challenge, combined with a later restructuring of the firewall from blacklisting attacker signals to whitelisting the legitimate structure of the site itself.

How This Was Evaluated

All figures come from edge security analytics and firewall event logs covering the 24 hour attack window, reviewed while the attack was still partially active. The review compared each active firewall rule against the number of events it matched during the flood. AI-assisted analysis was used to structure the post-incident review of the rule set; all observations and data are firsthand.

What Is an Application Layer (L7) DDoS Attack?

An application layer DDoS attack floods a website with requests that look like normal web traffic, forcing the server to spend real resources processing each one. Unlike volumetric L3 or L4 attacks, which try to saturate bandwidth, an L7 flood targets the application itself: page loads, form submissions, and API calls. Because each request resembles a legitimate browser visit, L7 attacks are significantly harder to filter. The Cloudflare Learning Center provides a general overview of application layer DDoS attacks and why they evade simple filtering.

Anatomy of the Attack

The flood peaked over roughly one hour and produced the following totals across 24 hours:

Three characteristics defined the attack.

First, it was POST-heavy. POST requests are more expensive for a server to process than GET requests, and nearly 60 percent of the flood used them.

Second, every request carried a spoofed real-browser user agent. The traffic identified itself as Firefox, mobile Safari, and mobile Chrome in almost equal shares of roughly 5.6 million requests each. Nothing in the headers distinguished it from human visitors.

Third, the botnet was wide and globally distributed. No single IP address dominated. The top source IP produced only 153 thousand of the 25.7 million requests. Traffic originated mainly from Iraq (3.01 million), Brazil (3.01 million), Bangladesh (1.62 million), the United States (1.30 million), and Turkey (1.30 million), with a long tail across many other countries. The botnet operated from residential and mobile networks rather than datacenter ranges. Running a proxy business provides a useful vantage point here: this is the same address space that legitimate residential proxies operate in, which is precisely why ASN-based blocking of hosting providers matched almost nothing.

The sampled request paths showed the bots hammering random, nonexistent PHP paths such as /eee.php and /xamp.php. The site does not run PHP at all, yet each of those requests still reached the application and consumed resources. The roughly 7.6 million requests that reached origin forced a temporary server upgrade that roughly tripled monthly hosting costs while the incident was handled.

What Actually Stopped the Attack

The overwhelming majority of mitigation came from the edge provider's automated managed challenge, which scores request reputation and issues a verification step to suspicious clients. Custom firewall rules contributed a small fraction of blocks. An emergency mode that challenges all visitors handled the remainder during the peak.

The post-incident rule review produced the most important finding of the whole event. Four signature-based blocking rules were active during the attack: block empty user agents, block known scanner user agents, block requests without a host header, and block HTTP/1.0 POST floods. Their combined match count during 25.7 million attack requests was approximately two events. Not two million. Two.

The rules were not misconfigured. They were aimed at the wrong target. Every signal they inspected, the user agent string, the HTTP version, the host header, is fully controlled by the attacker. A modern botnet simply sets those values to look like a real browser, and it did.

The Fix: Whitelist Site Structure, Not Attacker Signals

The principle that came out of the incident is simple to state. Stop writing rules that describe what attack traffic looks like, because the attacker decides what attack traffic looks like. Instead, write rules that describe what the site actually is, because the attacker has no control over that.

The rebuilt firewall applies this in three layers. Requests to path patterns the site has never served, such as PHP files, WordPress paths, and configuration file probes, are blocked outright. The site knows its own URL structure; anything outside it is junk by definition. POST requests are denied everywhere except the small set of route groups where the application legitimately accepts them. A POST flood aimed at arbitrary paths now dies at the edge instead of reaching the application. Signature rules against crude clients remain in place as cheap insurance against unsophisticated attacks, but they are no longer treated as the primary defense.

Rate limiting was also rebuilt around the same idea. A single global per-IP limit does very little against a wide botnet, because each of thousands of IPs stays comfortably under any reasonable threshold. A limit scoped tightly to expensive endpoints, such as authentication routes, protects what actually needs protecting without throttling normal browsing.

This restructuring matters for any site evaluating its own firewall, including teams running cyber security workloads that need to distinguish hostile automation from legitimate traffic.

When This Approach Will Not Work

Structural whitelisting has clear limits. It does not help when the flood targets endpoints the application genuinely must accept, such as a login route or a public API. Those paths still depend on reputation-based challenges, scoped rate limits, and capacity. It also does nothing against volumetric L3 or L4 attacks, which must be absorbed at the network edge before they reach any firewall rule. Finally, it assumes the site has a stable, known URL structure; applications with highly dynamic or user-generated paths cannot define "junk paths" as cleanly.

Common Misconceptions

"Blocking the top attacking countries stops the attack." In this incident, the three largest source countries together produced roughly 30 percent of the traffic. Blocking all three would have cut volume but left the attack fully operational, and the operator could shift regions within minutes. Geographic blocking also punishes legitimate visitors in those countries.

"Custom user agent rules protect against botnets." Modern botnets spoof current browser user agent strings exactly. The user agent is attacker-controlled text. During this attack, user agent based rules matched effectively zero of 25.7 million requests.

"Per IP rate limiting stops a DDoS flood." It stops a flood from a small number of sources. Against a distributed botnet where no single IP exceeds a normal browsing rate, a global per-IP limit is nearly invisible to the attack.

"If a CDN or edge proxy sits in front of the site, the origin is safe by default." Roughly 29.6 percent of this flood, 7.6 million requests, still reached the origin server. Default protection reduced the attack; it did not eliminate it. Configuration determines how much leaks through.

FAQ

Does Cloudflare stop L7 DDoS attacks automatically?

Partially. Automated reputation scoring and managed challenges mitigated roughly 70 percent of this flood with no manual intervention. The remaining traffic reached the origin until emergency challenge mode and restructured rules closed the gap. Automatic protection is a strong baseline, not a complete defense.

Why do user agent blocking rules fail against modern botnets?

Because the user agent is a plain text header the client writes itself. Botnet software copies the exact strings used by current Firefox, Chrome, and Safari builds. A rule matching "suspicious" user agents only catches tools that do not bother to disguise themselves.

How can you tell traffic is a botnet rather than real users?

Individual requests look legitimate, so detection relies on aggregate patterns: a sudden spike in POST volume, requests to paths that have never existed on the site, an unusually flat distribution across thousands of IPs, and traffic geography that does not match the normal audience. In this incident, requests to nonexistent PHP paths on a site that does not run PHP were the clearest single indicator.

Does blocking countries stop a DDoS attack?

No. It reduces volume in proportion to how concentrated the attack is, and distributed attacks are deliberately not concentrated. It also blocks legitimate users from entire regions, which has a direct business cost.

What is the difference between an L7 attack and a volumetric attack?

A volumetric (L3/L4) attack tries to exhaust bandwidth or connection capacity with raw packet volume. An L7 attack sends fewer, well-formed HTTP requests designed to consume application resources such as CPU, database queries, and backend processing. L7 attacks are smaller in bandwidth terms but harder to filter.

Final Notes

The incident cost one temporary server upgrade and an evening of analysis. It also produced a firewall that is built around what the site is rather than guesses about what attacks look like, which is a trade most site owners would take. CatProxies continues to operate its full proxy lineup, with current plans listed on the pricing page. A portion of every CatProxies plan funds monthly donations to cat shelters.