WG interface to ipv4

[Jordan Glover]

On May 6, 2018 10:58 AM, ѽ҉ᶬḳ℠ <vtol at gmx.net> wrote:

> > Why? Can you outline the threat model?
> > 
> > As I mentioned earlier, to disable v6 socket creation, pass
> > 
> > ipv6.disable=1 on the kernel command line, or just unload the v6
> > 
> > module. If you're worried about the Linux v6 stack being a pile of
> > 
> > scary bugs, then you certainly want to be doing this already, and not
> > 
> > relying on simply disabling v6 routing within that network namespace,
> > 
> > which you're doing with the conf.default.disable_ipv6=1. In other
> > 
> > words, if you don't want v6 for reasons of attack surface, then you
> > 
> > should actually be disabling v6 properly.
> 
> Any piece of software is flawed (threat model), proven by the various
> 
> CVE and others yet to be discovered, that including Linux kernel and its
> 
> userland.
> 
> ipv6 deployment/utilization is hardly a matter of black and white, i.e.
> 
> turning it off/on during boot time. Some scenarios call for ipv6 to be
> 
> available whilst others not and thus ipv6 routing is disabled whenever
> 
> not needed in order to tailor mitigation of potential attack surfaces.
> 
> Like ssh can be constrained to a particular ipv socket and so it can be
> 
> set for ntp, dnsmasq, bind, unbound, just to name  a few.
> 
> Why would WG take the high route and curtail user control of whether to
> 
> open an ipv4 or ipv6 (someone else may not be keen on ipv4) socket, or both?
> 
> > Why is this a matter of network security? WireGuard will ignore
> > 
> > packets that don't have the correct authentication tag. If you're
> > 
> > receiving authentic packets, you're receiving authentic packets, and
> > 
> > the origin shouldn't matter, in terms of the packets' authenticity. In
> > 
> > other words, if an attacker has stolen a private key, this is the
> > 
> > problem to address.
> 
> Why to offer a the broadest surface (0.0.0.0 - all IPv4 addresses on the
> 
> local machine and with the ipv6 socket open also those) for a potential
> 
> attack in the first place and deprive the user of tailoring/binding WG
> 
> deployment to the respective network layout?
> 
> > Anyway, regardless of this, if you want to filter
> > 
> > out packets coming from a certain interface, a certain subnet, or any
> > 
> > other characteristics, use netfilter and make these preferences
> > 
> > explicit in your rules, rather than the implicit details of listening
> > 
> > sockets.
> 
> I would not consider binding WG to a particular iface/subnet an implicit
> 
> choice but rather being explicit, but that is perhaps a matter of
> 
> perspective then. Netfilter rules can easily get convoluted in complex
> 
> scenarios.

Jason already explained it but maybe it needs to be repeated several more
times. WG security model doesn't rely on which interface, port or subnet it's
listening on. You can screw your network configuration in myriad ways and
WG will still save you due to it's design. Private keys are all that matters.
Keep them secure and forget about the rest of things you know about
unbound, dnsmasq, bind, ssh, openvpn and ipsec. Use route tables and
netfilter rules to choose where the network traffic should go. That's all.

​Jordan