WG interface to ipv4

[Kalin KOZHUHAROV]

I've written that yesterday, but forgot to post it, it was left in the Drafts...
While some of the content was touched upon already, so I tried to edit
it to reflect the current state of this thread...

On Sun, May 6, 2018 at 3:21 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Sat, May 5, 2018 at 10:18 AM, ѽ҉ᶬḳ℠ <vtol at gmx.net> wrote:
>> It would certainly instill more confidence in network security/control
>
> Why? Can you outline the threat model?
>
It is not exactly a "security model", rather that KISS or limit attack
surface, disable what is not needed principle.
Also it speeds up security audits :-) By (at least my) definition, a
security audit needs to check (at least) all exposed surfaces, so
reducing them at the core helps tremendously.

> As I mentioned earlier, to disable v6 socket creation, pass
> ipv6.disable=1 on the kernel command line, or just unload the v6
> module.
>
I tried both, without success... On a freshly booted box:
# dmesg |grep command
2018-05-06T08:33:34,000000+0200 Kernel command line:
BOOT_IMAGE=/boot/vmlinuz root=/dev/sda ro rootdelay=3 net.ifnames=0
ipv6.disable=1

# lsmod |grep wireguard
wireguard             141025  0
ip6_udp_tunnel          1367  1 wireguard
udp_tunnel              1859  1 wireguard
ipv6                  253477  1 wireguard
# lsmod |grep -P "ipv*6"
ip6_udp_tunnel          1367  1 wireguard
ipv6                  253477  1 wireguard

# rmmod ipv6
rmmod: ERROR: Module ipv6 is in use by: wireguard
# rmmod -f ipv6
rmmod: ERROR: could not remove 'ipv6': Resource temporarily unavailable
rmmod: ERROR: could not remove module ipv6: Resource temporarily unavailable

Hmm... Oh yes, on that kernel I forgot to enable
CONFIG_MODULE_FORCE_UNLOAD  ... oh yes, will retest later.

Well... so, this does disable listening on udp6 socket though `netstat
-unelp|grep udp6` :-)

But it does load ipv6 and ip6_udp_tunnel anyway without needing them apparently.

For a real security and ipv4-only box, I will not compile the ipv6
stuff at all, but I often try to keep same kernel config for boxes
that do use ipv6 and those that don't.
And as mentioned already, there are use cases where one wants to
enable some services on ipv4 others on ipv6 and some on both (and I
thing of WG as a service in the broad sense).

>> Which brings up the next point, I have asked previously twice about -
>> wildcard ip 0.0.0.0 . How to bind WG to a particular iface/subnet, as  a
>> another matter of network security?
>
> 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.
>
Well that is true in the simplest of scenarios - trust a box
ultimately (box has private keys, not "user").
May be I want to detect/prevent when some network changes (box gets
moved, stollen,  BGP hacked, etc.).
Hard thinking of an example...
I trust (the voice of) of my friend calling me from his registered
phone, but will do additional "checks" if s/he suddenly calls me from
unknown phone or my parents' house number...
(and yes numbers can easily be spoofed, as well as IP addresses)

> 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.
>
Well, again it is a choice of complexity. If one wants
defense-in-depth, it is better to be able to control it at the source
as well.
Of course, this will add complexity by definition, but should at least
not affect default case.

I know there are 10, LoL, types of users:
* those who want everything to "just work, don't care how, and of
course be secure"
* the security freaks, who want something to work if and only if they
enabled it (and spent some time learning the technology) and does only
what it is configured to and nothing extra

Keeping both camps happy is a _hard_ task, if at all possible. One
step forward, that usually works, is for one camp to show working code
that the other camp is not turned off by.

Disclaimer: I am professionally squished into the 10nd camp :-^D

Cheers,
Kalin.