Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security
-- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xen-utils-common depends on: ii lsb-base 9.20161125 ii python 2.7.13-2 ii ucf 3.0036 ii udev 232-25+deb9u2 ii xenstore-utils 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 xen-utils-common recommends no packages. xen-utils-common suggests no packages. -- Configuration Files: /etc/default/xendomains changed [not included] /etc/xen/scripts/vif-bridge changed [not included] /etc/xen/scripts/vif-common.sh changed [not included] /etc/xen/xend-config.sxp changed [not included] /etc/xen/xl.conf changed [not included] -- no debconf information Hi all I've already filed this issue with the Debian user-list and XEN project - they asked me to file it here as well. On XEN project you can find it here: https://lists.xenproject.org/archives/html/xen-users/2018-03/msg00043.html I have issues with the on domU startup automatically generated antispoofing rules by /etc/xen/scripts/vif-bridge and /etc/xen/scripts/vif-common.sh Both are part of the Debian xen-utils-common package (4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 installed on Debian 9.4). A domU test01 has two virtual interfaces - vif-test01-INT and vif-test01-TEST, both are connected to separate bridges named brINT and brTEST. The brINT is just an internal bridge without connectivity to an outside network to just connect all domUs and the dom0. The IP addressfor the vif-test01-INT interface is 192.168.240.68. The automatically generated rules per domU are: 1 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged 2 ACCEPT udp -- anywhere anywhere PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged udp spt:bootpc dpt:bootps 3 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged 4 ACCEPT all -- 192.168.240.68 anywhere PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged 5 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged 6 ACCEPT udp -- anywhere anywhere PHYSDEV match --physdev-in vif-test01-TEST --physdev-is-bridged udp spt:bootpc dpt:bootps 7 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged 8 ACCEPT all -- test01 anywhere PHYSDEV match --physdev-in vif-test01-TEST --physdev-is-bridged ... 33 REJECT all -- anywhere anywhere reject-with icmp-port-unreachable >From what I see is that the rules 1/3 and 5/7 are doubled. The next issue is that antispoofing rules just don't work. If I change the ip adress of the vif-test01-INT interface to something like 192.168.240.168 IP packets between test01 and other domUs are still forwarded. If I manually change the iptables rules to something like (in this example just for the brINT connected interface): -A FORWARD -m physdev --physdev-is-bridged --physdev-in vif-test01-INT -p all ! -s 192.168.240.68 -j DROP -A FORWARD -m physdev --physdev-is-bridged --physdev-out vif-test01-INT -p all ! -d 192.168.240.68 -j DROP -A FORWARD -m physdev --physdev-is-bridged --physdev-in vif-test01-INT -p all -j ACCEPT -A FORWARD -m physdev --physdev-is-bridged --physdev-out vif-test01-INT -p all -j ACCEPT ... -A FORWARD -j REJECT --reject-with icmp-port-unreachable then antispoofing works and IP packets with IP addresses different then 192.168.240.68 get dropped. Can somebody confirm this is an issue? Or do I just not understand how the antispoofing rules work on a virtual bridge? Is there a way to diable generation of antispoofing rules automatically on domU startup? I could configure a different vif.default.script in xl.conf and write a wrapper script, but it might be easier to just disable it and load iptables rules manually. Why do I think that is a security issue? The antispoofing rules being set up automatically create the false impression of working. At least in my case they don't. If someone connects a domU to the Internet and hosts public services that system is under constant risk. If such a system got hacked the intruder might get access to other internal machines as well by manipulating the domU's IP address. Take for instance NFS authentication based on IP addresses as an example. One could argue here that a proper NFS authentication is needed here and that's completely true, but NFSv4 with Kerberos tickets for domU file services sounds like a nightmare. However dom0 and domU bring a perfect way for antispoofing rules - we know and trust all the interfaces as they are managed by the dom0 and we can apply filter on these. In a physical environment it is not that easy to obtain. Binding IP addresses to MAC addresses doesn't address this issue as MAC addresses easily can be spoofed too. So the equivalent in the physical world would be one-to-one physical connections between hosts and a firewall to bind IP addresses to real physical interfaces. That's a huge benefit of virtualization. Antispoofing much easier to get. Cheers, Sebastian
