That's great! Fine by me then, but we need to be careful and not mess up the SG bits for XenServer.
I think they are sharing the same python scripts right now. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Wido den Hollander" <w...@widodh.nl> > To: dev@cloudstack.apache.org > Sent: Wednesday, 6 January, 2016 14:38:17 > Subject: Re: KVM: Security grouping through libvirt instead of Python > On 06-01-16 13:12, Nux! wrote: >> Hi Wido, >> >> +1 for using more libvirt and less custom stuff, but what do we do about >> XenServer? SG is supported with it as well and there is no libvirt there. >> Would this be a different implementation just for KVM? >> > > Yes. For KVM we control almost everything through libvirt. Moving > Security Grouping there would be a good thing. > > I never do anything with Xen, so I have no clue there. > >> In addition, I have the following in production and it's not clear if it >> would >> continue to work with libvirt filters - my hunch is that it will not since it >> involves multiple, different src IPs. >> >> 1 - additional IPs on instance >> 2 - subnets routed via instance IPs (I usually assign them on loopback on the >> VM) >> > > No problem at all. Just tested this: > > <rule action='return' direction='out' priority='500'> > <ip srcipaddr='192.168.100.101'/> > </rule> > <rule action='return' direction='out' priority='501'> > <ip srcipaddr='192.168.100.201'/> > </rule> > <rule action='return' direction='out' priority='502'> > <ip srcipaddr='10.0.0.0' srcipmask='24'/> > </rule> > > <rule action='drop' direction='out' priority='1000'/> > > So this VM had this config: > > auto ens7 > iface ens7 inet static > address 192.168.100.101 > netmask 255.255.255.0 > > auto ens7:0 > iface ens7:0 inet static > address 192.168.100.201 > netmask 255.255.255.0 > > auto dummy0 > iface dummy0 inet static > address 10.0.0.1 > netmask 255.255.255.0 > > From my other host I could reach all IPs just fine: > > $ ip route add 10.0.0.0/24 via 192.168.100.101 > > Trying to use any other IP than listed in the filter would be dropped. > > So it can support multiple IPs and routed subnets as well. The latter > would be required for IPv6 with DHCPv6+Prefix Delegation. > > Wido > >> Lucian >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >>> From: "Wido den Hollander" <w...@widodh.nl> >>> To: dev@cloudstack.apache.org >>> Sent: Wednesday, 6 January, 2016 10:02:31 >>> Subject: KVM: Security grouping through libvirt instead of Python >> >>> Hi, >>> >>> A while back I opened CLOUDSTACK-1164 [0] since I think that we should >>> use as much features of libvirt as possible. >>> >>> libvirt supports network filtering [1] which basically controls >>> ebtables, iptables and ip6tables (IPv6 support!). >>> >>> Using a XML definition you can create a filter and than use this filter >>> for a interface. >>> >>> I created a simple setup to test: >>> - Can I prevent MAC spoofing? >>> - Can I prevent IP spoofing? >>> - Can I reload a filter without stopping my VM >>> >>> All the questions were answered by "Yes", so I figured it was useful to >>> share this information. >>> >>> On my laptop running Ubuntu 14.04 and libvirt 1.2.2 I created two VMs: >>> - One NIC with NAT for Internet access (no filter) >>> - One NIC on a isolated bridge >>> >>> On the second NIC I assigned 192.168.100.1 and .2. >>> >>> VM network_filter_1 got a filter assigned: >>> >>> <interface type='network'> >>> <mac address='52:54:00:c1:b9:5b'/> >>> <source network='filternetwork'/> >>> <model type='virtio'/> >>> <filterref filter='network_filter_1'/> >>> </interface> >>> >>> I created a filter called 'network_filter_1' >>> >>> <filter name='network_filter_1' chain='ipv4'> >>> <uuid>64b80046-9a9d-40c2-8782-ed5878146262</uuid> >>> >>> <rule action='drop' direction='out'> >>> <mac match='no' srcmacaddr='52:54:00:c1:b9:5b'/> >>> </rule> >>> >>> <rule action='drop' direction='out'> >>> <ip match='no' srcipaddr='192.168.100.1'/> >>> </rule> >>> >>> <rule action='accept' direction='in'> >>> <tcp dstportstart='22'/> >>> </rule> >>> >>> <rule action='accept' direction='in'> >>> <tcp dstportstart='80'/> >>> </rule> >>> >>> <rule action='accept' direction='in'> >>> <tcp dstportstart='443'/> >>> </rule> >>> >>> <rule action='drop' direction='in'> >>> <all/> >>> </rule> >>> </filter> >>> >>> libvirt can auto-detect the MAC and IP, but since we already know that >>> information I didn't think I needed to test that. >>> >>> $ virsh nwfilter-define filter.xml >>> $ virsh define network_filter_1.xml >>> $ virsh start network_filter_1 >>> >>> The result was simple. Using any different IP then 192.168.100.1 failed >>> and connections to ports not being 22, 80 or 443 failed. >>> >>> Changes to filters were simple as well. Edit filter.xml and run: >>> >>> $ virsh nwfilter-define filter.xml >>> >>> Those changes were applied without stopping the VM. Done within 1 second. >>> >>> I think it is worth the effort to use this instead of using >>> 'security_group.py'. >>> >>> On KVM we can always perform MAC address filtering and when security >>> grouping in shared or basic networking is used we can use libvirt to >>> filter all the traffic. >>> >>> Less code we have to maintain and I prefer using libvirt over our custom >>> Python code. >>> >>> This is not a functional spec yet, but I just wanted to get this >>> information out there and share what I found. >>> >>> Looking at the libvirt docs I can't find anything which it can't do >>> which our security groups currently can. It already fully supports IPv6 >>> which we don't. >>> >>> CloudStack would only need to generate the proper XML documents and >>> that's all. >>> >>> Wido >>> >>> [0]: https://issues.apache.org/jira/browse/CLOUDSTACK-1164 > >> [1]: http://libvirt.org/formatnwfilter.html
