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

[Daniel P. Berrange]

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 :|