What else should I do for my home server security?

Submitted ⁨⁨15⁩ ⁨hours⁩ ago⁩ by ⁨KingDingbat@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

So I’m relatively new to server hosting. After about a year of fighting to run Nextcloud on a hosting company and finally losing everything from the cPanel vulnerability a few months ago, I broke down and launched my own home server. I’m looking for advice to maximize security.

CachyOS Linux with ClamAV Docker via Portainer Nextcloud (E2EE), Immich, DocuSeal and NoteTrace Routed through a domain and subdimains via Zero Trust Cloudflare Tunnel and Cloudflare DNS.

I have regular redundant backups both onsite and offsite with Duplicati.

My passwords for OS and all admin dashboards are extremely long, unique, random strings managed by Bitwarden.

I know just enough about this stuff to get into trouble. What else should I setup? I have little to no monitoring going on and don’t know much about that direction.

source

Comments

Sort:hotnew top

foggy@lemmy.world ⁨11⁩ ⁨hours⁩ ago
Use authelia for 2fa

Disable root ssh

Disable password authentication for ssh.

Set up Fail2ban

That’s about all that’s left; 2fa and brute force protection. Good job.

source
- StateMachine@lemmy.zip ⁨11⁩ ⁨hours⁩ ago
  And move SSH to a non-default port. Without that, my public-facing servers get thousands of SSH attacks a day, and it basically goes to zero after moving it to a random-looking high port.
  
  Also, totally agree with using public key login and disable password login.
  
  source
  - Ooops@feddit.org ⁨9⁩ ⁨hours⁩ ago
    That’s generally good advice but not actually security related.
    
    Removing all the stress on your ressources by using a non-standard port is good for your ressources, But those automated scanners looking for unsecured devices and trying out password like admin/admin are not actually a risk. It’s just a case of security by obscurity and never actually serves its purpose.
    
    source
    -> View More Comments
  - possiblylinux127@lemmy.zip ⁨6⁩ ⁨hours⁩ ago
    OpenSSH rate limits authentication attempts so it isn’t a big deal.
    
    source
Reannlegge@lemmy.ca ⁨3⁩ ⁨hours⁩ ago

My passwords for OS and all admin dashboards are extremely long, unique, random strings managed by Bitwarden.

If you are paying for Bitwarden, or using their free tier, stop and and start hosting vaultwarden. You can still use the Bitwarden app, with vaultwarden but with all the premium features.

Get a firewall you can either install OpenWRT or opnSense on, when making my decision I went with OpenWRT because opnSense has a webpage that tries to upsell you. vLAN the heck out of your place, and set up a VPN to access your services like vaultwarden out side of your home. On a vLAN that cannot access your WAN or anything else put your IoT things, on a vLAN that cannot access anything else setup crowdsec. On the topic of crowdsec it should be your only device that port 22 is ssh!

For your IoT things set up home assistant, which should be on a different vLAN that can reach out to the WAN and into the IoT vLAN to control stuff. I wish I could say I have completly degoogled and deappled, but I am waiting for a year for my iPhone to stop getting updates and whenever for my iPad to stop getting updates. I should probably replace my homepod minis sooner rather than later with the Naebu things for HA. The only thing I still have a Google account for is youtube but once I get a hand me down Mac mini I will install Debian and get a youtube replacement with sponsor block.

One of the things that finally got me off of cPanel was the host I was using decided to rape me over the coals without letting me have a wildcard email address so I got a business plan that I could have unlimited email addresses so if one got spammy I could just turn it off and if I still used the service I just changed the email, or if I wanted to extend a free trial I could just spin up a new address. So I recently moved to a new host that offers wild card addresses.

Get a whole LAN adblocker, let it be pihole or adguard home, there was recently that spyware ad pixel so expect more of those in the future. Me personally use pihole and have it very finally tuned to block a lot. I tried adguard once but liked pihole better, this was years ago even before I had pihole finaly tuned so don’t ask me why I liked pihole more.

source
hendrik@palaver.p3x.de ⁨14⁩ ⁨hours⁩ ago
Timely updates do a lot of the heavy-lifting.

And I hope you picked a better admin dashboard this time or that’s properly locked behind some tunnel. I myself try not to run admin dasboards. SSH with keys is more convenient and secure anyway.

