[Open-scap] RHEL FirewallD Requirement for Hosts that have well defined STATIC configurations

Trevor Vaughan tvaughan at onyxpoint.com
Tue Oct 13 13:47:47 UTC 2015


I was at PuppetConf last week and, from an automation perspective (and ease
of overall management), the majority of people that I spoke with turn off
firewalld in favor of iptables.

In particular, anyone that was compliance focused was 100% against any
application being able to modify the firewall directly with the notable
exceptions of Docker and OpenStack.

Finally, I have enough trouble getting people to understand the output of a
linear iptables output. I gave up trying to explain the firewalld output.

Prior to sticking it in the STIG, *please* see if a stock-standard ISSO can
understand both the ramifications and the output of using firewalld in
production.

If we are to stick with firewalld, I might suggest that the default rules
be replaced with two zones, trusted and untrusted as this makes things MUCH
easier.

To Jeff's original point, there is now the 'direct' command in firewall-cmd
that lets you just shove iptables rules into the stack. I haven't played
with this enough to determine if it makes any sense to use in production. I
will say that trying to read the output of a raw iptables command once
firewalld is running is pretty much impossible on a standard terminal.
Likewise, running 15 commands to try and figure out what's actually going
on with the firewalld stack is highly irritating.

Heck, I had to resort to writing down the entire stack on paper because I
couldn't just read it!

Yours Curmudgeonly,

Trevor

On Thu, Oct 8, 2015 at 12:31 PM, Gabe Alford <redhatrises at gmail.com> wrote:

> Here are some old threads that discussed this that *I think* (should say
> vaguely remember) moved to usage of Firewalld over the IPTables services.
>
>
> https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-October/006214.html
>
> https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-October/006208.html
>
> On Thu, Oct 8, 2015 at 10:07 AM, Šimon Lukašík <slukasik at redhat.com>
> wrote:
>
>> On 10/07/2015 07:55 PM, Jeffrey Hawkins wrote:
>>
>>>
>>> A question on Requirements, in particular STIGs.
>>>
>>> Looking thru the work-in-progress it appears there is a callout for
>>> usage of FIREWALLD, otherwise, a Finding.  I would have thought it would
>>> be acceptable for RHEL Hosts with static configurations using IPTABLES
>>> is acceptable.  We have RHEL Application Server Hosts (Headless)  that
>>> have static services and configurations with well defined static
>>> IPTABLES based rules for INPUT/OUTPUT (FORWARDING disabled).  There are
>>> no dynamic changes that are ever applied to these Hosts, and if there
>>> are changes, we explicitly account for these.    We are moving from
>>> RHEL6 to RHEL7 and do not see any security benefit in moving the INPUT
>>> rules set to be managed by FIREWALLD. If FIREWALLD evolves to be a
>>> complete controller of IPTABLES Rules, rather than a mixture of
>>> FIREWALLD manages some, while other must be manually configured in
>>> IPTABLES, the we will move to FIREWALLD. We would like to see the STIG
>>> Requirements provide for an OR Case to allow for STATIC based IPTABLES
>>> Usage, rather than requiring usage of FIREWALLD.
>>>
>>> Who is handling this area to discuss this, and make acceptable the usage
>>> of STATIC IPTABLES Rules ?
>>>
>>> Jeff
>>>
>>>
>> Hello Jeff,
>>
>> I think you are touching some of the harder questions here.
>>
>> We are in transition period. There is a lot of deployments and
>> configuration systems touching iptables directly. On the other hand,
>> firewalld abstraction can make some of the use-cases easier.
>>
>> If the question was, can a general guidance like STIG require everyone to
>> use firewalld. It could, however, it may not get adopted due to the upper
>> mentioned facts.
>>
>> If the question was, will the SSG upstream accept my contribution if I
>> choose either part. The answer is yes. We can have OVAL checks for
>> firewalld and iptables combined and then XCCDF description that describes
>> the rational rather then technical detail. If you happen to use iptables
>> (or firewalld) heavily in your organization, feel free to start with
>> adressing your use case.
>>
>> Thoughts?
>> ~š.
>> --
>> SCAP Security Guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> https://github.com/OpenSCAP/scap-security-guide/
>
>
>
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20151013/e212b00b/attachment-0001.html>


More information about the scap-security-guide mailing list