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@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@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/