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

25 Jan 2010


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