I find firewalld rather easy to manage, as by default it expects to have configurations
broken out into separate files. So if 200 systems are running Service X and the rest
aren't, I can simply push the relevant .xml files to those systems, and have one
script that deals with adding rules from any new files that show up.
It's sort of the same reason I "backported" augenrules to RHEL5 and RHEL6 in
our environment: monolithic config files are a headache. I'm sure one could do
something similar with iptables, but I don't think it's set up that way out of the
box.
--
Ray Shaw
Unix Support, ARL
Contractor, TENAX (Team Catapult)
-----Original Message-----
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trevor Vaughan
Sent: Tuesday, October 13, 2015 9:48 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
Cc: open-scap-list(a)redhat.com
Subject: Re: [Open-scap] RHEL FirewallD Requirement for Hosts that have well defined
STATIC configurations
This email was sent from a non-Department of Defense email account, and contained active
links. All links are disabled, and require you to copy and paste the address to a Web
browser. Please verify the identity of the sender, and confirm authenticity of all links
contained within the message.
________________________________
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(a)gmail.com <
Caution-mailto:redhatrises@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.
Caution-https://lists.fedorahosted.org/pipermail/scap-security-guide/2014...
<
Caution-https://lists.fedorahosted.org/pipermail/scap-security-guide/2014...
>
Caution-https://lists.fedorahosted.org/pipermail/scap-security-guide/2014...
<
Caution-https://lists.fedorahosted.org/pipermail/scap-security-guide/2014...
>
On Thu, Oct 8, 2015 at 10:07 AM, Šimon Lukašík <slukasik(a)redhat.com <
Caution-mailto: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(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@lists.fedorahosted.org >
Caution-https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide <
Caution-https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >
Caution-https://github.com/OpenSCAP/scap-security-guide/ <
Caution-https://github.com/OpenSCAP/scap-security-guide/ >
--
SCAP Security Guide mailing list
scap-security-guide(a)lists.fedorahosted.org <
Caution-mailto:scap-security-guide@lists.fedorahosted.org >
Caution-https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide <
Caution-https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >
Caution-https://github.com/OpenSCAP/scap-security-guide/ <
Caution-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 --