Wireguard is too simple. With IKEv2, you can push routes and DNS (configuration payload). I think IKEv2 displaced many proprietary VPN/OpenVPN setups because of this (IKEv1 was not able to do that).
It's not that WireGuard "can't" do that, it's that it pushes those features to another layer of the stack. There are WireGuard-backed VPN systems that have all those features and more.
IKEv2 does all those things without any further integration, and all major OSes support said features without further integration. It doesn't matter what Wireguard can do if you just bolt more things on top of it.
In Linux you mean, or as a protocol? As a protocol, sure, the complexity is far bigger but it also enables many enterprisy things (through authentication or payload configuration). I also wonder how Wireguard will implement post-quantum cryptography, while this is already available with IPsec.
Is plain IKE/IPsec that widely used for remote access/client VPNs? I've only seen it used as the transport layer for some proprietary vendor solution like AnyConnect/GlobalProtect/FortiVPN/etc.
For site to site tunnels it is the standard, but I'm surprised to hear about the importance of dynamic configuration, since those proprietary solutions bolt their own control plane on top anyway
With IKEv1, you had to rely on proprietary Cisco extensions, or using L2TP over IPsec, which was not a convenient setup. With IKEv2, it is easy to setup both on client side (Windows, Linux through Network Manager, macOS all support this out of the box) and server side (StrongSWAN on Linux). I think the proprietary vendor solutions stay popular because of inertia and I assume they bolt some additional unrelated features on top of that.
At work we run both IKEv1 and IKEv2 to interface with different enterprise VPNs of different companies. I'd say they're about the same level of hassle and definitely nowhere near as easy as Wireguard.
IKEv2 is perhaps simpler on the "happy path", but that barely ever happens and you'll still get stuck manually negotiating all of the billion connection parameters via e-mail.
Secureblue has been blacklisting problematic kernel modules for a while, I think they might be planning to move to an allowlist in the future? Brace (same dev as the defunct DivestOS) is also doing some interesting work in that area.
To pick the example of IPSEC, i wonder if it wouldn't be better to
have, e.g., a separate "linux-modules-ipsec" package that isn't
installed by default.
I have been thinking about this, too. The only distro I know which does this for their binary kernel packaging is OpenWRT (for size reasons), and it does seem like an easy way to shrink the kernel module attack surface down.
For existing distro kernels, I wonder if there's a tool similar to make localmodconfig that looks at the currently installed kernel modules and drops an entry into /etc/modprobe.d/ that blacklists everything but those kernel modules? (AFAICT there's no wildcard or whitelisting support in modprobe.d so you'd need to do this in a hook after every kernel update, but it seems like a viable thing to do...?)
a tool similar to make localmodconfig that looks at the currently installed kernel modules and drops an entry into /etc/modprobe.d/ that blacklists everything but those kernel modules?
Oh, the Brace module_restricter scripts linked from this comment look like they're intended to do something like this. Looks like started last week and actively being worked on. Nice!
There is also the old school way of dealing with this: building your own kernel with only the stuff you actually need. I realize that few people are prepared to do this anymore and it can be difficult to scale to large environments but it can drastically reduce the attack surface.
A recent distribution kernel I have handy has a 16MB vmlinuz and 169MB of kernel modules. That's zstd compressed, the actual size is about 600MB. My personal kernel build for a similar version has a 4.5MB vmlinuz and 1MB modules. I didn't go out of my way to trim it, it's just the basic sensible config for my needs.
There’s an experiment network my friend set up. We have a fairly large IPsec mesh with ~150 nodes. I told him about this vulnerability, and after some discussion, we decided that it doesn’t significantly impact us. While these LPEs are generic, if our single user machines are properly configured, attackers can't even gain access to perform LPE...
stephank | a day ago
It isn't? Isn't it the basis for lots of corporate VPN software still?
I found IKEv2 to be a lot simpler to setup than older IPsec, but obviously Wireguard beats it in simplicity.
vbernat | a day ago
Wireguard is too simple. With IKEv2, you can push routes and DNS (configuration payload). I think IKEv2 displaced many proprietary VPN/OpenVPN setups because of this (IKEv1 was not able to do that).
tptacek | a day ago
It's not that WireGuard "can't" do that, it's that it pushes those features to another layer of the stack. There are WireGuard-backed VPN systems that have all those features and more.
ambee | a day ago
IKEv2 does all those things without any further integration, and all major OSes support said features without further integration. It doesn't matter what Wireguard can do if you just bolt more things on top of it.
tptacek | a day ago
Right, the only problem with it is that it's a security train wreck.
vbernat | 23 hours ago
In Linux you mean, or as a protocol? As a protocol, sure, the complexity is far bigger but it also enables many enterprisy things (through authentication or payload configuration). I also wonder how Wireguard will implement post-quantum cryptography, while this is already available with IPsec.
varesa | 15 hours ago
Is plain IKE/IPsec that widely used for remote access/client VPNs? I've only seen it used as the transport layer for some proprietary vendor solution like AnyConnect/GlobalProtect/FortiVPN/etc.
For site to site tunnels it is the standard, but I'm surprised to hear about the importance of dynamic configuration, since those proprietary solutions bolt their own control plane on top anyway
vbernat | 12 hours ago
With IKEv1, you had to rely on proprietary Cisco extensions, or using L2TP over IPsec, which was not a convenient setup. With IKEv2, it is easy to setup both on client side (Windows, Linux through Network Manager, macOS all support this out of the box) and server side (StrongSWAN on Linux). I think the proprietary vendor solutions stay popular because of inertia and I assume they bolt some additional unrelated features on top of that.
muvlon | 15 hours ago
At work we run both IKEv1 and IKEv2 to interface with different enterprise VPNs of different companies. I'd say they're about the same level of hassle and definitely nowhere near as easy as Wireguard.
IKEv2 is perhaps simpler on the "happy path", but that barely ever happens and you'll still get stuck manually negotiating all of the billion connection parameters via e-mail.
thesadsre | a day ago
Not many corporates run Linux desktops and on the server side it can always be enabled as part of the install configuration.
jstoja | 17 hours ago
IPSec is WIDELY used. So many S2S VPNs are relying on it.
7tehdt3cnw6kir6o | a day ago
Secureblue has been blacklisting problematic kernel modules for a while, I think they might be planning to move to an allowlist in the future? Brace (same dev as the defunct DivestOS) is also doing some interesting work in that area.
doctor_eval | a day ago
IPSec is the standard for inter-DC routing, used by AWS and OCI to name just two. So idk but it seems pretty important, certainly it is to me.
I can set up a managed and redundant IPsec tunnel pair at both AWS and OCI but AFAIK I cant do that using wireguard.
projectgus | a day ago
I have been thinking about this, too. The only distro I know which does this for their binary kernel packaging is OpenWRT (for size reasons), and it does seem like an easy way to shrink the kernel module attack surface down.
For existing distro kernels, I wonder if there's a tool similar to
make localmodconfigthat looks at the currently installed kernel modules and drops an entry into/etc/modprobe.d/that blacklists everything but those kernel modules? (AFAICT there's no wildcard or whitelisting support inmodprobe.dso you'd need to do this in a hook after every kernel update, but it seems like a viable thing to do...?)projectgus | a day ago
Oh, the Brace
module_restricterscripts linked from this comment look like they're intended to do something like this. Looks like started last week and actively being worked on. Nice!donio | 5 hours ago
That would be nice to have.
There is also the old school way of dealing with this: building your own kernel with only the stuff you actually need. I realize that few people are prepared to do this anymore and it can be difficult to scale to large environments but it can drastically reduce the attack surface.
A recent distribution kernel I have handy has a 16MB vmlinuz and 169MB of kernel modules. That's zstd compressed, the actual size is about 600MB. My personal kernel build for a similar version has a 4.5MB vmlinuz and 1MB modules. I didn't go out of my way to trim it, it's just the basic sensible config for my needs.
vbernat | 12 hours ago
This is mostly like
kernel.modules_disabled=1after boot?On Debian, there is a linux-vulnerability-mitigation package that also blacklist problematic modules.
projectgus | 59 minutes ago
Yeah, quite similar I think. Thanks for the pointer!
Thanks for this, too. It also seems very worthwhile, although IIUC it's more about stop-gap mitigating known CVEs than preemptively reducing the attack surface to begin with. i.e. https://forgejo.debian.net/linux/linux-vulnerability-mitigation/src/branch/main/mitigations - still a good idea though!
ysun | 15 hours ago
There’s an experiment network my friend set up. We have a fairly large IPsec mesh with ~150 nodes. I told him about this vulnerability, and after some discussion, we decided that it doesn’t significantly impact us. While these LPEs are generic, if our single user machines are properly configured, attackers can't even gain access to perform LPE...