The Cutting Room Floor, a wiki cataloguing unused video-game content, spent the end of August offline. Its operator published a day-by-day postmortem of the DDoS that did it: attack begins August 27, the site is back behind proper mitigations four days later, and the garbage traffic finally stops on September 9 — twelve days and sixteen hours after it started.

The mechanics are the interesting part, because they invalidate the defenses most small sites have:

  • The flood saturated the server’s network connection with pure garbage, with peaks around 1.6–2.0 Gbps
  • The server was not busy; CPU time went to receiving and discarding packets, so there was no application work to protect
  • Anti-bot proof-of-work gates like Anubis stop scrapers that exhaust CPU. They do nothing against a bandwidth flood, which needs pipe capacity and upstream scrubbing
  • The hosting provider’s automated mitigation null-routed the IP: all traffic dropped, including IPs explicitly whitelisted in the on-server firewall, with no ETA and no customer override
  • The provider’s Cloud Firewall product could not have helped — support confirmed the block sits upstream of the firewall rules

Two secondary lessons are worth more than the timeline. A hand-written status page on a second machine was knocked offline within hours, so “put up a status page” is not a mitigation. And when a mitigation vendor was brought in mid-incident, the advertised immediate DDoS mitigation took roughly 900 minutes, the DDoS-protection add-on blocked 0 of 3.9 million requests while billing past the spend cap, and the account was suspended fifteen hours in for excessive bandwidth usage — on a dev-tier account doing exactly what the vendor’s own “under active attack?” page told it to do.

The one mistake the author takes on himself is the most copyable: in the rush to put a proxy in front, the backend kept accepting requests from anywhere. The attacker scanned the provider’s IP space, asked each address for the site, found the unproxied origin, and knocked that over too.

The takeaway is a boundary worth remembering. A CPU-exhaustion attack is an application problem, and application controls (firewall rules, bot checks, caching) address it. A volumetric flood is a transit problem, and the only real answers are upstream capacity and a scrubbing layer you control — plus an origin that refuses traffic from anywhere else, configured before the attack rather than during it. Once a provider’s automated mitigation engages, the site operator has no lever at all.