{"slug": "august-27-tcrf-ddos-attack-postmortem", "title": "August 27 TCRF DDoS Attack Postmortem", "summary": "The Cutting Room Floor (TCRF) suffered a DDoS attack beginning August 27, 2026, that forced host Linode to null-route the wiki's server connection, according to a postmortem published by the site. The postmortem ties the attack's timing to a ban TCRF placed on visitors using a \"Claude-code\" user agent, after a Twitter user evaded the ban and spread a false claim that a TCRF prompt-injection page wiped a virtual machine. TCRF said anti-bot proxies such as Anubis are ineffective against the traffic-flooding attack, which required a larger network pipe rather than bot mitigation.", "body_md": "…but first, a quick digression about what likely started it.\n\nOur stance on AI agents isn’t much of a secret. I recently added a new feature to *[The Cutting Room Floor](https://tcrf.net/The_Cutting_Room_Floor)*: If you visit the site with a “Claude-code” user agent… it adds you to a Claude user ban list. Then, if you try and visit the site later, *without* Claude — maybe because you wanted to investigate the “[prompt injection](https://tcrf.net/test.html)” page it received — you’re greeted with [a special error page telling you to get out](https://tcrf.net/?not-claude-just-visiting=1), featuring a pixelated Claude logo:\n\nA Twitter bluecheck ran into this, evaded the ban, then proceeded to get increasingly mad at the fact he got banned. Not only did he dig up long-inactive versions of the “prompt injection”, but he then made up an entire story about how it zeroed a VM and wiped the OS, sent that made-up sob story to our host multiple times, and then got a Twitter mob going over it. [Kotaku](https://kotaku.com/ddos-attack-breaks-beloved-video-game-wiki-after-ai-bro-was-banned-2000729335) even covered some of this nonsense. Notably, when they asked both of us for comment, I responded, while the other guy… asked Grok for legal advice on suing for defamation.\n\nLLMs rot your brain. Not even once.\n\nI mention this backstory, because the ban and Twitter meltdown happened *just before th*e attack *started*. The timing seems more than mere coincidence.\n\n## The DDoS attack itself\n\nWhen discussing DDoSes affecting TCRF, they’re *typically* done via bots or scrapers. They request hundreds of pages, trying to exhaust the server’s CPU time generating responses nobody will read. Attacks like this can be worked against with mitigation tools like [Anubis](https://anubis.techaro.lol/), which stop a bot from requesting pages until they spend a second doing math.\n\nThat wasn’t the case with this attack. The perpetrator here aimed to simply saturate the server’s network connection, overwhelming it with literal garbage traffic to a degree nothing legitimate could get through. It was bad enough, and extended enough, that Linode had to null-route (disable) our server’s connection — the DDoS traffic was starting to affect Linode’s other customers. *Their infrastructure couldn’t handle the sheer amount of garbage traffic being sent to us.*\n\nUnfortunately, anti-bot proxies like Anubis [aren’t effective for this type of problem](https://bsky.app/profile/xeiaso.net/post/3muabt6dwlk2r); you need a big enough pipe to handle all the traffic.\n\nBelow is a timeline of what happened, and what we did about it.\n\n### Pre-attack\n\n*※ (All times in this post are in Pacific Time unless otherwise specified.)*\n\nThe first point I noticed something was up can be dated to this screenshot, taken **August 27, 12:11 PM**. The main indicator is the purple segment of the CPU; this is from the system dealing with a huge influx of garbage traffic. It’s not actually *busy* work (the green and red sections), it’s just trash.\n\nWe were getting a ***massive*** flood of incoming traffic. The server wasn’t *doing* anything beyond dumping all of this in the garbage, but there was so much of that it was all it *could* do. This attack lasted for maybe half an hour, but was enough to make accessing the website nearly impossible during that time.\n\nIn retrospect, it’s possible that Linode’s automated DDoS mitigation kicked in temporarily, rather than the attacker themselves backing off.\n\n### Main attack starts (August 27)\n\nAt **7:39 PM**, another wave of the attack began, knocking things offline. The attack was sending a huge amount of trash to port 80, and even with most of it being filtered out before hitting any actual assets (either by *ufw* or *nginx* rules), traffic at that level was enough to overwhelm the server.\n\nBut before long, the traffic stopped. *All* web traffic. Even known-safe traffic, explicitly allowed through our server’s firewall, was getting dropped.\n\n### Initial investigation and response\n\nWe spent some time trying to troubleshoot. The Linode network graph showed no traffic; attempts to connect from various sources didn’t work, including ones I had specifically whitelisted in the on-server firewall. After exhausting all options, at 8:34 PM, we reached out to Linode customer support.\n\nAt **10:44 PM**, we received a reply from Linode:\n\nHello,\n\nThank you for your patience while we investigated this.\n\nWe confirmed that an automated mitigation block targeting incoming TCP port 443 traffic was triggered at the router level in response to the recent DDoS activity against your IP (tcrf.net).\n\nBecause this block is managed by our automated DDoS defense system, we do not have a specific ETA for its manual removal. However, once the DDoS event subsides and attack traffic is clear, the system will automatically remove the block and restore normal HTTPS traffic.\n\nWe are actively monitoring the situation on our end to ensure connectivity is restored as soon as traffic conditions stabilize. Please let us know if you have any additional questions in the meantime.\n\nIn short: “*There was so much traffic that we had to turn it off because it was interfering with our hardware. When the traffic subsides, it will turn back on automatically. There is nothing you can do.*” Not ideal, but, well. There’s not much we *could* do: it was simply unreachable.\n\n### Day Two (August 28)\n\nThe DDoS attack had not stopped by this point, over 12 hours. We reached out to Linode and received this response, at **8:56 AM**:\n\nHey there,\n\nThank you for following up, and I sincerely apologize for the delay and continued disruption to your service.\n\nThe automated router-level mitigation that W previously mentioned is still active as our network systems continue to handle the ongoing attack traffic against your IP. We are actively tracking the situation on our end and will reply here with an update as soon as we can.\n\nIn the meantime, please feel free to reach out if you have any further questions or if we can assist with anything else!\n\nBest regards,\n\nK\n\nAt this point, I began preparing a second server to host a “status page” while the attack was ongoing. Its only purpose was to serve a tiny HTML page (under 3 KB). We switched over the DNS entry, and presto! Status page.\n\nJob done, I got up and decided to do something else productive, like have breakfast, take a shower, maybe even run an errand.\n\n*Overexcited host voice*: You won’t *believe* what happened next!\n\nYep. Temporary site online? Better knock that one down too. And so they did; down goes the backup server.\n\nIf that wasn’t enough, our “friend” was also going after auxiliary services I run, including this very blog:\n\nIn this case, there’s nothing I can do. Most of these are simple shared hosting, not even a VPS, and in those cases I couldn’t even use something like Anubis if I wanted to; it’s entirely out of my hands. Thankfully, the attacks on the other websites *mostly* stopped after a little while.\n\nWhile all of this was going on, I had also checked to see if Linode had anything that might help. They offer a “cloud firewall”, so I inquire about it (along with the general status of things). At **8:36 PM**, I get a response, emphasis added:\n\n2026-08-28\n\nHi there,\n\nI completely understand wanting a path back online sooner rather than later. **Unfortunately, Cloud Firewall wouldn’t help in this specific case**, since the block is happening further upstream, before traffic even reaches your Linode’s own firewall rules. **The most reliable path here is letting the automated mitigation run its course**, it’s specifically designed to lift once the attack traffic settles, and that’s the resolution we’d recommend standing by for.\n\nWe’re actively monitoring the situation on our end and will let you know as soon as we see things stabilize.\n\nRegards,\n\nN\n\nWe’re keeping a close eye on this to get you back to normal as quickly as possible. Please don’t hesitate to reach out with any questions in the meantime, we’re here to help!\n\nSo, there’s *still* pretty much nothing I can do but wait, and now they’ve knocked down both the primary *and* the backup server. \n\nWell, at least it can’t get any worse.\n\n(gritting teeth) *Well, at least it can’t get any worse.* Ultimately, the other party failed to comment (again, asking Grok for legal advice instead), and you can read that whole story above.\n\nOn top of all of this… we were also getting spurious abuse reports sent to Linode / Akamai, with no details and made up URLs, forcing us to file similarly pointless “this URL does not exist, and has never existed” responses. (Linode’s response at one point included a note that they were obligated to open them, and thanked me for always promptly responding.)\n\n### Day Three (August 29)\n\nToday starts off with what seems to be good news. Linode support messages me at **7:07** AM:\n\nHello,\n\nI checked a few moments ago and I didn’t see any null routes for your IPv4 address in our system, so it looks like the attack has stopped and the service is back to regular operation.\n\nCan you please let us know how things look on your end at this time?\n\nAll the best,\n\nA\n\nThis is about one and a half days into the attack, now, and it sounds like things have finally let up. We start checking how things look on our end, and… nothing. The uptime tracker still reports it’s down; while my SSH connections are up, the traffic logs on both servers are still empty. At **7:50 AM**, we reply with our findings, and at **9:09 AM** Linode support responds:\n\nHello,\n\nI took a look at both of your Linodes to see what is holding up the traffic. We can confirm the automated mitigation blocks were removed for both IP addresses.\n\nThe block on your original IP (xx.xx.xx.xx) was cleared yesterday at 4:43 AM EDT, and the block on your secondary IP (yy.yy.yy.yy) was removed today at 11:08 AM EDT.\n\nI went ahead and reset the networking on our end to make sure everything is clear on the routing side.\n\n[…]\n\nThey also provided some advice (they offer *enterprise-level* firewalls, and a third-party proxy solution is likely best). But, we should be good to go, right?\n\nSupport and I go back and forth, troubleshooting the networking — booting into Rescue Mode, doing additional network tests — but, after several different steps… **2026-08-29 3:08 PM**:\n\nHello,\n\nThank you for confirming that for us. I wanted to confirm that our engineers are actively investigating this with us now. They have discovered that the IP xx.xx.xx.xx is currently being filtered as a result of our DDoS protection, and I can confirm that the current connectivity issue to that IP is a result of that block.\n\nThey are currently working to remove that block if they determine that traffic has returned to safe levels. We will keep you updated on this and will share any new information as it becomes available. We have noted the urgency of this situation to those involved, and so we are working to resolve this as soon as possible.\n\nThank you for your continued patience throughout this. Please don’t hesitate to contact us if you have any questions in the meantime.\n\nRegards,\n\nC\n\nFrom 7 AM to 3 PM, I was sitting around my desktop, stuck between running various troubleshooting/diagnosis steps, and waiting for support replies… and, well, it was all for naught. The block was never lifted. The attack hadn’t ended. Support confirmed this at 3**:49 PM**  after I asked them to clarify the discrepancy, emphasis added:\n\nHello,\n\nI apologize for the confusion. The message you’ve quoted from my teammate V was based off of the information and monitoring that our Support team had available to us at that time, which indicated the block had cleared.\n\nBecause connectivity had not resumed after our Support team observed messages indicating a removal of the block, we then requested additional investigation from our internal teams. **Further investigation with those teams has now confirmed that the block has remained in place for the duration, and has not actually been lifted.**\n\n**They have also now confirmed that the DDoS attack traffic targeting your Linode IP has not returned to safe levels since its initial onset, which occurred about an hour prior (August 27 around 10:35pm ET) to you opening this ticket.**\n\nSince the volume of the traffic is still high at this time, the DDoS mitigation block remains in place and will be removed automatically once the traffic to the IP returns to acceptable levels.\n\nAt this point, the attack has been going on for **1 day, 20 hours**: 8/27 7:35 PM to 8/29 3:49 PM.\n\nI get up and take a break for a while, to consider next steps. It’s clear waiting isn’t going to work. Whoever is doing this has more money than sense. Since it’s pure trash traffic, something like Anubis won’t help. We need a [layer-3 service](https://www.fastly.com/learning/security/what-is-a-ddos-attack#what-is-a-layer-/-ddos-attack) that can handle it.\n\nIt’s not much of a secret that [I’m not the biggest fan of Cloudflare](https://blog.xkeeper.net/the-cutting-room-floor/self-hosting-and-junk-traffic/). I settle on trying out one of their competitors: [Fastly](https://fastly.com/).\n\n#### Life in the Fastly lane\n\nFastly has (had?) an “[Under Attack](https://web.archive.org/web/20260826091354/https://www.fastly.com/under-attack)” link in the header, which suggests [signing up for an account](https://www.fastly.com/signup) and routing your traffic through “Fastly’s DDoS mitigation”. So I do, setting it up in front of our backup server. While Linode won’t let me assign a *new* IPv4 to the attacked machine outright, it *will* let me *swap* IPs… so I make a new Nanode™, swap the IPs around, and now the backup server has a fresh IP address. Nothing to it.\n\nMy initial impression of Fastly isn’t too bad. We get it online around **Aug 30, 12:00 AM**. I set a $10 monthly spend limit, get things configured, and before long, the backup server is back online! I’ve spruced it up a bit by this point to feature some simple icons and status updates as things progressed.\n\nJob done. Backup site online. I go to bed.\n\n### Day Four (August 30)\n\nLinode reaches out this morning at **10:37 AM** (2 days, 15 hours into the attack):\n\nHello,\n\nThe attack appears to be ongoing. If you would like to try and access your linode using another IP, you can try adding a second one to see if you can use it to connect, as P said before.\n\n[…]\n\nThey are suggesting *more or less* what I’ve done with the backup server: a second IP address that we keep private. We’re going to do just that, and the backup server is the preparation for it. Making sure configurations and such set are up before unleashing it on the “real” server.\n\nSo far, so good! Everything’s coming up Milhouse.\n\n#### Move to Fastly and things break\n\nWith almost *comical* timing, at **11:00 AM**, I get an automated e-mail from Fastly:\n\n**Spend limit exceeded**\n\nYour spend limit for the month is set to $10.00. Your current month-to-date spend is $21.00. You can monitor usage in real-time using Observability.\n\nTo view products with the most usage visit the plan usage page on the Fastly Control Panel.\n\nUhhhhhhhhhhhhhhhhhhh*hhhhhhhhhhhhhhhhhhh*. Keep in mind that the *entire backup site* is about 25 KB uncompressed. Let’s check out that Observability:\n\nOur simple downtime page has accumulated nearly 700k requests in 14 hours. (The full wiki typically serves about 5,000k/day.) Is that a lot for Fastly? I’m not sure. I’m confused as to how I spent $20 already. Let’s check out that plan usage page…\n\n*Excellent!* I understand everything now.\n\nAt some point, *some* page reveals it is the “DDoS protection” I activated:\n\n$20 on DDoS protection. I checked whatever page it was, and it said it had blocked exactly 0 requests and allowed 100% of them. I’m not really sure what it *did*, other than cost money. Since it had a literal 0% block rate, and it was something I activated *on top of* the basic account, I cancel it.\n\nAt some point around **August 30, 2:30 PM**, about 15 hours after we started using it… *Fastly suspends our account*.\n\nI have no emails, no notifications, no *anything* to indicate why. I am not sure what the “violation” is. We joke that it’s because I griped about their billing interface while *Carnival Night Zone* played. I send a support email at 2:46 PM.\n\nWe’ll skip ahead in the timeline momentarily to their response (**Aug 31, 11:17 AM**, almost a full day later), as Fastly exits the story afterwards:\n\nHello X,\n\nThank you for your patience while I worked with internal teams on finding the cause here.\n\nWe were able to see the cause of the account being turned down was marked as **Excessive Bandwidth Usage,** and was disabled for bandwidth abuse. This appears to be because the account was a Dev account, and those are generally used for testing functionality or creating a POC, and not fielding that volume of bandwidth.\n\nI’ll be honest: in the process of writing this (currently **9/23**), I had to go check the archives to double-check that the instructions said, quote,\n\n**Under active attack?** Create a free account to route your traffic through Fastly’s network in minutes for immediate DDoS mitigation.\n\nWhat they *don’t* tell you is that the “immediate DDoS mitigation” is also measured in minutes (~900). At least for us.\n\nThe funniest thing about it happened a few days later, when this message hit my inbox:\n\nI had high hopes for Fastly, but pretty much every step (aside from initial setup!) was a blunder.\n\n#### Meanwhile…\n\nBack where we were, something else was happening to the backup server:\n\nIn my haste to get Fastly set up, **I had made a critical opsec error: Make sure the backend server *only accepts requests from authorized frontends.*** (In practice, this just means “drop all traffic except for the specific proxy origins they give you”, it’s not that scary.)\n\nI suspect that our attacker scanned Linode’s IP space and found the backup server by simply asking each one for our site, until he found the one that gave it. Oops. Oh well, lesson learned. We made sure to add the firewall rules *first* next time.\n\n#### Enter Cloudflare\n\nAt **Aug 30, 3:52 PM**, *tcrf.net* was added to Cloudflare. At **6:17 PM**, “Under Attack” mode was activated, and has remained on since. We decided to leave the backup server in place for a while until we could be sure everything was ironed out, set up some basic rules, etc… and it was a good thing we did: around **6:12 PM**, we were hit by a DDoS *through Cloudflare*:\n\nThe perpetrator of *this specific attack* ***directly reached out to me via Telegram and Discord***. I immediately blocked both. (I don’t have any solid evidence that any other attacks were related to this person.) Aside from that *event*, things were smooth: the backup site stayed online.\n\n### Day Five (August 31)\n\nI send a message at **10:18 AM** thanking Linode for the extra IP address, and mentioning that I’m curious if there’s any clue as to just *how much* traffic has been blasting our server.\n\nLinode greets me with an update relatively early, at **10:52 AM**:\n\nHi,\n\nThat’s very understandable, and I agree that this attack seems unusually sustained and targeted. […]\n\nDue to security concerns, we generally aren’t able to share the specific amount or kind of traffic that will trigger our null routing, but I can confirm that this does seem to be quite a large scale attack. I also confirmed that the attack is still ongoing, as a block was just temporarily removed and then re-added a little bit ago.\n\nPlease let us know if you have any other questions for our team during this time, we thank you for your patience. We’ll provide any important updates here as we receive them\n\nRegards,\n\nB (he/him)\n\nWe’re now **3 days, 15 hours** into this attack. I really, really wonder how much something of this scale costs.\n\nI spent most of the rest of the day preparing the main server to be online again, cleaning out older firewall rules for newer and simpler ones, preparing the Linode Cloud Firewall for Cloudflare traffic, and otherwise getting ready for the relaunch.\n\n### Day Six (September 1)\n\n**Midnight, September 1 — 4 days, 4 hours after the attack started — we’re back online.** There’s a few tweaks to be made, security settings to be tweaked, and so on, but the site is back and browsable for everyone. The attack itself wouldn’t end for several days yet, but **it was now fully mitigated**.\n\n### The End (September 9)\n\n**September 9, 12 PM — 12 days, 16 hours after the attack began — it ends.** Incoming garbage traffic finally disappears from both the main and backup servers.\n\nAt **4:22 PM**, Linode support confirms that it’s over, and their automated mitigations have ended:\n\nHello,\n\nI checked both of those IPs and it looks like the last networking block was removed around the same time that you also noticed the traffic dip, potentially indicating an end to these attacks! We’re going to keep this ticket open for a few more days just to make sure that things have actually subsided, feel free to reach out with anything else in the meantime.\n\nRegards,\n\nB (he/him)\n\nFinally.\n\n## Ongoing Attacks\n\nWhile the main DDoS attack ended, we still see sporadic HTTP-level attacks, lasting about 10 minutes each. They’re relatively infrequent, perhaps one or two per day, and not enough to majorly disrupt service. We can just tell people “yeah, wait a few minutes and it’ll work”; we’re still working to mitigate even *those*, but it’s a lot less critical now that the site is back to 99.5% uptime 🙂\n\nFor similar reasons, we recently had to implement Cloudflare for our [Rusted Logic](https://rustedlogic.net/) domain. Publishing this post (and drawing attention to the attack, again) means that it’s very possible I’ll have to put this blog and the rest of [xkeeper.net](https://xkeeper.net) behind it, too. At least the process has been relatively painless.\n\n*To whoever is doing this: hi, please find a hobby that isn’t trying to take down my sites.*\n\n## Positive Outcomes\n\nIn the process of mitigating, migrating, and updating things, we’ve made a lot of upgrades and improvements to the wiki and infrastructure:\n\n- Improved caching / distribution\n- Full IPv6 support\n- Automatic blocking of many bots and other nuisances, including Tor exit nodes\n- Unblocking most VPNs\n- Better embeds for Discord, Bluesky, etc.\n- Cloudflare’s automated Wayback Machine archiving\n- Better security, firewall, etc.\n- Support for HTTP/2 and HTTP/3\n- Basic analytics (more than simple nginx logs, at least)\n- Potentially more benefits?\n\nMy eventual goal is to have a non-Cloudflare proxy for logged-in users, so that people who can’t access it through Cloudflare can still view the site (e.g. ancient hardware, etc). But that’ll come once we finish getting the software more up to date and such; for now I’m just enjoying some (relative) peace and quiet.\n\n## Closing thoughts\n\nI’d like to thank everyone for their patience and support while we weathered this attack. The support helped keep us going during the long nights spent trying workarounds and troubleshooting, and ultimately we came out of it stronger and better than before.\n\nIf you’d like to support us and the wiki, consider [joining our Patreon](https://www.patreon.com/c/tcrfwiki) or [supporting us via Ko-fi](https://ko-fi.com/xkeeper). As always, thank you; it means a lot to us.\n\n(Please keep any comments respectful.)", "url": "https://wpnews.pro/news/august-27-tcrf-ddos-attack-postmortem", "canonical_source": "https://blog.xkeeper.net/the-cutting-room-floor/tcrf-2026-ddos-postmortem/", "published_at": "2026-09-24 19:46:22+00:00", "updated_at": "2026-09-24 19:59:48.269329+00:00", "lang": "en", "topics": ["ai-agents", "ai-crawlers", "ai-safety"], "entities": ["The Cutting Room Floor", "Linode", "Anubis", "Claude", "Kotaku", "Grok", "Twitter"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/august-27-tcrf-ddos-attack-postmortem", "markdown": "https://wpnews.pro/news/august-27-tcrf-ddos-attack-postmortem.md", "text": "https://wpnews.pro/news/august-27-tcrf-ddos-attack-postmortem.txt", "jsonld": "https://wpnews.pro/news/august-27-tcrf-ddos-attack-postmortem.jsonld"}}