Guide to the Secure Configuration of Red Hat Enterprise Linux 7

with profile DISA STIG for Apache HTTP on Red Hat Enterprise Linux 7
This profile contains configuration checks that align to the DISA STIG for Apache HTTP web server.

This guide presents a catalog of security-relevant configuration settings for Red Hat Enterprise Linux 7. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 7, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.

This benchmark is a direct port of a SCAP Security Guide benchmark developed for Red Hat Enterprise Linux. It has been modified through an automated process to remove specific dependencies on Red Hat Enterprise Linux and to function with CentOS. The result is a generally useful SCAP Security Guide benchmark with the following caveats:

  • CentOS is not an exact copy of Red Hat Enterprise Linux. There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
  • CentOS has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. CentOS does not inherit certifications or evaluations from Red Hat Enterprise Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on CentOS.

Members of the CentOS community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.

Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.
Profile TitleDISA STIG for Apache HTTP on Red Hat Enterprise Linux 7
Profile IDxccdf_org.ssgproject.content_profile_stig-http-disa

Revision History

Current version: 0.1.38

  • draft (as of 2018-03-05)

Platforms

  • cpe:/o:redhat:enterprise_linux:7
  • cpe:/o:centos:centos:7
  • cpe:/o:redhat:enterprise_linux:7::client
  • cpe:/o:redhat:enterprise_linux:7::computenode

Table of Contents

  1. Services
    1. Web Server

Checklist

contains 26 rules

Services   [ref]group

The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Enterprise Linux 7 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Red Hat Enterprise Linux 7 system and provides guidance about which ones can be safely disabled.

Red Hat Enterprise Linux 7 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Red Hat Enterprise Linux 7 systems, it is highly recommended to select the minimal packages and then build up the system from there.

contains 26 rules

Web Server   [ref]group

The web server is responsible for providing access to content via the HTTP protocol. Web servers represent a significant security risk because:

  • The HTTP port is commonly probed by malicious sources
  • Web server software is very complex, and includes a long history of vulnerabilities
  • The HTTP protocol is unencrypted and vulnerable to passive monitoring


The system's default web server software is Apache 2 and is provided in the RPM package httpd.

contains 26 rules

Secure Apache Configuration   [ref]group

The httpd configuration file is /etc/httpd/conf/httpd.conf. Apply the recommendations in the remainder of this section to this file.

contains 26 rules

Minimize Web Server Loadable Modules   [ref]group

A default installation of httpd includes a plethora of dynamically shared objects (DSO) that are loaded at run-time. Unlike the aforementioned compiled-in modules, a DSO can be disabled in the configuration file by removing the corresponding LoadModule directive.

Note: A DSO only provides additional functionality if associated directives are included in the httpd configuration file. It should also be noted that removing a DSO will produce errors on httpd startup if the configuration file contains directives that apply to that module. Refer to http://httpd.apache.org/docs/ for details on which directives are associated with each DSO.

Following each DSO removal, the configuration can be tested with the following command to check if everything still works:

$ sudo service httpd configtest
The purpose of each of the modules loaded by default will now be addressed one at a time. If none of a module's directives are being used, remove it.

contains 1 rule

httpd Core Modules   [ref]group

These modules comprise a basic subset of modules that are likely needed for base httpd functionality; ensure they are not commented out in /etc/httpd/conf/httpd.conf:

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mome.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.

contains 1 rule

Enable log_config_module For HTTPD Logging   [ref]rule

The log_config_module should exist and be configured in the /etc/httpd/conf/httpd.conf file by adding the following module to configure logging:

log_config_module

Rationale:

A major tool in exploring the web site use, attempted use, unusual conditions, and problems are reported in the access and error logs. In the event of a security incident, these logs can provide the SA and the web manager with valuable information. Without these log files, SAs and web managers are seriously hindered in their efforts to respond appropriately to suspicious or criminal actions targeted at the web site.

Severity:  medium

Directory Restrictions   [ref]group

