𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍
  • 0 Posts
  • 6 Comments
Joined 2 years ago
Cake day: August 26th, 2022
  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.socialtoSelfhosted@lemmy.world•Docker in LXC vs VMEnglish
    1·
    3 days ago

    Is your server a dedicated server, or a VPS? Because if it’s a VPS, you’re probably already running in a VM.

    Adding a VM might provide more security, especially if you aren’t an expert in LXC security configuration. It will add overhead. Running Docker inside Docker provides nothing but more overhead and unnecessary complexity to your setup.

    Also, because it isn’t clear to me from your post: LXC and Docker are two ways of doing the same thing, using the same Kernel capabilities. Docker was, in fact, written in top of LXC. The only real difference is the container format. Saying “running Docker on LXC” is like saying “running Docker on Docker,” or “running Docker on Podman,” or “running LXC on Docker”. All you’re doing is nesting container implementations. As opposed to VMs, which do not just use Linux namespace capabilities, and which emulate an entirely different computer.

    LXC, Podman, and Docker use the underlying OS kernel and resources. VMs create new, virtual hardware (necessarily sharing the same hardware architecture, but nothing else from the host) and run their own kernels.

    Saying “Docker VM” is therefore confusing. Containers - LXC, Podman, or Docker - don’t create VMs. They partition and segregate off resources from the host, but they do not provide a virtual machine. You can not run OpenBSD in a Docker container on Linux; you can run OpenBSD in a VM on Linux.

  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.socialtoSelfhosted@lemmy.world•Are there any security concerns I need to know about before exposing everything with wireguard?English
    2·
    6 days ago

    Nope! No security concerns!

    But, seriously, if one machine in the Wireguard network is compromised, attacks can be launched on any other machine in that Wireguard subnet. At that point, whether you’re running Wireguard or not is irrelevant.

    For your specific setup, the weak point is the VPS. Everything is good, but if someone successfully beaks into an account on your VPS with access to the Wireguard device (and almost nobody goes through the effort of constraining network devices by account, and of course there’s always root) they can launch attacks on any machine in the WG subnet.

    It’s a little better if you’re running containers and they’re secure, but even then there are security considerations with containers. Still, that’s about the best you’re going to get: anything listening to any external internet port is running in a container with no resource runtime, and those ideally each only have limited access to the ports in the WG subnet that they need. Eg, something like:

    In your diagram, your VPS is just a gateway. If the only way to log into the VPS is over WG; and if the reverse proxy is running in a locked-down container; then this is about a secure as you can make it and still allow public access.

    Or: if the only way your VPS is at all accessible is over WG – all clients have to be connected to it via VPN – then it’s reasonably secure as long as no client is compromised. Then your remote devices become the weak points.