| blob | e86ab0d9747ab0bafe6b0364672430fc9de14433 |
4 <body>
6 <p>There are three pieces of libvirt functionality which do network
7 filtering of some type.
8 <br /><br />
9 At a high level they are:
10 </p>
11 <ul>
12 <li>The virtual network driver
13 <br /><br />
14 This provides an isolated bridge device (ie no physical NICs
15 enslaved). Guest TAP devices are attached to this bridge.
16 Guests can talk to each other and the host, and optionally the
17 wider world.
18 <br /><br />
19 </li>
20 <li>The QEMU driver MAC filtering
21 <br /><br />
22 This provides a generic filtering of MAC addresses to prevent
23 the guest spoofing its MAC address. This is mostly obsoleted by
24 the next item, so won't be discussed further.
25 <br /><br />
26 </li>
27 <li>The network filter driver
28 <br /><br />
29 This provides fully configurable, arbitrary network filtering
30 of traffic on guest NICs. Generic rulesets are defined at the
31 host level to control traffic in some manner. Rules sets are
32 then associated with individual NICs of a guest. While not as
33 expressive as directly using iptables/ebtables, this can still
34 do nearly everything you would want to on a guest NIC filter.
35 </li>
36 </ul>
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>
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
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
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
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
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
129 </li>
130 </ul>
132 <h3><a id="fw-firewalld-and-virtual-network-driver">firewalld and the virtual network driver</a>
133 </h3>
134 <p>
136 the host, libvirt will attempt to place the bridge interface of
137 a libvirt virtual network into the firewalld zone named
139 subject to the rules of the "libvirt" zone). This is done
140 because, if firewalld is using its nftables backend (available
141 since firewalld 0.6.0) the default firewalld zone (which would
142 be used if libvirt didn't explicitly set the zone) prevents
143 forwarding traffic from guests through the bridge, as well as
144 preventing DHCP, DNS, and most other traffic from guests to
145 host. The zone named "libvirt" is installed into the firewalld
146 configuration by libvirt (not by firewalld), and allows
147 forwarded traffic through the bridge as well as DHCP, DNS, TFTP,
148 and SSH traffic to the host - depending on firewalld's backend
149 this will be implemented via either iptables or nftables
150 rules. libvirt's own rules outlined above will *always* be
151 iptables rules regardless of which backend is in use by
152 firewalld.
153 </p>
154 <p>
155 NB: It is possible to manually set the firewalld zone for a
156 network's interface with the "zone" attribute of the network's
157 "bridge" element.
158 </p>
159 <p>
161 exist, and prior to firewalld 0.7.0 a feature crucial to making
162 the "libvirt" zone operate properly (rich rule priority
163 settings) was not implemented in firewalld. In cases where one
164 or the other of the two packages is missing the necessary
165 functionality, it's still possible to have functional guest
166 networking by setting the firewalld backend to "iptables" (in
167 firewalld prior to 0.6.0, this was the only backend available).
168 </p>
171 </h3>
172 <p>This driver provides a fully configurable network filtering capability
173 that leverages ebtables, iptables and ip6tables. This was written by
174 the libvirt guys at IBM and although its XML schema is defined by libvirt,
175 the conceptual model is closely aligned with the DMTF CIM schema for
176 network filtering:
177 </p>
178 <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>
179 <p>The filters are managed in libvirt as a top level, standalone object.
180 This allows the filters to then be referenced by any libvirt object
181 that requires their functionality, instead tying them only to use
182 by guest NICs. In the current implementation, filters can be associated
183 with individual guest NICs via the libvirt domain XML format. In the
184 future we might allow filters to be associated with the virtual network
185 objects. Further we're expecting to define a new 'virtual switch' object
186 to remove the complexity of configuring bridge/sriov/vepa networking
187 modes. This make also end up making use of network filters.
188 </p>
190 <ul>
191 <li>virsh nwfilter-define
192 <br /><br />
193 define or update a network filter from an XML file
194 <br /><br />
195 </li>
196 <li>virsh nwfilter-undefine
197 <br /><br />
198 undefine a network filter
199 <br /><br />
200 </li>
201 <li>virsh nwfilter-dumpxml
202 <br /><br />
203 network filter information in XML
204 <br /><br />
205 </li>
206 <li>virsh nwfilter-list
207 <br /><br />
208 list network filters
209 <br /><br />
210 </li>
211 <li>virsh nwfilter-edit
212 <br /><br />
213 edit XML configuration for a network filter
214 </li>
215 </ul>
217 <p>As with all objects libvirt manages, network filters are configured
218 using an XML format. At a high level the format looks like this:
219 </p>
220 <pre>
225 ....
230 <p>Every filter has a name and UUID which serve as unique identifiers.
232 are used to actually define network controls. Filters can be arranged
234 also allowed. Cycles in the graph are not allowed.
235 </p>
237 happens. It has three attributes, an action, a traffic direction and an
238 optional priority. E.g.:
239 </p>
241 <p>Within the rule there are a wide variety of elements allowed, which
242 do protocol specific matching. Supported protocols currently include
251 </p>
252 <pre>
256 <p>Attributes can included references to variables defined by the
257 object using the rule. So the guest XML format allows each NIC
258 to have a MAC address and IP address defined. These are made
261 </p>
262 <p>So to define a filter that prevents IP address spoofing we can
264 </p>
265 <pre>
271 <p>I'm not going to go into details on all the other protocol
272 matches you can do, because it'll take far too much space.
273 You can read about the options
275 </p>
276 <p>Out of the box in RHEL6/Fedora rawhide, libvirt ships with a
277 set of default useful rules:
278 </p>
279 <pre>
280 # virsh nwfilter-list
281 UUID Name
282 ----------------------------------------------------------------
298 <p>Most of these are just building blocks. The interesting one here
299 is 'clean-traffic'. This pulls together all the building blocks
300 into one filter that you can then associate with a guest NIC.
301 This stops the most common bad things a guest might try, IP
302 spoofing, arp spoofing and MAC spoofing. To look at the rules for
303 any of these just do:
304 </p>
308 to update them. This ensures the guests have their iptables/ebtables
309 rules recreated.
310 </p>
311 <p>To associate the clean-traffic filter with a guest, edit the
315 use:
316 </p>
317 <pre>
327 driver will activate its 'learning mode'. This uses libpcap to snoop on
328 network traffic the guest sends and attempts to identify the
329 first IP address it uses. It then locks traffic to this address.
330 Obviously this isn't entirely secure, but it does offer some
331 protection against the guest being trojaned once up and running.
332 In the future we intend to enhance the learning mode so that it
333 looks for DHCPOFFERS from a trusted DHCP server and only allows
334 the offered IP address to be used.
335 </p>
337 <p>The network filter driver uses a combination of ebtables, iptables and
338 ip6tables, depending on which protocols are referenced in a filter. The
339 out of the box 'clean-traffic' filter rules only require use of
340 ebtables. If you want to do matching at tcp/udp/etc protocols (eg to add
341 a new filter 'no-email-spamming' to block port 25), then iptables will
342 also be used.
343 </p>
344 <p>The driver attempts to keep its rules separate from those that
345 the host admin might already have configured. So the first thing
346 it does with ebtables, is to add two hooks in POSTROUTING and
347 PREROUTING chains, to redirect traffic to custom chains. These
348 hooks match on the TAP device name of the guest NIC, so they
349 should not interact badly with any administrator defined rules:
350 </p>
351 <pre>
352 Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
353 -i vnet0 -j libvirt-I-vnet0
355 Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
356 -o vnet0 -j libvirt-O-vnet0</pre>
357 <p>To keep things manageable and easy to follow, the driver will then
358 create further sub-chains for each protocol then it needs to match
359 against:
360 </p>
361 <pre>
362 Bridge chain: libvirt-I-vnet0, entries: 5, policy: ACCEPT
363 -p IPv4 -j I-vnet0-ipv4
364 -p ARP -j I-vnet0-arp
365 -p 0x8035 -j I-vnet0-rarp
366 -p 0x835 -j ACCEPT
367 -j DROP
369 Bridge chain: libvirt-O-vnet0, entries: 4, policy: ACCEPT
370 -p IPv4 -j O-vnet0-ipv4
371 -p ARP -j O-vnet0-arp
372 -p 0x8035 -j O-vnet0-rarp
373 -j DROP</pre>
374 <p>Finally, here comes the actual implementation of the filters. This
375 example shows the 'clean-traffic' filter implementation.
376 I'm not going to explain what this is doing now. :-)
377 </p>
378 <pre>
379 Bridge chain: I-vnet0-ipv4, entries: 2, policy: ACCEPT
381 -p IPv4 --ip-src ! 10.33.8.131 -j DROP
383 Bridge chain: O-vnet0-ipv4, entries: 1, policy: ACCEPT
384 -j ACCEPT
386 Bridge chain: I-vnet0-arp, entries: 6, policy: ACCEPT
389 -p ARP --arp-ip-src ! 10.33.8.131 -j DROP
390 -p ARP --arp-op Request -j ACCEPT
391 -p ARP --arp-op Reply -j ACCEPT
392 -j DROP
394 Bridge chain: O-vnet0-arp, entries: 5, policy: ACCEPT
396 -p ARP --arp-ip-dst ! 10.33.8.131 -j DROP
397 -p ARP --arp-op Request -j ACCEPT
398 -p ARP --arp-op Reply -j ACCEPT
399 -j DROP
401 Bridge chain: I-vnet0-rarp, entries: 2, policy: ACCEPT
402 -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
403 -j DROP
405 Bridge chain: O-vnet0-rarp, entries: 2, policy: ACCEPT
406 -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
407 -j DROP</pre>
408 <p>NB, we would have liked to include the prefix 'libvirt-' in all
409 of our chain names, but unfortunately the kernel limits names
410 to a very short maximum length. So only the first two custom
411 chains can include that prefix. The others just include the
412 TAP device name + protocol name.
413 </p>
414 <p>If I define a new filter 'no-spamming' and then add this to the
415 'clean-traffic' filter, I can illustrate how iptables usage works:
416 </p>
417 <pre>
425 EOF
426 # virsh nwfilter-define /root/spamming.xml
427 # virsh nwfilter-edit clean-traffic</pre>
430 <p>All active guests immediately have their iptables/ebtables rules
431 rebuilt.
432 </p>
433 <p>The network filter driver deals with iptables in a very similar
434 way. First it separates out its rules from those the admin may
435 have defined, by adding a couple of hooks into the INPUT/FORWARD
436 chains:
437 </p>
438 <pre>
440 target prot opt in out source destination
444 target prot opt in out source destination
448 <p>These custom chains then do matching based on the TAP device
449 name, so they won't open holes in the admin defined matches for
450 the LAN/WAN (if any).
451 </p>
452 <pre>
453 Chain libvirt-host-in (1 references)
454 target prot opt in out source destination
457 Chain libvirt-in (1 references)
458 target prot opt in out source destination
461 Chain libvirt-in-post (1 references)
462 target prot opt in out source destination
465 Chain libvirt-out (1 references)
466 target prot opt in out source destination
468 <p>Finally, we can see the interesting bit which is the actual
469 implementation of my filter to block port 25 access:
470 </p>
471 <pre>
472 Chain FI-vnet0 (1 references)
473 target prot opt in out source destination
476 Chain FO-vnet0 (1 references)
477 target prot opt in out source destination
480 Chain HI-vnet0 (1 references)
481 target prot opt in out source destination
483 <p>One thing in looking at this you may notice is that if there
484 are many guests all using the same filters, we will be duplicating
485 the iptables rules over and over for each guest. This is merely a
486 limitation of the current rules engine implementation. At the libvirt
487 object modelling level you can clearly see we've designed the model
488 so filter rules are defined in one place, and indirectly referenced
489 by guests. Thus it should be possible to change the implementation in
490 the future so we can share the actual iptables/ebtables rules for
491 each guest to create a more scalable system. The stuff in current libvirt
492 is more or less the very first working implementation we've had of this,
493 so there's not been much optimization work done yet.
494 </p>
495 <p>Also notice that at the XML level we don't expose the fact we
496 are using iptables or ebtables at all. The rule definition is done in
497 terms of network protocols. Thus if we ever find a need, we could
498 plug in an alternative implementation that calls out to a different
499 firewall implementation instead of ebtables/iptables (providing that
500 implementation was suitably expressive of course)
501 </p>
502 <p>Finally, in terms of problems we have in deployment. The biggest
504 all our work gets blown away. We've experimented with using lokkit
505 to record our custom rules in a persistent config file, but that
506 caused different problem. Admins who were not using lokkit for
507 their config found that all their own rules got blown away. So
508 we threw away our lokkit code. Instead we document that if you
510 libvirt to make it recreate its rules.
511 </p>
513 </body>
514 </html>