Re: Firewall settings unworkable
On 10/06/2010 08:31 PM, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. Rich. I have thought a lot about the iptables.d directory. It is a nice thing if your firewall is static and there are no dynamic elements like wireless networks or services or programs requesting to open a port and also if the rule representation would be non-ambiguous. Saving the rules with service ip*tables save is hard to do with this because you you have to check if the rules in the firewall match rules in one or more of the files to prevent to have double, triple, .. rules every time you are saving them. The biggest problem here is though that ip*tables are reformatting and also changing parameters from the external to the internal representation (see icmp types, marks, insert id's, addresses, .. ). If you are saving, then you will get the internal representation, which might be different to the one you have in the file. Therefore simple rule matching is impossible to decide if the rule is the same or not. You have to actively parse and compare every single parameter. Insert id's for example are completely lost in the internal representation. Using the ip*tables commands to add and remove rules is working, because it does not matter if you are using names or id's and so on, because it matches the internal representation in netfilter. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/07/2010 02:20 AM, Genes MailLists wrote: On 10/06/2010 11:26 AM, Thomas Woerner wrote: 6) Compatibility Mode The current static firewall model will still be available for compatibility for users or administrators creating their own firewall. This deactivates the firewall service and also the D-BUS daemon. --- Comments and additional information is highly welcome. I hope by 'compatibility mode' you mean it is 'completely off' and there is no possibility of it touching the rules because its not running in any form. Its vital for those of us who have hand coded firewall rules that this is totally turned off and it is impossible for it to touch the rules. In my case, I have about 40,000 rules and I def don't want anything else mucking with them! Thanks - its an interesting idea and the default firewall could use some spiffing up for many use cases. Yes, the compatibility mode means that the dynamic daemon is disabled and the current system-config-firewall, ip*tables and ebtables services will still be availabe to be able to have an own and/or static firewall setup. The only question here is what the default should be in the furture. I think for desktop installations it should be the daemon and for servers the static model. Firstboot, installation time or first network usage is a good place to define this in my opinion. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Wed, 2010-10-06 at 17:26 +0200, Thomas Woerner wrote: It is possible to specify a timeout for a firewall service and also the other features. The service will be opened immediately and closed again after the defined period is over. This allows to accept new connections from unknown sources in the specified time frame. This will be very useful for UPNP, SNMP or NetBIOS for example to find printers or to share data with others. This mechanism is similar to the bluetooth handler in cell phones. This is great news, can't wait to see the interface. Thanks, Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Wed, 2010-10-06 at 19:31 +0100, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. Other applications need more than that. For example, when CUPS wants to detect network printers using SNMP, a query is sent as a UDP packet to the broadcast address(es) from a local unprivileged port to the remote SNMP port, 161. It needs to be able to hear replies. What I was saying in my original post is that there is no simple iptables rule that can be written today to express that, aside from simply allowing all UDP packets to unprivileged ports, obviously not something we want to do. Ideally the kernel would provide a way to express this using a conntrack module. Until that time, however, being able to do this would suffice: * bind() to get a free local unprivileged port * use D-Bus to tell the firewall to allow UDP sport:161 dport:$port for a short time * send query * listen for responses * (optionally) use D-Bus to tell the firewall it can discard that rule now Until bind() is called, no-one knows what local port to allow UDP packets in on. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
I am currently working on a proof of concept implementation of a firewall daemon, that will support dynamic firewall management with a D-BUS interface. This implementation should be usable in some days and will feature the transition of the current firewall model to the dynamic version. It will provide the majority of features system-config-firewall has at the moment (services, ports, trusted, forward, icmp and masquerading), but will be limited to a command line client with D-BUS interface. Here is more information on planned and proposed features: Firewall Concepts - PROPOSAL 1) Firewall daemon The current firewall services are static and can not handle dynamic firewall changes. Also system, user and administrator preferences can not be incorporated easily. The separation of IPv4 and IPv6 firewall services makes all this even worse. The solution is to create a firewall service with a daemon, which is taking care of the firewall similar to NetworkManager that does this for network connections. The firewall daemon provides information about the current active firewall settings via D-BUS and also accepts firewall changes via D-BUS by using policykit authentication methods. The firewall daemon is acting as a single authority for firewall creation and management. Controlling and maintaining the firewall if there are several applications or daemons changing firewall rules and behavior independently will most likely make it impossible to have a sane firewall state. Support for additional firewall features like ebtables is needed to be able to support desktop and virtualizsation requirements. 2) Dynamic firewall The current static model does not allow to add or remove rules and to load or unload netfilter firewall helpers easily. Restarting the firewall completely is required. Also the order of rules is very important and the usage of the predefined INPUT and FORWARD rules chains only is not helping to solve this. The chains need to be separated. For example chains for services and ports, masquerading, port forwarding, icmp filtering and virtualization and custom rules. This makes it much more flexible, safe and robust. Adding a rule with the firewall daemon to one of these chains will most likely not interefere with rules of other chains. The order of the chains and how they are used is fixed and will not change. For the netfilter firewall helpers it is not that easy. Helpers are for example used for amanda, ftp, samba and tftp services. If one of these services gets disabled, then the helper has to get unloaded from the kernel. For some of the helpers this is only possible after all connections that are handled by the module are closed. Therefore connection tracking information is important here and needs to get into account. Adding support for conntrack connection handling is therefore needed here. It is possible to specify a timeout for a firewall service and also the other features. The service will be opened immediately and closed again after the defined period is over. This allows to accept new connections from unknown sources in the specified time frame. This will be very useful for UPNP, SNMP or NetBIOS for example to find printers or to share data with others. This mechanism is similar to the bluetooth handler in cell phones. 3) Network zones: Network security model The network security model specifies the default trust level of all connections and can be selected initially at installation time, firstboot or when the first network connection gets established. The model describes the trust level of the whole network environment, the host is connected to and also defines what to do with new connections. There are different initial models: - Home / Work - Public - Connection specific The home or work zone has the highest trust level. All incoming connections are allowed. The public zone on the other hand is fully untrusted. No incoming connection is allowed. The connection specific model requires that the user tunes the trust level of a connection according to the needs. The default is untrusted. The user or administrator is able to define new zones or adapt initial zones to change the behaviour according to their needs. Network connections can be bound to zones. The network security model makes it possible to have one trust level for all connections or to have several connections with different trust levels. The firewall has support for these zones and makes it possible that the user or admin can enable firewall features for zones. If a new or undefined network connection is enabled in NetworkManager, the firewall daemon gets informed about this via D-BUS and can set firewall rules accordingly. There are chains for all supported network zones 4) Port metadata information (proposed by Lennart Poettering) To have a port independent metadata information would be good to have. The current
Re: Firewall settings unworkable
On 10/06/2010 08:31 PM, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. If you do an /etc/init.d/iptables save and then reboot the machine you will probably end up with duplicate rules because the libvirt rules are now created from /etc/sysconfig/iptables and then again from the respective iptables.d file. That's why I mentioned the two layer approach. You basically need a layer that loads the basic rules and then applies the per-subsystem ones and that is able to extract the per-subsystem rules again on save. This could be relatively easy or very hard depending the subset of rules you want to support for the subsystems. Thomas Woerners idea looks like the best approach to this. I was aiming for a more iterative approach using scripts instead of a daemon but if Thomas has fleshed this out already and some code working then more power to him :) Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/06/2010 11:26 AM, Thomas Woerner wrote: 6) Compatibility Mode The current static firewall model will still be available for compatibility for users or administrators creating their own firewall. This deactivates the firewall service and also the D-BUS daemon. --- Comments and additional information is highly welcome. I hope by 'compatibility mode' you mean it is 'completely off' and there is no possibility of it touching the rules because its not running in any form. Its vital for those of us who have hand coded firewall rules that this is totally turned off and it is impossible for it to touch the rules. In my case, I have about 40,000 rules and I def don't want anything else mucking with them! Thanks - its an interesting idea and the default firewall could use some spiffing up for many use cases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Sat, Oct 02, 2010 at 02:17:49AM +0200, Dennis J. wrote: [...] I asked Dan Berrange to join this thread since he's most knowledgable about the exact problem and requirements from the libvirt side. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: There are several protocols used for discovery of network services that currently cannot be made to work on Fedora simply due to the restrictive firewall we use by default. For example, a broadcast SNMP query to discover network printers is sent as a UDP packet from an unprivileged local port to SNMP port of the broadcast address. Network printers respond by sending a UDP packet in response, from the SNMP port back to the local unprivileged port. ZeroConf discovery (port 5353) is denied by default also :( -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
The following works for UDP too: -A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT Leastways, I can do AFS through my firewall with it. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, 2010-10-01 at 15:23 +0200, Tomasz Torcz wrote: ZeroConf discovery (port 5353) is denied by default also :( But that can be enabled with a single checkbox (Multicast DNS (mDNS)), and that can also be done programmatically using system-config-firewall's D-Bus interface, such as it is. In fact, system-config-printer does just that. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, 2010-10-01 at 15:07 +0100, David Howells wrote: The following works for UDP too: -A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT Leastways, I can do AFS through my firewall with it. Does that work for unicast replies to broadcast queries though? e.g. IP 10.1.1.8.33353 10.1.1.255.snmp: GetRequest(28) .1.3.6.1.2.1.25.3.2.1.2.1 IP 10.1.1.7.snmp 10.1.1.8.33353: GetResponse(37) .1.3.6.1.2.1.25.3.2.1.2.1=.1.3.6.1.2.1.25.3.1.5 Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, 2010-10-01 at 15:19 +0100, David Howells wrote: Good question; I don't know. netfil...@vger.kernel.org is probably the place to ask. I did ask about this issue on netfilter, last year (look for SNMP conntrack module a la netbios_ns, Dec 4th 2009). That's where the idea for a general broadcast query response tracking module came from. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: In system-config-printer I try to get it to modify the firewall to allow in the various network query responses that we expect, [...] I should note, although it's not your fault, that this breaks libvirt networking. libvirt needs to add its own firewall rules too, and restarting the firewall breaks these rules until you restart the libvirt network and all your VMs. The root problem here is that our firewall rules aren't composable. As you can tell by the bug #, this issue has been around for quite a long time ... https://bugzilla.redhat.com/show_bug.cgi?id=227011 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/01/2010 10:36 PM, Richard W.M. Jones wrote: On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: In system-config-printer I try to get it to modify the firewall to allow in the various network query responses that we expect, [...] I should note, although it's not your fault, that this breaks libvirt networking. libvirt needs to add its own firewall rules too, and restarting the firewall breaks these rules until you restart the libvirt network and all your VMs. The root problem here is that our firewall rules aren't composable. As you can tell by the bug #, this issue has been around for quite a long time ... https://bugzilla.redhat.com/show_bug.cgi?id=227011 I'm wondering what the actual requirements are in order to make it possible for a service to add rules to the firewall. The discussion in the bug mixes general requirements for such a feature with current iptables limitations which makes it difficult to understand the problem fully. In a first step it would probably be best to create a layer on top of iptables that manages the addition and removal of rules that can be independently configured. That way you don't have to find quirky hacks for iptables. service iptables save for would then call the save function of that management layer which in turn could save the iptables rules to a temporary file, filter out the service rules and then save the standard/global/default rules in /etc/sysconfig/iptables and the service rules it filterd out into /etc/sysconfig/iptables.d/service. When loading the whole thing is executed in reverse. Once workable semantics are found for such a management layer the second step could be to move these features into iptables itself if possible. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
