this post was submitted on 02 Apr 2025
121 points (98.4% liked)

Selfhosted

46372 readers
523 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Inspired by this comment to try to learn what I'm missing.

  • Cloudflare proxy
  • Reverse Proxy
  • Fail2ban
  • Docker containers on their own networks

Another concern I have is does it need to be on a separate machine on a vlan from the rest of the network or is that too much?

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 3 weeks ago

To add some points, that I do:

  • Proper logging: So I could realize something unusual is going on
  • rootless podman container: harder to escalate privileges and gain root
  • Apparmor: same, plus it could trigger suspicious log entries
[–] [email protected] 2 points 3 weeks ago

NPM, Nginx

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.

[–] [email protected] 8 points 3 weeks ago* (last edited 3 weeks ago)

They aren't on the internet mainly.

My router (opnsense) has a wireguard server which is how I access things when out of the house.

I do have a minecraft server for my friends and I, but that VM is on its own network isolated from everything else.

[–] [email protected] 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

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.

[–] [email protected] 2 points 3 weeks ago

Thanks!

Here’s the setup I followed. It seems like it might take away some manual work for you: https://m.youtube.com/watch?v=Ha8NIAOsNvo&t=1294s&pp=ygUIRmFpbDJiYW4%3D

[–] [email protected] 11 points 3 weeks ago* (last edited 3 weeks ago) (2 children)

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, ...)
[–] [email protected] 2 points 3 weeks ago (1 children)

Does adding 127.0.0.1 make it so only that server can access it or what? I’ve seen that but not understand

[–] [email protected] 2 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Yes. 127.0.0.0 is the localhost. This is the IP the container is listening on. Even if there was no firewall it wouldn't allow any connection except from the host. If it's set to 0.0.0.0 it means it'll allow connections from any IP (which might not be an issue depending on your setup).

The reverse proxy runs on localhost anyway, so any other IPs have no reason to ever have access.

[–] [email protected] 2 points 2 weeks ago

Yes. 127.0.0.0 is the localhost. This is the IP the container is listening on. Even if there was no firewall it wouldn’t allow any connection except from the host. If it’s set to 0.0.0.0 it means it’ll allow connections from any IP (which might not be an issue depending on your setup).

Thanks for explaining this!

[–] [email protected] 2 points 3 weeks ago (2 children)

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.

[–] [email protected] 2 points 3 weeks ago (1 children)

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.

[–] [email protected] 2 points 3 weeks ago

OK, yah, that's what I was getting at.

[–] [email protected] 3 points 3 weeks ago (1 children)

Containers can talk to each other without any ports exposed at all, they just need to be added to the same docker network.

[–] [email protected] 1 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

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 are controlling other containers from interacting except on the allowed ports, and keeping those port from being available off the host.

[–] [email protected] 3 points 3 weeks ago (1 children)

You can do that by joining the containers to the same docker network, you don't need to expose ports even to localhost.

[–] [email protected] 1 points 3 weeks ago

I mustn't be communicating well, but that's fine.

[–] [email protected] 19 points 3 weeks ago (1 children)

I put up a sign that says, "No hackers allowed plz"

[–] [email protected] 4 points 3 weeks ago (1 children)
[–] [email protected] 7 points 3 weeks ago

"All your containers are belong to us."

[–] [email protected] 6 points 3 weeks ago (2 children)

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.

[–] [email protected] 1 points 3 weeks ago
[–] [email protected] 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

I do the same, but with Wireguard instead of OpenVPN. The performance is much better in my experience and it sucks less battery life.

[–] [email protected] 1 points 3 weeks ago (1 children)

I’ve been meaning to learn how to make my own

[–] [email protected] 2 points 3 weeks ago (1 children)

I found the guide/examples on their website a bit irritating at first (that's on me) but it works well once understood and configured.

[–] [email protected] 1 points 3 weeks ago

Thanks! I’ll do that

[–] [email protected] 4 points 3 weeks ago

Tailscale and being at my house is the only two ways in so I feel those are pretty good for me.

[–] [email protected] 11 points 3 weeks ago
  • Fail2ban
  • UFW
  • Reverse Proxy
  • IPtraf (monitor)
  • Lynis (Audit)
  • OpenVas (Audit)
  • Nessus (Audit)
  • Non standard SSH port
  • CrowdSec + Appsec
  • No root logins
  • SSH keys
  • Tailscale
  • RKHunter
[–] [email protected] 6 points 3 weeks ago

in the context of the comment you referenced:

Definitely have the server on its own VLAN. It shouldn't have any access to other devices that are not related to the services and I would also add some sort of security software.

If you have a public service that you expect to have multiple users on you definitely should have some level of monitoring whether it is just the application logs from the forum that you want to host or further have some sort of EDR on the server.

Things I would do if I was hosting a public forum:

  • Reverse proxy
  • fail2ban
  • dedicated server that does not have any personal data or other services that are sensitive
  • complete network isolation with VLAN
  • send application logs to ELK
  • clamAV

And if the user base grows I would also add:

  • EDR such as velociraptor
  • an external firewall / ips
  • possibly move from docker to VM for further isolation (not likely)
[–] [email protected] 3 points 3 weeks ago

use a cheap vlan switch to make an actual vlan DMZ with the services' router

use non-root containers everywhere. segment services in different containers

[–] [email protected] 9 points 3 weeks ago

Just tailscale really.

My services are only exposed to the tailscale network, so I don't have to worry about otger devices on my LAN.

A good VPN with MFA is all you really need if you are the only user.

[–] [email protected] 3 points 3 weeks ago

Default block for incoming traffic is always a good starting point.
I'm personally using crowdsec to good results, but still need to add some more to it as I keep seeing failed attacks that should be blocked much quicker.

[–] [email protected] 2 points 3 weeks ago (1 children)

I expose some stuff through IPv6 only with my Synology NAS (I am CGNATED) and I have always wondered if I still need to use fail2ban in that environment...

My Synology has an auto block feature that from my understanding is essentially fail2ban, what I don't know is if such a feature works for all my exposed services but Synology's.

[–] [email protected] 1 points 3 weeks ago

My Synology has an auto block feature that from my understanding is essentially fail2ban, what I don’t know is if such a feature works for all my exposed services but Synology’s

I'd be surprised if it works for custom services. Fail2ban has to know what's running and haw to have access to its log file to know what is a failed authentication request. The best you can do without log access is to rate limit new tcp connections. But still you should know what's the service behind because 5 new SSH sessions per minute and IP can be reasonable 5 new http1.0 connections likely cannot load a single html page.

load more comments
view more: next ›