WG interface to ipv4

WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Debian kernel 4.15.11
WG 0.0.20180420-1

Hi

Is there a way to constrain WG to ipv4? ipv6 is disabled on the server 
and the WG iface has indeed just assigned an ipv4 address but netstat 
-tulpn is still showing the WG port on upd6?

udp        0      0 0.0.0.0:45065           0.0.0.0:*
udp6       0      0 :::45065                :::*

Also wondering why it showing the wildcard address and not the subnet 
ip. And the State does not show as LISTEN. Similar output with ss -tulpn.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jason A. Donenfeld]

Hi,

If v6 is disabled, no packets will make it to the v6 sockets, and you
should be fine. To entirely disable the creation of that socket,
disable the ipv6 module, via ipv6.disable=1 on the kernel command
line. This shouldn't actually be necessary for you though.

Jason

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

Thanks Jason. Perhaps I should have pointed out initially that ipv6 is 
disabled on the server via kernel as in sysctl.conf (see below) and thus 
would not expect a WG socket on ipv6, however it is still there.

netstat -uapnw
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name
udp        0      0 0.0.0.0:45065 0.0.0.0:*                           -
udp6       0      0 :::45065 :::*                                -

And why displaying wildcard ip (0.0.0.0) as opposed to its iface 
configuration:

---/etc/network/interfaces

auto lo wg0 eth0
iface wg0 inet static
     address 172.23.0.1
     netmask 255.255.255.0
     broadcast 172.23.0.255
     network 172.23.0.0
     pre-up ip link add wg0 type wireguard
     pre-up wg setconf wg0 /etc/wireguard/wg0.conf
     up ip link set wg0 up
     post-up sysctl -w net.ipv4.ip_forward=1
     down ip link set wg0 down
     post-down sysctl -w net.ipv4.ip_forward=0
     post-down ip link delete wg0

---- sysctl.conf

# Disable IPv6 unless required
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wg0.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.lo.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.wg0.autoconf = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.lo.use_tempaddr = 0
net.ipv6.conf.eth0.use_tempaddr = 0
net.ipv6.conf.wg0.use_tempaddr = 0

# Do not accept router advertisements
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.wg0.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.eth0.accept_dad = 0
net.ipv6.conf.wg0.accept_dad = 0


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jason A. Donenfeld]

If v6 is disabled, then no packets will make it to that socket, and it
won't be used. Nothing to worry about.

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

I like to keep things neat/controlled and any necessary open socket is 
only sticking out like a sore (wondering why it is opened when not 
wanted for). It would certainly instill more confidence in network 
security/control if it would be possible to define which sockets are 
opened by WG, like other apps do.

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?



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Kalin KOZHUHAROV]

On Sat, May 5, 2018 at 10:18 AM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <v=
tol@gmx.net> wrote:
> I like to keep things neat/controlled and any necessary open socket is on=
ly
> sticking out like a sore (wondering why it is opened when not wanted for)=
.
> It would certainly instill more confidence in network security/control if=
 it
> would be possible to define which sockets are opened by WG, like other ap=
ps
> do.
>
+1 !

> 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?
>
It is not possible AFAIK. I am not sure in the intrinsic workings, may
be it is not possible by design?

Hmm, should be, given that it only listens to UDP on a single IP
address (as configured on the wgX interface).
Well, one can configure multiple addresses to a single interface, but still
What about when we have more than one wgX interface, do they share memory?

Certainly, the source lists it is binds to any interface:
https://git.zx2c4.com/WireGuard/tree/src/socket.c#n330
unconditionally.

So I guess we can use (from `man 7 socket`)

       SO_BINDTODEVICE
              Bind this socket to a particular device like =E2=80=9Ceth0=E2=
=80=9D, as
specified in the passed interface name.  If  the
              name  is an empty string or the option length is zero,
the socket device binding is removed.  The passed
              option is a variable-length null-terminated interface
name string with the maximum size of IFNAMSIZ.  If
              a socket is bound to an interface, only packets received
from that particular interface are processed by
              the socket.  Note that this works only for some socket
types, particularly AF_INET sockets.  It  is  not
              supported for packet sockets (use normal bind(2) there).

              Before  Linux  3.8,  this socket option could be set,
