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

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



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


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