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

[Gerhard Stenzel]

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

Daniel,

ok, trying to combine your suggestions:

- guest contains a single filter reference per interface

guest.xml:
----------
<domain type='kvm'>
  <name>demo</name>
  <memory>256000</memory>
  <devices>
    <interface type="bridge">
      <filter name='demofilter' ipaddr='10.0.0.1'/>
    </interface>
  </devices>
</domain>

- 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'/>
  </rule>
</filter>

- 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' />
  </rule>
  <!-- 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' />
  </rule>
  <!-- allow all other request or reply packets -->
  <rule action='allow' direction='inout'>
    <arp opcode='request'/>
    <arp opcode='reply'/>
  </rule>
 </filter>

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