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/0... [2] https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8... [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/htm...
--
Nicholas P. Crawford
Senior UNIX Systems Administrator
contractor, General Dynamics Information Technology
NVESD Network Services Branch, US Army
email: Nicholas.Crawford@gdit.com
comm: (703) 704-2299 dsn: (312) 654-2299
cell: (571) 225-1283
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@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:
- 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".
- 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/0... [2] https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8... [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/htm...
--
*Nicholas P. Crawford*
*Senior UNIX Systems Administrator*
contractor, *General Dynamics Information Technology*
NVESD Network Services Branch, US Army
email: Nicholas.Crawford@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Hello Trevor,
thanks for raising this question.
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Sunday, October 5, 2014 11:36:06 PM Subject: Re: (RHEL7) IPTables vs FirewallD
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.
Have checked the above point with firewalld upstream developers (Cc-ed) and below is their reaction (since they are not subscribed to the SSG mailing list if you have further questions / comments & want them to react on these, pls keep them Cc-ed). To get to the reply (Thomas Woerner):
<quote> There are no hooks to automatically open ports in the firewall. It is needed to be authenticated to open ports in the firewall.
Some firewalld service definitions are enabling netfilter conntrack helpers to allow connections that are defined in the helpers to fix 'broken' protocols. But this applies only if the service is enabled in the firewall configuration.
The services that are enabling helpers are: amanda-client.xml: <module name="nf_conntrack_amanda"/> amanda-k5-client.xml: <module name="nf_conntrack_amanda"/> ftp.xml: <module name="nf_conntrack_ftp"/> samba-client.xml: <module name="nf_conntrack_netbios_ns"/> samba.xml: <module name="nf_conntrack_netbios_ns"/> sane.xml: <module name="nf_conntrack_sane"/> tftp-client.xml: <module name="nf_conntrack_tftp"/> tftp.xml: <module name="nf_conntrack_tftp"/>
</quote>
<iankko> I was also wondering if the behaviour you see / describe above isn't related with systemd's socket activation feature (some services even when disabled can be activated by receiving data on their particular listening socket) </iankko>. Reply from Thomas below:
<quote> There are some services like for example libvirt that are adding firewall rules using the direct interface in firewalld. These are running as root and therefore there are no limits for them in the default configuration, but the lockdown feature in firewalld can be used to limit changes in the firewall for these. But as root this could be disabled again.
No, there are no hooks for automatically opening ports in firewalld. I can not say if there is code in systemd that is changing the firewall somehow, but I have not recognized this on my machines, yet."
</quote>
Let us know if the above answer is sufficient / share more details from your configuration (what's the configuration, what's the expected behaviour & what's the actually observed one) so we can follow on this.
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.
From what I have got from conversation with firewalld developers there are
three "levels" of firewalld / iptables expertise / work: * using GUI firewall-config tool, * using CLI firewall-cmd with firewalld.richlanguage concept, and finally * using CLI firewall-cmd with --direct option which gives the user direct access to the firewall (but also requires more responsibility).
At first sight all the possibilities firewalld provides might appear as confusing, but (I think) it's just question of point of view (less familiar iptables knowledge users would choose to use the GUI tool to abstract from underlying iptables concept. More demanding users might prefer richlanguage constructs, while finally experienced system administrators would want to stay at "iptables raw level"). So far it looks to me firewalld has ways / means of configuration to provide / offer to all three these groups of possibly targeted users / audience. But this is maybe just personal PoV.
The only place where this might hurt is the new libvirt integration, I'm not quite sure yet.
See explanation above wrt to libvirt service case.
Hrm, after re-reading this I sound a bit of a curmudgeon. Oh well, get off my IPTables lawn!
Trevor
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Sat, Oct 4, 2014 at 2:42 PM, Crawford, Nicholas P CTR USARMY CERDEC (US) < nicholas.p.crawford.ctr@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:
- 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".
- 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/0... [2] https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8... [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/htm...
--
Nicholas P. Crawford
Senior UNIX Systems Administrator
contractor, General Dynamics Information Technology
NVESD Network Services Branch, US Army
email: Nicholas.Crawford@gdit.com
comm: (703) 704-2299 dsn: (312) 654-2299
cell: (571) 225-1283
-- SCAP Security Guide mailing list scap-security-guide@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@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Interesting, thanks for getting back to me on this.
I'm unfortunately not finding it now and perhaps it was just some future plans on the Fedora writeups for having various services be authorized to open holes in the firewall.
I still think that it's going to be amazingly difficult to verify automatically that you have a reasonably sane firewall configuration with FirewallD.
Would it go something like:
- Remove all default zones + make permanent - Insert trusted zone + make permanent - Add rules using whatever syntax-fu is appropriate + make permanent - Check (?) for validation where ? is one of: iptables-save, XML files, something else...
Trevor
On Tue, Oct 7, 2014 at 11:06 AM, Jan Lieskovsky jlieskov@redhat.com wrote:
Hello Trevor,
thanks for raising this question.
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Sunday, October 5, 2014 11:36:06 PM Subject: Re: (RHEL7) IPTables vs FirewallD
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.
Have checked the above point with firewalld upstream developers (Cc-ed) and below is their reaction (since they are not subscribed to the SSG mailing list if you have further questions / comments & want them to react on these, pls keep them Cc-ed). To get to the reply (Thomas Woerner):
<quote> There are no hooks to automatically open ports in the firewall. It is needed to be authenticated to open ports in the firewall.
Some firewalld service definitions are enabling netfilter conntrack helpers to allow connections that are defined in the helpers to fix 'broken' protocols. But this applies only if the service is enabled in the firewall configuration.
The services that are enabling helpers are: amanda-client.xml: <module name="nf_conntrack_amanda"/> amanda-k5-client.xml: <module name="nf_conntrack_amanda"/> ftp.xml: <module name="nf_conntrack_ftp"/> samba-client.xml: <module name="nf_conntrack_netbios_ns"/> samba.xml: <module name="nf_conntrack_netbios_ns"/> sane.xml: <module name="nf_conntrack_sane"/> tftp-client.xml: <module name="nf_conntrack_tftp"/> tftp.xml: <module name="nf_conntrack_tftp"/>
</quote>
<iankko> I was also wondering if the behaviour you see / describe above isn't related with systemd's socket activation feature (some services even when disabled can be activated by receiving data on their particular listening socket) </iankko>. Reply from Thomas below:
<quote> There are some services like for example libvirt that are adding firewall rules using the direct interface in firewalld. These are running as root and therefore there are no limits for them in the default configuration, but the lockdown feature in firewalld can be used to limit changes in the firewall for these. But as root this could be disabled again.
No, there are no hooks for automatically opening ports in firewalld. I can not say if there is code in systemd that is changing the firewall somehow, but I have not recognized this on my machines, yet."
</quote>
Let us know if the above answer is sufficient / share more details from your configuration (what's the configuration, what's the expected behaviour & what's the actually observed one) so we can follow on this.
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.
From what I have got from conversation with firewalld developers there are three "levels" of firewalld / iptables expertise / work:
- using GUI firewall-config tool,
- using CLI firewall-cmd with firewalld.richlanguage concept, and finally
- using CLI firewall-cmd with --direct option which gives the user direct access to the firewall (but also requires more responsibility).
At first sight all the possibilities firewalld provides might appear as confusing, but (I think) it's just question of point of view (less familiar iptables knowledge users would choose to use the GUI tool to abstract from underlying iptables concept. More demanding users might prefer richlanguage constructs, while finally experienced system administrators would want to stay at "iptables raw level"). So far it looks to me firewalld has ways / means of configuration to provide / offer to all three these groups of possibly targeted users / audience. But this is maybe just personal PoV.
The only place where this might hurt is the new libvirt integration, I'm
not
quite sure yet.
See explanation above wrt to libvirt service case.
Hrm, after re-reading this I sound a bit of a curmudgeon. Oh well, get
off my
IPTables lawn!
Trevor
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Sat, Oct 4, 2014 at 2:42 PM, Crawford, Nicholas P CTR USARMY CERDEC
(US) <
nicholas.p.crawford.ctr@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:
- 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".
- 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/0...
[2]
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8...
[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/htm...
--
Nicholas P. Crawford
Senior UNIX Systems Administrator
contractor, General Dynamics Information Technology
NVESD Network Services Branch, US Army
email: Nicholas.Crawford@gdit.com
comm: (703) 704-2299 dsn: (312) 654-2299
cell: (571) 225-1283
-- SCAP Security Guide mailing list scap-security-guide@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@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 10/7/14, 12:46 PM, Trevor Vaughan wrote:
Interesting, thanks for getting back to me on this.
I'm unfortunately not finding it now and perhaps it was just some future plans on the Fedora writeups for having various services be authorized to open holes in the firewall.
You're not crazy. I remember this messaging too.
I still think that it's going to be amazingly difficult to verify automatically that you have a reasonably sane firewall configuration with FirewallD.
Would it go something like:
- Remove all default zones + make permanent
- Insert trusted zone + make permanent
- Add rules using whatever syntax-fu is appropriate + make permanent
- Check (?) for validation where ? is one of: iptables-save, XML
files, something else...
Extending the "take system defaults," while firewalld adds complication, the fact that it's system default means firewalld will be written into RHCE exams (and thus what people are trained on). Not writing guidance against it would be going against the grain.
As porting towards RHEL7 continues we can utilize the OVAL "criteria operators".... if iptables check X; if firewalld check Y... akin to the PAM checks: https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/acco...
Perhaps the first cut will inherit/update IPTables, then add in criteria operators for firewalld in the second pass.
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Tuesday, October 7, 2014 11:48:36 PM Subject: Re: (RHEL7) IPTables vs FirewallD
On 10/7/14, 12:46 PM, Trevor Vaughan wrote:
Interesting, thanks for getting back to me on this.
I'm unfortunately not finding it now and perhaps it was just some future plans on the Fedora writeups for having various services be authorized to open holes in the firewall.
You're not crazy. I remember this messaging too.
Got any pointers (read as exact message form) we could investigate further?
I still think that it's going to be amazingly difficult to verify automatically that you have a reasonably sane firewall configuration with FirewallD.
Would it go something like:
- Remove all default zones + make permanent
- Insert trusted zone + make permanent
- Add rules using whatever syntax-fu is appropriate + make permanent
- Check (?) for validation where ? is one of: iptables-save, XML
files, something else...
Extending the "take system defaults," while firewalld adds complication, the fact that it's system default means firewalld will be written into RHCE exams (and thus what people are trained on). Not writing guidance against it would be going against the grain.
As porting towards RHEL7 continues we can utilize the OVAL "criteria operators".... if iptables check X; if firewalld check Y... akin to the PAM checks: https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/acco...
Perhaps the first cut will inherit/update IPTables, then add in criteria operators for firewalld in the second pass.
+1. Yeah, that's the plan.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Cc: "Thomas Woerner" twoerner@redhat.com, "Jiri Popelka" jpopelka@redhat.com Sent: Tuesday, October 7, 2014 6:46:51 PM Subject: Re: (RHEL7) IPTables vs FirewallD
Interesting, thanks for getting back to me on this.
I'm unfortunately not finding it now and perhaps it was just some future plans on the Fedora writeups for having various services be authorized to open holes in the firewall.
No worries. Should you find some link pointers in the future regarding this pls share.
I still think that it's going to be amazingly difficult to verify automatically that you have a reasonably sane firewall configuration with FirewallD.
Easy or not, we need to start looking into & handle this.
Would it go something like:
- Remove all default zones + make permanent
- Insert trusted zone + make permanent
- Add rules using whatever syntax-fu is appropriate + make permanent
- Check (?) for validation where ? is one of: iptables-save, XML files,
something else...
From what I have got so far from testing iptables-save is just dump of
current kernel iptables (read as current runtime firewall) configuration.
Also using firewall-config with "Runtime" option selected modifies just runtime kernel status. So we would be checking firewalld XML config files (which are updated when "Permanent" option is selected in firewall-config).
Regarding zones configuration - I would suggest for the start just port former iptables rules to firewalld syntax. Later we can make use of new firewalld option (for example check if all connections belong to at least one zone or the rule options you sketched above).
So definitely if there's firewalld add-on value / feature (not provided / not feasible to be implemented by current iptables functionality) the community is aware of / would like to see now it's the right time to raise the request for its consideration for inclusion / implementation.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Trevor
On Tue, Oct 7, 2014 at 11:06 AM, Jan Lieskovsky < jlieskov@redhat.com > wrote:
Hello Trevor,
thanks for raising this question.
----- Original Message -----
From: "Trevor Vaughan" < tvaughan@onyxpoint.com > To: "SCAP Security Guide" < scap-security-guide@lists.fedorahosted.org > Sent: Sunday, October 5, 2014 11:36:06 PM Subject: Re: (RHEL7) IPTables vs FirewallD
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.
Have checked the above point with firewalld upstream developers (Cc-ed) and below is their reaction (since they are not subscribed to the SSG mailing list if you have further questions / comments & want them to react on these, pls keep them Cc-ed). To get to the reply (Thomas Woerner):
<quote> There are no hooks to automatically open ports in the firewall. It is needed to be authenticated to open ports in the firewall.
Some firewalld service definitions are enabling netfilter conntrack helpers to allow connections that are defined in the helpers to fix 'broken' protocols. But this applies only if the service is enabled in the firewall configuration.
The services that are enabling helpers are: amanda-client.xml: <module name="nf_conntrack_amanda"/> amanda-k5-client.xml: <module name="nf_conntrack_amanda"/> ftp.xml: <module name="nf_conntrack_ftp"/> samba-client.xml: <module name="nf_conntrack_netbios_ns"/> samba.xml: <module name="nf_conntrack_netbios_ns"/> sane.xml: <module name="nf_conntrack_sane"/> tftp-client.xml: <module name="nf_conntrack_tftp"/> tftp.xml: <module name="nf_conntrack_tftp"/>
</quote>
<iankko> I was also wondering if the behaviour you see / describe above isn't related with systemd's socket activation feature (some services even when disabled can be activated by receiving data on their particular listening socket) </iankko>. Reply from Thomas below:
<quote> There are some services like for example libvirt that are adding firewall rules using the direct interface in firewalld. These are running as root and therefore there are no limits for them in the default configuration, but the lockdown feature in firewalld can be used to limit changes in the firewall for these. But as root this could be disabled again.
No, there are no hooks for automatically opening ports in firewalld. I can not say if there is code in systemd that is changing the firewall somehow, but I have not recognized this on my machines, yet."
</quote>
Let us know if the above answer is sufficient / share more details from your configuration (what's the configuration, what's the expected behaviour & what's the actually observed one) so we can follow on this.
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.
From what I have got from conversation with firewalld developers there are three "levels" of firewalld / iptables expertise / work:
- using GUI firewall-config tool,
- using CLI firewall-cmd with firewalld.richlanguage concept, and finally
- using CLI firewall-cmd with --direct option which gives the user direct
access to the firewall (but also requires more responsibility).
At first sight all the possibilities firewalld provides might appear as confusing, but (I think) it's just question of point of view (less familiar iptables knowledge users would choose to use the GUI tool to abstract from underlying iptables concept. More demanding users might prefer richlanguage constructs, while finally experienced system administrators would want to stay at "iptables raw level"). So far it looks to me firewalld has ways / means of configuration to provide / offer to all three these groups of possibly targeted users / audience. But this is maybe just personal PoV.
The only place where this might hurt is the new libvirt integration, I'm not quite sure yet.
See explanation above wrt to libvirt service case.
Hrm, after re-reading this I sound a bit of a curmudgeon. Oh well, get off my IPTables lawn!
Trevor
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Sat, Oct 4, 2014 at 2:42 PM, Crawford, Nicholas P CTR USARMY CERDEC (US) < nicholas.p.crawford.ctr@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:
- 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".
- 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/0... [2] https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8... [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/htm...
--
Nicholas P. Crawford
Senior UNIX Systems Administrator
contractor, General Dynamics Information Technology
NVESD Network Services Branch, US Army
email: Nicholas.Crawford@gdit.com
comm: (703) 704-2299 dsn: (312) 654-2299
cell: (571) 225-1283
-- SCAP Security Guide mailing list scap-security-guide@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@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@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@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Crawford, Nicholas P CTR USARMY RDECOM CERDEC (US) -
Jan Lieskovsky -
Shawn Wells -
Trevor Vaughan