[libvirt] Don't add iptables rules when creating networks

Felix Schwarz felix.schwarz at oss.schwarz.eu
Mon Dec 21 14:42:17 UTC 2009


Am 21.12.2009 13:04, schrieb Daniel P. Berrange:
> There shold never be duplicated rules. If you stop a libvirt virutal network,
> it will remove its previously added rules, so there should be no duplication
> next time it is started. If removal isn't working, that's a bug to be fixed.

I had two different networks, one with nat, one routed. Only one is started 
with autostart. As soon as I start the other, I get additional (duplicated I 
think) rules.

> Can you outline how your desired configuration for libvirt NAT mode is
> different from what libvirt already does ? The goal for this is to be
> totally zero-conf, so that fact that you can't use the default setup
> shows something is lacking in our impl&  I'd prefer to identify what
> that is rather than blindly disabling it.

Actually my main interest is the routed mode, not NAT.

This is my iptables after I started two networks (no other packet filter):

# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere            udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:bootps
ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere            udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.78.21
ACCEPT     all  --  192.168.78.21        anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable
ACCEPT     all  --  anywhere             192.168.122.0/24    state 
RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable

(...)

My issues:
1) INPUT chain ACCEPTs DNS/dhcp from outside

You might notice that the INPUT chain basically says that I ACCEPT all 
DNS/dhcp from all interfaces. I don't want that. As soon as I configure a 
packet filter (e.g. shorewall), libvirt's configuration will take precedence.

2) FORWARD contains general rules
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with 
icmp-port-unreachable

These rules apply to all FORWARDed connections. I need *way* more control.

3) FORWARD ACCEPTs packets from all hosts
ACCEPT     all  --  anywhere             192.168.78.21
ACCEPT     all  --  192.168.78.21        anywhere

Say I have routed libvirt network but I want to protect these hosts - only 
some specific hosts may reach them (e.g. a virtualized backend app server is 
only reachable by the frontend servers). With the generated iptables rules I 
can not do that.

4) No way to override rules
All new iptables rules are pre-prepended when a new network is started (which 
may happen at any time), potentially circumventing all existing rules.

5) Company policies
How do you keep firewall rules manageable/auditable in 'not extremly simple' 
situations?
Many companies I know have a very strict policy that only one application is 
allowed to define rules (e.g. shorewall or a proprietary FW). I mean you @Red 
Hat should know stuff like that. If libvirt touches my carefully reviewed 
policies, it might open a lot of security issues.


That being said I appreciate your approach to make it easy for simple cases 
and desktop end users. In fact, I'm using libvirt since Fedora 10 on a desktop 
with problems. Now with RHEL 5.4 I'm starting to use that on servers and here 
I need way more control.

I guess there are a lot more use cases when you just need to disable automated 
iptables changes - just because libvirt does not have the whole picture.

 >> Therefore I would like to have some kind 'power user' flag that prevents
 >> libvirt from adding any filter rules. I'm fine with activating it manually
 >> as long as I don't have to patch libvirt.
 >
 > This isn't really something we want to support. As I mention above we
 > want to make sure this works out of the box without manual config.

I can totally understand you - but how do you think you can deal with system 
security if libvirt just does not have all information? How can I use a 
libvirt host as a router, only giving specific IPs accesss to a routed network?

 > The one change we do want to make to the setup, is to move all the rules
 > into dedicated chains (libvirt_INPUT, libvirt_FORWARD, etc) so that we
 > only add a single rule to the main INPUT/FORWARD chains.

I'm afraid that this won't help in my situation: Still all the rules are 
prepended and I can not specify which rules should be inserted.

fs




More information about the libvir-list mailing list