[libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs
Vivek Kashyap
kashyapv at us.ibm.com
Tue Jan 26 08:34:39 UTC 2010
On Mon, 25 Jan 2010, Daniel P. Berrange wrote:
> Date: Mon, 25 Jan 2010 14:59:04 +0000
> From: Daniel P. Berrange <berrange at redhat.com>
> To: Gerhard Stenzel <gstenzel at linux.vnet.ibm.com>
> Cc: libvir-list at redhat.com, Gerhard Stenzel <gerhard.stenzel at de.ibm.com>,
> Vivek Kashyap <vivk at us.ibm.com>
> Subject: Re: [libvirt] [RFC] Proposal for introduction of network traffic
> filtering capabilities for filtering of network traffic from and to VMs
>
> 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'/>
Yes,that would be cleaner. It can be done with the above xml if the
rules are organised in such a way. Or, are you suggesting that it must
always be that there is only one entry referring to a separate filter object.
>
> 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
Yes, this is a good idea. We had originally thought of introducing a
symbol like 'THIS_IP' for the specific domain.
>
>> </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.
yes, that should be possible.
thanks
Vivek
>
>
> 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 :|
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
__
Vivek Kashyap
Linux Technology Center, IBM
More information about the libvir-list
mailing list