The CIA of this blog
Introduction
One of my best friends introduced FreeBSD to me in the days of FreeBSD version 2.2 / 3.0. At that time I had some experience with Unix. I liked FreeBSD immediatly and started running it at home. And I have used it at home ever since. Things got more serious when I bought an internet domain to play with. It got me to the point where I started to run internet services from my home lab (and later from orher places as well!). And eventually this also included a web server with a blog.
Through the years, I’ve tried different web servers (primarily Apache and Nginx) and tools to write the content (such as Wordpress, Jekyll and now ssg).
I run the SoCruel.NU environment purely as a hobby. It is not a company or enterprise. But I like running this blog and providing FreeBSD related content. And of course you want your blog to be up and running with a high uptime percentage. And as such I started thinking of the CIA triad regarding this blog.
The CIA triad and this blog
The CIA triad is at the heart and core of IT security. The letters C, I and A stand for:
- Confidentiality
- Integrity
- Availablity
It is a simple and widely used security model consisting of these three key principles, which should be guaranteed in any kind of secure system.
Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. This is the easy one. This blog is public, so no worries about confidentiality. The data integrity of my blog is important to me. Data integrity means maintaining and assuring the accuracy and completeness of data over its entire lifecycle. So I want to make sure my content is not tampered with. To ensure the data integrity of the content of my blog the following is done:
- use a configuration management system to configure and manage the web servers and also manage the content
- use a static site generator to generate the web site content
- use the least privilege principle on the web servers
- have the web server operating system hardened
- have a secure configuration of the web server software
- have the web servers monitored
- have the logs of the web servers monitored
- have the traffic to and from the web servers monitored
- use SSL/TLS and present the content using HTTPS
And then we have availability. In this case it means that the content of my blog - the data - is actually available to its readers. my blog ran on a single server (virtual) up until recently. Protocols as DNS and SMTP have redundancy built in but HTTP has not. There are a lot of technologies out there to make a web site or web application higher available than a single server. Examples are:
- multiple DNS A records for the same FQDN
- load balancing multiple web servers (but then your load balancers must also be high available)
- global site load balancing (smart DNS)
The history showed that downtime of this blog was not caused by software failures or misconfigurations of the server. And downtime because of reboots is accepted. No, the main reasons for (longer) outages were (at home lab):
- a broken internet connection (i.e. DLS not working or old and not working properly internet router)
- broken server hardware (i.e. harddisk failure of the virtualisation host - bhyve does not support VM failover between hosts yet!)
The number of visitors of this blog is still quit low, so I do not want/need a solution for an occasional reboot of the server (mostly because of an operating system update). But I do want a solution for the 2 reasons mentioned above!
The chosen availability solution
Back in 2012 I attended my second EuroBSDCon held in Warsaw, Poland. On the Sunday afternoon a talk was given (by the now well known Allan Jude) about A Fault Aware Global Server Load Balancer in DNS. At the time I did not know that an open source global load balancer existed, let alone that gdnsd - the subject of the talk - existed. I was known with some commercial solutions at the time. So this was all very exciting!
gdnsd is an Authoritative-only DNS server. The initial ‘g’ stands for Geographic, as gdnsd offers a plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover.
After the conference I started reading about gdnsd. But it was only up to last year that I started experimenting with gdnsd in my home lab. It became obvious soon that this was a nice way to implement my availability whishes!
As you read this a gdnsd solution has been designed and implemented in the SoCruel.NU environment for the www and blog web sites.
SoCruel.NU run its own name servers for the socruel.nu zone and I decided NOT to change these and keep them as they are. I decided to run seperate zones for www.socruel.nu and blog.socruel.nu on seperate gdnsd based name servers. gdnsd ships with eight different monitoring plugins from a simple primary -> secondary failover configuration to a configuration involving the GeoIP database.
The simple primary -> secondary failover monitoring plugin configuration (gdnsd Simplefo plugin) satisfied my needs in just the right way. As it provides a perfect solution for the main reasons of the longer outages I’ve experienced in the past. A single web server is more than enough to cope with the small demand of requests for both my www.socruel.nu and blog.socruel.nu sites. When the demand should grow beyond my imagination and more web servers are needed in parallel gdnsd will also provide a perfect solution using another monitoring plugin configuration.
I have described the details of my gdnsd implementation in another blog post.
Resources
Some (other) resources about this subject: