Hi Sebastian, On 03/25/2018 12:09 PM, Sebastian wrote: > [...] > > 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 > > [...] > > 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.
I actually never understood this whole thing, and I also don't use linux bridge, but openvswitch instead for many years now, so these rules don't do anything at all for me. > 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. This also requires putting IP addresses in the guest config file, which I never do. So, I end up having these kinds of rules in the dom0 iptables: -A FORWARD -m physdev --physdev-out vif8.0 --physdev-is-bridged -j ACCEPT -A FORWARD -m physdev --physdev-in vif8.0 --physdev-is-bridged -j ACCEPT > Can somebody confirm this is an issue? Or do I just not understand how > the antispoofing rules work on a virtual bridge? The behaviour is an upstream thing... I think it got introduced here: commit 67e0d840e74f7a40087a0a4436ce6ecdd3811044 Author: m...@wray-m-3.hpl.hp.com <m...@wray-m-3.hpl.hp.com> Date: Fri Jul 9 10:38:33 2004 +0000 bitkeeper revision 1.1053.1.1 (40ee75a9YghVZFFolzFjyJngpxAbKg) Move to new model of network and vif control using shell scripts. ... And then it was moved around several times. > 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. Just commenting the handle_iptable here and there will disable it. I think we should do that in our packaging. It's just annoying. > 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. Yes, that's true. There is no proper working thing out of the box. > 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. Perfect... Maybe for very simple configurations, where you also specify some mac address and ip address in the guest config file. It's not perfect. E.g. the domU might be a router... how are you going to deal with specifying what IP addresses it can send traffic for? (only doing layer 2 in the dom0). > 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. Anyway, implementing an actual working better alternative is something that has to happen upstream. Which still does mean we can help, but fixing this will not be a debian add-on in the packaging. I must admit I didn't spend a lot of time to understand the physdev rules, but it looks like you found a combination of rules that actually does what you think it has to do. If that's the case we could prepare a patch for upstream to fix it. And, remove the handle_iptable from vif-openvswitch, doh. Thanks, Hans
