view the rest of the comments
Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
Yeah but you need to draw the line somewhere. With a VPN the attacker needs to compromise 2 different layers, which is far harder and less likely, especially if you put the VPN in a dedicated VM on a separate VLAN. If you are especially paranoid, you'd use a simpler VPN, like WireGuard, that has less chances of having unnoticed issues (code is small and well vetted), and use a different OS to run the VPN from the one running your services, so a critical flaw in one of the OSs is not enough for a full compromise.
Personally, I run all my services in Debian/Ubuntu systems, but they are behind WireGuard running in Alpine Linux VMs, which use musl instead of glibc, though I've considered using BSD there.
In your example the Linux TCP vulnerability would let an attacker into all your systems, and likely your network firewall too
Musl also exposed you to unauthenticated SSH access this month
I do recommend freebsd or openbsd
That's why mixing OSs is a good way to spread the eggs in more baskets, so do consider using BSD. However, you are wrong on both claims, WireGuard is UDP only, it doesn't use TCP, and my Alpine guest has had SSH disabled since the beginning, it can only be managed through the virtual serial port from the host OS, so locally only (unless someone manages to escape the VM), plus the SSH vulnerability was only possible when using OpenSSH, but one of the reasons for going with Alpine with musl was to avoid using the same packages as on my service hosts and use those that are smaller with less moving parts, so I'd have used Dropbear instead anyway.