Currently there is just one anti-spoofing firewall rule ensuring packets
coming through vif+ interfaces have the right source address. Add
another rule ensuring that addresses that belongs to VMs behind those
vif+ interface do not appear on other interfaces (specifically eth0, but
also physical ones).
Normally it wouldn't be an issue because of rp_filter (doing the same
based on route table), default DROP in FORWARD chain and also conntrack
(the need to guess exact port numbers and sequence numbers). But it
appears all three mechanisms are ineffective in some cases:
- rp_filter in many distributions (including Fedora and Debian) was
switched to Loose Mode, which doesn't verify exact interface
- there is a rule in FORWARD table allowing established connections and
conntrack does not keep track of input/output interfaces
- CVE-2019-14899 allows to guess all the data needed to inject packets
Reported-by: Demi M. Obenour <demiobenour@gmail.com>
Previously enabling the interface was the first action in the setup
steps. Linux theoretically do not forward the traffic until proper
IP address and route is added to the interface (depending on rp_filter
setting). But instead of relying on this opaque behavior better setup
anti-spoofing rules earlier. Also, add 'set -o pipefail' for more
reliable error handling.
Note the rules for actual VM traffic (qvm-firewall) are properly
enforced - until those rules are loaded, traffic from appropriate vif
interface is blocked. But this relies on proper source IP address,
anti-spoofing rules need to be setup race-free.
Reported-by: Demi M. Obenour <demiobenour@gmail.com>
Detect if IPv6 is disabled in the kernel (like it is in Whonix Gateway)
and skip setting IPv6 in that case. Otherwise 'ip' call would fail and
since the script is with 'set -e', it would interrupt setting IPv4 too.
Log error message in that case anyway.
FixesQubesOS/qubes-issues#5110
Example:
/rw/config/network-hooks.d/test.sh
\#!/bin/bash
command="$1"
vif="$2"
ip="$3"
if [ "$ip" == '10.137.0.100' ]; then
case "$command" in
online)
ip route add 192.168.0.100 via 10.137.0.100
;;
offline)
ip route del 192.168.0.100
;;
esac
fi
In rare cases when vif-route-qubes is called simultaneously with some
other iptables-restore instance, it fails because of missing --wait (and
recent iptables-restore defaults to aborting instead of waiting
for lock). That other call may be from qubes-firewall or user script.
Related to QubesOS/qubes-issues#3665
If IPv6 gateway address provided by dom0 isn't a link local address, add
a /128 route to it. Also, add this address on backend interfaces (vif*).
This is to allow proper ICMP host unreachable packets forwarding - if
gateway (address on vif* interface) have only fe80: address, it will be
used as a source for ICMP reply. It will be properly delivered to the VM
directly connected there (for example from sys-net to sys-firewall), but
because of being link-local address, it will not be forwarded any
further.
This results timeouts if host doesn't have IPv6 connectivity.
If dom0 expose IPv6 address settings, configure it on the interface.
Both backend and frontend side. If no IPv6 configuration is provided,
block IPv6 as it was before.
FixesQubesOS/qubes-issues#718
Core3 no longer reuse netvm own IP for primary DNS. At the same time,
disable dropping traffic to netvm itself because it breaks DNS (as one
of blocked things). This allows VM to learn real netvm IP, but:
- this mechanism is not intended to avoid detection from already
compromised VM, only about unintentional leaks
- this can be prevented using vif-qubes-nat.sh on the netvm itself (so
it will also have hidden its own IP)
QubesOS/qubes-issues#1143
Since 'script' xenstore entry no longer allows passing arguments
(actually this always was a side effect, not intended behaviour), we
need to pass additional parameters some other way. Natural choice for
Qubes-specific script is to use QubesDB.
And since those parameters are passed some other way, it is no longer
necessary to keep it as separate script.
FixesQubesOS/qubes-issues#1143
Apparently even iptables-restore does not handle concurrent firewall
updates. This is especially a problem in case of HVM, which have two
network interfaces (one through stubom and the other direct) added at
the same time.
The later one is present only in latest iptables version - especially
debian does not have it. But we need to handle "Device or resources
busy" problem somehow.
vif-route-qubes can be called simultaneously, for example in case of:
- multiple domains startup
- HVM startup (two interfaces: one to the target domain, second one to
stubdom)
If that happens, one of calls can fail because of iptables lock.
