P { MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px }
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: [email protected]
comm: (703) 704-2299 dsn: (312) 654-2299
cell: (571) 225-1283
smime.p7s
Description: S/MIME cryptographic signature
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
