| 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
|
|
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). |