Putting SSH behind WireGuard

A common practice for Linux servers is to expose an OpenSSH service for administration, which allows authorized users to get shell access on the remote machine. (Note that Linux hosts around 96% of word's top servers, so pretty much the entire Web runs on Linux).

Last week a very sophisticated supply-chain attack which aimed to introduce a backdoor into the OpenSSH server was caught by chance. Rolling releases, such as Arch Linux, already had the malicious code in the updated machines.

Luckily enough, the wildly more popular distribution choice for servers is Ubuntu/Debian, which follows a slower deployment schedule, and thus had not yet shipped the updated affected code.

While the details of the attack are out of scope of this post, it could just as easily have been gone undetected and hit major distributions in a few months time.

Before last week I'd consider exposing SSH at the default port, with password login disabled (in favor of public key authentication) and root user login disabled, to be just enough security and even the “best practice”, industry-standard way to do it.

Now it seems to be just the time to adopt the newly enhanced best practice of adding an additional layer of security: requiring VPN access through WireGuard.

The way this enhances security is by implementing “defense-in-depth”: Either WireGuard or SSH alone are enough by themselves to implement a secure, authenticated and cryptographed communication channel.

By requiring a WireGuard VPN connection first to only then get access to the SSH port, falling victim to this same attack method outlined above would require two independent high-visibility projects to be successfully compromised in an undetected manner at the same time, which is very unlikely.

What this attack showed for systems administrators is: Be very careful and selective with every software service you expose to the wider internet.

For example, it is already known that database instances should most likely never have a publicly-facing endpoint, and it now seems that even trusted and battle-tested administration endpoints should not be openly exposed.

NOTE: Changing from the default port or adding a VPN layer might sound like “security-through-obscurity” instead of solving the underlying more serious issue, but in reality it substantially increases the resources it requires on the attacking side to successfully compromise a large number of systems.