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

Jan Lieskovsky jlieskov at redhat.com
Thu Oct 8 16:29:29 UTC 2015


  Hello Jeff,

----- Original Message -----
> From: "Šimon Lukašík" <slukasik at redhat.com>
> To: "Jeffrey Hawkins" <rtswguru at hotmail.com>, open-scap-list at redhat.com, scap-security-guide at lists.fedorahosted.org
> Cc: "Thomas Woerner" <twoerner at redhat.com>
> Sent: Thursday, October 8, 2015 6:07:27 PM
> Subject: Re: [Open-scap] RHEL FirewallD Requirement for Hosts that have well defined STATIC configurations
> 
> 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.

  To follow up on the SSG position / opinion wrt to the preference of iptables vs.
firewalld when creating SCAP rules. It's not like SSG upstream would prefer
one solution rather than the other. Like Simon said both of them should be
supported / available. The reason why couple of firewalld rules have been
added into the RHEL-7 benchmark being, firewalld is the default firewall application /
package installed on Red Hat Enterprise Linux 7 system. We first want the defaults
to be covered, then port existing RHEL-6 iptables rules to RHEL-7 system
(because they need to be ported or at least tested && recognized as still to be
working before they can be included into the RHEL-7 benchmark).

  To sketch the approach shortly basically we would follow the same approach
which is applied in the chronyd vs ntpd case (meaning to support both of the possibilities).
Though chronyd being the default, there still are valid use-cases when use of ntpd
might be preferred / is recommended over use of chronyd.

  Similarly with iptables vs firewalld approach. We want to support both of them.
Just focusing on firewalld first because it's what's installed by default on the system.

Hope the above clarifies the approach. If not, don't hesitate to ask further.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

> 
> Thoughts?
> ~š.
> 
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 


More information about the scap-security-guide mailing list