[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Thu, 2010-02-18 at 10:45 -0500, Stefan Berger wrote:
....

>  <filterref ref='no-arp-spoofing'>
>   <parameter name='IP' value='1.2.3.4'/>
> </include>
> 
> ... to be consistent. 
> 
> 
> Thanks for feedback. 
> 
>    Stefan 
> 
> 
> > 
> > Matthias
> --
> libvir-list mailing list
> libvir-list redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list

Hi, here is a preview of a chapter which is eventually intended for the
libvirt application development guide. It is not final yet, but I feel
now would be a good moment to gather some first feedback and to
"finalise" the XML schema which is used in the examples.

------------------------------------------------------------------------

1. Network Filter

      1.1. Overview

      1.2. XML Filter Description Format

            1.2.1. Complex Filter

            1.2.2. Simple Filters

      1.3. Retrieving Information About Filter

            1.3.1. TBD


Chapter 1. Network Filter
---------------------------

1.1. Overview

1.2. XML Filter Description Format

      1.2.1. Complex Filter

      1.2.2. Simple Filters

1.3. Retrieving Information About Filter

      1.3.1. TBD

This section covers the management and definition of network filters
using the libvirt API.


1.1. Overview
--------------

The configuration of network filters can be examined and modified with
functions in the virTBSL API. This is useful for setting up filter rules
to control which network packets are allowed from and to a guest
domains.
Currently, filters for Ethernet (MAC) frames, ARP packet data and IP
header information are possible.


1.2. XML Filter Description Format
-----------------------------------

The current Relax NG schema definition of the XML that is
produced/accepted by TBD can be found in the filter.rng. Filtering is
currently enabled by adding a filterref element to the interface
description of a domain XML file. The filterref element has a filter
atttribute which references the corresponding filter definition like in
the following example.

        <domain type='kvm' id='1'>
  <name>build1</name>
  <uuid>c7ac4ad9-e5ce-4c93-b380-013c85663e39</uuid>
  <memory>262144</memory>
  <currentMemory>262144</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-0.11'>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <kernel>/etc/libvirt/qemu/bzImage</kernel>
    <initrd>/etc/libvirt/qemu/i686-rootfs.i686.cpio.gz</initrd>
    <cmdline>kvmguest=1</cmdline>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <source file='/etc/libvirt/qemu/i686-rootfs.i686.ext2'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
    <controller type='ide' index='0'/>
    <interface type='network'>
      <mac address='d0:0f:d0:0f:02:01'/>
      <source network='mynet'/>
      <model type='virtio'/>
      <filterref filter='demofilter'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
    </serial>
    <console type='pty' tty='/dev/pts/1'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'/>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
    </video>
  </devices>
</domain>



Example 1.1. XML definition for a guest.


Network filters are specified using rules or by referencing other
filters
via filterref. This allows to construct complex filters from simpler,
potentially predefined filters.


1.2.1. Complex Filter

The named filters in the following examples are complex filters, which
include other, potentially predefined, filters. Included filters can
take
parameters, which are specified via an attX-valX pair (X starts at 0).

          <filter name='demofilter'>
  <filterref filter='no-arp-spoofing'/>
  <filterref filter='no-mac-spoofing'/>
  <filterref filter='no-ip-spoofing'/>
  <filterref filter='no-mac-broadcast'/>
  <filterref filter='allow-dhcp'>
    <parameter name='DHCPSERVER' value='10.3.2.1'/>
  </filterref>
  <filterref filter='no-other-l2-traffic'/>
</filter>


Example 1.2. XML definition for a complex filetr.


This is a pure Layer 2 filter configuration:

          <filter name='demofilter2'>
  <filterref filter='no-mac-spoofing'/>
  <filterref filter='no-mac-broadcast'/>
  <filterref filter='allow-arp'/>
  <filterref filter='allow-ipv4'/>
  <filterref filter='no-other-l2-traffic'/>
</filter>


Example 1.3. XML definition for another complex filetr.


1.2.2. Simple Filters

The following examples of simple filters are predefined and address
distint filter requirements. The predefined no-arp-spoofing filter drops
all ARP packets

  *  originating from the guest if they contain other than the guests IP
    or MAC address

  *  destined for the guest if they contain other than the guests IP or
    MAC address

It accepts all request or reply ARP packets.

          <filter name='no-arp-spoofing' chain='arp'>
   <uuid>f88f1932-debf-4aa1-9fbe-f10d3aa4bc95</uuid>
   
   <!-- no arp spoofing -->
   <!-- drop if ipaddr or macaddr does not belong to guest -->
   <rule action='drop' direction='out'>
       <arp match='no' srcmacaddr='$MAC'/>
   </rule>
   <rule action='drop' direction='out'>
       <arp match='no' srcipaddr='$IP' />
   </rule>
   <!-- drop if ipaddr or macaddr odes not belong to guest -->
   <rule action='drop' direction='in'>
       <arp match='no' dstmacaddr='$MAC'/>
   </rule>
   <rule action='drop' direction='in'>
       <arp match='no' dstipaddr='$IP' />
   </rule>
   <!-- accept only request or reply packets -->
   <rule action='accept' direction='inout'>
       <arp opcode='request'/>
   </rule>
   <rule action='accept' direction='inout'>
       <arp opcode='reply'/>
   </rule>
   <!-- drop everything else -->
   <rule action='drop' direction='inout'/>
</filter>


Example 1.4. XML definition to prevent ARP spoofing.


The predefined no-mac-spoofing filter drops all ethernet packets from
the
guest containing other than the guests MAC address as the source MAC
address.

          <filter name='no-mac-spoofing' chain='ipv4'>
  <rule action='drop' direction='out'>
      <mac match='no' srcmacaddr='$MAC' />
  </rule>
</filter>


Example 1.5. XML definition to prevent MAC spoofing.


The predefined no-ip-spoofing filter drops all IP packets from the guest
containing other than the guests IP address as the source IP address.

          <filter name='no-ip-spoofing' chain='ipv4'>

    <!-- no ip spoofing -->
    <!-- drop if srcipaddr is not the address of the guest -->
    <rule action='drop' direction='out'>
        <ip match='no' srcipaddr='$IP' />
    </rule>

    <!-- not doing anything with receiving side to prevent eavesdropping
-->
</filter>


Example 1.6. XML definition to prevent IP spoofing.


The predefined no-mac-broadcast filter drops all ethernet packets with
the broadcast mac address as destination.

          <filter name='no-mac-broadcast' chain='ipv4'>
    <!-- drop if destination mac is bcast mac addr. -->
    <rule action='drop' direction='out'>
        <mac dstmacaddr='ff:ff:ff:ff:ff:ff' />
    </rule>

    <!-- not doing anything with receiving side ... -->
</filter>


Example 1.7. XML definition to prevent outgoing broadcasts.


The predefined allow-dhcp filter allows DHCP requests and replies from
the specified DHCP server.

          <filter name='allow-dhcp' chain='ipv4'>

    <!-- accept outgoing DHCP requests -->
    <!-- not, this rule must be avaluated before general MAC broadcast 
         traffic is discarded since DHCP requests use MAC broadcast -->
    <rule action='accept' direction='out'>
        <ip srcipaddr='0.0.0.0'
            dstipaddr='255.255.255.255'
            protocol='udp'
            srcportstart='68'
            dstportstart='67' />
    </rule>
    
    <!-- accept incoming DHCP responses from a specific DHCP server
         parameter DHPCSERVER needs to be passed from where this filter
is
         referenced -->
    <rule action='accept' direction='in'>
        <ip srcipaddr='$DHCPSERVER'
            protocol='udp'
            srcportstart='67'
            dstportstart='68'/>
    </rule>

</filter>


Example 1.8. XML definition to allow DHCP requests and replys.


The predefined no-ip-multicast filter drops all ethernet packets with
the
multicast IP address as destination.

          <filter name='no-ip-multicast' chain='ipv4'>

    <!-- drop if destination IP address is in the 224.0.0.0/4 subnet -->
    <rule action='drop' direction='out'>
        <ip dstipaddr='224.0.0.0' dstipmask='4' />
    </rule>

    <!-- not doing anything with receiving side ... -->
</filter>


Example 1.9. XML definition to prevent multicast


The predefined no-other-l2-traffic filter drops all layer 2 packets
which
did not match other rules.

          <filter name='no-other-l2-traffic'>

    <!-- drop all other l2 traffic than for which rules have been
         written for
         Note: this rule should be the last on in the 'root' chain -->
    <rule action='drop' direction='inout'/>

</filter>


Example 1.10. XML definition to drop all other layer 2 traffic.


          <filter name='allow-arp' chain='arp'> 
  <rule direction='inout' action='accept'/> 
</filter>


Example 1.11. XML definition to allow arp traffic.


          <filter name='allow-ipv4' chain='ipv4'> 
  <rule direction='inout' action='accept'/> 
</filter>


Example 1.12. XML definition to allow IPV4 traffic.
------------------------------------------------------------------------



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]