Title: Using a dedicated administration workstation for my

	Title: Using a dedicated administration workstation for my
	infrastructure
	Author: Solène
	Date: 19 October 2024
	Tags: security network
	Description: In this guide, I will explain how and why I started using
	a dedicated computer to administrate my infrastructure

	# Introduction

	As I moved my infrastructure to a whole new architecture, I decided to
	only expose critical accesses to dedicated administration systems (I
	have just one). That workstation is dedicated to my infrastructure
	administration, it can only connect to my servers over a VPN and can
	not reach the Internet.

	This blog post explains why I am doing this, and gives a high level
	overview of the setup. Implementation details are not fascinating as
	it only requires basics firewall, HTTP proxy and VPN configuration.

	# The need

	I wanted to have my regular computer not being able to handle any
	administration task, so I have a computer "like a regular person"
	without SSH keys, VPN and a password manager that does not mix personal
	credentials with administration credentials ... To prevent credentials
	leaks or malware risks, it makes sense to uncouple the admin role from
	the "everything else" role. So far, I have been using Qubes OS which
	helped me to do so at the software level, but I wanted to go further.

	# Setup

	This is a rather quick and simple explanation of what you have to do in
	order to set up a dedicated system for administration tasks.

	## Workstation

	The admin workstation I use is an old laptop, it only needs a web
	browser (except if you have no internal web services), a SSH client,
	and being able to connect to a VPN. Almost any OS can do it, just pick
	the one you are the most conformable with, especially with regard to
	the firewall configuration.

	The workstation has its own SSH key that is deployed on the servers.
	It also has its own VPN to the infrastructure core. And its own
	password manager.

	Its firewall is configured to block all in and out traffic except the
	following:

	* UDP traffic to allow WireGuard
	* HTTP proxy address:port through WireGuard interface
	* SSH through WireGuard

	The HTTP proxy exposed on the infrastructure has a whitelist to allow
	some fqdn. I actually want to use the admin workstation for some
	tasks, like managing my domains through my registrar web console.
	Keeping the list as small as possible is important, you do not want to
	start using this workstation for browsing the web or reading emails.

	On this machine, make sure to configure the system to use the HTTP
	proxy for updates and installing packages. The difficulty of doing so
	will vary from an operating system to another. While Debian required a
	single file in `/etc/apt/apt.conf.d/` to configure apt to use the HTTP
	proxy, OpenBSD needed both `http_proxy` and `https_proxy` environment
	variables, but some scripts needed to be patched as they do not use the
	variables, I had to check fw_update, pkg_add, sysupgrade and syspatch
	were all working.

	Ideally, if you can afford it, configure a remote logging of this
	workstation logs to a central log server. When available, `auditd`
	monitoring important files access/changes in `/etc` could give precious
	information.

	## Servers

	My SSH servers are only reachable through a VPN, I do not expose it
	publicly anymore. And I do IP filtering over the VPN, so only the VPN
	clients that have a use to connect over SSH will be allowed to connect.

	When I have some web interfaces for services like Minio, Pi-Hole and
	the monitoring dashboard, all of that is restricted to the admin
	workstations only. Sometimes, you have the opportunity to separate the
	admin part by adding a HTTP filter on a `/admin/` URI, or if the
	service uses a different port for the admin and the service (like
	Minio). When enabling a new service, you need to think about all the
	things you can restrict to the admin workstations only.

	Depending on your infrastructure size and locations, you may want to
	use dedicated systems for SSH/VPN/HTTP proxy entry points, it is better
	if it is not shared with important services.

	## File exchange

	You will need to exchange data to the admin workstation (rarely the
	other way), I found nncp to be a good tool for that. You can imagine a
	lot of different setup, but I recommend picking one that:

	* does not require a daemon on the admin workstation: this does not
	increase the workstation attack surface
	* allows encryption at rest: so you can easily use any deposit system
	for the data exchange
	* is asynchronous: as a synchronous connection could be potentially
	dangerous because it establishes a link directly between the sender and
	the receiver

	Previous blog post: Secure file transfer with NNCP

	# Conclusion

	I learned about this method while reading ANSSI (French cybersecurity
	national agency) papers. While it may sound extreme, it is a good
	practice I endorse. This gives a use to old second hand hardware I
	own, and it improves my infrastructure security while giving me peace
	of mind.

	ANSSI website (in French)

	In addition, if you want to allow some people to work on your
	infrastructure (maybe you want to set up some infra for an
	association?), you already have the framework to restrict their scope
	and trace what they do.

	Of course, the amount of complexity and resources you can throw at this
	is up to you, you could totally have a single server and lock most of
	its services behind a VPN and call it a day, or have multiple servers
	worldwide and use dedicated servers to enter their software defined
	network.

	Last thing, make sure that you can bootstrap into your infrastructure
	if the only admin workstation is lost/destroyed. Most of the time, you
	will have a physical/console access that is enough (make sure the
	password manager is reachable from the outside for this case).