docs/firewall.html.in

   1 <?xml version="1.0"?>
   2 <html>
   3   <body>
   4     <h1 >Firewall and network filtering in libvirt</h1>
   5     <p>There are three pieces of libvirt functionality which do network
   6        filtering of some type.
   7        <br /><br />
   8        At a high level they are:
   9     </p>
  10     <ul>
  11       <li>The virtual network driver
  12           <br /><br />
  13           This provides a isolated bridge device (ie no physical NICs
  14           enslaved). Guest TAP devices are attached to this bridge.
  15           Guests can talk to each other and the host, and optionally the
  16           wider world.
  17           <br /><br />
  18       </li>
  19       <li>The QEMU driver MAC filtering
  20           <br /><br />
  21           This provides a generic filtering of MAC addresses to prevent
  22           the guest spoofing its MAC address. This is mostly obsoleted by
  23           the next item, so won't be discussed further.
  24           <br /><br />
  25       </li>
  26       <li>The network filter driver
  27           <br /><br />
  28           This provides fully configurable, arbitrary network filtering
  29           of traffic on guest NICs. Generic rulesets are defined at the
  30           host level to control traffic in some manner. Rules sets are
  31           then associated with individual NICs of a guest. While not as
  32           expressive as directly using iptables/ebtables, this can still
  33           do nearly everything you would want to on a guest NIC filter.
  34       </li>
  35     </ul>
  36
  37     <h3><a name="name-fw-virtual-network-driver"
  38            id="id-fw-virtual-network-driver">The virtual network driver</a>
  39     </h3>
  40     <p>The typical configuration for guests is to use bridging of the
  41        physical NIC on the host to connect the guest directly to the LAN.
  42        In RHEL6 there is also the possibility of using macvtap/sr-iov
  43        and VEPA connectivity. None of this stuff plays nicely with wireless
  44        NICs, since they will typically silently drop any traffic with a
  45        MAC address that doesn't match that of the physical NIC.
  46     </p>
  47     <p>Thus the virtual network driver in libvirt was invented. This takes
  48        the form of an isolated bridge device (ie one with no physical NICs
  49        enslaved). The TAP devices associated with the guest NICs are attached
  50        to the bridge device. This immediately allows guests on a single host
  51        to talk to each other and to the host OS (modulo host IPtables rules).
  52     </p>
  53     <p>libvirt then uses iptables to control what further connectivity is
  54        available. There are three configurations possible for a virtual
  55        network at time of writing:
  56     </p>
  57     <ul>
  58       <li>isolated: all off-node traffic is completely blocked</li>
  59       <li>nat: outbound traffic to the LAN is allowed, but MASQUERADED</li>
  60       <li>forward: outbound traffic to the LAN is allowed</li>
  61     </ul>
  62     <p>The latter 'forward' case requires the virtual network be on a
  63        separate sub-net from the main LAN, and that the LAN admin has
  64        configured routing for this subnet.  In the future we intend to
  65        add support for IP subnetting and/or proxy-arp. This allows for
  66        the virtual network to use the same subnet as the main LAN and
  67        should avoid need for the LAN admin to configure special routing.
  68     </p>
  69     <p>Libvirt will optionally also provide DHCP services to the virtual
  70        network using DNSMASQ. In all cases, we need to allow DNS/DHCP
  71        queries to the host OS. Since we can't predict whether the host
  72        firewall setup is already allowing this, we insert 4 rules into
  73        the head of the INPUT chain
  74     </p>
  75     <pre>
  76 target     prot opt in     out     source               destination
  77 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
  78 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
  79 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
  80 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:67</pre>
  81     <p>Note we have restricted our rules to just the bridge associated
  82        with the virtual network, to avoid opening undesirable holes in
  83        the host firewall wrt the LAN/WAN.
  84     </p>
  85     <p>The next rules depend on the type of connectivity allowed, and go
  86        in the main FORWARD chain:
  87     </p>
  88     <ul>
  89       <li>type=isolated
  90           <br /><br />
  91 Allow traffic between guests. Deny inbound. Deny outbound.
  92     <pre>
  93 target     prot opt in     out     source               destination
  94 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0
  95 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
  96 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
  97       </li>
  98       <li>type=nat
  99           <br /><br />
 100 Allow inbound related to an established connection. Allow
 101 outbound, but only from our expected subnet. Allow traffic
 102 between guests. Deny all other inbound. Deny all other outbound.
 103     <pre>
 104 target     prot opt in     out     source               destination
 105 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24    state RELATED,ESTABLISHED
 106 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0
 107 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
 108 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
 109 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
 110       </li>
 111       <li>type=routed
 112           <br /><br />
 113 Allow inbound, but only to our expected subnet. Allow
 114 outbound, but only from our expected subnet. Allow traffic
 115 between guests. Deny all other inbound. Deny all other outbound.
 116     <pre>
 117 target     prot opt in     out     source               destination
 118 ACCEPT     all  --  *      virbr2  0.0.0.0/0            192.168.124.0/24
 119 ACCEPT     all  --  virbr2 *       192.168.124.0/24     0.0.0.0/0
 120 ACCEPT     all  --  virbr2 virbr2  0.0.0.0/0            0.0.0.0/0
 121 REJECT     all  --  *      virbr2  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
 122 REJECT     all  --  virbr2 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable</pre>
 123       </li>
 124       <li>Finally, with type=nat, there is also an entry in the POSTROUTING
 125 chain to apply masquerading:
 126     <pre>
 127 target     prot opt in     out     source               destination
 128 MASQUERADE all  --  *      *       192.168.122.0/24    !192.168.122.0/24</pre>
 129       </li>
 130     </ul>
 131
 132     <h3><a name="name-fw-network-filter-driver"
 133            id="id-fw-network-filter-driver">The network filter driver</a>
 134     </h3>
 135     <p>This driver provides a fully configurable network filtering capability
 136        that leverages ebtables, iptables and ip6tables. This was written by
 137        the libvirt guys at IBM and although its XML schema is defined by libvirt,
 138        the conceptual model is closely aligned with the DMTF CIM schema for
 139        network filtering:
 140     </p>
 141     <p><a href="http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf">http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf</a></p>
 142     <p>The filters are managed in libvirt as a top level, standalone object.
 143        This allows the filters to then be referenced by any libvirt object
 144        that requires their functionality, instead tieing them only to use
 145        by guest NICs. In the current implementation, filters can be associated
 146        with individual guest NICs via the libvirt domain XML format. In the
 147        future we might allow filters to be associated with the virtual network
 148        objects. Further we're expecting to define a new 'virtual switch' object
 149        to remove the complexity of configuring bridge/sriov/vepa networking
 150        modes. This make also end up making use of network filters.
 151     </p>
 152     <p>There are a new set of virsh commands for managing network filters:</p>
 153     <ul>
 154       <li>virsh nwfilter-define
 155           <br /><br />
 156           define or update a network filter from an XML file
 157           <br /><br />
 158       </li>
 159       <li>virsh nwfilter-undefine
 160           <br /><br />
 161           undefine a network filter
 162           <br /><br />
 163       </li>
 164       <li>virsh nwfilter-dumpxml
 165           <br /><br />
 166           network filter information in XML
 167           <br /><br />
 168       </li>
 169       <li>virsh nwfilter-list
 170           <br /><br />
 171           list network filters
 172           <br /><br />
 173       </li>
 174       <li>virsh nwfilter-edit
 175           <br /><br />
 176           edit XML configuration for a network filter
 177       </li>
 178     </ul>
 179     <p>There are equivalently named C APIs for each of these commands.</p>
 180     <p>As with all objects libvirt manages, network filters are configured
 181 using an XML format. At a high level the format looks like this:
 182     </p>
 183 <pre>
 184 &lt;filter name='no-spamming' chain='XXXX'&gt;
 185   &lt;uuid&gt;d217f2d7-5a04-0e01-8b98-ec2743436b74&lt;/uuid&gt;
 186
 187   &lt;rule ...&gt;
 188     ....
 189   &lt;/rule&gt;
 190
 191   &lt;filterref filter='XXXX'/&gt;
 192 &lt;/filter&gt;</pre>
 193     <p>Every filter has a name and UUID which serve as unique identifiers.
 194        A filter can have zero-or-more <code>&lt;rule&gt;</code> elements which
 195        are used to actually define network controls. Filters can be arranged
 196        into a DAG, so zero-or-more <code>&lt;filterref/&gt;</code> elements are
 197        also allowed. Cycles in the graph are not allowed.
 198     </p>
 199     <p>The <code>&lt;rule&gt;</code> element is where all the interesting stuff
 200        happens. It has three attributes, an action, a traffic direction and an
 201        optional priority. eg:
 202     </p>
 203     <pre>&lt;rule action='drop' direction='out' priority='500'&gt;</pre>
 204     <p>Within the rule there are a wide variety of elements allowed, which
 205        do protocol specific matching. Supported protocols currently include
 206        <code>mac</code>, <code>arp</code>, <code>rarp</code>, <code>ip</code>,
 207        <code>ipv6</code>, <code>tcp/ip</code>, <code>icmp/ip</code>,
 208        <code>igmp/ip</code>, <code>udp/ip</code>, <code>udplite/ip</code>,
 209        <code>esp/ip</code>, <code>ah/ip</code>, <code>sctp/ip</code>,
 210        <code>tcp/ipv6</code>, <code>icmp/ipv6</code>, <code>igmp/ipv6</code>,
 211        <code>udp/ipv6</code>, <code>udplite/ipv6</code>, <code>esp/ipv6</code>,
 212        <code>ah/ipv6</code>, <code>sctp/ipv6</code>. Each protocol defines what
 213        is valid inside the &lt;rule&gt; element. The general pattern though is:
 214     </p>
 215     <pre>
 216 &lt;protocol match='yes|no' attribute1='value1' attribute2='value2'/&gt;</pre>
 217     <p>So, eg a TCP protocol, matching ports 0-1023 would be expressed as:</p>
 218     <pre>&lt;tcp match='yes' srcportstart='0' srcportend='1023'/&gt;</pre>
 219     <p>Attributes can included references to variables defined by the
 220        object using the rule. So the guest XML format allows each NIC
 221        to have a MAC address and IP address defined. These are made
 222        available to filters via the variables <code><b>$IP</b></code> and
 223        <code><b>$MAC</b></code>.
 224     </p>
 225     <p>So to define a filter that prevents IP address spoofing we can
 226        simply match on source IP address <code>!= $IP</code> like this:
 227     </p>
 228     <pre>
 229 &lt;filter name='no-ip-spoofing' chain='ipv4'&gt;
 230   &lt;rule action='drop' direction='out'&gt;
 231     &lt;ip match='no' srcipaddr='<b>$IP</b>' /&gt;
 232   &lt;/rule&gt;
 233 &lt;/filter&gt;</pre>
 234     <p>I'm not going to go into details on all the other protocol
 235        matches you can do, because it'll take far too much space.
 236        You can read about the options
 237        <a href="formatnwfilter.html#nwfelemsRulesProto">here</a>.
 238     </p>
 239     <p>Out of the box in RHEL6/Fedora rawhide, libvirt ships with a
 240        set of default useful rules:
 241     </p>
 242     <pre>
 243 # virsh nwfilter-list
 244 UUID                                  Name
 245 ----------------------------------------------------------------
 246 15b1ab2b-b1ac-1be2-ed49-2042caba4abb  allow-arp
 247 6c51a466-8d14-6d11-46b0-68b1a883d00f  allow-dhcp
 248 7517ad6c-bd90-37c8-26c9-4eabcb69848d  allow-dhcp-server
 249 3d38b406-7cf0-8335-f5ff-4b9add35f288  allow-incoming-ipv4
 250 5ff06320-9228-2899-3db0-e32554933415  allow-ipv4
 251 db0b1767-d62b-269b-ea96-0cc8b451144e  clean-traffic
 252 f88f1932-debf-4aa1-9fbe-f10d3aa4bc95  no-arp-spoofing
 253 772f112d-52e4-700c-0250-e178a3d91a7a  no-ip-multicast
 254 7ee20370-8106-765d-f7ff-8a60d5aaf30b  no-ip-spoofing
 255 d5d3c490-c2eb-68b1-24fc-3ee362fc8af3  no-mac-broadcast
 256 fb57c546-76dc-a372-513f-e8179011b48a  no-mac-spoofing
 257 dba10ea7-446d-76de-346f-335bd99c1d05  no-other-l2-traffic
 258 f5c78134-9da4-0c60-a9f0-fb37bc21ac1f  no-other-rarp-traffic
 259 7637e405-4ccf-42ac-5b41-14f8d03d8cf3  qemu-announce-self
 260 9aed52e7-f0f3-343e-fe5c-7dcb27b594e5  qemu-announce-self-rarp</pre>
 261     <p>Most of these are just building blocks. The interesting one here
 262        is 'clean-traffic'. This pulls together all the building blocks
 263        into one filter that you can then associate with a guest NIC.
 264        This stops the most common bad things a guest might try, IP
 265        spoofing, arp spoofing and MAC spoofing. To look at the rules for
 266        any of these just do:
 267     </p>
 268     <pre>virsh nwfilter-dumpxml FILTERNAME|UUID</pre>
 269     <p>They are all stored in <code>/etc/libvirt/nwfilter</code>, but don't
 270        edit the files there directly. Use <code>virsh nwfilter-define</code>
 271        to update them. This ensures the guests have their iptables/ebtables
 272        rules recreated.
 273     </p>
 274     <p>To associate the clean-trafffic filter with a guest, edit the
 275        guest XML config and change the <code>&lt;interface&gt;</code> element
 276        to include a <code>&lt;filterref&gt;</code> and also specify the
 277        whitelisted <code>&lt;ip address/&gt;</code> the guest is allowed to
 278        use:
 279     </p>
 280     <pre>
 281 &lt;interface type='bridge'&gt;
 282   &lt;mac address='52:54:00:56:44:32'/&gt;
 283   &lt;source bridge='br1'/&gt;
 284   &lt;ip address='10.33.8.131'/&gt;
 285   &lt;target dev='vnet0'/&gt;
 286   &lt;model type='virtio'/&gt;
 287   &lt;filterref filter='clean-traffic'/&gt;
 288 &lt;/interface&gt;</pre>
 289     <p>If no <code>&lt;ip address&gt;</code> is included, the network filter
 290        driver will activate its 'learning mode'. This uses libpcap to snoop on
 291        network traffic the guest sends and attempts to identify the
 292        first IP address it uses. It then locks traffic to this address.
 293        Obviously this isn't entirely secure, but it does offer some
 294        protection against the guest being trojaned once up and running.
 295        In the future we intend to enhance the learning mode so that it
 296        looks for DHCPOFFERS from a trusted DHCP server and only allows
 297        the offered IP address to be used.
 298     </p>
 299     <p>Now, how is all this implemented...?</p>
 300     <p>The network filter driver uses a combination of ebtables, iptables and
 301        ip6tables, depending on which protocols are referenced in a filter. The
 302        out of the box 'clean-traffic' filter rules only require use of
 303        ebtables. If you want to do matching at tcp/udp/etc protocols (eg to add
 304        a new filter 'no-email-spamming' to block port 25), then iptables will
 305        also be used.
 306     </p>
 307     <p>The driver attempts to keep its rules separate from those that
 308        the host admin might already have configured. So the first thing
 309        it does with ebtables, is to add two hooks in POSTROUTING and
 310        PREROUTING chains, to redirect traffic to custom chains. These
 311        hooks match on the TAP device name of the guest NIC, so they
 312        should not interact badly with any administrator defined rules:
 313     </p>
 314     <pre>
 315 Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
 316 -i vnet0 -j libvirt-I-vnet0
 317
 318 Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
 319 -o vnet0 -j libvirt-O-vnet0</pre>
 320     <p>To keep things managable and easy to follow, the driver will then
 321        create further sub-chains for each protocol then it needs to match
 322        against:
 323     </p>
 324     <pre>
 325 Bridge chain: libvirt-I-vnet0, entries: 5, policy: ACCEPT
 326 -p IPv4 -j I-vnet0-ipv4
 327 -p ARP -j I-vnet0-arp
 328 -p 0x8035 -j I-vnet0-rarp
 329 -p 0x835 -j ACCEPT
 330 -j DROP
 331
 332 Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
 333 -p IPv4 -j O-vnet0-ipv4
 334 -p ARP -j O-vnet0-arp
 335 -p 0x8035 -j O-vnet0-rarp
 336 -j DROP</pre>
 337     <p>Finally, here comes the actual implementation of the filters. This
 338        example shows the 'clean-traffic' filter implementation.
 339        I'm not going to explain what this is doing now. :-)
 340     </p>
 341     <pre>
 342 Bridge chain: I-vnet0-ipv4, entries: 2, policy: ACCEPT
 343 -s ! 52:54:0:56:44:32 -j DROP
 344 -p IPv4 --ip-src ! 10.33.8.131 -j DROP
 345
 346 Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
 347 -j ACCEPT
 348
 349 Bridge chain: I-vnet0-arp, entries: 6, policy: ACCEPT
 350 -s ! 52:54:0:56:44:32 -j DROP
 351 -p ARP --arp-mac-src ! 52:54:0:56:44:32 -j DROP
 352 -p ARP --arp-ip-src ! 10.33.8.131 -j DROP
 353 -p ARP --arp-op Request -j ACCEPT
 354 -p ARP --arp-op Reply -j ACCEPT
 355 -j DROP
 356
 357 Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT
 358 -p ARP --arp-op Reply --arp-mac-dst ! 52:54:0:56:44:32 -j DROP
 359 -p ARP --arp-ip-dst ! 10.33.8.131 -j DROP
 360 -p ARP --arp-op Request -j ACCEPT
 361 -p ARP --arp-op Reply -j ACCEPT
 362 -j DROP
 363
 364 Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT
 365 -p 0x8035 -s 52:54:0:56:44:32 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
 366 -j DROP
 367
 368 Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT
 369 -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 52:54:0:56:44:32 --arp-mac-dst 52:54:0:56:44:32 -j ACCEPT
 370 -j DROP</pre>
 371     <p>NB, we would have liked to include the prefix 'libvirt-' in all
 372        of our chain names, but unfortunately the kernel limits names
 373        to a very short maximum length. So only the first two custom
 374        chains can include that prefix. The others just include the
 375        TAP device name + protocol name.
 376     </p>
 377     <p>If I define a new filter 'no-spamming' and then add this to the
 378        'clean-traffic' filter, I can illustrate how iptables usage works:
 379     </p>
 380     <pre>
 381 # cat &gt; /root/spamming.xml &lt;&lt;EOF
 382 &lt;filter name='no-spamming' chain='root'&gt;
 383   &lt;uuid&gt;d217f2d7-5a04-0e01-8b98-ec2743436b74&lt;/uuid&gt;
 384   &lt;rule action='drop' direction='out' priority='500'&gt;
 385     &lt;tcp dstportstart='25' dstportend='25'/&gt;
 386   &lt;/rule&gt;
 387 &lt;/filter&gt;
 388 EOF
 389 # virsh nwfilter-define /root/spamming.xml
 390 # virsh nwfilter-edit clean-traffic</pre>
 391
 392     <p>...add <code>&lt;filterref filter='no-spamming'/&gt;</code></p>
 393     <p>All active guests immediately have their iptables/ebtables rules
 394        rebuilt.
 395     </p>
 396     <p>The network filter driver deals with iptables in a very similar
 397        way. First it separates out its rules from those the admin may
 398        have defined, by adding a couple of hooks into the INPUT/FORWARD
 399        chains:
 400     </p>
 401     <pre>
 402 Chain INPUT (policy ACCEPT 13M packets, 21G bytes)
 403 target           prot opt in     out     source               destination
 404 libvirt-host-in  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 405
 406 Chain FORWARD (policy ACCEPT 5532K packets, 3010M bytes)
 407 target           prot opt in     out     source               destination
 408 libvirt-in       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 409 libvirt-out      all  --  *      *       0.0.0.0/0            0.0.0.0/0
 410 libvirt-in-post  all  --  *      *       0.0.0.0/0            0.0.0.0/0</pre>
 411     <p>These custom chains then do matching based on the TAP device
 412        name, so they won't open holes in the admin defined matches for
 413        the LAN/WAN (if any).
 414     </p>
 415     <pre>
 416 Chain libvirt-host-in (1 references)
 417   target     prot opt in     out     source               destination
 418   HI-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-in vnet0
 419
 420 Chain libvirt-in (1 references)
 421   target     prot opt in     out     source               destination
 422   FI-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-in vnet0
 423
 424 Chain libvirt-in-post (1 references)
 425   target     prot opt in     out     source               destination
 426   ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vnet0
 427
 428 Chain libvirt-out (1 references)
 429   target     prot opt in     out     source               destination
 430   FO-vnet0   all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] PHYSDEV match --physdev-out vnet0</pre>
 431     <p>Finally, we can see the interesting bit which is the actual
 432        implementation of my filter to block port 25 access:
 433     </p>
 434     <pre>
 435 Chain FI-vnet0 (1 references)
 436   target     prot opt in     out     source               destination
 437   DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25
 438
 439 Chain FO-vnet0 (1 references)
 440   target     prot opt in     out     source               destination
 441   DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25
 442
 443 Chain HI-vnet0 (1 references)
 444   target     prot opt in     out     source               destination
 445   DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25</pre>
 446     <p>One thing in looking at this you may notice is that if there
 447        are many guests all using the same filters, we will be duplicating
 448        the iptables rules over and over for each guest. This is merely a
 449        limitation of the current rules engine implementation. At the libvirt
 450        object modelling level you can clearly see we've designed the model
 451        so filter rules are defined in one place, and indirectly referenced
 452        by guests. Thus it should be possible to change the implementation in
 453        the future so we can share the actual iptables/ebtables rules for
 454        each guest to create a more scalable system. The stuff in current libvirt
 455        is more or less the very first working implementation we've had of this,
 456        so there's not been much optimization work done yet.
 457     </p>
 458     <p>Also notice that at the XML level we don't expose the fact we
 459        are using iptables or ebtables at all. The rule definition is done in
 460        terms of network protocols. Thus if we ever find a need, we could
 461        plug in an alternative implementation that calls out to a different
 462        firewall implementation instead of ebtables/iptables (providing that
 463        implementation was suitably expressive of course)
 464     </p>
 465     <p>Finally, in terms of problems we have in deployment. The biggest
 466        problem is that if the admin does <code>service iptables restart</code>
 467        all our work gets blown away. We've experimented with using lokkit
 468        to record our custom rules in a persistent config file, but that
 469        caused different problem. Admins who were not using lokkit for
 470        their config found that all their own rules got blown away. So
 471        we threw away our lokkit code. Instead we document that if you
 472        run <code>service iptables restart</code>, you need to send SIGHUP to
 473        libvirt to make it recreate its rules.
 474     </p>
 475     <p>More in depth documentation on this is <a href="formatnwfilter.html">here</a>.</p>
 476   </body>
 477 </html>