Selfhosted

40732 readers

389 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:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

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

Questions? DM the mods!

founded 2 years ago

MODERATORS

182

What are the most paranoid network/OS security measures you've implemented in your homelab? (self.selfhosted)

submitted 10 months ago by MigratingtoLemmy to c/selfhosted

132 comments fedilink hide all child comments

As the title says, I want to know the most paranoid security measures you've implemented in your homelab. I can think of SDN solutions with firewalls covering every interface, ACLs, locked-down/hardened OSes etc but not much beyond that. I'm wondering how deep this paranoia can go (and maybe even go down my own route too!).

Thanks!

you are viewing a single comment's thread
view the rest of the comments

[–] MigratingtoLemmy 3 points 10 months ago (1 children)

Every web-based service is only accessible with a FQDN which auto-redirects to HTTPS and has an actual certificate signed by a trusted CA

I'm assuming this is in your internal network. The problem with this is that communication from the client to the reverse-proxy (unless you're running a reverse-proxy sandboxed with each application/are directly decrypting traffic at the base of your application) is encrypted, but the traffic from the server to the reverse-proxy is not.

[–] [email protected] 2 points 10 months ago (1 children)

Definitely a consideration. In my case, the vast majority of my services are running in docker on a single host box, including the reverse proxy itself (Traefik). That unencrypted traffic never goes out over a wire, so for now I'm not concerned.

[–] raldone01 2 points 10 months ago* (last edited 10 months ago)

Bonus points for creating lots and lots of networks grouping the databases together with only their respective containers.

ip a is a huge mess.