Re: [libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs
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