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

Gerhard Stenzel gstenzel at linux.vnet.ibm.com
Tue Jan 26 13:24:43 UTC 2010

On Mon, 2010-01-25 at 14:59 +0000, Daniel P. Berrange wrote:
> 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:
> 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. 
> 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
> 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


ok, trying to combine your suggestions:

- guest contains a single filter reference per interface

<domain type='kvm'>
    <interface type="bridge">
      <filter name='demofilter' ipaddr=''/>

- complex filter include other filter and can contain rules

complex demofilter.xml:
<filter name='demofilter'>
  <include href='drop-all'/>
  <include href='no-arp-spoofing' srcipaddr='$IP'/>
  <include href='no-mac-spoofing'/>
  <include href='no-ip-spoofing' srcipaddr='$IP'/>
  <!-- no ip spoofing -->
  <rule action='drop' direction='out'>
    <ip match='no' srcipaddr='$IP'/>

- simple filter contain only rules

simple no-arp-spoofing.xml:
<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='$MAC'/>
    <arp match='no' srcipaddr='$IP' />
  <!-- drop if ipaddr or macaddr does not belong to guest -->
  <rule action='drop' direction='in'>
    <arp match='no' dstmacaddr='$MAC'/>
    <arp match='no' dstipaddr='$IP' />
  <!-- allow all other request or reply packets -->
  <rule action='allow' direction='inout'>
    <arp opcode='request'/>
    <arp opcode='reply'/>

- $IP, $MAC represent the guests configured IP,MAC values

If the above seems acceptable for the moment, I would suggest we verify that this is actually implementable or if we missed something.

Best regards, 

Gerhard Stenzel, 
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

More information about the libvir-list mailing list