(RHEL7) IPTables vs FirewallD

Trevor Vaughan tvaughan at onyxpoint.com
Sun Oct 5 21:36:06 UTC 2014


After using both, I would recommend using iptables for servers and
firewalld for desktops. (As a side note, anyone have notes on allowing
users to change the firewall but only for certain ports?).

You may be able to disable this, but it looks like firewalld has hooks that
allow for services to open their own ports as necessary. I would never want
this in a production system. Firewall rules must be approved and then
applied not applied as applications see fit. The exception to this would be
things like OpenStack and OpenShift but trying to explain either of those
has been an exercise in patience.

Also, to verify that firewalld is doing what you actually expect it to, you
need to know iptables. If you know iptables, you don't need firewalld.

Finally, there's the firewalld rich language. It appears to be an almost
direct mapping of the iptables rules yet with slightly different syntax
and/or XML files to maintain. In other words, confusing.

The only place where this might hurt is the new libvirt integration, I'm
not quite sure yet.

Hrm, after re-reading this I sound a bit of a curmudgeon. Oh well, get off
my IPTables lawn!

Trevor

On Sat, Oct 4, 2014 at 2:42 PM, Crawford, Nicholas P CTR USARMY CERDEC (US)
<nicholas.p.crawford.ctr at mail.mil> wrote:

>   Currently it looks like the momentum is towards tables.  The updates
> from Maura Dailey [1] for systemd fixed the majority of the checks.
> Additionally future editions of RHEL 7 may include nftables as it’s
> currently in Tech Preview.
>
> • IPTables work is already done, seems to still be valid, and requires no
> obvious updates.
> • FirewallD, will require some work (see below).
> • NFTables, TBD.
>
> If the intent is to support both, then the logical fork would be at the
> currently active service.  Further checks will need to rely on the results
> of which firewall is in use.  Is it possible to logically fork in OVAL?
>
>
>
> From the rhel7-guide and stig table it appears that our only automated
> checks are:
>
> 1) Is it enabled?
>
> The actual requirement is that the system provides an IPv4 and IPv6
> firewall.  FirewallD is both an IPv4 and and IPv6 firewall and satisfies
> this requirement.
>
> Resolution: `systemctl is-active firewalld` should return "active".
>
> 2) Are the default INPUT/FORWARD policies set to DROP?
>
> The actual requirement is the firewall must be DAPE (Deny All Permit by
> Exception), the FirewallD Zone/Target is synonymous with this requirement.
>
> firewalld always leaves the tables policy as ACCEPT, additionally
> firewalld doesn’t use /etc/sysconfig/ip[6]tables. Thus the current check
> will always fail. Further, compliant /etc/sysconfig/ip[6]tables files while
> using firewalld could lead to a false-negative.
>
> All default zones appear to meet this requirement except trusted which
> defaults to ACCEPT.  The end-user can create and modify zones with the
> ACCEPT target.  A check of the active zones’ targets should verify that
> none are set to ACCEPT.
>
> Proposal: the check should simply ensure that active zones’ targets are
> not set to ACCEPT.  `firewall-cmd --get-default-zone` , `firewall-cmd
> --get-active-zones` , `firewall-cmd --get-target` , `firewall-cmd
> --zone=<zone> --get-target`.
>
>
>
> The get-target output will be one of DROP, %%REJECT%%, ACCEPT or
> {chain}_{zone}.  {chain}_{zone} was changed to “default” upstream with
> commit 267bb9d103f7134d8d0116ab0b7d3aaf38f5f3c8 [2].  As far as I can tell,
> as long as the target is not ACCEPT, it’s a DAPE firewall.
>
> Further hardening
>
>
>
> More firewalld work is required to support ICMP hardening, suspicious
> source log drops, and services hardening for both implementation and
> evaluation.  Services seems pretty simple, ICMP and suspicious source
> appear to require RichLanguage [3].
>
> Whether firewalld is capable of accepting the current ICMP rules isn’t
> immediately obvious as Fedora’s [4] and Red Hat’s [5] documentation only
> point to “icmp-block”.  Potentially the logic can be reversed.  Change the
> current allow echo-reply (0), destination-unreachable (3), time-exceeded
> (11) and instead block the remaining firewalld supported icmp types;
> parameter-problem (12), redirect (5), router-advertisement (9),
> router-solicitation (10), source-quench (4).  However, this doesn't address
> over 30 other defined and 200 undefined ICMP types that would be allowed
> because they can’t be blocked by firewalld.
>
> With firewalld there may be additional checks to add.  For example, the
> default zone “external” includes masquerading, this zone shouldn’t be
> active unless the system is a router.  To check for the presence of
> masquerading `firewall-cmd --zone=<zone> --query-masquerade` should return
> no for active zones.
>
> References
> [1]
> https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-February/005015.html
> [2]
> https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8d0116ab0b7d3aaf38f5f3c8
> [3] https://fedoraproject.org/wiki/FirewallD
> [4] http://fedoraproject.org/wiki/Features/FirewalldRichLanguage
> [5]
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html
>
>
>
> --
>
> *Nicholas P. Crawford*
>
> *Senior UNIX Systems Administrator*
>
> contractor, *General Dynamics Information Technology*
>
> NVESD Network Services Branch, US Army
>
> email: Nicholas.Crawford at gdit.com
> <https://web.mail.mil/owa/redir.aspx?C=00688bcc9fc8448894ffb85cfe4572f0&URL=mailto%3aNicholas.Crawford%40gdit.com>
>
> comm: (703) 704-2299 dsn: (312) 654-2299
>
> cell: (571) 225-1283
>
> --
> 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
tvaughan at onyxpoint.com

-- 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/20141005/ed359368/attachment.html>


More information about the scap-security-guide mailing list