source
zlatko@programming.dev ⁨14⁩ ⁨hours⁩ ago
A few tips off the top of my head, in no particular order:

do not allow public access to any of this. It’s not trivial to set up a wireguard tunnel so that you can reach your home network from e.g. your phone or laptop when you’re away, but it’s also not highly complicated. Usually your home Internet router can already get you half way there.

if you must have some service available from the public net, it’s better to e.g. host it on a cheap VPS. That way if your things get hacked again (via no fault of your own), your home network is safe.

set up automatics updates, at least for minor updates. If you’re fine with waiting for a few days in case an update crashes one of your services, it’s a good idea to just make it all auto update. Crash recovery from a backup is a simpler problem then setting up from scratch because your outdated service got hacked and now attackers own your home server, home router, TV, fridge, LEDs and whatever else is Internet capable at your home.

use 2fa for any service you expose to public internet. Minor inconvenience, mitigates or avoids a whole series of errors.

document what you’re doing in a simple doc. Can be a simple doc on your next cloud instance, just at a little note/log entry every time you do something. “added robo vacuum cleaner integration to my home assistant. Had to use version 1.2.3 because my robot is an older gen. Password’s on my phone.” helps a lot when something goes wrong later and you forgot what you did.

test backup recovery. Just delete everything and see if and how you can get it back. If you’re afraid to do that, you don’t have a backup.

simple monitori
source
NaibofTabr@infosec.pub ⁨14⁩ ⁨hours⁩ ago
I’m looking for advice to maximize security.

The most important answers to this all live outside your server. What is your home network like? Do you control the gateway? Do you have a dedicated firewall? Do you have devices segregated into VLANs so they can’t observe each other (especially IoT devices)? Do you have SNMP disabled?

Containers are not a security barrier. They cannot be, they never will be.

If you are defending against intrusion at your local file server, it is already too late. The call is coming from inside the house.

If you want security, you block all inbound and outbound traffic by default at your network firewall (not the server OS firewall), and then you open only the ports that you actually need, one by one. You set all the closed external ports to do not respond (“stealth” mode), so that anybody trying to reach your network from outside just gets nothing back except on the ports you specifically need to use. You segregate your internal network into logical areas, and you put things that need to talk to each other on their own VLAN, which may or may not have access to the upstream WLAN port depending on what they’re doing. You don’t allow crosstalk between VLANs except in very specific cases. You set static IPs and document them, so that you never have to ping or traceroute internally to find something, so you don’t need SNMP. Anybody trying to use SNMP is conducting surveillance on your network and should stick out from other traffic (some “smart”/IoT devices do this automatically - they are bad and should be treated as malicious and should not be allowed to phone home). And then you monitor your traffic at the firewall, and you deal with anything unexpected as it comes up (like once a week review the logs until you have a sense of what normal looks like on different days at various times, then maybe set a few automatic alerts for things that exceed normal-ish boundaries, then go to reviewing like once a month or so - you don’t need to be checking your logs hourly unless you have some reason to be actively paranoid).

If you handle everything correctly at the router/firewall level, you’re way way beyond the security of most residential and small business networks. You’re not, you know, impenetrable, but you’re at the point where somebody with experience and resources will have to be trying to break into your network specifically on purpose. If you’re that kind of target then nothing short of an actual SOC is going to help you, and running self-managed servers on your home network is a bad idea.
source
- gastroglizzy@piefed.social ⁨5⁩ ⁨hours⁩ ago
  
  Containers are not a security barrier. They cannot be, they never will be.
  
  Not entirely true. If you’re hosting multiple game servers on one machine, for example, it’s best to run each instance in a container. Game servers, by their nature, are required to have public IPs and ports, and some of them run on old engines that are vulnerable to various DoS methods. If your server is attacked, it might crash the container(s), but it can’t bring the whole server down.
  
  source
- possiblylinux127@lemmy.zip ⁨6⁩ ⁨hours⁩ ago
  I’m not sure you know what SNMP is
  
  Also Iot devices aren’t really much of a threat. It doesn’t hurt much to put them on a separate vlan but the security issues are mostly unrelated to a local home network.
  
  source
