Hello,
Researchers have shown that many operating systems, sometimes
in default configurations, allow packets to be received on an interface
with a destination address that does not match a route that would send
return packets back out of that interface.
For example, you have a LAN interface which uses the address range
192.168.1.0/24, and a WAN interface with a public IP address. In some
configurations, packets received with destination IP address 192.168.1.x
on the WAN interface will be accepted and might even be forwarded to LAN
interface.
This behaviour might be desirable in some cases, especially if you are
roaming from one network to another, switching from Ethernet to WiFi, or
when you log in to a captive portal, as it allows old connections to
stay alive while routes have been changed.
However, if an attacker can see encrypted VPN packets and can send
packets with arbitrary destination addresses to a machine on the VPN,
they can try to guess IP addresses by looking for response packets being
sent via the VPN when they guess right. More worryingly, the researches
show it is possible in the same way to guess TCP sequence numbers, which
could potentially allow an attacker to inject arbitrary data into an
existing TCP connection on the VPN, even if they cannot decrypt any of
the data being sent back.
The attack depends on being able to send these packets in the first
place, the operating system accepting them, and then also guessing which
open TCP connections to which services are currently going on on the
VPN, so it is not a trivial attack, regardless you should try to
configure your operating systems to avoid it.
In general, you can add firewall rules to block packets with destination
IP addresses in the VPN range arriving on WAN interfaces, and possibly
block it for anything but the VPN interface itself.
On Linux, the kernel has a facility called "reverse-path filtering",
which would normally block these packets if it's enabled. Check the
contents of /proc/sys/net/ipv4/all/rp_filter and
/proc/sys/net/ipv4/default/rp_filter. If it is not 1, the filter is not
on or not effective. Writing 1 to these files as root will turn on the
filter, but you might need to check if your distribution can set these
values at boot time. On Debian-derived distributions, this can be
configured in the file /etc/sysctl.conf.
VPNs in general could protect against this attack by making traffic
analysis more difficult, by making packets all have the same size, and
by sending packets at a fixed rate. However, this will result in lower
performance, and will use a lot more bandwidth, so it is unlikely many
people will want this.
See https://seclists.org/oss-sec/2019/q4/122 for the original report.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20191205/5c62383f/attachment.sig>