but could not retrieved with getsockopt(2).  Since
              Linux 3.8, it is readable.  The optlen argument should
contain the buffer size available to receive  the
              device name and is recommended to be IFNAMSZ bytes.  The
real device name length is reported back in the
              optlen argument.

Just a wild guess.

Cheers,
Kalin.

Re: WG interface to ipv4

[Christophe-Marie Duquesne]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

If wg was binding to a particular interface, I don't think it would be
possible to support roaming scenarios. I have a travel wifi router, and I
love the fact that it will automatically switch between connecting through
the Ethernet interface or the USB tethering one.

The need you describe is orthogonal to the role of wireguard. If you want
to tightly control what wireguard is doing, you should use 1) good routing
rules and 2) iptables to match these rules.


On Sat, May 5, 2018, 11:33 Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:

> On Sat, May 5, 2018 at 10:18 AM, ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> > I like to keep things neat/controlled and any necessary open socket is
> only
> > sticking out like a sore (wondering why it is opened when not wanted
> for).
> > It would certainly instill more confidence in network security/control
> if it
> > would be possible to define which sockets are opened by WG, like other
> apps
> > do.
> >
> +1 !
>
> > 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?
> >
> It is not possible AFAIK. I am not sure in the intrinsic workings, may
> be it is not possible by design?
>
> Hmm, should be, given that it only listens to UDP on a single IP
> address (as configured on the wgX interface).
> Well, one can configure multiple addresses to a single interface, but still
> What about when we have more than one wgX interface, do they share memory?
>
> Certainly, the source lists it is binds to any interface:
> https://git.zx2c4.com/WireGuard/tree/src/socket.c#n330
> unconditionally.
>
> So I guess we can use (from `man 7 socket`)
>
>        SO_BINDTODEVICE
>               Bind this socket to a particular device like “eth0”, as
> specified in the passed interface name.  If  the
>               name  is an empty string or the option length is zero,
> the socket device binding is removed.  The passed
>               option is a variable-length null-terminated interface
> name string with the maximum size of IFNAMSIZ.  If
>               a socket is bound to an interface, only packets received
> from that particular interface are processed by
>               the socket.  Note that this works only for some socket
> types, particularly AF_INET sockets.  It  is  not
>               supported for packet sockets (use normal bind(2) there).
>
>               Before  Linux  3.8,  this socket option could be set,
> but could not retrieved with getsockopt(2).  Since
>               Linux 3.8, it is readable.  The optlen argument should
> contain the buffer size available to receive  the
>               device name and is recommended to be IFNAMSZ bytes.  The
> real device name length is reported back in the
>               optlen argument.
>
> Just a wild guess.
>
> Cheers,
> Kalin.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #2: Type: text/html, Size: 4011 bytes --]

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

I am not asking to castrate WG in any way and suppose you are referring 
likely to WG clients when citing a roaming scenario, at least my servers 
are not roaming.

And on a server I prefer tight control over what is happening with the 
network. Hence, it would be good to have an option (enhancing WG) in the 
settings/configuration:

- choose ip protocol version - ipv4 or or ipv6 or both
- bind WG to either iface(s) or subnet(s)

I trust that such is available and common practice with other VPN apps.

> If wg was binding to a particular interface, I don't think it would be 
> possible to support roaming scenarios. I have a travel wifi router, 
> and I love the fact that it will automatically switch between 
> connecting through the Ethernet interface or the USB tethering one.
>
> The need you describe is orthogonal to the role of wireguard. If you 
> want to tightly control what wireguard is doing, you should use 1) 
> good routing rules and 2) iptables to match these rules.
>


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jason A. Donenfeld]

On Sat, May 5, 2018 at 7:53 PM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vt=
ol@gmx.net> wrote:
> I trust that such is available and common practice with other VPN apps.

I should point out that "other VPN apps are doing it" is mostly not a
motivation for adding a nob. We're trying to aim with WireGuard as
close to a nob-less security model as possible. This is indeed a
substantially different goal from other projects, many of which love
to add features and choices. On the other hand, WireGuard aims to look
at the complete system and tries to determine what set of parameters
always provide security in the model we're going for. For example,
most other VPN apps let you choose your "cipher suite". DES? Blowfish?
AES? XTEA? This project has a bit of a different focus. I realize this
might be less exciting to watch, but I do believe this approach will
nudge us a tiny bit closer to having secure software.

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]