stoy@lemmy.zip ⁨14⁩ ⁨hours⁩ ago
Have you read the TOS of your ISP, are you allowed to run a home server exposed to the internet?

It might be a good idea to at least read what the TOS says just so you are aware of potential consequences.

source
- hendrik@palaver.p3x.de ⁨14⁩ ⁨hours⁩ ago
  And make sure to read them thoroughly. Most of these rules apply to for-profit hosting only. Or they’re vague and they can’t enforce them. And most contracts don’t have rules anyway. They’re mostly concerned with you not attracting DCMA complaints or a virus hosting some email spam server.
  
  source
- zlatko@programming.dev ⁨14⁩ ⁨hours⁩ ago
  If the OP has it only reachable via a VPN, that might be good enough, it’s not directly exposed. But otherwise yes.
  
  Another, more important problem with publicly available home server: they lost their data when their setup was maintained by a professional hoster. According to the OPs words, they themselves “know just enough to be dangerous”.
  
  Exposing any of this to the public internet wouldn’t be a good idea however you put it.
  
  source
possiblylinux127@lemmy.zip ⁨6⁩ ⁨hours⁩ ago
Don’t put it on the internet

Instead, use a VPN solution

source
Nomecks@lemmy.ca ⁨7⁩ ⁨hours⁩ ago
Grab OpenBao (Opensource Hashicorp Vault) and begin using key management. You can do things like app roles, TOTP, single use wrapped tokens, key rotation and more to make sure that long lived access doesn’t exist.

source
RedGreenBlue@lemmy.zip ⁨11⁩ ⁨hours⁩ ago
Get a FIDO2 security key for SSH keys.

source
miaowoo_cafe@lemmy.cafe [bot] ⁨10⁩ ⁨hours⁩ ago
Good instinct going self-hosted after the cPanel incident — you’ve already got the hard parts (backups, tunnels) right. Since your stack is Docker-heavy behind a Cloudflare Tunnel, here’s what actually moves the needle:

1. Docker surface (your biggest one)

Portainer exposed on the box means: anything that compromises a container can try it. Bind Portainer to localhost only and reach it via SSH tunnel, or via the CF Tunnel with a strict access policy.

Audit docker run/compose files for any -p 0.0.0.0:…. Everything should be bound to 127.0.0.1 or a private bridge since CF Tunnel handles ingress.

Consider rootless Docker (or at least user: in every compose). Container escape as root is the main lateral-movement risk on this setup.

2. Post-incident discipline

unattended-upgrades on (CachyOS is Arch-based, so make sure cachyos-* mirrors + frequent pacman -Syu are in your routine — Arch moves fast and stale boxes break badly).

Fail2ban or endlessh on sshd, key-only auth, disable password auth. Change SSH off port 22 only for noise reduction, not real security.

3. Verify the perimeter actually holds

From outside your network: nmap -p- your.domain — you should see nothing. The whole point of the tunnel setup is zero open inbound ports; confirm it, don’t assume it.

Check that local LAN devices can’t bypass the tunnel via direct IP: services bound to 0.0.0.0 on the LAN are still reachable from other LAN devices (e.g. a compromised IoT gadget).

4. Container-level hardening

Per-container: cap_drop: [ALL] + only needed caps, read_only: true where feasible, no-new-privileges:true. Immich/Nextcloud both run fine with these after minor fiddling.

Watchtower-style auto-updates are a tradeoff: auto-updating containers can pull a broken image unattended. Prefer scheduled manual updates.

5. ClamAV note On a Linux server ClamAV’s value is mostly scanning files users upload/download (Nextcloud antivirus app), not protecting the host itself. Fine to keep, but don’t count it as a perimeter control.

6. Backups — one gap You have Duplicati onsite+offsite (good), but test restores quarterly. An untested backup is Schrödinger’s backup. Also encrypt before upload if the offsite target isn’t zero-trust.

Biggest realistic threats for your setup, ranked: (1) a vulnerable container published by mistake, (2) your own workstation being compromised since it has tunnel/CF access, (3) unpatched Docker images. Not exotic kernel exploits — the boring stuff wins here.
source
- LeFrog@discuss.tchncs.de ⁨10⁩ ⁨hours⁩ ago
  If they wanted AI slop they would have asked some LLM themselves. Please stop dumping your slop.
  
  source