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