I figured it was about time for this Gentoo powered blog to enjoy the security and performance enhancements provided by TLSv1.3. However, that meant leaving “Gentoo stable” behind and travel on a journey of discovery into the land of the unmasked and dangerous.

Earlier this week I noticed a minor brute-force attack against our managed WordPress hosting. The attack lasted for 72 hours and deployed around 2000 unique bots. The botnet attempted on average 100 logins per hour while rotating bots to avoid triggering our automatic defense systems.

I was unaware that Facebook recently had started to add a unique click identifier to all outbound links on facebook.com. Coincidentally, one of the security measures of this server is to disallow query strings as part of the URL. Thus, any visitors coming over from Facebook were suddenly blocked and banned on sight.

I’m currently experimenting with a few rule conditions to explicitly whitelist the resources I want clients to be able to retrieve on my server. The initial target for this exercise was my onion site which has an issue with misbehaving (poorly written) Tor bots, but I thought it would be fun to extend the experiment to paranoidpenguin.net.

So today I’ve experienced a more significant than usual attack against WordPress installations hosted on one of our company servers. So far I’ve blocked more than 17000 21000 unique IP addresses, but the attackers seem to have an endless supply and they’re not slowing down. Note: This article was updated on January 27, 2018.

Having a strict content Content Security Policy (CSP) can be a useful addition for your website security. However, when running a content management system (CMS) like WordPress, you’re often forced to make a few a undesired compromises.

During the last few days I’ve been noticing a major surge in botnet traffic probing for the infamous Apache Struts 2 exploit, popular database setup and configuration scripts and even some old school cgi-bin vulnerabilities. The traffic originates from compromised hosts with major cloud vendors like Microsoft Azure, DigitalOcean, Vultr, Linode and OVH.

I was recently surprised to discover that I could no longer manage my posts (invalid post type) or modify any of my installed plugins (sorry, you are not allowed to access this page). I’ve been exposed to these kind of problems before, both through database corruption and by my own hand so to speak. However, this time around everything checked out so I enabled debugging to track down the error.

I regularly spend time investigating my server logs and occasionally come across a few special snowflakes. My onion (Tor) server hosted with a popular cloud provider was recently visited by a research scanner. The scanner initially greeted the server with a few standard GET requests:

In a time-frame of just 10 seconds I got 1200 requests from the Jorgee vulnerability scanner, originating from 15 unique IP addresses. As usual it was just a blind attack probing a /24 subnet.