The Directory tags in the web server configuration file allow finer grained access control for a specified directory. All web directories should be configured on a case-by-case basis, allowing access only where needed.

contains 4 rules

Disable Anonymous FTP Access   [ref]rule

If any directories that contain dynamic scripts can be accessed via FTP by any group or user that does not require access, remove permissions to such directories that allow anonymous access. Also, ensure that any such access employs an encrypted connection.

Rationale:

The directories containing the CGI scripts, such as PERL, must not be accessible to anonymous users via FTP. This applies to all directories that contain scripts that can dynamically produce web pages in an interactive manner (i.e., scripts based upon user-provided input). Such scripts contain information that could be used to compromise a web service, access system resources, or deface a web site.

Severity:  medium

Ignore HTTPD .htaccess Files   [ref]rule

Set AllowOverride to none for each instant of <Directory>.

Rationale:

CGI scripts represents one of the most common and exploitable means of compromising a web server. By definition, CGI are executable by the operating system of the host server. While access control is provided via the web service, the execution of CGI programs is not otherwise limited unless the SA or Web Manager takes specific measures. CGI programs can access and alter data files, launch other programs and use the network. CGI programs can be written in any available programming language. C, PERL, PHP, Javascript, VBScript and shell (sh, ksh, bash) are popular choices.

Severity:  medium

Web Content Directories Must Not Be Shared Anonymously   [ref]rule

Web content directories should not be shared anonymously over remote filesystems such as nfs and smb. Remove the shares from the applicable directories.

Rationale:

Sharing web content is a security risk when a web server is involved. Users accessing the share anonymously could experience privileged access to the content of such directories. Network sharable directories expose those directories and their contents to unnecessary access. Any unnecessary exposure increases the risk that someone could exploit that access and either compromises the web content or cause web server performance problems.

Severity:  medium

Remove Write Permissions From Filesystem Paths And Server Scripts   [ref]rule

Configure permissions for each instance of Alias, ScriptAlias, and ScriptAliasMatch that exist.

$ sudo find DIR -type d -exec chmod 755 {} \;
$ sudo find DIR -type f -exec chmod 555 {} \;
Where DIR matches the paths from Alias, ScriptAlias, and ScriptAliasMatch.

Rationale:

Excessive permissions for the anonymous web user account are one of the most common faults contributing to the compromise of a web server. If this user is able to upload and execute files on the web server, the organization or owner of the server will no longer have control of the asset.

Severity:  high

Use Appropriate Modules to Improve httpd's Security   [ref]group

Among the modules available for httpd are several whose use may improve the security of the web server installation. This section recommends and discusses the deployment of security-relevant modules.

contains 3 rules

Deploy mod_ssl   [ref]group

Because HTTP is a plain text protocol, all traffic is susceptible to passive monitoring. If there is a need for confidentiality, SSL should be configured and enabled to encrypt content.

Note: mod_nss is a FIPS 140-2 certified alternative to mod_ssl. The modules share a considerable amount of code and should be nearly identical in functionality. If FIPS 140-2 validation is required, then mod_nss should be used. If it provides some feature or its greater compatibility is required, then mod_ssl should be used.

contains 3 rules

Enable Transport Layer Security (TLS) Encryption   [ref]rule

Disable old SSL and TLS version and enable the latest TLS encryption by setting the following in /etc/httpd/conf.modules.d/ssl.conf:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
Make sure to also set SSLEngine to on in /etc/httpd/conf.modules.d/ssl.conf like the following:
SSLEngine on

Rationale:

Transport Layer Security (TLS) encryption is a required security setting for a private web server. Encryption of private information is essential to ensuring data confidentiality. If private information is not encrypted, it can be intercepted and easily read by an unauthorized party. A web server must use a FIPS 140-2 approved TLS version, and all non-FIPS-approved SSL versions must be disabled.

Severity:  medium

Require Client Certificates   [ref]rule

SSLVerifyClient should be set and configured to require by setting the following in /etc/httpd/conf/httpd.conf:

SSLVerifyClient require