> I should point out that "other VPN apps are doing it" is mostly not a
> motivation for adding a nob. We're trying to aim with WireGuard as
> close to a nob-less security model as possible. This is indeed a
> substantially different goal from other projects, many of which love
> to add features and choices. On the other hand, WireGuard aims to look
> at the complete system and tries to determine what set of parameters
> always provide security in the model we're going for. For example,
> most other VPN apps let you choose your "cipher suite". DES? Blowfish?
> AES? XTEA? This project has a bit of a different focus. I realize this
> might be less exciting to watch, but I do believe this approach will
> nudge us a tiny bit closer to having secure software.

Added/enhanced (network) security is hardly an knob meant to excite, not 
sure how you reach that conclusion.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Matthias Urlichs]

Am 6=2E Mai 2018 09:31:16 MESZ schrieb "=D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=
=84=A0" <vtol@gmx=2Enet>:
>
>Added/enhanced (network) security is hardly an knob meant to excite,
>not=20
>sure how you reach that conclusion=2E

Please tell us how adding such an option could possibly enhance security, =
given that you can get the same effect with a simple iptables rule=2E
--=20
-- Matthias Urlichs

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]


> Please tell us how adding such an option could possibly enhance security, given that you can get the same effect with a simple iptables rule.
Security enhanced by /tailoring mitigating surfaces, which is not for 
netfilter rules, different concepts. netfilter rules, particular 
iptables, can get easily convoluted in complex scenarios.
If it were for everything network security related to be resolved by 
netfilter rules than certainly the likes of ssh, dnsmasq, ntp, bind, 
unbound etc would not need to implement features like socket contains 
and binding to iface/subnet. Or do reckon such as obsolete nonsense?

Look, except for Kalin's response 
(https://lists.zx2c4.com/pipermail/wireguard/2018-May/002759.html) the 
reluctance to consider this is rather apparent. Which is fine as 
statement and of course anyone is at liberty to deploy WG. I think I 
made my point and if it is considered invalid than it is fair enough and 
no need to be argued further.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

RFE: Name of peer in configuration

[John Huttley]

Hi
we can can put comments into  configuration files but on
wg show

these are lost

Request:
Add name or Description or comment field to the [peer] stanza

[Peer]
       PublicKey = OYXXXXmTNf2RpiIBW4=
       Endpoint = gatekeeper.hisdad.org:999
       AllowedIPs = 192.168.94.0/24, 192.168.95.0/24
       Name =  "gatekeeper home server"


Then wg show


peer: OYXXXXmTNf2RpiIBW4=
   name: "gatekeeper home server"
   endpoint: 210.54.33.48:999
   allowed ips: 192.168.95.0/24, 192.168.94.0/24
   latest handshake: 2 minutes, 9 seconds ago
   transfer: 455.03 MiB received, 56.57 MiB sent

Regards,
dad

Re: WG interface to ipv4

[Jason A. Donenfeld]

On Sat, May 5, 2018 at 10:18 AM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <v=
tol@gmx.net> wrote:
> It would certainly instill more confidence in network security/control

Why? Can you outline the threat model?

As I mentioned earlier, to disable v6 socket creation, pass
ipv6.disable=3D1 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=3D1. In other
words, if you don't want v6 for reasons of attack surface, then you
should actually be disabling v6 properly.

> 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. 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.

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]


> 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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jordan Glover]

On May 6, 2018 10:58 AM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vtol@gmx.=
net> wrote:

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

=E2=80=8BJordan

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]


> Jason already explained it but maybe it needs to be repeated several more
> times.

No need, it is understood.

> 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

That seems a bit of narrow focus, and sort of insinuating that WG due to 
its design is invincible, when WG is just one piece integrating into a 
broader (server) network landscape.

Also wondering how ssh is discarded when the WG online presence stating:

"WireGuard aims to be as easy to configure and deploy as SSH. A VPN 
connection is made simply by exchanging very simple public keys – 
exactly like exchanging SSH keys"

For that matter it is pretty easy in ssh to limit its socket and 
iface/ip range exposure. Is it due to the inferior design of ssh that 
such security hardening features are made available/considered? If you 
keep the ssh keys safe that should be all that matters, should it not?



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Sun, May 6, 2018, 16:13 ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:

