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:
>
> 1ACCEPT all -- anywhere anywhere
> PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged
> 2ACCEPT udp -- anywhere anywhere
> PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged udp
> spt:bootpc dpt:bootps
> 3ACCEPT all -- anywhere anywhere
> PHYSDEV match --physdev-out vif-test01-INT --physdev-is-bridged
> 4ACCEPT all -- 192.168.240.68 anywhere
> PHYSDEV match --physdev-in vif-test01-INT --physdev-is-bridged
> 5ACCEPT all -- anywhere anywhere
> PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged
> 6ACCEPT udp -- anywhere anywhere
> PHYSDEV match --physdev-in vif-test01-TEST --physdev-is-bridged udp
> spt:bootpc dpt:bootps
> 7ACCEPT all -- anywhere anywhere
> PHYSDEV match --physdev-out vif-test01-TEST --physdev-is-bridged
> 8ACCEPT 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
Date: Fri Jul 9 10:38:33 2004 +
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
