this post was submitted on 02 Apr 2025
109 points (98.2% liked)

Selfhosted

45446 readers
278 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?

you are viewing a single comment's thread
view the rest of the comments
[–] Chewy7324@discuss.tchncs.de 10 points 1 day ago* (last edited 1 day 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, ...)
[–] ocean@lemmy.selfhostcat.com 2 points 17 hours ago

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

[–] ikidd@lemmy.world 2 points 1 day 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.

[–] MangoPenguin@lemmy.blahaj.zone 3 points 1 day 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.

[–] ikidd@lemmy.world 1 points 1 day ago* (last edited 1 day 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.

[–] MangoPenguin@lemmy.blahaj.zone 3 points 1 day 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.

[–] ikidd@lemmy.world 1 points 1 day ago

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

[–] Chewy7324@discuss.tchncs.de 2 points 1 day 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.

[–] ikidd@lemmy.world 2 points 1 day ago

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