>
> ? If you
> keep the ssh keys safe that should be all that matters, should it not?
>

Worth noting, writing from my telephone, that SSH is a tcp-based protocol
that always responds to incoming packets and processes data preauth.



>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: WG interface to ipv4

[Toke Høiland-Jørgensen]

=D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vtol@gmx.net> writes:

> For that matter it is pretty easy in ssh to limit its socket and
> iface/ip range exposure. Is it due to the inferior design of ssh that
> such security hardening features are made available/considered? If you
> keep the ssh keys safe that should be all that matters, should it not?

SSH is different for two reasons: It runs over TCP, and it runs in
userspace.

Because it runs over TCP, it will react to unauthenticated packets,
perform a handshake and exchange quite a bit of traffic before its gets
to the point where it can authenticate its peer. Wireguard does not
exhibit this behaviour: Instead, every data packet is authenticated
individually, and if it doesn't match it is simply dropped. So an
attacker that doesn't know the private key can't even discover that a
host is running wireguard.

Secondly, because SSH runs in userspace, a lot of the processing (such
as the TCP handshake) is done by the kernel on the application's behalf.
So the only way the application has of telling the kernel not to do
this, is by setting the listen address. Wireguard lives directly in the
kernel and so can perform the authentication directly after receiving
the packet, without suffering a context switch to userspace.

The first reason is obviously more important than the second one. Either
way, the decision about whether to add a configuration knob is a
tradeoff; where any possible security gains have to be weighed against
the added complexity (which includes maintaining the extra code, the
risk of misconfiguration, and the cognitive load on the user who has to
deal with more options). Wireguard, in general, tries very hard to avoid
configuration knobs that are not absolutely necessary; and since in this
case the security gains are lower than in many other cases (to the point
where they are mostly theoretical), this decision does make sense :)

-Toke

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]


> SSH is different for two reasons: It runs over TCP, and it runs in
> userspace.
>
> Because it runs over TCP, it will react to unauthenticated packets,
> perform a handshake and exchange quite a bit of traffic before its gets
> to the point where it can authenticate its peer. Wireguard does not
> exhibit this behaviour: Instead, every data packet is authenticated
> individually, and if it doesn't match it is simply dropped. So an
> attacker that doesn't know the private key can't even discover that a
> host is running wireguard.
>
> Secondly, because SSH runs in userspace, a lot of the processing (such
> as the TCP handshake) is done by the kernel on the application's behalf.
> So the only way the application has of telling the kernel not to do
> this, is by setting the listen address. Wireguard lives directly in the
> kernel and so can perform the authentication directly after receiving
> the packet, without suffering a context switch to userspace.

Thanks for the expansive discourse.

> The first reason is obviously more important than the second one. Either
> way, the decision about whether to add a configuration knob is a
> tradeoff; where any possible security gains have to be weighed against
> the added complexity (which includes maintaining the extra code, the
> risk of misconfiguration, and the cognitive load on the user who has to
> deal with more options). Wireguard, in general, tries very hard to avoid
> configuration knobs that are not absolutely necessary; and since in this
> case the security gains are lower than in many other cases (to the point
> where they are mostly theoretical), this decision does make sense :)
>
> -Toke

Depends perhaps a bit of what the (long term) aim/goal of the WG is - 
whether to be a niche product for enthusiasts (only guessing here that 
this is the current state) or to make it into the 
mainstream/corporate/commercial arena. I doubt that server 
administrators will take to it with no control over WG's socket/iface 
exposure. Probably time will tell and/or I am wrong with that 
perspective already.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jordan Glover]

On May 6, 2018 6:33 PM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vtol@gmx.n=
et> wrote:

> Depends perhaps a bit of what the (long term) aim/goal of the WG is -
>=20
> whether to be a niche product for enthusiasts (only guessing here that
>=20
> this is the current state) or to make it into the
>=20
> mainstream/corporate/commercial arena. I doubt that server
>=20
> administrators will take to it with no control over WG's socket/iface
>=20
> exposure. Probably time will tell and/or I am wrong with that
>=20
> perspective already.