Rationale:

Web sites requiring authentication within the DoD must utilize PKI as an authentication mechanism for web users. Information systems residing behind web servers requiring authorization based on individual identity must use the identity provided by certificate-based authentication to support access control decisions.

Severity:  medium

Configure A Valid Server Certificate   [ref]rule

Configure the web site to use a valid organizationally defined certificate. For DoD, this is a DoD server certificate issued by the DoD CA.

Rationale:

This check verifies that DoD is a hosted web site's CA. The certificate is actually a DoD-issued server certificate used by the organization being reviewed. This is used to verify the authenticity of the web site to the user. If the certificate is not for the server (Certificate belongs to), if the certificate is not issued by DoD (Certificate was issued by), or if the current date is not included in the valid date (Certificate is valid from), then there is no assurance that the use of the certificate is valid. The entire purpose of using a certificate is, therefore, compromised.

Severity:  medium

Configure PHP Securely   [ref]group

PERL (Practical Extraction and Report Language) is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. The language is often used in shell scripting and is intended to be practical, easy to use, and efficient means of generating interactive web pages for the user.

contains 1 rule

Configure HTTP PERL Scripts To Use TAINT Option   [ref]rule

If the mod_perl module is installed, enable Perl Taint checking in /etc/httpd/conf/httpd.conf. To enable Perl Taint checking, add or uncomment the following to /etc/httpd/conf.d/perl.conf:

PerlSwitches -T

Rationale:

PERL (Practical Extraction and Report Language) is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. The language is often used in shell scripting and is intended to be practical, easy to use, and efficient means of generating interactive web pages for the user. Unfortunately, many widely available freeware PERL programs (scripts) are extremely insecure. This is most readily accomplished by a malicious user substituting input to a PERL script during a POST or a GET operation.

Consequently, the founders of PERL have developed a mechanism named TAINT that protects the system from malicious input sent from outside the program. When the data is tainted, it cannot be used in programs or functions such as eval(), system(), exec(), pipes, or popen(). The script will exit with a warning message.

Severity:  medium

Configure Operating System to Protect Web Server   [ref]group

The following configuration steps should be taken on the system which hosts the web server, in order to provide as safe an environment as possible for the web server.

contains 5 rules

Restrict File and Directory Access   [ref]group

Minimize access to critical httpd files and directories.

contains 2 rules

Set Permissions on the /var/log/httpd/ Directory   [ref]rule

Ensure that the permissions on the web server log directory is set to 700:

$ sudo chmod 700 /var/log/httpd/
This is its default setting.

Rationale:

A major tool in exploring the web site use, attempted use, unusual conditions, and problems are the access and error logs. In the event of a security incident, these logs can provide the SA and the web manager with valuable information. To ensure the integrity of the log files and protect the SA and the web manager from a conflict of interest related to the maintenance of these files, only the members of the Auditors group will be granted permissions to move, copy, and delete these files in the course of their duties related to the archiving of these files.

Severity:  medium

References:  CM-7

HTTPD Log Files Must Be Owned By Root   [ref]rule

All httpd logs must be owned by root user and group. By default, the path for httpd logs is /var/log/httpd/ To properly set the owner of /var/log/httpd, run the command:

