firewalld vs iptables vs ? as default (was Comparison to Workstation Technical Specification)

Jonathan Dieter jdieter at lesbg.com
Wed Feb 26 13:30:48 UTC 2014


On Wed, 2014-02-26 at 08:24 -0500, Stephen Gallagher wrote:
> On 02/26/2014 03:03 AM, Jonathan Dieter wrote:
> > On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
> >> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
> >>> I would extend this statement to include that the deployment of
> >>> Server Roles should also adjust the firewall operation in a
> >>> manner consistent with user expectation.
> >> 
> >> Are we going to use something like firewalld or something else ?
> > 
> > Just want to ask this question again, with an additional one.  What
> > does firewalld give us that iptables doesn't in a server
> > environment?  Should we default to iptables instead?  Are there
> > other alternatives we should consider?
> > 
> 
> About two years ago now, some members of product management did a
> customer tour to see how people are actually using RHEL and Fedora in
> production environments.
> 
> The overwhelming majority of real-world deployments disable the Linux
> kernel firewall (iptables) entirely and rely exclusively on perimeter
> security. The reason they cited for this was this: iptables is nearly
> impossible to manage centrally. This is primarily because the only
> interface to manipulating iptables are highly-complex command-line
> tools that have to be executed in a shell.
> 
> The main advantage that we get from firewalld is that it is providing
> a public D-BUS interface that we can use to connect central management
> tools (such as puppet) to apply a complete set of rules in one go (as
> opposed to the necessarily procedural approach we are currently faced
> with, which is reading the current state, parsing it, determining
> which changes need to be made and then performing the diff... all
> manually and racy)

Ok, that makes sense.

Thanks,
Jonathan



More information about the server mailing list