On Tue, Sep 24, 2013 at 6:57 PM, Eric H. Christensen <sparks@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