Several people described to you that there is no exposure as every invalid
packet will be silently dropped and you still insist there is a flaw in WG
which will hurt it's adoption. For constructive discussion I propose this:
present us PoC which will show that listening on 0.0.0.0 and ::1 can be
exploited with WG and binding it exclusively to x.x.x.x will help to mitiga=
te
it. At least try to describe such scenario. That would move this discussion
forward and may even lead to WG code improvements.

=E2=80=8BJordan

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]


> Several people described to you that there is no exposure as every invalid
> packet will be silently dropped and you still insist there is a flaw in WG
> which will hurt it's adoption.

Perhaps a bit of misunderstanding here. Nowhere I stated that WG in 
particularly has a flaw but exposing potential attack surfaces 
unnecessarily.

Having searched the net for wireguard vetting/(security) audit/scrutiny 
I came up empty. Thus so far any statement on WG security seems to be 
stemming from the horse's mouth (no pun intended just the old saying).

With a thread model considering every piece of software being flawed in 
mind, and with whatever CVE unearthed being a point in case, it should 
be of little surprise that the question of mitigating surface exposure 
is raised. Once WG would gain traction beyond a niche app it is likely 
to be subjected to malicious attacks with increased frequency.

I am having trouble seeing a server admin going happy with WG spawning 
all over the network (0.0.0.0) and neither being able to constrain 
ipv4/6 sockets. But again that is just my opinion whilst you may have 
sampled some to the contrary from server/system admins.

Truly understanding and appreciating simplicity and ease of use but 
without options to fine tune some (security) aspects of the app, and 
which don't need to be exposed in the default setup, it may fall short 
for certain deployment markets/adaption. Yet the latter should not be my 
concern.

This thread started as question of how to and perhaps my end tuning it 
more into a suggestion but I am far from asking for it. Like stated 
earlier everyone is at liberty to deploy either this app or another, 
whatever suits. It seems moot to ride this subject any further.

> For constructive discussion I propose this:
> present us PoC which will show that listening on 0.0.0.0 and ::1 can be
> exploited with WG and binding it exclusively to x.x.x.x will help to mitigate
> it.

It would not be within my capacity to produce such PoC. But then not 
every potential WG user (system/server admin) will be able too. Will 
that stop them from wanting to be in control of sockets/binds?

> At least try to describe such scenario. That would move this discussion
> forward and may even lead to WG code improvements.
>
> ​Jordan

Any sort of attack inside a corporate lan, probably brute force or 
cypher cracking/padding attempts, with zero knowledge of the network 
layout since WG is offering on the wildcard and ipv4/ipv6 sockets and no 
limit to unsuccessful connection attempts (unless I missed that). All it 
needs is a compromised machine in the lan with malicious code incl. a 
suitable udp port scanner/probe.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Android Configuration File

[John Huttley]

I'm just trying to set up the app to talk to my server.
Its unclear what a "configuration file" is. I've presumed it was 
wg-quick compatible.

wg1.conf


[Interface]
     Address = 192.168.94.13/32
       PrivateKey = SNIP

[Peer]
       PublicKey = SNIP
       Endpoint = gatekeeper.hisdad.org:6678
       AllowedIPs = 192.168.94.0/24, 192.168.95.0/24

Is a valid wg-quick file but the app flashes a "Invalid Virtual" or 
something, just for a second.

Whats the requirement?

--dad

Re: Android Configuration File

[Jason A. Donenfeld]

Hey John,

Sorry about that. I actually fixed this a few days ago, but we haven't
yet put out a new alpha release apk.

https://git.zx2c4.com/wireguard-android/commit/?id=8ef4a2f2f0216d5bd716d990dbf89b80868b9103

I'll get something released soon that should fix this issue for you.

In the mean time, just remove the leading spaces of each line.

Jason

Re: Android Configuration File

[John Huttley]

Awesome, works perfectly!

--dad

On 07/05/18 10:10, Jason A. Donenfeld wrote:
> Hey John,
>
> Sorry about that. I actually fixed this a few days ago, but we haven't
> yet put out a new alpha release apk.
>
> https://git.zx2c4.com/wireguard-android/commit/?id=8ef4a2f2f0216d5bd716d990dbf89b80868b9103
>
> I'll get something released soon that should fix this issue for you.
>
> In the mean time, just remove the leading spaces of each line.
>
> Jason

