Setting up this blog

Sharing the network topology of a server certainly can't help with security, and not sharing it would be security through obscurity, so by sharing it makes it more secure? Or at least it means that despite all the information that I am about to share, I believe that the configuration is secure enough given the low risk associated with a personal website that has no critical information and is backed up.

The First Server

There are a total of 2 machines that make up this blog, the first server (server00) is a droplet from Digital Ocean (IP ranges of their products are publicly available here)

I mostly use this server as a public IP address and gateway to my second server. It comes in handy for CTF challenges that require a publicly accessible address such as reverse shells, or XSS callbacks.

The issue with this server is that I have to pay a subscription for it. This increases if I want more storage, or faster hardware, which isn't ideal.

The services running here are SSH ofc so I can access the server, an apache server with certbot to serve https web requests and handle http proxy forwarding, and Wireguard to connect to the second server.

The Second Server

This second server (server01) is a physical server that I can upgrade at a 1 time cost, which can be free if those upgrades come from consumer grade parts from computers that have been thrown away (which is the case with 99% of the parts on this machine). This being said, I am counting down the days until the drives fail, but it helps knowing that I have an up to date backup of the configurations and keys.

This server has all of the services running on it. The most important of those being a Minecraft server, but I digress. This post is about this blog, and this blog is being run from server01.

Before Wireguard – Reverse SSH Tunnelling

Before I set up Wireguard, I was using reverse SSH tunneling which worked, but introduced a long latency into my connections. This could be from the (literal) dumpster parts of this server, but I convinced myself that it was simply the protocol that each packet was being forwarded through since SSH "unwraps" and "rewraps" the payload to solve the TCP over TCP problem.

Here's a graphic of the process. Essentially because server01 [firewalled server] doesn't have a static and publicly facing IP address, I can't access it unless I'm at home. This is okay for me when I'm at home, but if I want to have other people read this blog post I can't invite them all into my apartment.

Since server00 [public server] has a public IP address, server01 can initiate the connection and allow traffic to be forwarded from server00 to server01.

A big note here is that since the HTTPS certificate is for the connection between a user and server00's apache service, this reverse SSH tunnel provides an encrypted tunnel.

This allowed me to host a blog on a server I own, but let other people access it without having to pack into my apartment.

Wireguarding The Servers Together

What is Wireguard

Wireguard is a "simple yet fast and modern VPN". A Virtual Private Network (VPN) extends a private network across a public network. What this means is that server00 can be connected to server01 and server01 can be connected to server00 through a "private" network interface.

➜ ifconfig
...snip...
ethernet: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 256.10.10.1  netmask 255.255.224.0  broadcast 256.10.10.255
        inet6 ffff::ffff:ffff:ffff:ffff  prefixlen 64  scopeid 0x20<link>
        ether ff:ff:ff:ff:ff:ff  txqueuelen 1000  (Ethernet)
        RX packets     70  bytes 500000000 (500.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets     70  bytes 500000000 (500.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...snip...
wireguard: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 256.1.1.1  netmask 255.255.255.0  destination 256.1.1.2
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets     70  bytes 100000000 (100.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets     70  bytes 100000000 (100.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This output of ifconfig on server01 shows 2 interfaces: ethernet and wireguard. The ethernet interface is how the machine connects to the internet, while the wireguard interface emulates a private network that gets forwarded over the ethernet interface, or public network.

Apache configuration

This abstraction allows simple configuration for services to work. For example the apache site configuration for this blog is:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName blog.phsc138.com
        RequestHeader set X-Forwarded-Proto "https"
        ProxyPreserveHost on
        ProxyPass / http://256.1.1.1:65536/
        ProxyPassReverse / http://256.1.1.1:65536/
        <IfModule mod_headers.c>
          Header always set Strict-Transport-Security "max-age=123456; include SubDomains"
        </IfModule>
...snip...
</VirtualHost>
</IfModule>

This virtual host is listening on port 443 (HTTPS port) and the blog.phsc138.com address.

The X-Forwarded-Proto header identifies the protocol that a client is using to connect to the proxy. This fixed a bug that prevented mixed-content images from being sent.

The ProxyPreserveHost is used to keep the original host that is requesting the site rather than updating it with the proxy's host information.

The ProxyPass and ProxyPassReverse directive forward / to and from server01 using the Wireguard interface.

The Strict-Transport-Security header is used to tell browsers to use HTTPS instead of HTTP. This is similar to a 301 permanent redirect, but since the http request can be MiTM'd, this header is more secure ONLY if a user has loaded the site or one of it's subdomains (with the includeSubDomains parameter) beforehand since it knows to use HTTPS.

Is Wireguard Faster, or is My Server Junk?

My server is junk, but Wireguard is 139.06% faster than the reverse SSH tunnel in Chrome, and 123.53% faster in Firefox.

I'd say that this small test of 12 HTTPS requests is significant enough for me, but not enough to write a paper about.

Closing

Now I've got a blog, learned about some headers for security, and it (and my other web services) are at least 120% faster then they were before!