homelab.

This is an automated archive.

The original was posted on /r/homelab by /u/BrimarX on 2024-01-23 07:13:50+00:00.

Many homelabers want some of their homelab 'stuff' accessible from the Internet. There are many ways of doing that, but one is amost always described as insecure: NAT.

NAT alone is indeed a risky business as your applications are open to the internet and could be attacked directly.

However, using an SNI backhole properly our applications can be hidden from the Internet and accessible only to us, keeping them out of harm's way.

Here I am sharing my setup for review and criticism. This is a homelab variation of a very common enterprise setup.

It works like that:

1. All HTTP/HTTPS traffic is port-fowarded to a reverse-proxy
2. That reverse proxy has 2 virtual hosts:
3. One virtual host setup for your true homelab public servername (say homelab.example.com ) and reverse-proxing an internal origin server.
4. One virtual host setup as a default (say random.duckdns.org) and basically rejecting incoming traffic reaching that FQDN or any other a potential scanner might use.

This setup requires:

• A reverse-proxy supporting SNI in conjunction with default virtual hosts (ex: nginx)

• 1 homelab FQDN under your control.

• 1 'random' public FQDN under your control and used by default. It should be on a different domain than the homelab one and ideally have a random hostname (both to avoid leaking information an attacker might use to guess the homelab FQDN)

• Valid TLS certificates for both (typically achieved with let's encrypt)

With this setup legit traffic (with the homelab FQDN) is served as normal:

While any other traffic (without the homelab FQDN) is rejected with very minimal interaction:

So, what does that achieve?

The big reason why NAT is usually a bad idea is because it directly exposes internal origins to the Internet accessing (without knowing the FQDN or anything else) and those origins are usually soft targets.

Alternative setups (such as HTTP tunneling with ngrok or equivalents) do prevent that as there is no HTTP/HTTP server listening on our homelab public IP. Connection from Internet is only possible using our homelab FQDN.

The setup proposed here achieves the same: origins are exposed ONLY when accessed through our homelab FQDN.

It does require the reverse proxy to be properly configured and hardened though. A task delegated to the HTTP tunneling service with ngrok and such. But that is not very complicated to do right and test since the attack surface is very small, the setup very simple and it only relies on mainstream mature technology (ex: nginx + lets encrypt).

Why doing that?

Because we can... ;) And because it removes an external dependency and possibly subscription.

What do you think?