I have a VPS that I secure as much as possible since the IP is public, but does a wireguard-access-only homelab warrant the same efforts? Those with homelabs like this, what do you do?

  • surewhynotlem@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    3 hours ago

    If it’s just wireguard on a nonstandard port, then you are pretty much done. It’s UDP and won’t reply to incorrectly signed packets so it’s essentially invisible.

  • EarMaster@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 hours ago

    You should consider the VPN as a part of the protection (and also as a part of an attack vector).

  • Brkdncr@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 hours ago

    I run a weekly vuln scan against my ip ranges. If anything comes up I deal with it.

    • NarrativeBear@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      2 hours ago

      Could you provide some more information on how you perform a vuln scan, or what services/softwares you use to perform the scan?

  • moonpiedumplings@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    5 hours ago

    Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.

    Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container

    Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:

    https://pen.blahaj.zone/supakaity/weve-been-hacked

    I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?

    I have a comment on that post with some potential solutions, that would have cut off attack paths.

    Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.

    But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.

  • neidu3@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 hours ago

    My home servers have generally a lot smaller attack surface, as only a few ports are actually routed to them, so in theoey I could get away with a more relaxed approach. But I’m also a big believer in defense-in-depth, so I follow the same rules of thumb:

    • iptables (or equivalent) that drops anything incoming that isn’t wanted
    • any public facing service (except ssh) gets its own user
    • disable root login via ssh
    • ssh login with key only on any user in sudoers
  • i_stole_ur_taco@lemmy.ca
    link
    fedilink
    English
    arrow-up
    5
    ·
    5 hours ago

    I use pangolin and traefik together and expose a few of my services that way. But not everything.

    I slot services into categories based on:

    • do I really need to be able to access this externally?
    • …with full admin rights?
    • what write/delete access am I granting?
    • if an attacker got in, how much damage could they do with what they could access?

    Then the service is either not externally open at all, secured behind pangolin SSO, or secured behind pangolin SSO AND that service’s native auth. Which is an annoying double auth, but I feel like it’s another layer of protection in case one of them gets a 0-day exploit.