Re: WG interface to ipv4

[Christophe-Marie Duquesne]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Sun, May 6, 2018 at 9:39 PM, ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:

> With a thread model considering every piece of software being flawed in
> mind, and with whatever CVE unearthed being a point in case, it should be
> of little surprise that the question of mitigating surface exposure is
> raised. Once WG would gain traction beyond a niche app it is likely to be
> subjected to malicious attacks with increased frequency.
>


There is no need for a nob in wireguard to ensure that the wireguard
traffic goes through a specific interface or is bound to a specific ip
address. You can use iptables if you want to drop packets that are not for
the intended interface / ip address. You can disable ipv6 if you don't want
ipv6. If you think that wireguard could be flawed, why would you trust this
as a wireguard option? If you do not trust it, enforce it from the outside.

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]


> There is no need for a nob in wireguard to ensure that the wireguard 
> traffic goes through a specific interface or is bound to a specific ip 
> address.

All those statements are solely off the WG community and are certainly 
commendable. However, there is no (regular) external audit of WG, at 
least publicly available, neither confirming or contradicting. Intel 
probably thought their CPU programming as safe and sound until is was 
not, or maybe they knew and just buggered along till found out.

If the consensus is that WG does not need a knob then that is fine by 
all accounts and no sweat off anybody's brow.

> You can use iptables if you want to drop packets that are not for the 
> intended interface / ip address.
Sure, that has been repeatedly mentioned but there also folks who like 
to start at the source and not the tail end but that seems to be rather 
a matter of perspective/flavor.
Notwithstanding seen a bit of a fair share of netfilter rules getting 
convoluted in a complex network landscape and creating havoc, but then 
those sysmin folks might not have really know what they were doing.
> You can disable ipv6 if you don't want ipv6.
Yes, but that is no black/white (on/off), like mentioned previously.
> If you think that wireguard could be flawed, why would you trust this 
> as a wireguard option?
Because there are tools for checking/auditing sockets/binds.
> If you do not trust it, enforce it from the outside.
Why not to start from the inside, I was about to ask, but reckon that 
been explained lengthily in previous postings and hence no need to 
invite the same all over again ;)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Christophe-Marie Duquesne]

[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]

On Mon, May 7, 2018 at 6:34 PM, ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:

>
> there is no (regular) external audit of WG, at least publicly available,
> neither confirming or contradicting.
>

You keep bringing this lack of security audit as if it was a big deal, but
you don't get any intrinsic security from an audit: It's just an paid
assessment that professionals have read the code and have not spotted
obviously hazardous constructs. What you really want is that hundreds of
people, as opposed to a handful of security analysts, can read the code and
analyze it. Openvpn is 100+ KLOC, which makes it impossible for a single
programmer to read in a reasonable amount of time, and it thus requires
this kind of paid assessment. On the other hand, Wireguard is less than
4KLOC, which is the real deal maker: no unnecessary bloat and an increased
likeliness that more people can read it. Keeping it small is a difficult
task and credits should be given to the authors for staying strong about
it. You claim that the lack of a security audit is a reason to add more
code for supporting binding to a particular interface/ip, but I bet a lot
of people on this list think that it would actually hurt security because
it would grow the code base for no good reason.

[-- Attachment #2: Type: text/html, Size: 1595 bytes --]

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

>
> You keep bringing this lack of security audit as if it was a big deal, 
> but you don't get any intrinsic security from an audit: It's just an 
> paid assessment that professionals have read the code and have not 
> spotted obviously hazardous constructs. What you really want is that 
> hundreds of people, as opposed to a handful of security analysts, can 
> read the code and analyze it. Openvpn is 100+ KLOC, which makes it 
> impossible for a single programmer to read in a reasonable amount of 
> time, and it thus requires this kind of paid assessment. On the other 
> hand, Wireguard is less than 4KLOC, which is the real deal maker: no 
> unnecessary bloat and an increased likeliness that more people can 
> read it. Keeping it small is a difficult task and credits should be 
> given to the authors for staying strong about it. You claim that the 
> lack of a security audit is a reason to add more code for supporting 
> binding to a particular interface/ip, but I bet a lot of people on 
> this list think that it would actually hurt security because it would 
> grow the code base for no good reason.

Surely your bet would pay off and I would be a fool to contest it. ;)

