-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, Sep 24, 2013 at 11:53:29PM +0800, P J P wrote: Yeah, I've been reading that conversation but I never made any replies to it. I haven't investigated firewalld that much but here's my shoot-from-the-hip thought on the subject: I wrote a paper on using iptables at the end of one of my college courses on security. iptables (and its varient ip6tables) is a very powerful tool that allows people to do all kinds of things to incoming and outgoing packets. Here's the problem as I see it. iptables *can* be confusing to implement and software that needs a port opened hasn't really been able to interface with iptables very well in the past. Supposedly firewalld fixed the problem with iptables not being very dynamic. This would mean that if you stopped your SSH daemon TCP port 22 should also close as well (I haven't tested this and I won't comment on whether this actually works). firewalld also provides a nice GUI for people to use so they can setup complex rules based on what network they are connected to. Creating zones in iptables was always possible but it just sucked when you tried to manage it. This GUI, however, means that iptables rules now look horrible when you query them directly. Does this mean it has been done incorrectly? Nope. It just means that when you decide to use complex rules you get complex rules. System administrators should figure out if firewalld is a problem or an asset. firewalld does things like make sure that rules are echoed across iptables and ip6tables which further reduces the complexity of setting up rules. In my opinion, firewalld works very well when used on desktop (user) machines and not so much on servers and the like. This would not be the first tool that falls into this category. I suspect that when the F21 releases come out (different desktop and server images) we'll see a more specialized set of tools on each so that each group is happier (maybe). Does firewalld make systems more vulnerable? No, not any more than iptables did. Does it make the iptables ruleset look horrible? Why are you configuring iptables using a GUI tool and then looking at the raw rules anyway? - -- Eric - -------------------------------------------------- Eric "Sparks" Christensen Fedora Project sparks(a)fedoraproject.org - sparks(a)redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some random thoughts: 1) it would be nice to have capabilities like "do you want to let program X talk to the internet/receive connections" for client software with a GUI notification (like basically all the windows client/Mac OS X client firewall stuff). I would say this is probably the biggest capability needed for normal end users. 2) Tying firewall into networking detection, e.g. windows "is this your home/business/public network" and then remembering it (I assume IP/Mac address of default gateway would be a reasonably good way to identify networks). 3) Make it easy to modify policy, e.g. in section 1) if you choose to block/deny something and realize that was the wrong decision how do you go in an modify it? In Windows this is a PITA for normal users. Overall I'm not really sure firewalld solves much, anyone running a server will probably be able to tweak iptables to allow incoming services they want. So do we aim it at the end user/workstation style usage primarily (especially ones that move around networks)? - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

On Tue, Sep 24, 2013 at 6:57 PM, Eric H. Christensen <sparks(a)fedoraproject.org&gt; wrote: It does; in my view the primary problem it fixes is iptables being at too low level of abstraction. The question "is port 22 open" can be only answered for itpables by interpreting a Turing-complete language. The dynamic changes are more of a corner case That's not what firewalld does, and it doesn't make that much sense anyway - all it would protect against is vulnerabilities in kernel's handling of CLOSED sockets. Eliminating the no-op chains would make sense, and a bug has been already filed out for this. I don't think server/desktop is a very way to think about firewalls. The primary classes are "self-managed desktop" vs. "network endpoints: servers and IT-managed desktops" vs. "routers/NAT boxes/network infrastructure". For self-managed desktops, there really shouldn't be a firewall blocking anything the user wants to do - because it's impossible to reasonably ask the user for a firewall policy decision, all such a firewall would do is annoy the user, or make the product seem broken. (It might still make sense to have a default configuration blocking "system" services that the user might not even know about, like the sshd we run by default.) For centrally-managed network endpoints. having an actual API to call with firewalld instead of manually editing files and hoping that there wasn't a typo is, I think, usually beneficial. (Yes, administrators can get similar level of safety by using a different iptables front-end, like perhaps the puppet firewall module.) With http://fedoraproject.org/wiki/Features/FirewalldRichLanguage , it seems to me that the major use cases for an endpoint server (not a network gateway) have been covered fairly well. Is there anything missing? For routers/NAT/network infrastructure, it's firewalld is likely not sufficient. Will firewalld natively _everything_ that iptables can do? No, that would defeat the point of having a higher-level API. Still, there is the --direct API that allows users to talk to iptables directly; is that not working well enough? Mirek

On Tue, Sep 24, 2013 at 8:11 PM, Kurt Seifried <kseifried(a)redhat.com&gt; wrote: This really doesn't work. On the UI level: * It's impossible to ask about outgoing connections: "Do you want /usr/bin/yncp program to connect to 23.56.68.226 port 31337"? At best, the user will be afraid and click "no"; or perhaps they will guess that yncp stands for "your new chat program" that has been recently installed, and understand that it is wanting to connect - and of course they want the chat program to connect. Nobody will ever realize that that IP address is what www.nsa.gov resolves to, and that the port is the default for Black Orifice. * It's impossible to ask about opening listening sockets: "Do you want /usr/bin/yncp to accept connection requests over the Internet?" - "Of course I want my chat program to accept conversations!" * There isn't any practical difference between the two any more anyway, due to the prevalence of NAT firewalls. On the security architecture level, we don't have a concept of "program X" that is good enough for making security decisions (e.g. due to ptrace, shared access to the configuration in home directory, lack of X11 access control). This is a known problem, and is being slowly worked on, and will hopefully eventually be solved; however the UI problems are pretty much unsolvable. Anyone running a server will probably be able to learn iptables if they have to. Still, is a pretty sad thing to have to type in 2013 - we have all these computer things that are supposedly good at automating boring work, so why shouldn't this be automated/abstracted away by the computer? No, firewalld is primarily aimed at "network end-points", managed by an administrator who understands IP networks but not necessarily knowing iptables by heart. Mirek

On Thu, Sep 26, 2013 at 4:40 PM, Matthew Miller <mattdm(a)mattdm.org&gt; wrote: That somewhat works when checking for an open port, but not when you want the port to be closed. Perhaps it's only closed for the management machine that is doing the check, to shut the security department up. Mirek