Selfhosted

39435 readers

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

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

Questions? DM the mods!

founded 1 year ago

MODERATORS

[email protected]

182

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

submitted 9 months ago by [email protected] to c/[email protected]

131 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

[–] [email protected] 11 points 9 months ago* (last edited 9 months ago) (1 children)

I'm not super paranoid about security, but I do try to have a few good practices to make sure that it takes more than a bot scanning for /admin.php to find a way in.

Anything with SSH access uses key-based auth with password auth disabled. First thing I do when spinning up a new machine
Almost nothing is exposed directly to the Internet. I have wireguard set up on all my devices for remote access and also for extra security on public networks
Anyone who comes to visit gets put on the "guest" network, which is a separate subnet that can't see or talk to anything on the main network
For any service that supports creating multiple logins, I make sure I have a separate admin user with elevated permissions, and then create a non-privileged user that I sign in on other devices with
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. This is probably the most "paranoid" thing I do, because of the aforementioned not being accessible on the Internet, but it makes me happy to see the little lock symbol on my browser without having to fiddle around with trusting a self-signed cert.

[–] [email protected] 3 points 9 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 9 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.

[–] [email protected] 2 points 9 months ago* (last edited 9 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.