<div dir="ltr"><div><div><div><div><div>Interesting, thanks for getting back to me on this.<br><br></div>I&#39;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.<br><br>I still think that it&#39;s going to be amazingly difficult to verify automatically that you have a reasonably sane firewall configuration with FirewallD.<br><br>Would it go something like:<br><br></div>- Remove all default zones + make permanent<br></div>- Insert trusted zone + make permanent<br></div>- Add rules using whatever syntax-fu is appropriate + make permanent<br></div>- Check (?) for validation where ? is one of: iptables-save, XML files, something else...<br><br>Trevor<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 7, 2014 at 11:06 AM, Jan Lieskovsky <span dir="ltr">&lt;<a href="mailto:jlieskov@redhat.com" target="_blank">jlieskov@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Trevor,<br>
<br>
  thanks for raising this question.<br>
<span class=""><br>
----- Original Message -----<br>
&gt; From: &quot;Trevor Vaughan&quot; &lt;<a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a>&gt;<br>
&gt; To: &quot;SCAP Security Guide&quot; &lt;<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a>&gt;<br>
&gt; Sent: Sunday, October 5, 2014 11:36:06 PM<br>
&gt; Subject: Re: (RHEL7) IPTables vs FirewallD<br>
&gt;<br>
&gt; After using both, I would recommend using iptables for servers and firewalld<br>
&gt; for desktops. (As a side note, anyone have notes on allowing users to change<br>
&gt; the firewall but only for certain ports?).<br>
&gt;<br>
&gt; You may be able to disable this, but it looks like firewalld has hooks that<br>
&gt; allow for services to open their own ports as necessary. I would never want<br>
&gt; this in a production system.<br>
<br>
</span>Have checked the above point with firewalld upstream developers (Cc-ed) and<br>
below is their reaction (since they are not subscribed to the SSG mailing list<br>
if you have further questions / comments &amp; want them to react on these, pls<br>
keep them Cc-ed). To get to the reply (Thomas Woerner):<br>
<br>
&lt;quote&gt;<br>
There are no hooks to automatically open ports in the firewall. It is<br>
needed to be authenticated to open ports in the firewall.<br>
<br>
Some firewalld service definitions are enabling netfilter conntrack<br>
helpers to allow connections that are defined in the helpers to fix<br>
&#39;broken&#39; protocols. But this applies only if the service is enabled in<br>
the firewall configuration.<br>
<br>
The services that are enabling helpers are:<br>
   amanda-client.xml:  &lt;module name=&quot;nf_conntrack_amanda&quot;/&gt;<br>
   amanda-k5-client.xml:  &lt;module name=&quot;nf_conntrack_amanda&quot;/&gt;<br>
   ftp.xml:  &lt;module name=&quot;nf_conntrack_ftp&quot;/&gt;<br>
   samba-client.xml:  &lt;module name=&quot;nf_conntrack_netbios_ns&quot;/&gt;<br>
   samba.xml:  &lt;module name=&quot;nf_conntrack_netbios_ns&quot;/&gt;<br>
   sane.xml:  &lt;module name=&quot;nf_conntrack_sane&quot;/&gt;<br>
   tftp-client.xml:  &lt;module name=&quot;nf_conntrack_tftp&quot;/&gt;<br>
   tftp.xml:  &lt;module name=&quot;nf_conntrack_tftp&quot;/&gt;<br>
