By now most people have gotten up to speed with latest news regarding the attack against the Linux Mint infrastructure and the ripples it created within the Mint community. If not, here is yet another quick and superficial recap:

• The Linux Mint website was compromised.
• The Mint forum database containing 145k accounts was sold online.
• The Mint 17.3 Cinnamon edition was reassembled and bundled with malware.

Due to a city wide power outage I lost just short of 300 days of uptime on the RPi2. The RPi2 did boot back up when the power returned, but since I had received a new IP address I needed to make a DNS update before the server was reachable again. That’s obviously the downside of running a server on a dynamic IP space, but hey it doesn’t cost me a cent. I have a 300 seconds TTL (Time To Live) on my blog.paranoidpenguin.net A record so I think it’s good enough for a hobby project.

The symptom is rather ominous, your wp-content/cache/supercache folder is suddenly populated by additional domain name folders having no connection to your website. What could have caused this? Has your website been compromised or is there some reasonable explanation for this behavior.

Who would have thought, right? :-)

After installing my certificate from Let’s Encrypt last week I was immediately confronted with the fact that I had made the wrong choice in regard to key sizes. By using a 4096-bit private key I was relying too heavily on the RPi2’s CPU. This became abundantly clear as page load times were increased by 500 – 1000ms.

So you’re hosting your own WordPress blog on a Raspberry Pi 2 and want to join the HTTPS everywhere movement to ensure optimal privacy for your visitors. That’s great, but what kind of performance penalty can you expect as CPU intensive tasks are hardly a favorite with the RPi2. Is the extra computational cost of encrypting data and doing handshakes going to significantly slow down your site?

Well, you can probably answer that question yourself as your browser has just loaded this page over a secured TLS connection. Though WordPress can still serve static content generated by my caching plugin, there is no hiding the additional burden of doing handshakes and encryption. On my RPi2, the extra overhead is between 500 – 1000ms depending on latency.

I had some issues today with the Akonadi server failing on my Slackware 14.1 box at the office, so I resorted to killing X for a quick revival. However, issuing startx only resulted in the following errors:

By working in the “web business” I do get my hands on a fair share of malware kits as attackers continuously try to infect any website available with their automated scripts.

I woke up this morning to a mail informing me that WordPress had been upgraded to version 4.4.1. Shortly after I tried to access my blog to verify that everything had gone smoothly, but unfortunately my webserver showed no sign of life. Since I’ve previously had a few hard learned lessons with the RPi2, that made me a bit uneasy. A couple of hours later though, as I was reviewing my logs, the problem became pretty obvious:

Distrowatch had an interesting “feature story” on Void Linux last year that caught my attention. Though the review painted a rather bleak image of the distribution, it still came through as an original project with some exiting features.

So the “DELETE your logs” message hit my server last night and at first glance it does look like a HTTP DELETE request :-)

However, this is not a delete request or even a valid HTTP request. Since I’m running ModSecurity it got rejected, but most servers will just throw a “400 Bad request” response. The user agent string “masspoem4u/1.0” identifies the messenger as a bot, and it’s probably misbehaving by design.