It'd be only suiting that the first articles deal with my experience setting up this blog. I'm very much a hands-on kind of person; others might prefer to call me a control freak.
I have a number of VMs from different providers for personal use: my email, my git repositories, my Ubuntu archieve and now my brand-new blog. I am comfortable administrating various network services or developing my own network services and applications, from a security point of view; not so much with third-party web applications; somehow, silly vulnerabilities keep getting found in some of the most popular products.
The possible risks
Security is a compromise; in our case, the most secure blog is the one that doesn't exist. Having already decided against that option, I put my security analyst hat on. A sensible approach to security means weighing risks against functionality, convenience and cost. Once a number of options are considered, a risk assessment would be a sensible next step.
So let's take an informal approach and see what I'm risking here:
Having data stored by the blog stolen. The articles on the blog are public. I won't have a newsletter, so no data that doesn't belong to me; the only personal data belonging to me stored by the blog is my email address (which already receives lots of spam). I will use a unique password. Worst-case scenario, draft articles are made public. Whatever.
Having the blog defaced or made unavailable. I'm not earning any money from this, so nothing a good backup strategy can't solve. Embarassing, nevertheless.
Having malicious code injected in the public pages. Now here's a risk that opens up a world of possibilities! Unlike those before it, the main target would be the blog's readers. Quite a few vectors could allow this to happen. Unfortunately there is fairly little I can do (apart from choosing the most secure blog platform out there), as it's up to the blog's developers to enforce a good security model. I do promise to check the served pages every now and then (in addition to all other activities a security-conscious sysadmin would regularly engage in). If your CPU goes to 100% or your mobile device gets hot while visiting this blog, close the window and don't return; you might be unknowingly mining bitcoin.
Out with the current cryptocurrency craze, another likely attack would be to replace any social network integrations with phishing sites, thus targetting those that might want to interact with the blog. This is always a risk on any site you visit, so the best defense is to always ensure you're only providing sensitive credentials to the real social networking site. If in doubt, don't share any articles and don't comment on this blog.
Other client-side vulnerabilities or security issues in web applications you use (e.g. CSRF) would open up even more possibilities. In effect, the end-result would be the same as if you visited a malicious website. For me, it would be a considerable blow to my reputation. It's worth mentioning here that visiting dodgy websites in private/incognito mode offers more than just a clean browsing history.
Arbitrary code execution. This pretty much completely compromises the service, allowing all of the above to happen. And more. The issue here is limiting the impact, as much as possible, to the blog. There are several possible scenarios that can arise:
- Other services I am running can be compromised. Needless to say, we don't want that.
- Becoming part of a botnet. My blog software being used to send spam, spread viruses or be part of a DDoS attack would be pretty embarassing.
In terms of blogging software, I don't think there's any doubt that Wordpress is by far the most popular product. Looking at the vulnerabilities exposed for it, however, I simply couldn't feel comfortable running with it. I settled on Ghost. It's been described as an overrated platform whose popularity is due to being built on hipster technology. Fair enough. And I certainly don't expect it to be vulnerability-free.
But so far there's nothing really disturbing about it. Its functionality is minimal, but sufficient. It's clean and decently efficient. I don't quite understand how it cannot have support for automatic image resizing and optimisation and img srcset, but then again, what blogging platform does? Overall, it's just fine.
I contemplated using a dedicated VM which I wouldn't invest any feelings in, but in the end decided to find an elegant way to isolate, as much as possible, the blog application from the rest of the system. But there's no fun in jumping straight to the conclusion, so let me explain the thought process that went into eliminating the VM idea:
- More management work: a fully-fledged VM means more work goes into administrating it.
- Isolated, but less convenient: taking another VM would eliminate any risks to other services I am running, but fully isolating it would mean that I can't allow it to communicate with anything else from my infrastructure:
- My LDAP services for authentication
- My mail services for system email
- My backup processes
- My git repositories for any customisations
- Harder to not become part of a botnet: after all, the VM would have to be able to communicate with the rest of the world.
- More costly: it means paying another provider.
Linux Containers (LXC) with LXD seemed to provide an interesting alternative:
- Security-oriented: the project seems focused on ensuring that processes running in containers are isolated from the host system. They also have a fairly decent vulnerability track record.
- Fairly isolated: I can strictly limit the container's communication with the outside world and the host: this is useful not just for protecting other services running on the host, but also to ensure that the blog doesn't become part of a botnet. Of course, the processes are running on the same kernel as the host, which means that the container implementation is a fairly wide attack vector, but see the above point.
- Convenient: the host can be integrated with the rest of my infrastructure, while the container doesn't have to be. But I would be using the host to manage the container. For example, the backup process can run on the host, as it has full access to the container's filesystem.
- Cheap: ...if we ignore the time spent researching the solution, but we'll consider that an investment.
So why did I not choose other container technologies over LXC/LXD, I hear?
- VServer and OpenVZ would require using a very old patched kernel, unless I was willing to run with the experimental/testing branches. LXC was merged into the mainline kernel. Additionally, as the technology is sponsored by Canonical, Ubuntu comes with support for LXC/LXD built-in. They're all fairly similar and LXC/LXD does the job, so it's as simple as that: convenience.
- Docker simply didn't feel like a good fit: it seems very focused on short-lived instances and running the application as PID 1. I'm also not very comfortable with the ecosystem around it: default privileged containers (not using user namespaces), huge registry of images you can't be sure to trust, lots of articles praising how easy it is to use, with little attention given to security. I could go on, but at the end of the day, I just didn't like it.
I want to keep articles short, which means I wasn't able to dive into the details of the actual experience and configuration. Therefore, the next two posts will describe setting up LXD and Ghost, respectively, at length.
Needless to say, security is always work-in-progress. This means that all that we've discussed here has to be re-evaluated frequently, as everything that the informal risk assessment refers to is constantly evolving and changing. So much hard work just to keep a blog, don't you think?
I am not saying that the Ghost blog is vulnerable, but a pessimistic approach is a good fit when talking about security. I'm also trying hard not to sound like D. J. Bernstein. ↩︎
Full disclosure: I did not complete a formal risk assessment. ↩︎
The thought process was obviously not linear, but I'll do my best to express it here. ↩︎