WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: Vasili Pupkin <diggest@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	"William J. Tolley" <william@breakpointingbad.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
Date: Fri, 6 Dec 2019 00:28:38 +0300
Message-ID: <fdc450ad-f382-87d7-4c63-c31d595295df@gmail.com> (raw)
In-Reply-To: <CAHmME9osDRPQvfYMexRcAhHdAb-x2PjD8Wnf+nrcHyX42ivmqA@mail.gmail.com>

On 05.12.2019 23:24, Jason A. Donenfeld wrote:
> Hey Vasili,
> On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> wrote:
>> Isn't it enough to just enforce Strong Host Model, i.e. a host won't
>> respond from it's IP that is not facing the interface. If a host is
>> connected to two subnets 10.1.x.x and 10.2.x.x and have two IP
>> and, it will just drop all the packets sent to that
>> came from the interface and vice verse. This model can be
>> emulated using the FIB lookup feature of NFT with this one liner:
>> nft add rule inet filter input fib daddr . iif type != { local,
>> broadcast, multicast } drop
>> this also works for both IP4 and IP6. This mode can be safely enabled on
>> most setups not breaking things. Enabling it is a good precaution
>> measure anyway and it is a shame that it is not widely assumed as
>> default and standard.
>> Doing the same with just iptables isn't easy and can't be accomplished
>> with one liner but nft perfectly coexist with iptables.
> That actually appears to work pretty well in my quick bootleg setup.
> Thanks. I'm adding William to the email chain -- perhaps he can try
> this and report back with his attack rig?
> If we can make nft coexistance work reliably, perhaps we can run the
> nft rule on systems where the nft binary simply exists.
> For cleanup, we'll need some way of marking that rule as belonging to
> wg-quick(8) for our interface. The iptables magic currently uses
> --comment for that.
> There's also the issue with nft not having default table and chain
> names. Perhaps it'd be cleanest to just ad a new table and chain with
> a given name, and set that as a high priority input hook?
> We'll also probably want to make this only apply to our interface, and
> not others, if that's possible.
> Any downsides I'm overlooking?
> William -- you might want to subscribe to follow along better:
> https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html
> https://lists.zx2c4.com/mailman/listinfo/wireguard
I've just figured out that the same effect can also be achieved with 
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type 

So it is very similar to your solution. It is not exactly the same to 
nft oneliner, because it drops multicast and broadcast packets, this can 
probably be fixed though the multiple -j jumps, I am not an expert in 
this though:
iptables -t filter -N NOTLOCAL
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type 
iptables -t filter -I NOTLOCAL -m addrtype --limit-iface-in ! --dst-type 

It should also be dubbed with ip6tables command to also filter IP6 packets.

There can possibly be systems where only nftables is installed and there 
is no iptables though.

In any case you can limit it to just one wireguard interface. It is a 
good precaution measure to enable it systemwide and rule out the 
CVE-2019-14899 completely and many other possible attacks. The weak host 
model used in linux by default is literally weak and a good system 
administrator should avoid it by all means. But for the sake of wg-quick 
the filter can be enables for wireguard interface only to be sure it 
wouldn't break anything else and in this case you can probably also 
ignore multicasts and broadcasts.

One can possibly has a sophisticated firewall rule that only accept some 
packets and his firewall will unintentionally dodge packets around our 
rules and I don't see how this can be avoided.
WireGuard mailing list

  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-05 19:13 Jason A. Donenfeld
2019-12-05 19:50 ` Vasili Pupkin
2019-12-05 20:24   ` Jason A. Donenfeld
2019-12-05 21:28     ` Vasili Pupkin [this message]
2019-12-06 15:18       ` Jason A. Donenfeld
2019-12-06 17:21         ` Vasili Pupkin
2019-12-07 20:51         ` Lonnie Abelbeck
2019-12-06 12:58     ` William J. Tolley
2019-12-06 15:06     ` Jordan Glover
2019-12-06 15:08       ` Jason A. Donenfeld
2019-12-06 16:03         ` Vasili Pupkin
2019-12-06 16:12           ` Jordan Glover
2019-12-06 17:06             ` Vasili Pupkin
2019-12-05 20:10 ` zrm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fdc450ad-f382-87d7-4c63-c31d595295df@gmail.com \
    --to=diggest@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=william@breakpointingbad.com \
    --cc=wireguard@lists.zx2c4.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git