From: Stefan Berger Date: Thu, 7 Oct 2010 10:50:26 +0000 (-0400) Subject: nwfilter: Add 2nd example to the html docs X-Git-Tag: v0.8.5~185 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5e760a91ab0eb9284b81521f42195dee4a5a9743;p=thirdparty%2Flibvirt.git nwfilter: Add 2nd example to the html docs This patch adds another example to the nwfilter html page and provides 2 solutions for how to write a filter meeting the given requirements using newly added features. --- diff --git a/docs/formatnwfilter.html.in b/docs/formatnwfilter.html.in index 213b67605a..6cc433b168 100644 --- a/docs/formatnwfilter.html.in +++ b/docs/formatnwfilter.html.in @@ -1458,7 +1458,8 @@
  • prevents a VM's interface from MAC, IP and ARP spoofing
  • opens only TCP ports 22 and 80 of a VM's interface
  • allows the VM to send ping traffic from an interface - but no let the VM be pinged on the interface
  • + but not let the VM be pinged on the interface +
  • allows the VM to do DNS lookups (UDP towards port 53)
  • The requirement to prevent spoofing is fulfilled by the existing @@ -1500,6 +1501,11 @@ <icmp/> </rule> + <!-- enable outgoing DNS lookups using UDP --> + <rule action='accept' direction='out'> + <udp dstportstart='53'/> + </rule> + <!-- drop all other traffic --> <rule action='drop' direction='inout'> <all/> @@ -1546,6 +1552,178 @@ </rule> +

    Second example custom filter

    +

    + In this example we now want to build a similar filter as in the + example above, but extend the list of requirements with an + ftp server located inside the VM. Further, we will be using features + that have been added in version 0.8.5. + The requirements for this filter are: +

    + +

    + The additional requirement of allowing an ftp server to be run inside + the VM maps into the requirement of allowing port 21 to be reachable + for ftp control traffic as well as enabling the VM to establish an + outgoing tcp connection originating from the VM's TCP port 20 back to + the ftp client (ftp active mode). There are several ways of how this + filter can be written and we present 2 solutions. +

    + The 1st solution makes use of the state attribute of + the TCP protocol that gives us a hook into the connection tracking + framework of the Linux host. For the VM-initiated ftp data connection + (ftp active mode) we use the RELATED state that allows + us to detect that the VM-initiated ftp data connection is a consequence of + ( or 'has a relationship with' ) an existing ftp control connection, + thus we want to allow it to let packets + pass the firewall. The RELATED state, however, is only + valid for the very first packet of the outgoing TCP connection for the + ftp data path. Afterwards, the state to compare against is + ESTABLISHED, which then applies equally + to the incoming and outgoing direction. All this is related to the ftp + data traffic originating from TCP port 20 of the VM. This then leads to + the following solution + (since 0.8.5 (Qemu, KVM, UML)): +

    +
    +<filter name='test-eth0'>
    +  <!-- reference the clean traffic filter to prevent
    +       MAC, IP and ARP spoofing. By not providing
    +       and IP address parameter, libvirt will detect the
    +       IP address the VM is using. -->
    +  <filterref filter='clean-traffic'/>
    +
    +  <!-- enable TCP port 21 (ftp-control) to be reachable -->
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='21'/>
    +  </rule>
    +
    +  <!-- enable TCP port 20 for VM-initiated ftp data connection
    +       related to an existing ftp control connection -->
    +  <rule action='accept' direction='out'>
    +    <tcp srcportstart='20' state='RELATED,ESTABLISHED'/>
    +  </rule>
    +
    +  <!-- accept all packets from client on the ftp data connection -->
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='20' state='ESTABLISHED'/>
    +  </rule>
    +
    +  <!-- enable TCP ports 22 (ssh) and 80 (http) to be reachable -->
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='22'/>
    +  </rule>
    +
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='80'/>
    +  </rule>
    +
    +  <!-- enable general ICMP traffic to be initiated by the VM;
    +       this includes ping traffic -->
    +  <rule action='accept' direction='out'>
    +    <icmp/>
    +  </rule>
    +
    +  <!-- enable outgoing DNS lookups using UDP -->
    +  <rule action='accept' direction='out'>
    +    <udp dstportstart='53'/>
    +  </rule>
    +
    +  <!-- drop all other traffic -->
    +  <rule action='drop' direction='inout'>
    +    <all/>
    +  </rule>
    +
    +</filter>
    +
    +

    + Before trying out a filter using the RELATED state, + you have to make sure that the approriate connection tracking module + has been loaded into the host's kernel. Depending on the version of the + kernel, you must run either one of the following two commands before + the ftp connection with the VM is established. +

    +
    +    modprobe nf_conntrack_ftp   # where available  or
    +
    +    modprobe ip_conntrack_ftp   # if above is not available
    +
    +

    + If other protocols than ftp are to be used in conjunction with the + RELATED state, their corresponding module must be loaded. + Modules exist at least for the protocols ftp, tftp, irc, sip, + sctp, and amanda. +

    +

    + The 2nd solution makes uses the state flags of connections more + than the previous solution did. + In this solution we take advantage of the fact that the + NEW state of a connection is valid when the very + first packet of a traffic flow is seen. Subsequently, if the very first + packet of a flow is accepted, the flow becomes a connection and enters + the ESTABLISHED state. This allows us to write a general + rule for allowing packets of ESTABLISHED connections to + reach the VM or be sent by the VM. + We write specific rules for the very first packets identified by the + NEW state and for which ports they are acceptable. All + packets for ports that are not explicitly accepted will be dropped and + therefore the connection will not go into the ESTABLISHED + state and any subsequent packets be dropped. +

    + +
    +<filter name='test-eth0'>
    +  <!-- reference the clean traffic filter to prevent
    +       MAC, IP and ARP spoofing. By not providing
    +       and IP address parameter, libvirt will detect the
    +       IP address the VM is using. -->
    +  <filterref filter='clean-traffic'/>
    +
    +  <!-- let the packets of all previously accepted connections reach the VM -->
    +  <rule action='accept' direction='in'>
    +    <all state='ESTABLISHED'/>
    +  </rule>
    +
    +  <!-- let the packets of all previously accepted and related connections be sent from the VM -->
    +  <rule action='accept' direction='out'>
    +    <all state='ESTABLISHED,RELATED'/>
    +  </rule>
    +
    +  <!-- enable traffic towards port 21 (ftp), 22 (ssh) and 80 (http) -->
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='21' dstportend='22' state='NEW'/>
    +  </rule>
    +
    +  <rule action='accept' direction='in'>
    +    <tcp dstportstart='80' state='NEW'/>
    +  </rule>
    +
    +  <!-- enable general ICMP traffic to be initiated by the VM;
    +       this includes ping traffic -->
    +  <rule action='accept' direction='out'>
    +    <icmp state='NEW'/>
    +  </rule>
    +
    +  <!-- enable outgoing DNS lookups using UDP -->
    +  <rule action='accept' direction='out'>
    +    <udp dstportstart='53' state='NEW'/>
    +  </rule>
    +
    +  <!-- drop all other traffic -->
    +  <rule action='drop' direction='inout'>
    +    <all/>
    +  </rule>
    +
    +</filter>
    +
    +

    Limitations