Started off by

  1. Enabling unattended updates
  2. Enable only ssh login with key
  3. Create user with sudo privileges
  4. Disable root login
  5. Enable ufw with necessary ports
  6. Disable ping
  7. Change ssh default port 21 to something else.

Got the ideas from networkchuck

Did this on the proxmox host as well as all VMs.

Any suggestions?

  • Zerafiall@alien.topB
    link
    fedilink
    English
    arrow-up
    3
    ·
    10 months ago
    1. Don’t bother with disabling icmp. You’ll use it way more then it’s worth disabling, and something like nmap -Pn -p- X.X.X.0/24 will find all your servers anyways (same can be said for ssh and port 22. But moving that does stop some bots)

    2. As long as i go out not exposing anything the the global internet, you really don’t need a lot. The fire wall should already deny all inbound traffic.

    The next step is monitoring. It’s one thing to think your stuff is safe and locked down. It’s another thing to know your stuff is safe. Something like Observium, Nagios, Zabbix, or otherwise is a great way to make sure everything stays up, as well as having insights into what everything it doing. Even Uptime Kuma is a good test. Then something like Wazuh to watch for security events and OpenVAS or Nessus, to look holes. I’d even though in CrowdSec for host based virus detection. (Warning, this will quickly send you down the rabbit hole of being a SOC analyst for your own home)

    • Internet-of-cruft@alien.topB
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      Block outbound traffic too.

      Open up just what you need.

      Segment internally and restrict access. You don’t need more than SSH to a Linux Server, or perhaps to it’s web interface for an application running on it.

    • NevarroGuildsman@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      I just set up Wazuh at work and pointed it at a non-domain, vanilla Windows 11 machine to test and it came back with over 300 events immediately. Not trying to scare anyone off as I think it’s a great tool, more just a heads up that the rabbit hole runs very deep.

  • EugeneBelford1995@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    Honestly, between the home lab being behind a RTR, NATed, patched & updated, and given the lack of users clicking on random crap and plugging in thumb drives from God Only Knows Where … I’d go out on a limb and say it’s already more secure than most PCs.

    There’s also no data besides what I already put on Medium and GitHub, so it’s not a very attractive target.

  • sysadminafterdark@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    Take a look at CIS benchmarks and DoD STIGs. Many companies are starting to harden their infrastructure using these standards, depending on the requirements of the environment. Once you get the hang of it, then automate deployment. DO NOT blow in ALL of the rules at once. You WILL break shit. Every environment has security exceptions. If you’re running Active Directory, run Ping Castle and remediate any issues. Audit often, make sure everything is being monitored.

  • tango_suckah@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    I watch networkchuck on occasion, but some of his ideas are… questionable I think. Not necessarily wrong, but not the “YOU MUST DO THIS” that his titles suggest (I get it, get clicks, no hate).

    Of the ideas you mentioned, (2), (3), (4), and (5) are somewhere between “reasonable” and “definitely”. The rest are either iffy (unattended updates) or security theater (disable ICMP, change ports).

    Something to keep in mind for step (2), securing SSH login with a key: this is only as secure as your key. If your own machine, or any machine or service that stores your key, is compromised then your entire network is compromised. Granted, this is kind of obvious, but just making it clear.

    As for security theater, specifically step (6). Don’t disable ping. It adds nothing to security and makes it harder to troubleshoot. If I am an attacker in a position for ping to get to an internal resource in the first place, then I’m just going to listen for ARP broadcasts (on same subnet) or let an internal router do it for me (“request timed out” == host is there but not responding).

  • jmartin72@alien.topB
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    Don’t expose anything to the outside world. If you do, use something like Cloudflare tunnels or Tailscale.

    • umbrella@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      10 months ago

      Or host a VPN on it and get in through that. Many of these microservices are insecure, and the real risk comes from opening them up to the Internet. This is important.

      Also set permissions properly if applicable

  • mss-cyclist@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Unattended updates can be tricky.

    Think of config changes which need manual adjustment, or a broken update. This is something you would probably not like to happen at night without notice. Could easily break your vital systems (e.g. homeassistant, authentication, vaults…)

    • Daniel15@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      +1

      Use unattended updates ONLY for bug and security fixes, nor for minor or major releases. Ensure you configure your auto-updaters properly!

      Debian unattended-upgrades only upgrades packages from the main and security repos by default, so it should be fine since no major updates are performed within a particular Debian version.

  • Professional-Bug2305@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Don’t worry about it, no one wants to hack your plex server xD just don’t expose things directly to the internet and you’ll be fine.

  • gscjj@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    I use practical security measures that match my level of exposure and don’t severely limit my convienience.

    If your lab isn’t exposed directly to the internet, at the very least update your servers from time to time, use a string root (admin users as well) password. That’s more than enough.

    If your lab is exposed, the same applies but update more often. Use SSH keys.

    Don’t go overboard - the majority of security incidents are from lack of basic security

  • theRealNilz02@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Unattended updates are a recipe for trouble. I’d never enable that.

    I have no public services apart from 2 OpenVPN servers. To access everything else I connect to one of the OpenVPNs and use the services through the VPN routings.

    The VPN can only be accessed if you possess a cert and key. I could even implement 2fa but for now SSL auth works securely enough.

    • phein4242@alien.topB
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 months ago

      I run unattended-upgrades on all the debian/ubuntu deployments I manage. One of the deployments even has automatic reboots enabled. I still do major upgrades by hand/terraform, but the process itself works flawless in my experience.

  • Adventurous-Mud-5508@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    My security is basically if they get past an updated opnsense firewall I could be highly inconvenienced, but everything irreplaceable is backed up in the cloud and offline in my basement.

  • jjaAK3eG@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Hosted reverse proxy and VPN servers. I have no open ports on my home network.

  • gargravarr2112@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago
    1. Domain auth (1 place to set passwords and SSH keys), no root SSH
    2. SSH by key only
    3. Passworded sudo (last line of defence)
    4. Only open firewall hole is OpenVPN with security dialled up high
    5. VLANs - laptops segregated from servers
    6. Strict firewall rules between VLANs
    7. TLS on everything
    8. Daily update check alerts (no automatic updates, but persists until I deal with them)
    9. Separate isolated syslog server for audit trails
    10. Cold backups
  • calinet6@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    UDM’s regular built in threat filtering, good firewall rules, updated services, and not opening up unnecessarily to the internet. And be vigilant but don’t worry too much about it. That’s it.