A security audit may not stop short at just (academically) accessing the 
codebase but also include an assessment of how of the code is actually 
behaving in a (simulated) real world (complex network) scenario. It may 
even be subjected to a bounty contest to put it through the wringer.

The current concept of WG has indeed certain pros over other VPN 
solutions, but like most everything else in life, it has its cons too 
and it will be determined by the user what suits best. Time will tell 
the adoption/penetration level of WG is achieving. For me unfortunately 
the cons (not just what is mentioned in this thread) are outweighing the 
pros in WG's current state and thus departing from WG for the time being 
but keeping an eye on future developments.

Nonetheless it has been a pleasure to engage with the enthusiastic 
community of WG. Bon chance (as we French like to say)!  ;)



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[ѽ҉ᶬḳ℠]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]


> SSH is different for two reasons: It runs over TCP, and it runs in
> userspace.
>
> Secondly, because SSH runs in userspace, a lot of the processing (such
> as the TCP handshake) is done by the kernel on the application's behalf.
> So the only way the application has of telling the kernel not to do
> this, is by setting the listen address. Wireguard lives directly in the
> kernel and so can perform the authentication directly after receiving
> the packet, without suffering a context switch to userspace.
>
>
> -Toke

Perhaps worth noting this WG app (TunSafe) for WIN  "runs as a user-mode 
application and does not run inside of the kernel"

https://tunsafe.com/user-guide



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4174 bytes --]

Re: WG interface to ipv4

[Jordan Glover]

On May 7, 2018 10:24 AM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 <vtol@gmx.=
net> wrote:

> > SSH is different for two reasons: It runs over TCP, and it runs in
> >=20
> > userspace.
> >=20
> > Secondly, because SSH runs in userspace, a lot of the processing (such
> >=20
> > as the TCP handshake) is done by the kernel on the application's behalf=
.
> >=20
> > So the only way the application has of telling the kernel not to do
> >=20
> > this, is by setting the listen address. Wireguard lives directly in the
> >=20
> > kernel and so can perform the authentication directly after receiving
> >=20
> > the packet, without suffering a context switch to userspace.
> >=20
> > -Toke
>=20
> Perhaps worth noting this WG app (TunSafe) for WIN=C2=A0 "runs as a user-=
mode
>=20
> application and does not run inside of the kernel"
>=20
> https://tunsafe.com/user-guide

That's unfortunate example :)

It's closed source, unaffiliated  and was recommended against several times
here and on IRC. Pointing to go and rust implementations which are being
worked on will be much better.

=E2=80=8BJordan

Re: WG interface to ipv4

[Matthias Urlichs]

[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]

On 07.05.2018 10:41, Jordan Glover wrote:
> Pointing to go and rust implementations which are being
> worked on will be much better.
They still run in userspace.

That being said, I still don't see any reason for doing something in WG
for which (a) there's no threat model, (b) a perfectly adequate and
well-tested solution already exists, no matter whether the
implementation is userspace, kernelspace, or inside a network card's
firmware (well …).

Yes, ssh has a config option for that, but ssh runs on systems without
kernel-level IP filters. Using WG on a machine that will forward IP
packets but cannot do any firewalling is not a credible use case.

-- 
-- Matthias Urlichs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: WG interface to ipv4

[Jordan Glover]

On May 7, 2018 11:37 AM, Matthias Urlichs <matthias@urlichs.de> wrote:

> On 07.05.2018 10:41, Jordan Glover wrote:
>=20
> > Pointing to go and rust implementations which are being
> >=20
> > worked on will be much better.
>=20
> They still run in userspace.

=E2=80=8BAnd pointing to them will be better example for argumentation. Poi=
nting
to the closed source one isn't something that will win an argument in this
list.

Jordan

Re: WG interface to ipv4

[Kalin KOZHUHAROV]

I've written that yesterday, but forgot to post it, it was left in the Draf=
ts...
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@zx2c4.com> wrote:
> On Sat, May 5, 2018 at 10:18 AM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 =
<vtol@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=3D1 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=3D/boot/vmlinuz root=3D/dev/sda ro rootdelay=3D3 net.ifnames=3D0
ipv6.disable=3D1

# 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 unavailabl=
e

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 appare=
ntly.

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.