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.

I recently added support for the HTTP/2 protocol on this server and I am really pleased with the additional performance gains. This VPS was already running a functional LAMP stack, so the following steps describe the necessary configuration changes for my setup which relies on Apache with PHP-FPM.

This Scaleway hosted Gentoo x86_64 server (VC1S with 2 cores and 2GB of RAM) has finally completed the move to the new Gentoo 17.0 profile. Rebuilding my entire system consisting of 277 packages lasted 26 hours and went by without any issues. All packages were re-emerged with --jobs=1 to keep the system responsive during compilation, and to avoid exhausting available memory.

So the 34. Chaos Communication Congress is currently in progress and the boys (and girls) attending were kind enough to send some thoughtful wishes to working sysadmins around the globe. The following entry appeared in my server log earlier today:

Now that I’ve been running this blog on Gentoo Linux for a while, I’ve discovered a few new potential gotchas when failing to pay attention while interacting with Portage. The latest addition to my list was nearly removing my running PHP installation with emerge --depclean.

On the 18th of December Wordfence posted the following entry describing an ongoing distributed brute force-attack campaign targeting WordPress installations. It was accompanied by a dramatic chart highlighting the number of attacks per hour. According to Wordfence, it was the most aggressive campaign they’ve seen so far. However, as a WordPress hosting provider I’ve found no data to support these claims.

I’ve not experienced any increase in dictionary attacks or other malicious traffic against WordPress installations on our web hosting platform. Curiously enough, this would mark the first time that we have completely dodged such a large scale attack.

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.

I’ve received a few hundred requests originating from bots setting site.ru as their referrer. These attacks are scanning for compromised WordPress installations and PHP based shells and backdoors. The attacking IP’s belong to compromised hosts and websites from service providers around the world.

I wanted to register a new domain name and decided to go with the privacy-aware domain registration service from Njalla. Unlike other domain registration services, Njalla actually purchases the domain for themselves and acquires full legal ownership and responsibility for the domain name. Njalla however grants you full control over the domain as long as you abide by their terms and conditions.

About one and a half months ago I experienced a lot of botnet traffic originating from major cloud providers including Microsoft Azure. Against my better judgment I decided to see if reporting a few bad IP’s to the MS CERT team would make a difference.