Hosting This Website - The Hard Way

This article explains the design and architecture behind this very simple and static website. The idea is to give the reader ideas and hints about one deployment scenario and that even for such a simple website there are a multitude of conciderations and decisions that need to be made.

Before we start there is a far easier alternative and it is completely free… checkout Github’s or Gitlab’s pages. I am leveraging this amazing free feature for some of my static website myself, but this article is not about those services. Instead I will explain you how you can self-host such a website in your own on-premise or cloud environment, e.g. your homelab or even a production environment. To keep it real I will walk you through how this page is hosted and served to you.

The diagram below outlines the major parts involved in the hosting of this website.

Hosting Architecture

How is the IP of the host machine protected?

Cloudflare, even the free product, offers reverse proxy capabilities that hides your IP by tunneling all the HTTP(S) traffic through their services.

Wait… Doesn’t see Cloudflare all the traffic flowing through them?

Yes, that is indeed correct. The TLS connection is terminated on Cloudflare servers and a new TLS connection is opened to the backend. For Cloudlfare to offer their security suite that protects against different types of attacks they are using deep packet inspection and other mechanism.

Why are you not concerned about that?

Specifically for this website there is nothing to be gained to intercept the traffic. Everything a visitor to the website sees can be also seen by Cloudflare. There is no client-side content that needs to be protected, nor are there any credentials used. Everything, and I mean everything, on this website is public. If that would not be the case I would not use Cloudflare, or any other intermediarry for this purpose.

Please keep also in mind that there is no admin interface for this website. There is also no login functionality for the creation of new articles. Everything is generated via hugo from the source code management system by an internal CI/CD pipeline.

How does it work?

When you are typing the URL (or similar) in your browser, your browser makes a DNS queries to resolve to get the associated IPs. After that your Browser opens a TLS protected HTTP connection via TCP to one or more of those IPs. These requests are received by the Cloudflare servers and are forwarded to the Edge Firewall with Load Balancer and Reverse Proxy for this purpose another set of TLS connections is opened. Important to note is that the firewall only accepts request from selected Cloudflare IP addresses and not from random IP addresses from the internet.

What happens internally?

In short the request is forwarded to a Kubernetes cluster that hosts the application in an Nginx containers. The related docker image is created, checked and deployed via an internal Gitlab instance, but that is a topic of another article.

What are the attack vectors?

As outlined in the diagram above the IP addesses of the hosts serving the website are never visible to the visitor, nor to any potential malicious player. Cloudflare has a lot of security mechanism in place to detect and filter ongoing attacks. Even if an attacker gets hold of those IPs, the edge firewall would block all the traffic not coming from Cloudflare. Even if that fails the hosted website is containerized and serves only static files that are either way accessible from the internet. Breaching all those security layers is not an easy task, especially given that the information to gather is public in the first place.

As with all security designs there are mutliple layers available that are deployed in tandem. Assuring that one security hole or zero day exploit does not breach the whole infrastructure. Of course this is only a toy example to play with the technology. To protect production grade business critical application is far more challenging.


Alex Oberhauser

Alex Oberhauser is a passionate tech-entrepreneur, innovator and C-level executive. During his entrepreneurial journey he acquired a multitude of skills and expertise, far beyond his original core field of computer science and software engineering.

Audit Information
Modified by Alex Oberhauser at 2021-02-27 19:24:59 -0500 -0500 by commit 98ee6db