Wireguard runs over UDP, the port is undistinguishable from closed ports for most common port scanning bots. Changing the port will obfuscate the traffic a bit. Even if someone manages to guess the port, they’ll still need to use the right key, otherwise the response is like from a wrong port - no response. Your ISP can still see that it’s Wireguard traffic if they happen to be looking, but can’t decipher the contents.
I would drop containers from the equation and just run Wireguard on the host. When issues arise, you’ll have a hard time identifying the problem when container networking is in the mix.
hayalci@fstab.sh 1 year ago
VPN software usually is built strong to begin with, and any vulnerabilities discovered will be promptly fixed as well, so updating frequently should suffice. (Why not automate it with
unattended-upgrades
package?Using a random high port number will probably hide it well enough for Internet-wide port scanners as well.
if you want to be extra paranoid, you can hide the VPN service behind a port knocker as well.
BitPirate@feddit.de 1 year ago
Do you really know how Wireguard works?
Updating without a reboot only works for wireguard-go. The default implementation runs in the kernel. An update to it would require kernel live patching.
Wireguard doesn’t answer to unsigned packets. Using obscure ports or even port knocking is rather pointless. It’s indistinguishable from a closed port.
I’d rather take Casaos out of the equation and target Ubuntus’ Wireguard stack instead.
hayalci@fstab.sh 1 year ago
Good point, kernel updates should be paired with reboots to get kernel patches applied quickly.
Yes wireguard would only accept connections clfrom clients with known certificates, but this is “belt and suspenders” approach. What happens if there’s a bug in wireguards packet parsing or certificate processing? Using port knocking would protect against this —very remote— possibility.