$ sudo chown root /var/log/httpd 
To properly set the owner of /var/log/httpd/*, run the command:
$ sudo chown root /var/log/httpd/* 

Rationale:

A major tool in exploring the web site use, attempted use, unusual conditions, and problems are the access and error logs. In the event of a security incident, these logs can provide the SA and the web administrator with valuable information. Because of the information that is captured in the logs, it is critical that only authorized individuals have access to the logs.

Severity:  medium

Ensure Remote Administrative Access Is Encrypted   [ref]rule

Ensure that the SSH server service is enabled. The sshd service can be enabled with the following command:

$ sudo systemctl enable sshd.service

Rationale:

Logging into a web server remotely using an unencrypted protocol or service when performing updates and maintenance is a major risk. Data, such as user account, is transmitted in plaintext and can easily be compromised. When performing remote administrative tasks, a protocol or service that encrypts the communication channel must be used.

An alternative to remote administration of the web server is to perform web server administration locally at the console. Local administration at the console implies physical access to the server.

Severity:  high

Scan All Uploaded Content for Malicious Software   [ref]rule

Install anti-virus software on the system and set it to automatically scan new files that are introduced to the web server.

Rationale:

Remote web authors should not be able to upload files to the Document Root directory structure without virus checking and checking for malicious or mobile code. A remote web user, whose agency has a Memorandum of Agreement (MOA) with the hosting agency and has submitted a DoD form 2875 (System Authorization Access Request (SAAR)) or an equivalent document, will be allowed to post files to a temporary location on the server. All posted files to this temporary location will be scanned for viruses and content checked for malicious or mobile code. Only files free of viruses and malicious or mobile code will be posted to the appropriate DocumentRoot directory.

Severity:  medium

Configure firewalld to Allow Access to the Web Server   [ref]rule

By default, firewalld blocks access to the ports used by the web server. To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=http To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=https

Rationale:

Failure to comply with DoD ports, protocols, and services (PPS) requirements can result in compromise of enclave boundary protections and/or functionality of the AIS.

Severity:  low

Configure HTTPD-Served Web Content Securely   [ref]group

Running httpd inside a chroot jail is designed to isolate the web server process to a small section of the filesystem, limiting the damage if it is compromised. Versions of Apache greater than 2.2.10 (such as the one included with Red Hat Enterprise Linux 7) provide the ChrootDir directive. To run Apache inside a chroot jail in /chroot/apache, add the following line to /etc/httpd/conf/httpd.conf:

ChrootDir /chroot/apache
This necessitates placing all files required by httpd inside /chroot/apache , including httpd's binaries, modules, configuration files, and served web pages. The details of this configuration are beyond the scope of this guide. This may also require additional SELinux configuration.

contains 7 rules

Each Web Content Directory Must Contain An index.html File   [ref]rule

Every DocumentRoot that is configured should have an index.html file that exists. Add an index.html file to every configured DocumentRoot.

Rationale:

The goal is to completely control the web users experience in navigating any portion of the web document root directories. Ensuring all web content directories have at least the equivalent of an index.html file is a significant factor to accomplish this end. Also, enumeration techniques, such as URL parameter manipulation, rely upon being able to obtain information about the web server's directory structure by locating directories with default pages. This practice helps ensure that the anonymous web user will not obtain directory browsing information or an error message that reveals the server type and version.

Severity:  low

Ensure Web Content Located on Separate partition   [ref]rule

The DocumentRoot directory is used for storing web content and data. Ensure that the DocumentRoot directory exists on a separate logical volume at installation time, or migrate it using LVM.

Rationale:

Application partitioning enables an additional security measure by securing user traffic under one security context, while managing system and application files under another. Web content is can be to an anonymous web user. For such an account to have access to system files of any type is a major security risk that is avoidable and desirable. Failure to partition the system files from the web site documents increases risk of attack via directory traversal, or impede web site availability due to drive space exhaustion.

Severity:  medium

Encrypt All File Uploads   [ref]rule

Use only secure encrypted logons and connections for uploading files to the web site.

Rationale:

Logging in to a web server via an unencrypted protocol or service, to upload documents to the web site, is a risk if proper encryption is not utilized to protect the data being transmitted. An encrypted protocol or service must be used for remote access to web administration tasks.

Severity:  high

Configure A Banner Page For Each Website   [ref]rule

Configure a login banner for each website when authentication is required for user access.

Rationale:

A consent banner will be in place to make prospective entrants aware that the website they are about to enter is a DoD web site and their activity is subject to monitoring. The document, DoDI 8500.01, establishes the policy on the use of DoD information systems. It requires the use of a standard Notice and Consent Banner and standard text to be included in user agreements. The requirement for the banner is for websites with security and access controls. These are restricted and not publicly accessible. If the website does not require authentication/authorization for use, then the banner does not need to be present. A manual check of the document root directory for a banner page file (such as banner.html) or navigation to the website via a browser can be used to confirm the information provided from interviewing the web staff.

Severity:  low

The robots.txt Files Must Not Exist   [ref]rule

Remove any robots.txt files that may exist with any web content. Other methods must be employed if there is information on the web site that needs protection from search engines and public view. Inspect all instances of DocumentRoot and Alias and remove any robots.txt file.

$ sudo rm -f path/to/robots.txt

Rationale:

Search engines are constantly at work on the Internet. Search engines are augmented by agents, often referred to as spiders or bots, which endeavor to capture and catalog web-site content. In turn, these search engines make the content they obtain and catalog available to any public web user.

To request that a well behaved search engine not crawl and catalog a site, the web site may contain a file called robots.txt. This file contains directories and files that the web server SA desires not be crawled or cataloged, but this file can also be used, by an attacker or poorly coded search engine, as a directory and file index to a site. This information may be used to reduce an attacker's time searching and traversing the web site to find files that might be relevant. If information on the web site needs to be protected from search engines and public view, other methods must be used.

Severity:  medium

Remove .java And .jpp Files   [ref]rule

.java and .jpp files should not exist and should be removed from the web server.

Rationale:

From the source code in a .java or a .jpp file, the Java compiler produces a binary file with an extension of .class. The .java or .jpp file would, therefore, reveal sensitive information regarding an application's logic and permissions to resources on the server. By contrast, the .class file, because it is intended to be machine independent, is referred to as bytecode. Bytecodes are run by the Java Virtual Machine (JVM), or the Java Runtime Environment (JRE), via a browser configured to permit Java code.

Severity:  low

Enable HTTPD Error Logging   [ref]rule

ErrorLog should be enabled and set to the following in /etc/httpd/conf/httpd.conf:

ErrorLog "logs/error_log"

Rationale:

The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems.

Severity:  medium

Configure Error Log Format   [ref]rule

LogFormat should be enabled and set to the following in /etc/httpd/conf/httpd.conf:

LogFormat "a %A %h %H %l %m %s %t %u %U \"%{Referer}i\" \"%{User-Agent}i\"" combined

Rationale:

The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. The LogFormat directive defines the format and information to be included in the access log entries.

Severity:  medium

Enable HTTPD System Logging   [ref]rule

CustomLog should be enabled and set to the following in /etc/httpd/conf/httpd.conf:

CustomLog "logs/access_log" combined

Rationale:

The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. The CustomLog directive specifies the log file, syslog facility, or piped logging utility.

Severity:  medium

Enable HTTPD LogLevel   [ref]rule

LogLevel should be enabled and set to warn. Add or edit the following in /etc/httpd/conf/httpd.conf:

LogLevel warn

Rationale:

The server error logs are invaluable because they can also be used to identify potential problems and enable proactive remediation. Log data can reveal anomalous behavior such as "not found" or "unauthorized" errors that may be an evidence of attack attempts. Failure to enable error logging can significantly reduce the ability of Web Administrators to detect or remediate problems. While the ErrorLog directive configures the error log file name, the LogLevel directive is used to configure the severity level for the error logs. The log level values are the standard syslog levels: emerg, alert, crit, error, warn, notice, info and debug.

Severity:  medium

Configure The Number of Allowed Simultaneous Requests   [ref]rule

The MaxKeepAliveRequests directive should be set and configured to 100 or greater by setting the following in /etc/httpd/conf/httpd.conf:

MaxKeepAliveRequests 100

Rationale:

Resource exhaustion can occur when an unlimited number of concurrent requests are allowed on a web site, facilitating a denial of service attack. Mitigating this kind of attack will include limiting the number of concurrent HTTP/HTTPS requests per IP address and may include, where feasible, limiting parameter values associated with keepalive, (i.e., a parameter used to limit the amount of time a connection may be inactive).

Severity:  medium

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.