What steps do you take to secure your server and your selfhosted services?
-
ez pz:
#!/usr/sbin/nft -f table inet filter { chain input { type filter hook input priority raw; policy accept; iif "lo" accept ct state established,related accept iif "enp1s0" udp dport 51820 accept iif "enp1s0" drop } chain forward { type filter hook forward priority raw; policy accept; iif "lo" accept ct state established,related accept iif "enp1s0" udp dport 51820 accept iif "enp1s0" drop } chain output { type filter hook output priority raw; policy accept; } }I've seen it done as such:
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
One thing I do is instead of having an open SSH port, I have an OpenVPN server that I’ll connect to, then SSH to the host from within the network. Then, if someone hacks into the network, they still won’t have SSH access.
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
I put up a sign that says, "No hackers allowed plz"
-
One thing I do is instead of having an open SSH port, I have an OpenVPN server that I’ll connect to, then SSH to the host from within the network. Then, if someone hacks into the network, they still won’t have SSH access.
I do the same, but with Wireguard instead of OpenVPN. The performance is much better in my experience and it sucks less battery life.
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
Some I haven't yet found in this thread:
- rootless podman
- container port mapping to localhost (e.g. 127.0.0.1:8080:8080)
- systemd services with many of its sandboxing features (PrivateTmp, ...)
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
Fail2ban config can get fairly involved in my experience. I'm probably not doing it the right way, as I wrote a bunch of web server ban rules --- anyone trying to access wpadmin gets banned, for instance (I don't use WordPress, and if I did, it wouldn't be accessible from my public facing reverse proxy).
I just skimmed my nginx logs and looked for anything funky and put that in a ban rule, basically.
-
I put up a sign that says, "No hackers allowed plz"
How has that been going?
-
How has that been going?
"All your containers are belong to us."
-
Some I haven't yet found in this thread:
- rootless podman
- container port mapping to localhost (e.g. 127.0.0.1:8080:8080)
- systemd services with many of its sandboxing features (PrivateTmp, ...)
I assume #2 is just to keep containers/stacks able to talk to each other without piercing the firewall for ports that aren't to be exposed to the outside? It wouldn't prevent anything if one of the containers on that host were compromised, afaik.
-
Disable password authentication on SSH
Enable firewall and block all ports you're not using(most firewalls do this by default)
Switch to a LTS kernel(not security related, but it keeps things going smooth... Technically it is safer since it gets updated less often so it is a bit more battle tested? Never investigated whenever a LTS kernel is safer than a standard one)
Use Caddy to proxy to services instead of directly exposing them out
HTTPS for web stuff(Caddy does it automatically)
-
This, but I prefer nginx.
And no real need for tailscale or cloudflare. If you do not like to depend on a third party service, either port forward and ddns or an external vps+wire guard if you have gcnat
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
They aren't on the internet mainly.
-
I assume #2 is just to keep containers/stacks able to talk to each other without piercing the firewall for ports that aren't to be exposed to the outside? It wouldn't prevent anything if one of the containers on that host were compromised, afaik.
Containers can talk to each other without any ports exposed at all, they just need to be added to the same docker network.
-
Inspired by this comment to try to learn what I'm missing.
- Cloudflare proxy
- Reverse Proxy
- Fail2ban
- Docker containers on their own networks
If I need remote access, I just log into NPM and I have certain URL's created for Plex, or Sonarr, Radarr etc. No issues so far.
-
I assume #2 is just to keep containers/stacks able to talk to each other without piercing the firewall for ports that aren't to be exposed to the outside? It wouldn't prevent anything if one of the containers on that host were compromised, afaik.
It's mostly to allow the reverse proxy on localhost to connect to the container/service, while blocking all other hosts/IPs.
This is especially important when using docker as it messes with iptables and can circumvent firewall like e.g. ufw.
You're right that it doesn't increase security on case of a compromised container. It's just about outside connections.
-
It is, but you are free to switch at any time provider, there is no technological lock in like with cloudflare or tailscale (i know there is a free self hostable version, not talking about that).
So just rent a new one and switch your wireguard there.
-
Containers can talk to each other without any ports exposed at all, they just need to be added to the same docker network.
I was getting more at stacks on a host talking, ie: you have a postgres stack with PG and Pgadmin, but want to use it with other stacks or k8s swarm, without exposing the pg port outside the machine.
-
It's mostly to allow the reverse proxy on localhost to connect to the container/service, while blocking all other hosts/IPs.
This is especially important when using docker as it messes with iptables and can circumvent firewall like e.g. ufw.
You're right that it doesn't increase security on case of a compromised container. It's just about outside connections.
OK, yah, that's what I was getting at.
-
I was getting more at stacks on a host talking, ie: you have a postgres stack with PG and Pgadmin, but want to use it with other stacks or k8s swarm, without exposing the pg port outside the machine.
You can do that by joining the containers to the same docker network, you don't need to expose ports even to localhost.
-
You can do that by joining the containers to the same docker network, you don't need to expose ports even to localhost.
I mustn't be communicating well, but that's fine.
