I don't use WordPress. Not on my servers anyway. I think I have a small thing on WordPress.com, but I don't use it.

This blog uses PHP, for now. This software is no longer supported and I have aspirations to port the content to a different system, or even just static pages. I don't post enough to need a big system. Few people comment, so I can probably ignore that, and most of the comment attempts are blocked by the anti-spam feature of this site, mostly stupid track-backs to malicious sites.

Regardless, it isn't WordPress.

Still, my server gets thousands of "/wp-*" requests a day. Not just this server, or just this path on the server, either. All of the sites I host, including a couple with domains pointing to my server but no content, get these requests. And many also get a flurry of PHP page requests, even though I use very little PHP. I have a mail app, this blog (on several sites), and one "is it up?" kind of page that makes a simple DB query to ensure the database is up.

I made a trap for bad actors. In addition to putting a "disallow" rule in every site's robot.txt, I used a small app to generate garbage pages. The pages were essentially HTML formatted like a blog page, but with random words pulled from the server dictionary, instead of real content. In the pages I created garbage links made of more random words, back to the garbage pages. When a PHP page was requested. in a domain that didn't have them, or in the case of those "wp-" paths, I would return a response from this garbage generator, or redirect them to the garbage pages. In all of that, I added "nofollow" directives, headers, and whatnot to all the page links and responses so that any reasonable bot would not go into the trap. 

But they did. Boy, did they!

I unintentionally created a DDOS attack on my own servers! What I expected, was that the bad actors would get garbage, waste a little time, and go away. What happened instead is they continued to follow the random links. Every page had a few more random links, with "nofollow" directives, which they would still follow. Hundreds of thousands of requests every day, generating millions of new links for them to follow.

Whoops.

So I changed the page to no longer create links. Still waste their time, indexing and training on garbage, but not send them more garbage to follow. I let that sit for a while while I tinkered with making a different garbage page that would interact with my local AI to create pages that at least contained readable garbage. Still keyed on the words in the random paths of the links, but meaningless. I spent a couple days on it, and kind of like the results, but the AI takes a couple seconds to generate a paragraph containing three words, at its fastest. The random word pages take a few milliseconds to generate.

While I tinkered with this for the few days, the hits didn't slow. I guess there are so many queued paths in some of the parsers that they'll likely hit for a while.

This has caused a side problem with abusing my logging server. The sites in containers that do this garbage trickery all send their access logs to one server for aggregation into the log analyzer. Those logs were hitting tens to many-tens of gigabytes a day, instead of the normal few to dozens of megabytes. This was causing the log server storage to fill, even though the logs are compressed or removed after some time.

I had enough, so I spent some time looking at my CDN, Cloudflare,  to see if I could stop the requests there, instead of fighting it in every site I host. It took a little digging and experimenting in the interface, but I eventually found I could add the simple Security Rule (starts_with(http.request.uri.path, "/wp-")) or (ends_with(http.request.uri.path, ".php"))and all the attempts were stopped. I had to modify the rule a little for the sites that do use PHP, but they work on specific paths, so it was an easy add.

Within moments of deploying the rule on each site, the logs started slowing, as the traffic was stopped at the CDN.