What are the most paranoid network/OS security measures you've implemented in your homelab? - eviltoast

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!

  • MostlyGibberish@lemm.ee
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    9 months ago

    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.
    • MigratingtoLemmy@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      9 months ago

      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.

      • MostlyGibberish@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        9 months ago

        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@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          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.