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
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
