On Tue, Sep 24, 2013 at 6:57 PM, Eric H. Christensen <spa...@fedoraproject.org> wrote: > 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.
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 > 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). 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. > 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. Eliminating the no-op chains would make sense, and a bug has been already filed out for this. > In my opinion, firewalld works very well when used on desktop (user) machines > and not so much on servers and the like. 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 -- security mailing list security@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
