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

[Daniel P. Berrange]

On Tue, Jan 26, 2010 at 02:24:43PM +0100, Gerhard Stenzel wrote:
> 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>

There's no need for ipaddr there - the XML schema already allows
for a 

   <ip address='10.0.0.1'/>

within the <interface> tag here. We already have MAC address as
a separate tag too. We could likely add VLAN in a similar way.

>   </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.

Yes, those examples capture what I was trying to describe.

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