Re: [libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs

Date: Mon, 25 Jan 2010 14:59:04 +0000 From: Daniel P. Berrange <berrange(a)redhat.com&gt; To: Gerhard Stenzel <gstenzel(a)linux.vnet.ibm.com&gt; Cc: libvir-list(a)redhat.com, Gerhard Stenzel <gerhard.stenzel(a)de.ibm.com&gt;, Vivek Kashyap <vivk(a)us.ibm.com&gt; Subject: Re: [libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs On Fri, Jan 22, 2010 at 01:29:16PM +0100, Gerhard Stenzel wrote: > On Wed, 2010-01-13 at 17:36 +0000, Daniel P. Berrange wrote: >> In addition the DMTF XML format illustrated above is seriously ugly >> and not following the style of other libvirt XML formats. The use >> of UPPERCASE alone is reason enough to create a native libvirt format >> for this. We should of course ensure that whatever we do can be >> reliably mapped into the DMTF format via a simple XSL transform. >> >> Daniel > > Hi, we have been thinking about the comments regarding the XML format > and hope the following is more in line with other libvirt XML formats: > > As Stefan proposed originally, the guest interface has an additional > firewall. The firewall can have several filters, some of which are > generic and template based and some are guest specific. The template > filters can take parameters. > The filters contain rules, currently for mac, arp, vlan and ip. A rule > is applied if the conditions specified by the attributes and their > values are true and the specified action will happen. The match > attribute can be used to specify that the action should happen if the > condition is not true. > If an attribute is supplied on a rule but its value is empty (''), the > supplied parameter for a template or the respective value for the > current interface is used. > > This will need a few more examples to verify it is sufficient, but here > is the current status: > > The guest xml file: > ------------------- > <domain type='kvm'> > <name>demo</name> > <memory>256000</memory> > <devices> > <interface type="bridge"> > <firewall> > <filter template='drop-all'/> > <filter template='no-arp-spoofing' srcipaddr='10.0.0.1'/> > <filter template='no-mac-spoofing'/> > <filter template='no-ip-spoofing srcipaddr='10.0.0.1'/> > <filter> > <!-- allow outgoing IPV4 packets with the > guest mac addr and vlanid 3 --> > <rule action='allow' direction='out'> > <mac srcmacaddr='' /> > <vlan id='3'/> > <ip version='4'/> > </rule> > > <!-- only accept non-IPV6 packets from > 'aa:bb:cc:dd:ee:ff' --> > <rule action='allow' direction='in'> > <mac srcmacaddr='aa:bb:cc:dd:ee:ff' /> > <vlan id='3'/> > <ip match='no' version='6'/> > </rule> > > <!-- no access to port 25 allowed --> > <rule action='allow' direction='in'> > <ip match='no' > dstportstart = '25' > dstportend = '25' /> > </rule> > </filter> > </firewall> > </interface> > </devices> > </domain> The shear size of the ruleset inside the <interface> element is rather alarming to me. Imagine if you have a guest with more than one NIC. I'm inclined to suggest that the <interface> element in the domain XML description should only have a single rule <filter name='BLAH'/>

and if apps wish to construct a filter, from multiple independant sub-filters, then that should be done against the filter object's config, rather than the domain object's config. > The template xml files could be similar to this: > ------------------------------------------------ > > <firewall> > <!-- by default drop everything --> > <template name='drop-all'> > <filter policy='drop' /> > </template> > > <template name='no-arp-spoofing'> > <filter name='ARP' policy='drop'> > <!-- no arp spoofing --> > <!-- drop if ipaddr or macaddr does not belong to guest --> > <rule action='drop' direction='out'> > <arp match='no' srcmacaddr=''/> > <arp match='no' srcipaddr='' /> > </rule> > <!-- drop if ipaddr or macaddr does not belong to guest --> > <rule action='drop' direction='in'> > <arp match='no' dstmacaddr=' '/> > <arp match='no' dstipaddr='' /> What was the idea with the empty attributes here ? Are those implying that the attribute value is to be filled in with the value from the domain XML ? If so I'd probably make that more explicit using something like $IP and $MAC to represent the guest configured IP/MAC

> </rule> > <!-- allow all other request or reply packets --> > <rule action='allow' direction='inout'> > <arp opcode='request'/> > <arp opcode='reply'/> > </rule> > </filter> > </template> > > <template name='no-mac-spoofing'> > <filter name='DLFT'> > <!-- no mac spoofing --> > <rule action='drop' direction='out'> > <mac match='no' srcmacaddr=''/> > </rule> > </filter> > </template> > > <template name='no-ip-spoofing'> > <filter name='IPv4'> > <!-- no ip spoofing --> > <rule action='drop' direction='out'> > <ip match='no' srcipaddr=''/> > </rule> > </filter> > </template> I don't think that '<firewall>' is the top level object to be managed here. I would suggest that '<firewall>' and '<template>' elements are redundant, and that <filter> should be for the top level managed objects. The libvirt API would allow listing of existing filters, creating / deleting filters and updating the config. The <filter> element would allow some kind of <include> element to allow a complex filter to be built out of multiple simpler filters.

Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list