So I’m relatively new to server hosting. (But experienced with remote web hosting from providers.) 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.

  • miaowoo_cafe@lemmy.cafeB
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 days 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.