[PATCH] added significant body of apache configuration guidance

Jeffrey Blank blank at eclipse.ncsc.mil
Thu Apr 26 21:03:51 UTC 2012



> Shouldn't httpd_minimal_modules_installed by a <rule> not a <group>? See
> this in a few places of this patch.

This is intentional and I tried to explain why in the cover-letter
email.  This can always be revisited later, especially upon such time as
there is focused interest in a web server baseline.


> Early we told the user to 'yum install httpd' which implies "use the
> version the vendor ships." If that version is to bloated I'd argue we
> should open a bug/ticket with the vendor rather than tell the users to
> re-compile apache (and lose all vendor support).

The default is fine.  We are simply being informative (for example to
educate anyone who might have one compiled from source).


>> +<Group id="securing_httpd">
>> +<title>Secure Apache Configuration</title>
>> +<description>The<tt>httpd</tt>  configuration file
>> is<tt>/etc/httpd/conf/httpd.conf</tt>. Apply
>> +the recommendations in the remainder of this section to this file.
>> +</description>
> 
> I get why securing_httpd should be a parent group, but we still need to
> convert it's child controls to <rule>'s

All the ones that could be made into granular, automated compliance
checks have been made into Rules.


>> +<Group id="httpd_restrict_info_leakage">
>> +<title>Restrict Web Server Information Leakage</title>
>> +<description>
>> +The<tt>ServerTokens</tt>  and<tt>ServerSignature</tt>  directives
>> determine how
>> +much information the web server discloses about the configuration of
>> the system.<tt>ServerSignature Off</tt>
>> +keeps<tt>httpd</tt>  from displaying the server version on error
>> pages. It is a good security
>> +practice to limit the information provided to clients.
>> +</description>
> 
> Nitpick, I'd remove the language about specifics on ServerSignature. Let
> the group <description> cover the group, not specific rules.

Agreed - fixed/thanks.



> If there is a method to encrypt authenticated sessions, why would we not
> recommend it's use (vs making optional)?

Because there are multiple methods to accomplish this, and we are not
making a recommendation to choose a particular one.  We are providing
discussion about their existence (and the general recommendation to
disable code/modules that aren't used).



> As an aside, if the default settings of applications are not sane we
> should open up tickets with the vendor (that feels weird to say, since I
> work for one of them...). I'll skim through this patch later review for
> such things.

In the general case, admins will be customizing the living daylights out
of this file anyway (and this is advice for that process), so it's not a
big concern.  But that makes sense.


>> +<Rule id="httpd_install_mod_security">
>> +<title>Install<tt>mod_security</tt></title>
>> +<description>
>> +Install the<tt>security</tt>  module:
>> +<pre># yum install mod_security</pre>
>> +<!-- This is in EPEL and might be out of scope as a Rule. (?) -->
> 
> Good call. Perhaps we could clearly state this about this module. i.e.
> 
> The usage of httpd_deploy_mod_security is highly recommended. It should
> be noted this module does not ship within the base Enterprise Linux
> content, and instead is provided via Extra Packages for Enterprise Linux
> (EPEL). For more information on EPEL please refer to
> http://fedoraproject.org/wiki/EPEL.

Done.

>> +<Group id="httpd_use_dos_protection_modules">
>> +<title>Use Denial-of-Service Protection Modules</title>
>> +<description>
>> +Denial-of-service attacks are difficult to detect and prevent while
>> maintaining
>> +acceptable access to authorized users. However, some traffic-shaping
>> +modules can be used to address the problem. Well-known DoS protection
>> modules include:
>> +<pre>mod_cband mod_bwshare mod_limitipconn mod_evasive</pre>
>> +Denial-of-service prevention be implemented for a web server if such
>> a threat exists.
>> +However, specific configuration details are very dependent on the
>> environment and often best left
>> +at the discretion of the administrator.
>> +</description>
>> +</Group>  <!--<Group id="httpd_use_dos_protection_modules">  -->
> 
> <group> tags without a <rule> mean this should be a <rule>. 
> Why can't
> this be a rule under <Group id="securing_httpd"> ? This applies to a few
> of these....

Groups are informative while not (yet) asserting that there is a strict
need (or granular enough intent) to create a compliance check.  Groups
can be converted into Rules when such a need arises.


> This is a VERY good start. I'd like to see a few checks more;
> 
> (1) Verify httpd SELinux module is loaded
> (2) Verify selinux type for httpd directories (content, config, etc)
> (3) If httpd is removed, verify the selinux module is too (not default
> behavior)


These are excellent ideas for a future commit.
Next up will be this XCCDF with the immediately-recommended changes,
seeking an ACK for now.


More information about the scap-security-guide mailing list