Comment on What's the real danger of opening ports?

ryokimball@infosec.pub ⁨3⁩ ⁨weeks⁩ ago

• 0x0@lemmy.zip ⁨3⁩ ⁨weeks⁩ ago

  setting up a home VPN then trying to manage multiple public facing services.

  You mean than? Not being anal it but does change the meaning.

  source

  • ryokimball@infosec.pub ⁨3⁩ ⁨weeks⁩ ago

    You’re correct, imma let voice-to-text take the blame there.

    source
• Dagnet@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

  Self hosted newbie here. What if those services are docker containers? Wouldn’t the threat be isolated from the rest of the machine?

  source

  • Technus@lemmy.zip ⁨3⁩ ⁨weeks⁩ ago

    No. Docker containers aren’t a full sandbox. There’s a number of exploits that can break out of a container and gain root access to the host.

    source

    • kurikai@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

      Rootless podman helps

      source
    • possiblylinux127@lemmy.zip ⁨3⁩ ⁨weeks⁩ ago

      Yes and no

      Breaking out of docker in a real life context would require either a massive misconfiguration or a major security vulnerability. Chances are you aren’t going to have much in the way of lateral movement but it is always good to have defense in depth.

      source

      • Technus@lemmy.zip ⁨3⁩ ⁨weeks⁩ ago

        If someone’s self-hosting, I’d be willing to bet they don’t have the same hardened config or isolation that a cloud provider would.

        source

        • -> View More Comments
  • non_burglar@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

    Is your container isolated from your internal network?

    If I were to compromise your container, I’d immediately pivot to other systems on your private network.

    Why do the difficult thing of breaking out of a container when there’s a good chance I can use the credentials I got breaking in to your container to access other systems on your network?

    source
  • oddlyqueer@lemmy.ml ⁨3⁩ ⁨weeks⁩ ago

    it’s an extra hurdle, but it’s far from a guaranteed barrier. There’s a whole class of exploits called container escapes (or hypervisor escapes if you’re dealing with old-school VMs) that specifically focus on escalating an attack from a compromised container into whatever machine is hosting the container.

    source
  • Onomatopoeia@lemmy.cafe ⁨3⁩ ⁨weeks⁩ ago

    Others have clarified, but I’d like to add that security isn’t one thing - it’s done in layers so each layer protects from potential failures in another layer.

    This is called The Swiss Cheese Model. of risk mitigation.

    If you take a bunch of random slices of Swiss cheese and stack them up, how likely is there to be a single hole that goes though every layer?

    Using more layers reduces the risk of “hole alignment”.

    Here’s an example model:

    So a router that has no open ports, then a mesh VPN (wireguard/Tailscale) to access different services.

    That VPN should have rules that only specific ports may be connected to specific hosts.

    Hosts are on an isolated network (could be VLANS), with only specific ports permitted into the VLAN via the VPN (service dependent).

    Each service and host should use unique names for admin/root, with complex passwords, and preferably 2FA (or in the case of SSH, certs).

    Admin/root access should be limited to local devices, and if you want to get really restrictive, specific devices.

    In the Enterprise it’s not unusual to have an admin password management system that you have to request an admin password for a specific system, for a specific period of time (which is delivered via a secure mechanism, sometimes in person). This is logged, and when the requested time frame expires the password is changed.

    Everyone’s risk model and Swiss cheese layering will fall somewhere on this scale.

    source