<br>
&lt;/quote&gt;<br>
<br>
&lt;iankko&gt; I was also wondering if the behaviour you see / describe above<br>
isn&#39;t related with systemd&#39;s socket activation feature (some services<br>
even when disabled can be activated by receiving data on their particular<br>
listening socket) &lt;/iankko&gt;. Reply from Thomas below:<br>
<br>
&lt;quote&gt;<br>
There are some services like for example libvirt that are adding<br>
firewall rules using the direct interface in firewalld. These are<br>
running as root and therefore there are no limits for them in the<br>
default configuration, but the lockdown feature in firewalld can be used<br>
to limit changes in the firewall for these. But as root this could be<br>
disabled again.<br>
<br>
No, there are no hooks for automatically opening ports in firewalld. I<br>
can not say if there is code in systemd that is changing the firewall<br>
somehow, but I have not recognized this on my machines, yet.&quot;<br>
<br>
&lt;/quote&gt;<br>
<br>
Let us know if the above answer is sufficient / share more details<br>
from your configuration (what&#39;s the configuration, what&#39;s the expected<br>
behaviour &amp; what&#39;s the actually observed one) so we can follow on this.<br>
<span class=""><br>
&gt; Firewall rules must be approved and then<br>
&gt; applied not applied as applications see fit. The exception to this would be<br>
&gt; things like OpenStack and OpenShift but trying to explain either of those<br>
&gt; has been an exercise in patience.<br>
&gt;<br>
&gt; Also, to verify that firewalld is doing what you actually expect it to, you<br>
&gt; need to know iptables. If you know iptables, you don&#39;t need firewalld.<br>
&gt;<br>
&gt; Finally, there&#39;s the firewalld rich language. It appears to be an almost<br>
&gt; direct mapping of the iptables rules yet with slightly different syntax<br>
&gt; and/or XML files to maintain. In other words, confusing.<br>
<br>
</span>From what I have got from conversation with firewalld developers there are<br>
three &quot;levels&quot; of firewalld / iptables expertise / work:<br>
* using GUI firewall-config tool,<br>
* using CLI firewall-cmd with firewalld.richlanguage concept, and finally<br>
* using CLI firewall-cmd with --direct option which gives the user direct<br>
  access to the firewall (but also requires more responsibility).<br>
<br>
At first sight all the possibilities firewalld provides might appear as<br>
confusing, but (I think) it&#39;s just question of point of view (less familiar<br>
iptables knowledge users would choose to use the GUI tool to abstract from<br>
underlying iptables concept. More demanding users might prefer richlanguage<br>
constructs, while finally experienced system administrators would want to<br>
stay at &quot;iptables raw level&quot;). So far it looks to me firewalld has ways / means<br>
of configuration to provide / offer to all three these groups of possibly<br>
targeted users / audience. But this is maybe just personal PoV.<br>
<span class=""><br>
&gt;<br>
&gt; The only place where this might hurt is the new libvirt integration, I&#39;m not<br>
&gt; quite sure yet.<br>
<br>
</span>See explanation above wrt to libvirt service case.<br>
<span class=""><br>
&gt;<br>
&gt; Hrm, after re-reading this I sound a bit of a curmudgeon. Oh well, get off my<br>
&gt; IPTables lawn!<br>
&gt;<br>
&gt; Trevor<br>
<br>
</span>Thank you &amp;&amp; Regards, Jan.<br>
--<br>
Jan iankko Lieskovsky / Red Hat Security Technologies Team<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; On Sat, Oct 4, 2014 at 2:42 PM, Crawford, Nicholas P CTR USARMY CERDEC (US) &lt;<br>
&gt; <a href="mailto:nicholas.p.crawford.ctr@mail.mil">nicholas.p.crawford.ctr@mail.mil</a> &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Currently it looks like the momentum is towards tables. The updates from<br>
&gt; Maura Dailey [1] for systemd fixed the majority of the checks. Additionally<br>
&gt; future editions of RHEL 7 may include nftables as it’s currently in Tech<br>
&gt; Preview.<br>
&gt;<br>
&gt;<br>
&gt; • IPTables work is already done, seems to still be valid, and requires no<br>
&gt; obvious updates.<br>
&gt; • FirewallD, will require some work (see below).<br>
&gt; • NFTables, TBD.<br>
&gt;<br>
&gt;<br>
&gt; If the intent is to support both, then the logical fork would be at the<br>
&gt; currently active service. Further checks will need to rely on the results of<br>
&gt; which firewall is in use. Is it possible to logically fork in OVAL?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; From the rhel7-guide and stig table it appears that our only automated checks<br>
&gt; are:<br>
&gt;<br>
&gt;<br>
&gt; 1) Is it enabled?<br>
&gt;<br>
&gt;<br>
&gt; The actual requirement is that the system provides an IPv4 and IPv6 firewall.<br>
&gt; FirewallD is both an IPv4 and and IPv6 firewall and satisfies this<br>
&gt; requirement.<br>
&gt;<br>
&gt;<br>
&gt; Resolution: `systemctl is-active firewalld` should return &quot;active&quot;.<br>
&gt;<br>
&gt;<br>
&gt; 2) Are the default INPUT/FORWARD policies set to DROP?<br>
&gt;<br>
&gt;<br>
&gt; The actual requirement is the firewall must be DAPE (Deny All Permit by<br>
&gt; Exception), the FirewallD Zone/Target is synonymous with this requirement.<br>
&gt;<br>
&gt;<br>
&gt; firewalld always leaves the tables policy as ACCEPT, additionally firewalld<br>
&gt; doesn’t use /etc/sysconfig/ip[6]tables. Thus the current check will always<br>
&gt; fail. Further, compliant /etc/sysconfig/ip[6]tables files while using<br>
&gt; firewalld could lead to a false-negative.<br>
&gt;<br>
&gt;<br>
&gt; All default zones appear to meet this requirement except trusted which<br>
&gt; defaults to ACCEPT. The end-user can create and modify zones with the ACCEPT<br>
&gt; target. A check of the active zones’ targets should verify that none are set<br>
&gt; to ACCEPT.<br>
&gt;<br>
&gt;<br>
&gt; Proposal: the check should simply ensure that active zones’ targets are not<br>
&gt; set to ACCEPT. `firewall-cmd --get-default-zone` , `firewall-cmd<br>
&gt; --get-active-zones` , `firewall-cmd --get-target` , `firewall-cmd<br>
&gt; --zone=&lt;zone&gt; --get-target`.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; The get-target output will be one of DROP, %%REJECT%%, ACCEPT or<br>
&gt; {chain}_{zone}. {chain}_{zone} was changed to “default” upstream with commit<br>
&gt; 267bb9d103f7134d8d0116ab0b7d3aaf38f5f3c8 [2]. As far as I can tell, as long<br>
&gt; as the target is not ACCEPT, it’s a DAPE firewall.<br>
&gt;<br>
&gt;<br>
&gt; Further hardening<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; More firewalld work is required to support ICMP hardening, suspicious source<br>
&gt; log drops, and services hardening for both implementation and evaluation.<br>
&gt; Services seems pretty simple, ICMP and suspicious source appear to require<br>
&gt; RichLanguage [3].<br>
&gt;<br>
&gt;<br>
&gt; Whether firewalld is capable of accepting the current ICMP rules isn’t<br>
&gt; immediately obvious as Fedora’s [4] and Red Hat’s [5] documentation only<br>
&gt; point to “icmp-block”. Potentially the logic can be reversed. Change the<br>
&gt; current allow echo-reply (0), destination-unreachable (3), time-exceeded<br>
&gt; (11) and instead block the remaining firewalld supported icmp types;<br>
&gt; parameter-problem (12), redirect (5), router-advertisement (9),<br>
&gt; router-solicitation (10), source-quench (4). However, this doesn&#39;t address<br>
&gt; over 30 other defined and 200 undefined ICMP types that would be allowed<br>
&gt; because they can’t be blocked by firewalld.<br>
&gt;<br>
&gt;<br>
&gt; With firewalld there may be additional checks to add. For example, the<br>
&gt; default zone “external” includes masquerading, this zone shouldn’t be active<br>
&gt; unless the system is a router. To check for the presence of masquerading<br>
&gt; `firewall-cmd --zone=&lt;zone&gt; --query-masquerade` should return no for active<br>
&gt; zones.<br>
&gt;<br>
&gt;<br>
&gt; References<br>
&gt; [1]<br>
&gt; <a href="https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-February/005015.html" target="_blank">https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-February/005015.html</a><br>
&gt; [2]<br>
&gt; <a href="https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8d0116ab0b7d3aaf38f5f3c8" target="_blank">https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=267bb9d103f7134d8d0116ab0b7d3aaf38f5f3c8</a><br>
&gt; [3] <a href="https://fedoraproject.org/wiki/FirewallD" target="_blank">https://fedoraproject.org/wiki/FirewallD</a><br>
&gt; [4] <a href="http://fedoraproject.org/wiki/Features/FirewalldRichLanguage" target="_blank">http://fedoraproject.org/wiki/Features/FirewalldRichLanguage</a><br>
&gt; [5]<br>
&gt; <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html" target="_blank">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; Nicholas P. Crawford<br>
&gt;<br>
&gt; Senior UNIX Systems Administrator<br>
&gt;<br>
&gt; contractor, General Dynamics Information Technology<br>
&gt;<br>
&gt; NVESD Network Services Branch, US Army<br>
&gt;<br>
&gt; email: <a href="mailto:Nicholas.Crawford@gdit.com">Nicholas.Crawford@gdit.com</a><br>
&gt;<br>
&gt; comm: <a href="tel:%28703%29%20704-2299" value="+17037042299">(703) 704-2299</a> dsn: <a href="tel:%28312%29%20654-2299" value="+13126542299">(312) 654-2299</a><br>
&gt;<br>
&gt; cell: <a href="tel:%28571%29%20225-1283" value="+15712251283">(571) 225-1283</a><br>
&gt;<br>
&gt; --<br>
&gt; SCAP Security Guide mailing list<br>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt; <a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Trevor Vaughan<br>
&gt; Vice President, Onyx Point, Inc<br>
&gt; <a href="tel:%28410%29%20541-6699" value="+14105416699">(410) 541-6699</a><br>
&gt; <a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br>
&gt;<br>
&gt; -- This account not approved for unencrypted proprietary information --<br>
&gt;<br>
&gt; --<br>
&gt; SCAP Security Guide mailing list<br>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt; <a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a><br>
--<br>
SCAP Security Guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<a href="https://github.com/OpenSCAP/scap-security-guide/" target="_blank">https://github.com/OpenSCAP/scap-security-guide/</a></div></div></blockquote></div><br><br clear="all"><br>-- <br>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) 541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- This account not approved for unencrypted proprietary information --
</div>