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 <[email protected]> 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
