Adding a bastion host - restructuring the network
While trying to get started with Ansible I found Ansible really doesn’t like 2 factor sudo authentication. After trying, and failing, to write a new become plugin that merges the behaviour of the sudo plugin (use sudo) and su plugin (recognise other password prompts) I decided to try a different approach. Instead, I decided to setup a bastion/jumphost that will require 2 factors to login to and then fewer (i.e. just a password, or two (different) passwords or a certificate and a password) to login and become root on my systems. The bastion can be used as an ssh proxy host and this method is documented by Ansible although, for 2 factor logins to the bastion, we will need to pre-login and configure connection multiplexing (referenced from another post on using a bastion with Ansible) to reuse the connection without re-authenticating.
This post, cross-referenced in one dated two-days ago but still a work-in-progress (edit: I split it into 3 posts on 2nd January 2023 as it was still unfinished, over 2 months after stating it), exposes something that might not be obvious from my posts. The date of the post is when I started writing them, in the case of these technical posts it is often weeks, if not months, before I complete them. As well as working full-time, I am also a carer for my wife and have to do all the cooking and walk our 2 dogs twice a day - in short, I’m very busy and these tend to get worked on in bits and pieces when I can grab 10 or 20 minutes for myself. I am sharing this as it occurs to me some of my readers (if you exist!) might be in the same boat - don’t be disheartened if you find it hard to find time to play with these things, you are not alone!
Restructuring the network
To introduce the bastion, and at the same time strengthen the segregation (and security) of my network and fixing a couple of annoyances, I decided to do some restructuring.
Out with the old…
From a physical point of view, with the VLANs the devices belong to (the switches are shown in the VLAN of their management interface, and the trunk links labelled with the VLANs they carry), our current network is arranged like this:
The router I have shown as outside any VLAN, actually it exists on all VLANs (not only does it have an IP, to act as the gateway for each VLAN, it will accept SSH from any internal network currently).
Most of my servers are in the same VLAN as everything else and I put the TVs, smart assistants (a mix of 2nd and 3rd generation Amazon Echo Dots) and associated devices (e.g. Honeywell EvoHome central heating and TP-Link Tado P100 smart plugs) in the ‘internet-of-things’ VLAN. I did this as they are embedded devices that I decided posed a higher security risk (as some are very rarely updated by the manufacturers) but this meant that, for example, the Virgin TV GO apps refuse to work with our cable box due to being in different layer 3 networks. Virgin’s official stance seems to be they do not support segregating their box from end user devices in this way.
…and in with the new
My proposed new network looks like this, although I discovered today (13th December 2022) that the smart plugs’ firmware can only be updated from the Tapo Mobile App and only if the device with the app is in the same layer 3 network as the smart plug so I need to work out how I am going to do that regularly to update the firmware:
(Mostly as an aide-memoir to myself: the Dia files for these diagrams are stored with the exported images.)
My plan is to migrate the servers and printers to a new ‘services’ VLAN, with firewall holes from the device network(s) just for the individual services consumed. The cable box, TVs and games consoles added to the computer/phone/tablet VLAN (which will be renamed from ‘main’ to ‘end-user-devices’). The router, which will still route between networks, will only be managed from the existing management VLAN and the ssh daemon only configured to listen on that interface (hugely reducing its attack surface - DNS will be reconfigured to only listen on the services VLAN and there will be literally no services except DHCP listening on any other VLAN). I am tempted to move DNS to another system but I do not want to put it on a virtual machine. What was the general ‘internet-of-things’ will be renamed ‘home-automation’, in anticipation of turning that into a VLAN more orientated to that.
Access to these systems will be enforced with both network router level firewalling, for example only allowing connectivity from the bastion host for management traffic, and host level, with local firewalls further enforcing the same restriction and, on systems that span VLANs, restricting management services to the interfaces on the management VLAN.
My monitoring box (a Raspberry PI connected to a PoE-to-USB power supply) will double as the bastion host. This is not ideal, in case the monitoring software (which is only accessible from my network) gets compromised it would become a route to bypass the bastion security. In this event, an attack on the boxes it is intended to be the gateway for could be launched, however the alternative is procuring another system for the network and I simply cannot justify spending any money at the moment. The monitoring is to remain in the end-user network as checking system availability from that network is the most important perspective - the physical server hosting my VMs will become a satellite to monitor devices from behind the services VLAN’s firewall without creating unnecessary holes.
Making it happen
Obviously making significant changes, like this, to the live network is risky and might invoke the wrath of my wife if I break anything in the process. Fortunately I have been building an air-gapped test network that mirrors the live for exactly this sort of thing.
My original post carried on here, however on 2nd January 2023 it was still incomplete so I split where I had got to into 3 posts and carried on with a serialised approach to posts about this project (the end of each links to the next, so look at the end of the 3rd to find the next link in the series):