Virtualize or containerize everything.

The basics for anything:

• ssh key access only
• and a hardware key if available
• disabled root
• fail2ban
• rate limiting
• unattended upgrades
• calendar reminder to run full updates

After that, it really depends on what you’re running and who needs access where.

If it’s just you, or a small group of devices that you have access to and can maintain, Tailscale is the easiest best first step, or your own headscale server.

I’d recommend creating a gateway service. You basically have two routes, managed gateways or self hosted using a rented virtual private server (VPS).

Managed

These are services that are managed by companies, that allow the setup of VPN tunnels with a public access point. Some examples are:

• Cloudflare
• Tailscale

There’s not too much to say on this approach, it’s easy to setup, but depending on the level of ownership you’re looking for, it may or may not be the correct route for you.

Self-Hosted via VPS

Reason you want to use a VPS as the gateway, is so that at no point is your home server exposed to the public. Instead, any potentially malicious actions (which is an inevitably when creating public facing services ) are directed at your VPS rather than your actual server.

There are a few different options, some examples are:

• Netbird
• Headscale

Both of these are designed to implement an access point (your VPS) and any number of devices to proxy (your homeserver). They are built upon wireguard, and are feature rich.

Personally, I opted for a more lightweight approach using selfhosted-gateway, which is definitely a bare bones Reverse Proxy over VPN, designed specifically for exposing docker containers on your homeserver. Much like the other options, it’s built upon wireguard VPN. Theres no UI (which is why imo it’s perfect for a tiny VPS), just a simple MAKE command thats run from your homeserver and generates the required docker compose files, then once spun up creates the link between your VPS and exposes the appropriate docker container.

Connect via VPN instead of reverse proxy. Don’t expose services directly if you can avoid it.

I am certain this is an area my self hosted solutions lack, but still happy to share.

For me accessibility is the most important, and I have family that’s not technically savvy, so vpns/Wireguard arent great for my use case. So I use a reverse proxy to expose certain apps and have fail2ban configured to block/ban ips that misbehave. This essentially blocks people trying to guess accounts and I’ve been toying with some ratelimiting. However, as many will say, this is not a very secure system and I should monitor my local traffic more to be aware of bad actors.

At the end of the day though it’s really a battle of ease vs security. Reverse proxies provide easier access, but more risk compared to things like vpns. Also, SSH should be setup for key only (no password) and should never be exposed to the public internet (so no reverse proxy).

I would learn the following at some point (not in order):

• nftables - specifically how tables/chains/rules interact and how to use them correctly (this is a learning process)
• ssh - using non-default port key-only authentication.
• custom routing - more advanced, but is very handy if you plan to have services talking to each other in non-typical ways.
• openvpn and WireGuard - pros/cons, what they do and how they can make connecting to things more secure.
• podman - docker alternative that is imo more secure and open. It can run services in a non-root enabled way (rootless) which is great with you get it working, but can be hard to get there.

Above are more on personal preference in some cases. There are so many options to do things in the Linux world.

Be careful relying on AI to do this stuff for you. I’ve reviewed some generated nft configs that left things wide open in some cases, or added needless fluff that worked, but caused bottlenecks. Better to know what it is doing, so you can catch when it is confidently incorrect.

Ofc, if you want to go back to basics, you should first dive into the file system, data storage, permissions and ownership. Without those, the rest might not be able to protect you no matter how well they are setup.

I’m like you, learning as I go along. The answer for complete security seems to be that it takes a bachelors level of learning and you better make a start. I bookmarked this for when I have time to get into it.

For now though, I’ve just followed the steps in this guide and stopped there. I would recommend this.

The recommendations so far are quite solid.

I’d also add that crowdsec with the right collections as a primary filter within your reverse proxy setup can be extremely useful, potentially even better than fail2ban, as CS delivers a literal “scan every packet and put them against these rules” approach - where the rules are crowd sourced, thus are more up to date than any manual blocklists, filter list etc. can be, and can spot even 0day intrusion approaches.

Your really need to define your scope first. Is it just you? Family? Extended family? Strangers?

After understanding that, the best bang for your buck is a private mesh/tunnel VPN. Tailscale, Netbird, Pangolin, or plain wireguard. If you want real public routing, then you need to understand reverse tunnels and your app’s lifecycle/quality. After that, all the security guidelines are basically trying to reduce blast radius. And that depends a lot on how you’re running the app, what it has access to, etc. DMZ network for isolation goes a long way.

I posted this a while back. Maybe it will spark some ideas. I’m not holding it up as the pinnacle of security, but it has worked for me for quite a while.

https://lemmy.world/post/43533409

In that post, I forgot to specifically mention VLANS, but I do utilize them as a way to isolate everything.

I’ve had good success spinning up an authentik instance, and having my reverse proxy hit it first before it routes to the actual app. Puts another security layer in front in case sonarr itself has an issue, for ex.

Caddy snippet

handle {$host} {
		route {
			# always forward outpost path to actual outpost
			reverse_proxy /outpost.goauthentik.io/* authentik-server-1:9000

			# forward authentication to outpost
			forward_auth authentik-server-1:9000 {
				uri /outpost.goauthentik.io/auth/caddy

				# capitalization of the headers is important, otherwise they will be empty
				copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Entitlements X-Authentik-Email X-Authentik-Name X-Authentik-Uid X-Authentik-Jwt X-Authentik-Meta-Jwks X-Authentik-Meta-Outpost X-Authentik-Meta-Provider X-Authentik-Meta-App X-Authentik-Meta-Version
			}
			
			reverse_proxy {this_host_or_ip}:{this_port}
		}
}

Not gonna solve all your problems. Works for 70% of apps. Nice to slap on when you can.