# # This script is Copyright (C) 2004-2018 and is owned by Tenable, Inc. or an Affiliate thereof. # # This script is released under the Tenable Subscription License and # may not be used from within scripts released under another license # without authorization from Tenable, Inc. # # See the following licenses for details: # # http://static.tenable.com/prod_docs/Nessus_6_SLA_and_Subscription_Agreement.pdf # # @PROFESSIONALFEED@ # $Revision: 1.0 $ # $Date: 2018/08/03 $ # # Description : This document implements the security configuration as recommended by the # CIS Apache HTTP Server 2.4 Benchark v1.4.0 # # https://workbench.cisecurity.org/files/2056 # system : "Linux" type : CMD_EXEC description : "1.2 Do Not Install a Multi-Use System" info : "Default server configurations often expose a wide variety of services unnecessarily increasing the risk to the system. Just because a server can perform many services doesn't mean it is wise to do so. The number of services and daemons executing on the Apache Web server should be limited to those necessary, with the Web server being the only primary function of the server. Rationale: Maintaining a server for a single purpose increases the security of your application and system. The more services which are exposed to an attacker, the more potential vectors an attacker has to exploit the system and therefore the higher the risk for the server. A Web server should function as only a web server and if possible should not be mixed with other primary functions such as mail, DNS, database or middleware. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Leverage the package or services manager for your OS to uninstall or disable unneeded services. On Red Hat systems, the following will disable a given service: chkconfig off" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|9.5,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/sbin/chkconfig --list | /bin/grep ':on'" expect : "" severity : MEDIUM system : "Linux" type : RPM_CHECK description : "1.3 Installing Apache - rpm" rpm : "httpd-2.4.0-0" operator : "gte" required : YES system : "Linux" type : CMD_EXEC description : "1.3 Installing Apache - dpkg" cmd : "/usr/bin/dpkg -s apache2 | grep Status: 2>&1" expect : "^[\\s]*Status: install ok installed[\\s]*" description : "1.3 Installing Apache" info : "The CIS Apache Benchmark recommends using the Apache binary provided by your vendor for most situations in order to reduce the effort and increase the effectiveness of maintenance and security patches. However, to keep the benchmark as generic and applicable to all Unix/Linux platforms as possible, a default source build has been used for this benchmark. **Important Note**: There is a major difference between source builds and most vendor packages that is very important to highlight. The default source build of Apache is fairly conservative and minimalist in the modules included and therefore starts off in a fairly strong security state, while most vendor binaries are typically very well loaded with most of the functionality that one may be looking for. _**Therefore, it is important that you don't assume the default value shown in the benchmark will match default values in your installation.**_ You should always test any new installation in your environment before putting it into production. Also keep in mind you can install and run a new version alongside the old one by using a different Apache prefix and a different IP address or port number in the 'Listen' directive. Rationale: The benefits of using the vendor supplied binaries include: - Ease of installation as it will just work, straight out of the box. - It is customized for your OS environment. - It will be tested and have gone through QA procedures. - Everything you need is likely to be included, probably including some third-party modules. For example, many OS vendors ship Apache with 'mod_ssl' and OpenSSL, PHP, 'mod_perl,' and 'ModSecurity'. - Your vendor will tell you about security issues so you have to look in fewer places. - Updates to fix security issues will be easy to apply. The vendor will have already verified the problem, checked the signature on the Apache download, worked out the impact and so on. - You may be able to get the updates automatically, reducing the window of risk." solution : "Installation depends on the operating system platform. For a source build, consult the Apache 2.4 documentation on compiling and installing [https://httpd.apache.org/docs/2.4/install.html](https://httpd.apache.org/docs/2.2/install.html) for a Red Hat Enterprise Linux 5 or 6, the following 'yum' command could be used. # yum install httpd" reference : "CSCv6|2,LEVEL|1NS,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" description : "1.3 Installing Apache" info : "The CIS Apache Benchmark recommends using the Apache binary provided by your vendor for most situations in order to reduce the effort and increase the effectiveness of maintenance and security patches. However, to keep the benchmark as generic and applicable to all Unix/Linux platforms as possible, a default source build has been used for this benchmark. **Important Note**: There is a major difference between source builds and most vendor packages that is very important to highlight. The default source build of Apache is fairly conservative and minimalist in the modules included and therefore starts off in a fairly strong security state, while most vendor binaries are typically very well loaded with most of the functionality that one may be looking for. _**Therefore, it is important that you don't assume the default value shown in the benchmark will match default values in your installation.**_ You should always test any new installation in your environment before putting it into production. Also keep in mind you can install and run a new version alongside the old one by using a different Apache prefix and a different IP address or port number in the 'Listen' directive. Rationale: The benefits of using the vendor supplied binaries include: - Ease of installation as it will just work, straight out of the box. - It is customized for your OS environment. - It will be tested and have gone through QA procedures. - Everything you need is likely to be included, probably including some third-party modules. For example, many OS vendors ship Apache with 'mod_ssl' and OpenSSL, PHP, 'mod_perl,' and 'ModSecurity'. - Your vendor will tell you about security issues so you have to look in fewer places. - Updates to fix security issues will be easy to apply. The vendor will have already verified the problem, checked the signature on the Apache download, worked out the impact and so on. - You may be able to get the updates automatically, reducing the window of risk." solution : "Installation depends on the operating system platform. For a source build, consult the Apache 2.4 documentation on compiling and installing [https://httpd.apache.org/docs/2.4/install.html](https://httpd.apache.org/docs/2.2/install.html) for a Red Hat Enterprise Linux 5 or 6, the following 'yum' command could be used. # yum install httpd" reference : "CSCv6|2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" system : "Linux" type : CMD_EXEC description : "2.1 Enable only necessary Authentication and Authorization Modules - 'Loaded auth._* modules'" info : "The Apache 2.4 modules for authentication and authorization are grouped and named to provide both granularity, and a consistent naming convention to simplify configuration. The 'authn_*' modules provide authentication, while the 'authz_*' modules provide authorization. Apache provides two types of authentication - basic and digest. Review the Apache Authentication and Authorization how-to documentation [http://httpd.apache.org/docs/2.4/howto/auth.html](http://httpd.apache.org/docs/2.2/howto/auth.html) and enable only the modules that are required. Rationale: Authentication and authorization are the front doors to the protected information in your web site. Most installations only need a small subset of the modules available. By minimizing the enabled modules to those that are actually used, we reduce the number of 'doors' and therefore reduce the attack surface of the web site. Likewise, having fewer modules means less software that could have vulnerabilities." solution : "Consult Apache module documentation for descriptions of each module in order to determine the necessary modules for the specific installation. [http://httpd.apache.org/docs/2.4/mod/](http://httpd.apache.org/docs/2.2/mod/) The unnecessary static compiled modules are disabled through compile time configuration options as documented in [http://httpd.apache.org/docs/2.4/programs/configure.html](http://httpd.apache.org/docs/2.2/programs/configure.html). The dynamically loaded modules are disabled by commenting out or removing the 'LoadModule' directive from the Apache configuration files (typically 'httpd.conf'). Some modules may be separate packages, and may be removed." reference : "CSCv6|16,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep 'auth._' | /bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.1 Enable only necessary Authentication and Authorization Modules - 'Loaded ldap* modules'" info : "The Apache 2.4 modules for authentication and authorization are grouped and named to provide both granularity, and a consistent naming convention to simplify configuration. The 'authn_*' modules provide authentication, while the 'authz_*' modules provide authorization. Apache provides two types of authentication - basic and digest. Review the Apache Authentication and Authorization how-to documentation [http://httpd.apache.org/docs/2.4/howto/auth.html](http://httpd.apache.org/docs/2.2/howto/auth.html) and enable only the modules that are required. Rationale: Authentication and authorization are the front doors to the protected information in your web site. Most installations only need a small subset of the modules available. By minimizing the enabled modules to those that are actually used, we reduce the number of 'doors' and therefore reduce the attack surface of the web site. Likewise, having fewer modules means less software that could have vulnerabilities." solution : "Consult Apache module documentation for descriptions of each module in order to determine the necessary modules for the specific installation. [http://httpd.apache.org/docs/2.4/mod/](http://httpd.apache.org/docs/2.2/mod/) The unnecessary static compiled modules are disabled through compile time configuration options as documented in [http://httpd.apache.org/docs/2.4/programs/configure.html](http://httpd.apache.org/docs/2.2/programs/configure.html). The dynamically loaded modules are disabled by commenting out or removing the 'LoadModule' directive from the Apache configuration files (typically 'httpd.conf'). Some modules may be separate packages, and may be removed." reference : "CSCv6|16,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep 'ldap' | /bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.2 Enable the Log Config Module" info : "The 'log_config' module provides for flexible logging of client requests, and provides for the configuration of the information in each log. Rationale: Logging is critical for monitoring usage and potential abuse of your web server. This module is required to configure web server logging using the 'log_format' directive." solution : "Perform either one of the following: - For source builds with static modules, run the Apache './configure' script without including the '--disable-log-config' script options. $ cd $DOWNLOAD_HTTPD $ ./configure - For dynamically loaded modules, add or modify the 'LoadModule' directive so that it is present in the apache configuration as below and not commented out: LoadModule log_config_module modules/mod_log_config.so" reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /bin/grep log_config" expect : "^[\\s]*log_config_module[\\s]*\\((shared|static)\\)[\\s]*$" system : "Linux" type : CMD_EXEC description : "2.3 Disable WebDAV Modules" info : "The Apache 'mod_dav' and 'mod_dav_fs' modules support WebDAV ('Web-based Distributed Authoring and Versioning') functionality for Apache. WebDAV is an extension to the HTTP protocol which allows clients to create, move, and delete files and resources on the web server. Rationale: Disabling WebDAV modules will improve the security posture of the web server by reducing the amount of potentially vulnerable code paths exposed to the network and reducing potential for unauthorized access to files via misconfigured WebDAV access controls." solution : "Perform either one of the following to disable WebDAV module: 1. For source builds with static modules run the Apache './configure' script without including the 'mod_dav', and 'mod_dav_fs' in the '--enable-modules=configure' script options. $ cd $DOWNLOAD_HTTPD $ ./configure 2. For dynamically loaded modules comment out or remove the 'LoadModule' directive for 'mod_dav', and 'mod_dav_fs' modules from the 'httpd.conf' file. ##LoadModule dav_module modules/mod_dav.so ##LoadModule dav_fs_module modules/mod_dav_fs.so" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'dav[^\\s]+module' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.4 Disable Status Module" info : "The Apache 'mod_status' module provides current server performance statistics. Rationale: When 'mod_status' is loaded into the server, its handler capability is available in all configuration files, including per-directory files (e.g., '.htaccess'). The 'mod_status' module may provide an adversary with information that can be used to refine exploits that depend on measuring server load." solution : "Perform either one of the following to disable the 'mod_status' module: 1. For source builds with static modules, run the Apache './configure' script with the '--disable-status configure' script options. $ cd $DOWNLOAD_HTTPD $ ./configure --disable-status 2. For dynamically loaded modules, comment out or remove the 'LoadModule' directive for the 'mod_status' module from the 'httpd.conf' file. ##LoadModule status_module modules/mod_status.so" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'status_module' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.5 Disable Autoindex Module" info : "The Apache 'autoindex' module automatically generates web page listing the contents of directories on the server, typically used so that an 'index.html' does not have to be generated. Rationale: Automated directory listings should not be enabled as it will also reveal information helpful to an attacker such as naming conventions and directory paths. Directory listings may also reveal files that were not intended to be revealed." solution : "Perform either one of the following to disable the 'mod_autoindex' module: 1. For source builds with static modules, run the Apache './configure' script with the '--disable-autoindex' configure script options $ cd $DOWNLOAD_HTTPD $ ./configure -disable-autoindex 2. For dynamically loaded modules, comment out or remove the 'LoadModule' directive for 'mod_autoindex' from the 'httpd.conf' file. ## LoadModule autoindex_module modules/mod_autoindex.so" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'autoindex_module' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.6 Disable Proxy Modules" info : "The Apache proxy modules allow the server to act as a proxy (either forward or reverse proxy) of HTTP and other protocols with additional proxy modules loaded. If the Apache installation is not intended to proxy requests to or from another network then the proxy module should not be loaded. Rationale: Proxy servers can act as an important security control when properly configured, however a secure proxy server is not within the scope of this benchmark. A web server should be primarily a web server or a proxy server but not both, for the same reasons that other multi-use servers are not recommended. Scanning for web servers that will also proxy requests is a very common attack, as proxy servers are useful for anonymizing attacks on other servers, or possibly proxying requests into an otherwise protected network." solution : "Perform either one of the following to disable the proxy module: 1. For source builds with static modules, run the Apache './configure' script without including the 'mod_proxy' in the '--enable-modules=configure' script options. $ cd $DOWNLOAD_HTTPD $ ./configure 2. For dynamically loaded modules, comment out or remove the 'LoadModule' directive for 'mod_proxy' module and all other proxy modules from the 'httpd.conf' file. ##LoadModule proxy_module modules/mod_proxy.so ##LoadModule proxy_connect_module modules/mod_proxy_connect.so ##LoadModule proxy_ftp_module modules/mod_proxy_ftp.so ##LoadModule proxy_http_module modules/mod_proxy_http.so ##LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so ##LoadModule proxy_scgi_module modules/mod_proxy_scgi.so ##LoadModule proxy_ajp_module modules/mod_proxy_ajp.so ##LoadModule proxy_balancer_module modules/mod_proxy_balancer.so ##LoadModule proxy_express_module modules/mod_proxy_express.so ##LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so ##LoadModule proxy_fdpass_module modules/mod_proxy_fdpass.so" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'proxy_' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.7 Disable User Directories Modules" info : "The 'UserDir' directive must be disabled so that user home directories are not accessed via the web site with a tilde (~) preceding the username. The directive also sets the path name of the directory that will be accessed. For example: - [http://example.com/~ralph/](http://example.com/~ralph/) might access a 'public_html' sub-directory of 'ralph' user's home directory. - The directive 'UserDir ./' might map '/~root' to the root directory ('/'). Rationale: The user directories should not be globally enabled since it allows anonymous access to anything users may want to share with other users on the network. Also consider that every time a new account is created on the system, there is potentially new content available via the web site." solution : "Perform either one of the following to disable the user directories module: 1. For source builds with static modules, run the Apache './configure' script with the '--disable-userdir configure' script options. $ cd $DOWNLOAD_HTTPD $ ./configure --disable-userdir 2. For dynamically loaded modules, comment out or remove the 'LoadModule' directive for 'mod_userdir' module from the 'httpd.conf' file. ##LoadModule userdir_module modules/mod_userdir.so" reference : "800-53|CM-7,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'userdir_' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "2.8 Disable Info Module" info : "The Apache 'mod_info' module provides information on the server configuration via access to a '/server-info' URL location. Rationale: While having server configuration information available as a web page may be convenient it's recommended that this module NOT be enabled. Once 'mod_info' is loaded into the server, its handler capability is available in per-directory '.htaccess' files and can leak sensitive information from the configuration directives of other Apache modules such as system paths, usernames/passwords, database names, etc." solution : "Perform either one of the following to disable the 'mod_info' module: 1. For source builds with static modules, run the Apache './configure' script without including the 'mod_info' in the '--enable-modules= configure' script options. $ cd $DOWNLOAD_HTTPD $ ./configure 2. For dynamically loaded modules, comment out or remove the 'LoadModule' directive for the 'mod_info' module from the 'httpd.conf' file. ##LoadModule info_module modules/mod_info.so" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /usr/bin/egrep -v '^(Loaded|Syntax)' | /usr/bin/egrep 'info_module' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : FILE_CONTENT_CHECK description : "3.1 Run the Apache Web Server as a non-root user - 'httpd.conf User = apache'" info : "Although Apache is typically started with 'root' privileges in order to listen on port '80' and '443', it can and should run as another non-root user in order to perform the web services. The Apache User and Group directives are used to designate the user and group that the Apache worker processes will assume. Rationale: One of the best ways to reduce your exposure to attack when running a web server is to create a unique, unprivileged user and group for the server application. The 'nobody' or 'daemon' user and group that comes default on Unix variants should NOT be used to run the web server, since the account is commonly used for other separate daemon services. Instead, an account used only by the apache software so as to not give unnecessary access to other services. Also, the identifier used for the apache user should be a unique system account. System user accounts UID numbers have lower values which are reserved for the special system accounts not used by regular users, such as discussed in User Accounts section of the CIS Red Hat benchmark. Typically, system accounts numbers range from '1-999', or '1-499' and are defined in the '/etc/login.defs' file. As an even more secure alternative, if the Apache web server can be run on high unprivileged ports, then it is not necessary to start Apache as 'root', and all of the Apache processes may be run as the Apache specific user as described below." solution : "Perform the following: 1. If the apache user and group do not already exist, create the account and group as a unique system account: # groupadd -r apache # useradd apache -r -g apache -d /var/www -s /sbin/nologin 2. Configure the Apache user and group in the Apache configuration file 'httpd.conf': User apache Group apache" reference : "CSCv6|5.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*User[\\s]+" expect : "^[\\s]*User[\\s]+apache" system : "Linux" type : FILE_CONTENT_CHECK description : "3.1 Run the Apache Web Server as a non-root user - 'httpd.conf Group = apache'" info : "Although Apache is typically started with 'root' privileges in order to listen on port '80' and '443', it can and should run as another non-root user in order to perform the web services. The Apache User and Group directives are used to designate the user and group that the Apache worker processes will assume. Rationale: One of the best ways to reduce your exposure to attack when running a web server is to create a unique, unprivileged user and group for the server application. The 'nobody' or 'daemon' user and group that comes default on Unix variants should NOT be used to run the web server, since the account is commonly used for other separate daemon services. Instead, an account used only by the apache software so as to not give unnecessary access to other services. Also, the identifier used for the apache user should be a unique system account. System user accounts UID numbers have lower values which are reserved for the special system accounts not used by regular users, such as discussed in User Accounts section of the CIS Red Hat benchmark. Typically, system accounts numbers range from '1-999', or '1-499' and are defined in the '/etc/login.defs' file. As an even more secure alternative, if the Apache web server can be run on high unprivileged ports, then it is not necessary to start Apache as 'root', and all of the Apache processes may be run as the Apache specific user as described below." solution : "Perform the following: 1. If the apache user and group do not already exist, create the account and group as a unique system account: # groupadd -r apache # useradd apache -r -g apache -d /var/www -s /sbin/nologin 2. Configure the Apache user and group in the Apache configuration file 'httpd.conf': User apache Group apache" reference : "CSCv6|5.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*Group[\\s]+" expect : "^[\\s]*Group[\\s]+apache" system : "Linux" type : CMD_EXEC description : "3.1 Run the Apache Web Server as a non-root user - 'apache account is configured'" info : "Although Apache is typically started with 'root' privileges in order to listen on port '80' and '443', it can and should run as another non-root user in order to perform the web services. The Apache User and Group directives are used to designate the user and group that the Apache worker processes will assume. Rationale: One of the best ways to reduce your exposure to attack when running a web server is to create a unique, unprivileged user and group for the server application. The 'nobody' or 'daemon' user and group that comes default on Unix variants should NOT be used to run the web server, since the account is commonly used for other separate daemon services. Instead, an account used only by the apache software so as to not give unnecessary access to other services. Also, the identifier used for the apache user should be a unique system account. System user accounts UID numbers have lower values which are reserved for the special system accounts not used by regular users, such as discussed in User Accounts section of the CIS Red Hat benchmark. Typically, system accounts numbers range from '1-999', or '1-499' and are defined in the '/etc/login.defs' file. As an even more secure alternative, if the Apache web server can be run on high unprivileged ports, then it is not necessary to start Apache as 'root', and all of the Apache processes may be run as the Apache specific user as described below." solution : "Perform the following: 1. If the apache user and group do not already exist, create the account and group as a unique system account: # groupadd -r apache # useradd apache -r -g apache -d /var/www -s /sbin/nologin 2. Configure the Apache user and group in the Apache configuration file 'httpd.conf': User apache Group apache" reference : "800-53|AC-6,800-171|3.1.6,CSF|PR.AC-4,ITSG-33|AC-6,CSCv6|5.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/usr/bin/id apache" # Note: Variable @UID@ replaced with "500" in field "expect". # Note: Variable @GID@ replaced with "500" in field "expect". # Note: Variable @GROUPS_ID@ replaced with "48" in field "expect". expect : "^uid=500\\(apache\\)[\\s]+gid=500\\(apache\\)[\\s]+groups=48\\(apache\\)" system : "Linux" type : CMD_EXEC description : "3.1 Run the Apache Web Server as a non-root user - 'httpd services are running as apache user'" info : "Although Apache is typically started with 'root' privileges in order to listen on port '80' and '443', it can and should run as another non-root user in order to perform the web services. The Apache User and Group directives are used to designate the user and group that the Apache worker processes will assume. Rationale: One of the best ways to reduce your exposure to attack when running a web server is to create a unique, unprivileged user and group for the server application. The 'nobody' or 'daemon' user and group that comes default on Unix variants should NOT be used to run the web server, since the account is commonly used for other separate daemon services. Instead, an account used only by the apache software so as to not give unnecessary access to other services. Also, the identifier used for the apache user should be a unique system account. System user accounts UID numbers have lower values which are reserved for the special system accounts not used by regular users, such as discussed in User Accounts section of the CIS Red Hat benchmark. Typically, system accounts numbers range from '1-999', or '1-499' and are defined in the '/etc/login.defs' file. As an even more secure alternative, if the Apache web server can be run on high unprivileged ports, then it is not necessary to start Apache as 'root', and all of the Apache processes may be run as the Apache specific user as described below." solution : "Perform the following: 1. If the apache user and group do not already exist, create the account and group as a unique system account: # groupadd -r apache # useradd apache -r -g apache -d /var/www -s /sbin/nologin 2. Configure the Apache user and group in the Apache configuration file 'httpd.conf': User apache Group apache" reference : "CSCv6|5.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/ps axu | /bin/grep httpd | /usr/bin/egrep -v '(^root|grep[\\]s+httpd)' | /usr/bin/egrep -v '^apache' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "3.2 Give the Apache User Account an Invalid Shell" info : "The 'apache' account must not be used as a regular login account, and should be assigned an invalid or 'nologin' shell to ensure that the account cannot be used to login. Rationale: Service accounts such as the 'apache' account represent a risk if they can be used to get a login shell to the system." solution : "Change the 'apache' account to use the 'nologin' shell or an invalid shell such as '/dev/null': # chsh -s /sbin/nologin apache" reference : "CSCv6|16,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/grep apache /etc/passwd | /usr/bin/egrep -v '(\/sbin\/nologin|\/dev\/null)[\\s]*$' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "3.3 Lock the Apache User Account" info : "The user account under which Apache runs should not have a valid password, but should be locked. Rationale: As a defense-in-depth measure the Apache user account should be locked to prevent logins, and to prevent a user from su'ing to 'apache' using the password. In general, there shouldn't be a need for anyone to have to 'su' as 'apache', and when there is a need, then 'sudo' should be used instead, which would not require the 'apache' account password." solution : "Use the 'passwd' command to lock the 'apache' account: # passwd -l apache" reference : "800-53|AC-3,800-171|3.1.1,CSF|PR.AC-4,CSF|PR.PT-3,ISO/IEC-27001|A.9.4.1,ITSG-33|AC-3,CSCv6|16,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/usr/bin/passwd -S apache" expect : "^apache[\\s]+LK[\\s]+.+\\(Password locked\\.\\)[\\s]*$" system : "Linux" type : FILE_CHECK description : "3.4 Set Ownership on Apache Directories and ob体育s" info : "The Apache directories and files should be owned by 'root'. This applies to all of the Apache software directories and files installed. Rationale: Restricting ownership of the Apache files and directories will reduce the probability of unauthorized modifications to those resources." solution : "Perform the following: Set ownership on the '$APACHE_PREFIX' directories such as '/usr/local/apache2': $ chown -R root $APACHE_PREFIX" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|5.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @APACHE_PREFIX@ replaced with "/usr/local/apache2" in field "file". file : "/usr/local/apache2" owner : "root" system : "Linux" type : FILE_CHECK description : "3.5 Set Group Id on Apache Directories and ob体育s" info : "The Apache directories and files should be set to have a group Id of 'root', (or a root equivalent) group. This applies to all of the Apache software directories and files installed. The only expected exception is that the Apache web document root ('$APACHE_PREFIX/htdocs') is likely to need a designated group to allow web content to be updated (such as 'webupdate') through a change management process. Rationale: Securing Apache files and directories will reduce the probability of unauthorized modifications to those resources." solution : "Perform the following: Set ownership on the '$APACHE_PREFIX' directories such as '/usr/local/apache2': $ chgrp -R root $APACHE_PREFIX" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|5,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @APACHE_PREFIX@ replaced with "/usr/local/apache2" in field "file". file : "/usr/local/apache2" group : "root" system : "Linux" type : FILE_CHECK description : "3.6 Restrict Other Write Access on Apache Directories and ob体育s" info : "Permissions on Apache directories should generally be 'rwxr-xr-x' (755) and file permissions should be similar except not executable unless appropriate. This applies to all of the Apache software directories and files installed with the possible exception of the web document root '$APACHE_PREFIX/htdocs'. The directories and files in the web document root may have a designated group with write access to allow web content to be updated. In summary, the minimum recommendation is to not allow write access by 'other'. Rationale: None of the Apache files and directories, including the Web document root must allow other write access. Other write access is likely to be very useful for unauthorized modification of web content, configuration files or software for malicious attacks." solution : "Perform the following to remove other write access on the '$APACHE_PREFIX' directories. # chmod -R o-w $APACHE_PREFIX" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @APACHE_PREFIX@ replaced with "/usr/local/apache2" in field "file". file : "/usr/local/apache2" mask : "022" system : "Linux" type : FILE_CONTENT_CHECK description : "3.7 Secure Core Dump Directory - 'CoreDumpDirectory is defined correctly'" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*CoreDumpDirectory" expect : "^[\\s]*CoreDumpDirectory[\\s]+\\/" system : "Linux" type : FILE_CHECK description : "3.7 Secure Core Dump Directory" info : "The 'CoreDumpDirectory' directive is used to specify the directory Apache attempts to switch to before creating the core dump. Core dumps will be disabled if the directory is not writable by the Apache user. Also, core dumps will be disabled if the server is started as 'root' and switches to a non-root user, as is typical. It is recommended that the 'CoreDumpDirectory' directive be set to a directory that is owned by the 'root' user, owned by the group the Apache HTTPD process executes as, and be unaccessible to other users. Rationale: Core dumps are snapshots of memory and may contain sensitive information that should not be accessible by other accounts on the system." solution : "Either remove the 'CoreDumpDirectory' directive from the Apache configuration files or ensure that the configured directory meets the following requirements. 1. 'CoreDumpDirectory' is not to be within the Apache web document root ('$APACHE_PREFIX/htdocs') 2. Must be owned by root and have a group ownership of the Apache group (as defined via the Group directive) # chown root:apache /var/log/httpd 3. Must have no read-write-search access permission for other users. # chmod o-rwx /var/log/httpd" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @CORE_DUMP_DIR@ replaced with "/var/log/httpd" in field "file". file : "/var/log/httpd" owner : "root" mask : "007" # Note: Variable @APACHE_GRP@ replaced with "ServerRoot" in field "group". group : "root" || "apache" || "ServerRoot" system : "Linux" type : FILE_CONTENT_CHECK description : "3.7 Secure Core Dump Directory" info : "The 'CoreDumpDirectory' directive is used to specify the directory Apache attempts to switch to before creating the core dump. Core dumps will be disabled if the directory is not writable by the Apache user. Also, core dumps will be disabled if the server is started as 'root' and switches to a non-root user, as is typical. It is recommended that the 'CoreDumpDirectory' directive be set to a directory that is owned by the 'root' user, owned by the group the Apache HTTPD process executes as, and be unaccessible to other users. Rationale: Core dumps are snapshots of memory and may contain sensitive information that should not be accessible by other accounts on the system." solution : "Either remove the 'CoreDumpDirectory' directive from the Apache configuration files or ensure that the configured directory meets the following requirements. 1. 'CoreDumpDirectory' is not to be within the Apache web document root ('$APACHE_PREFIX/htdocs') 2. Must be owned by root and have a group ownership of the Apache group (as defined via the Group directive) # chown root:apache /var/log/httpd 3. Must have no read-write-search access permission for other users. # chmod o-rwx /var/log/httpd" reference : "800-53|AC-6,800-171|3.1.7,CSF|PR.AC-4,CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*CoreDumpDirectory" expect : "^[\\s]*CoreDumpDirectory[\\s]+\\/" system : "Linux" type : FILE_CONTENT_CHECK description : "3.8 Secure the Lock ob体育 - 'Lockob体育 is configured'" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*Mutex[\\s]+" expect : "^[\\s]*Mutex[\\s]+(flock|fcntl|file)" description : "3.8 Secure the Lock ob体育 - 'Lockob体育 directory'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name. NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" system : "Linux" type : FILE_CHECK description : "3.8 Secure the Lock ob体育 - 'Lockob体育 permissions'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @LOCK_FILE@ replaced with "/etc/httpd/logs" in field "file". file : "/etc/httpd/logs" owner : "root" mask : "022" group : "root" description : "3.8 Secure the Lock ob体育 - 'Lockob体育 on local hard drive'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name. NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" description : "3.8 Secure the Lock ob体育 - 'Lockob体育 directory'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" description : "3.8 Secure the Lock ob体育 - 'Lockob体育 permissions'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" description : "3.8 Secure the Lock ob体育 - 'Lockob体育 on local hard drive'" info : "The 'Mutex' directive sets the locking mechanism used to serialize access to resources. It may be used to specify that a lock file is to be used as a mutex mechanism and may provide the path to the lock file to be used with the 'fcntl(2)' or 'flock(2)' system calls. Most Linux systems will default to using semaphores instead, so the directive may not apply. However, in the event a lock file is used, it is important for the lock file to be in a local directory that is not writable by other users. Rationale: If the lock file to be used as a mutex is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a lock file with the same name." solution : "Find the directory path in which the lock file would be created. The default value is the 'ServerRoot/logs' directory. 1. Modify the directory if the path is a directory within the Apache 'DocumentRoot' 2. Change the ownership and group to be 'root:root', if not already. 3. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root), 4. Check that the lock file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" system : "Linux" type : FILE_CONTENT_CHECK description : "3.9 Secure the Pid ob体育 - 'Pidob体育 directory'" info : "The 'Pidob体育' directive sets the file path to the process ID file to which the server records the process id of the server, which is useful for sending a signal to the server process or for checking on the health of the process. Rationale: If the 'Pidob体育' is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a pid file with the same name." solution : "1. Find the directory in which the 'Pidob体育' would be created. The default value is the 'ServerRoot/logs' directory. 2. Modify the directory if the 'Pidob体育' is in a directory within the Apache 'DocumentRoot'. 3. Change the ownership and group to be 'root:root', if not already. 4. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root)." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*Pidob体育[\\s]+" expect : "^[\\s]*Pidob体育[\\s]+" system : "Linux" type : FILE_CHECK description : "3.9 Secure the Pid ob体育 - 'Pidob体育 permissions'" info : "The 'Pidob体育' directive sets the file path to the process ID file to which the server records the process id of the server, which is useful for sending a signal to the server process or for checking on the health of the process. Rationale: If the 'Pidob体育' is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a pid file with the same name." solution : "1. Find the directory in which the 'Pidob体育' would be created. The default value is the 'ServerRoot/logs' directory. 2. Modify the directory if the 'Pidob体育' is in a directory within the Apache 'DocumentRoot'. 3. Change the ownership and group to be 'root:root', if not already. 4. Change the permissions so that the directory is only writable by root, or the user under which Apache initially starts up (default is root)." reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @PID_FILE@ replaced with "/etc/httpd/run" in field "file". file : "/etc/httpd/run" owner : "root" mask : "022" group : "root" system : "Linux" type : FILE_CONTENT_CHECK description : "ScoreBoard ob体育 Security" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*ScoreBoardob体育[\\s]+" expect : "^[\\s]*ScoreBoardob体育[\\s]+" system : "Linux" type : FILE_CHECK description : "3.10 Secure the ScoreBoard ob体育" info : "The 'ScoreBoardob体育' directive sets a file path which the server will use for inter-process communication (IPC) among the Apache processes. On most Linux platforms, shared memory will be used instead of a file in the file system, so this directive is not generally needed and does not need to be specified. However, if the directive is specified, then Apache will use the configured file for the inter-process communication. Therefore if it is specified, it needs to be located in a secure directory. Rationale: If the 'ScoreBoardob体育' is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a file with the same name, and users could monitor and disrupt the communication between the processes by reading and writing to the file." solution : "1. Check to see if the 'ScoreBoardob体育' is specified in any of the Apache configuration files. If it is not present, no changes are required. 2. If the directive is present, find the directory in which the 'ScoreBoardob体育' would be created. The default value is the 'ServerRoot/logs' directory. 3. Modify the directory if the 'ScoreBoardob体育' is in a directory within the Apache 'DocumentRoot' 4. Change the ownership and group to be 'root:root', if not already. 5. Change the permissions so that the directory is only writable by root, or the user under which apache initially starts up (default is root), 6. Check that the scoreboard file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @SCOREBOARD_DIR@ replaced with "/etc/httpd/logs" in field "file". file : "/etc/httpd/logs" owner : "root" mask : "022" group : "root" system : "Linux" type : FILE_CONTENT_CHECK_NOT description : "3.10 Secure the ScoreBoard ob体育" info : "The 'ScoreBoardob体育' directive sets a file path which the server will use for inter-process communication (IPC) among the Apache processes. On most Linux platforms, shared memory will be used instead of a file in the file system, so this directive is not generally needed and does not need to be specified. However, if the directive is specified, then Apache will use the configured file for the inter-process communication. Therefore if it is specified, it needs to be located in a secure directory. Rationale: If the 'ScoreBoardob体育' is placed in a writable directory, other accounts could create a denial of service attack and prevent the server from starting by creating a file with the same name, and users could monitor and disrupt the communication between the processes by reading and writing to the file." solution : "1. Check to see if the 'ScoreBoardob体育' is specified in any of the Apache configuration files. If it is not present, no changes are required. 2. If the directive is present, find the directory in which the 'ScoreBoardob体育' would be created. The default value is the 'ServerRoot/logs' directory. 3. Modify the directory if the 'ScoreBoardob体育' is in a directory within the Apache 'DocumentRoot' 4. Change the ownership and group to be 'root:root', if not already. 5. Change the permissions so that the directory is only writable by root, or the user under which apache initially starts up (default is root), 6. Check that the scoreboard file directory is on a locally mounted hard drive rather than an NFS mounted file system." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*ScoreBoardob体育[\\s]+" expect : "^[\\s]*ScoreBoardob体育[\\s]+" system : "Linux" type : FILE_CHECK description : "3.11 Restrict Group Write Access for the Apache Directories and ob体育s" info : "Group permissions on Apache directories should generally be 'r-x' and file permissions should be similar except not executable if executable is not appropriate. This applies to all of the Apache software directories and files installed with the possible exception of the web document root '$DOCROOT' defined by Apache 'DocumentRoot' and defaults to '$APACHE_PREFIX/htdocs'. The directories and files in the web document root may have a designated web development group with write access to allow web content to be updated. Rationale: Restricting write permissions on the Apache files and directories can help mitigate attacks that modify web content to provide unauthorized access, or to attack web clients." solution : "Perform the following to remove group write access on the '$APACHE_PREFIX' directories. # chmod -R g-w $APACHE_PREFIX" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @APACHE_PREFIX@ replaced with "/usr/local/apache2" in field "file". file : "/usr/local/apache2" mask : "022" system : "Linux" type : FILE_CHECK description : "3.12 Restrict Group Write Access for the Document Root Directories and ob体育s" info : "Group permissions on Apache Document Root directories '$DOCROOT' may need to be writable by an authorized group such as development, support, or a production content management tool. However, it is important that the Apache group used to run the server does not have write access to any directories or files in the document root. Rationale: Preventing Apache from writing to the web document root helps mitigate risk associated with web application vulnerabilities associated with file uploads or command execution. Typically, if an application hosted by Apache needs to write to directory, it is best practice to have that directory live outside the web root." solution : "Perform the following to remove group write access on the '$DOCROOT' directories and files with the 'apache' group. # find -L $DOCROOT -group $GRP -perm /g=w -print | xargs chmod g-w" reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @DOCROOT@ replaced with "/etc/httpd" in field "file". file : "/etc/httpd" mask : "022" system : "Linux" type : CMD_EXEC description : "4.1 Deny Access to OS Root Directory - 'httpd.conf Require all denied'" info : "The Apache 'Directory' directive allows for directory specific configuration of access controls and many other features and options. One important usage is to create a default deny policy that does not allow access to operating system directories and files, except for those specifically allowed. This is done by denying access to the OS root directory. Rationale: One aspect of Apache, which is occasionally misunderstood, is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can and will serve it to clients. Having a default deny is a predominate security principle, and then helps prevent the unintended access, and we do that in this case by denying access to the OS root directory using either of two methods but not both: 1. Using the Apache 'Deny' directive along with an 'Order' directive. 2. Using the Apache 'Require' directive. Either method is effective. The 'Order/Deny/Allow' combination are now deprecated; they provide three passes where all the directives are processed in the specified order. In contrast, the 'Require' directive works on the first match similar to firewall rules. The 'Require' directive is the default for Apache 2.4 and is demonstrated in the remediation procedure as it may be less likely to be misunderstood." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root element. 2. Add a single 'Require' directive and set the value to 'all denied' 3. Remove any 'Deny' and 'Allow' directives from the root '' element. Require all denied " reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Require\\s+'" expect : "[\\s]*Require[\\s]*[Aa]ll[\\s]+[Dd]enied[\\s]*$" system : "Linux" type : CMD_EXEC description : "4.1 Deny Access to OS Root Directory - 'httpd.conf no Allow directives exist'" info : "The Apache 'Directory' directive allows for directory specific configuration of access controls and many other features and options. One important usage is to create a default deny policy that does not allow access to operating system directories and files, except for those specifically allowed. This is done by denying access to the OS root directory. Rationale: One aspect of Apache, which is occasionally misunderstood, is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can and will serve it to clients. Having a default deny is a predominate security principle, and then helps prevent the unintended access, and we do that in this case by denying access to the OS root directory using either of two methods but not both: 1. Using the Apache 'Deny' directive along with an 'Order' directive. 2. Using the Apache 'Require' directive. Either method is effective. The 'Order/Deny/Allow' combination are now deprecated; they provide three passes where all the directives are processed in the specified order. In contrast, the 'Require' directive works on the first match similar to firewall rules. The 'Require' directive is the default for Apache 2.4 and is demonstrated in the remediation procedure as it may be less likely to be misunderstood." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root element. 2. Add a single 'Require' directive and set the value to 'all denied' 3. Remove any 'Deny' and 'Allow' directives from the root '' element. Require all denied " reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^[\\s]*Allow[\\s]+' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "4.1 Deny Access to OS Root Directory" info : "The Apache 'Directory' directive allows for directory specific configuration of access controls and many other features and options. One important usage is to create a default deny policy that does not allow access to operating system directories and files, except for those specifically allowed. This is done by denying access to the OS root directory. Rationale: One aspect of Apache, which is occasionally misunderstood, is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can and will serve it to clients. Having a default deny is a predominate security principle, and then helps prevent the unintended access, and we do that in this case by denying access to the OS root directory using either of two methods but not both: 1. Using the Apache 'Deny' directive along with an 'Order' directive. 2. Using the Apache 'Require' directive. Either method is effective. The 'Order/Deny/Allow' combination are now deprecated; they provide three passes where all the directives are processed in the specified order. In contrast, the 'Require' directive works on the first match similar to firewall rules. The 'Require' directive is the default for Apache 2.4 and is demonstrated in the remediation procedure as it may be less likely to be misunderstood." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root element. 2. Add a single 'Require' directive and set the value to 'all denied' 3. Remove any 'Deny' and 'Allow' directives from the root '' element. Require all denied " reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^[\\s]*Deny[\\s]+' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : CMD_EXEC description : "4.2 Allow Appropriate Access to Web Content" info : "In order to serve Web content, either the Apache 'Allow' directive or the 'Require' directive will need to be used to allow for appropriate access to directories, locations and virtual hosts that contain web content. Rationale: Either the 'Allow' or 'Require' directives may be used within a directory, a location or other context to allow appropriate access. Access may be allowed to all, or to specific networks, or hosts, or users as appropriate. The 'Allow/Deny/Order' directives are deprecated and should be replaced by the 'Require' directive. It is also recommended that either the 'Allow' directive or the 'Require' directive be used, but not both in the same context." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find all '' and '' elements. There should be one for the document root and any special purpose directories or locations. There are likely to be other access control directives in other contexts, such as virtual hosts or special elements like ''. 2. Include the appropriate 'Require' directives, with values that are appropriate for the purposes of the directory. The configurations below are just a few possible examples. Require ip 192.169. Require all granted Require local Requirevalid-user" reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @DIRECTORY_1@ replaced with "\\\\/var\\\\/www\\\\/html" in field "cmd". cmd : "/bin/sed -n '//p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Require\\s+'" # Note: Variable @REQUIRE_OPTION@ replaced with "Require all granted" in field "expect". expect : "[\\s]*Require[\\s]+Require all granted[\\s]*$" system : "Linux" type : CMD_EXEC description : "4.3 Restrict Override for the OS Root Directory 'AllowOverride None'" info : "The Apache 'AllowOverRide' directive and the new 'AllowOverrideList' directive allow for '.htaccess' files to be used to override much of the configuration, including authentication, handling of document types, auto generated indexes, access control, and options. When the server finds an '.htaccess' file (as specified by 'Accessob体育Name') it needs to know which directives declared in that file can override earlier access information. When this directive is set to 'None', then '.htaccess' files are completely ignored. In this case, the server will not even attempt to read '.htaccess' files in the filesystem. When this directive is set to 'All', then any directive which has the '.htaccess' Context is allowed in the '.htaccess' files. Rationale: While the functionality of 'htaccess' files is sometimes convenient, usage decentralizes the access controls and increases the risk of configurations being changed or viewed inappropriately by an unintended or rogue '.htaccess' file. Consider also that some of the more common vulnerabilities in web servers and web applications allow the web files to be viewed or to be modified, then it is wise to keep the configuration out of the web server from being placed in '.htaccess' files." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root '' element. 2. Remove any 'AllowOverrideList' directives found. 3. Add a single 'AllowOverride' directive if there is none. 4. Set the value for 'AllowOverride' to 'None'. AllowOverride None" reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*AllowOverride\\s+'" expect : "[\\s]*AllowOverride[\\s]+[Nn]one[\\s]*$" system : "Linux" type : CMD_EXEC description : "4.3 Restrict Override for the OS Root Directory 'exclude AllowOverrideList'" info : "The Apache 'AllowOverRide' directive and the new 'AllowOverrideList' directive allow for '.htaccess' files to be used to override much of the configuration, including authentication, handling of document types, auto generated indexes, access control, and options. When the server finds an '.htaccess' file (as specified by 'Accessob体育Name') it needs to know which directives declared in that file can override earlier access information. When this directive is set to 'None', then '.htaccess' files are completely ignored. In this case, the server will not even attempt to read '.htaccess' files in the filesystem. When this directive is set to 'All', then any directive which has the '.htaccess' Context is allowed in the '.htaccess' files. Rationale: While the functionality of 'htaccess' files is sometimes convenient, usage decentralizes the access controls and increases the risk of configurations being changed or viewed inappropriately by an unintended or rogue '.htaccess' file. Consider also that some of the more common vulnerabilities in web servers and web applications allow the web files to be viewed or to be modified, then it is wise to keep the configuration out of the web server from being placed in '.htaccess' files." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root '' element. 2. Remove any 'AllowOverrideList' directives found. 3. Add a single 'AllowOverride' directive if there is none. 4. Set the value for 'AllowOverride' to 'None'. AllowOverride None" reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*AllowOverrideList\\s+'" expect : "" system : "Linux" type : FILE_CONTENT_CHECK_NOT description : "4.4 Restrict Override for All Directories" info : "The Apache 'AllowOverride' directive and the new 'AllowOverrideList' directive allow for '.htaccess' files to be used to override much of the configuration, including authentication, handling of document types, auto generated indexes, access control, and options. When the server finds an '.htaccess' file (as specified by 'Accessob体育Name') it needs to know which directives declared in that file can override earlier access information. When this directive is set to 'None', then '.htaccess' files are completely ignored. In this case, the server will not even attempt to read '.htaccess' files in the filesystem. When this directive is set to 'All', then any directive which has the '.htaccess' context is allowed in '.htaccess' files. Rationale: '.htaccess' files decentralizes access control and increases the risk of server configuration being changed inappropriately." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find 'AllowOverride' directives. 2. Set the value for all 'AllowOverride' directives to 'None'. AllowOverride None 3. Remove any 'AllowOverrideList' directives found." reference : "CSCv6|14.4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*AllowOverrideList[\\s]*" expect : "^[\\s]*AllowOverrideList[\\s]*" system : "Linux" type : CMD_EXEC description : "5.1 Restrict Options for the OS Root Directory" info : "The Apache 'Options' directive allows for specific configuration of options, including execution of CGI, following symbolic links, server side includes, and content negotiation. Rationale: The 'Options' directive for the root OS level is used to create a default minimal options policy that allows only the minimal options at the root directory level. Then for specific web sites or portions of the web site, options may be enabled as needed and appropriate. No options should be enabled and the value for the 'Options' directive should be 'None'." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find a root '' element. 2. Add a single 'Options' directive if there is none. 3. Set the value for 'Options' to 'None'. Options None" reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//,/<\\/Directory>/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Options\\s+'" expect : "[\\s]*Options[\\s]+[Nn]one[\\s]*$" system : "Linux" type : CMD_EXEC description : "5.2 Restrict Options for the Web Root Directory" info : "The Apache 'Options' directive allows for specific configuration of options, including: - Execution of CGI - Following symbolic links - Server side includes - Content negotiation Rationale: The 'Options' directive at the web root or document root level also needs to be restricted to the minimal options required. A setting of 'None' is highly recommended, however it is recognized that this level content negotiation may be needed if multiple languages are supported. No other options should be enabled." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find the document root '' element. 2. Add or modify any existing 'Options' directive to have a value of 'None' or 'Multiviews', if multiviews are needed. Options None" reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @WEB_ROOT_DIR@ replaced with "/usr/local/apache2/htdocs" in field "cmd". cmd : "/bin/sed -n '//p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Options\\s+'" expect : "[\\s]*Options[\\s]+([Nn]one|Multiviews)*$" system : "Linux" type : CMD_EXEC description : "5.3 Minimize Options for Other Directories" info : "The Apache 'Options' directive allows for specific configuration of options, including execution of CGI, following symbolic links, server side includes, and content negotiation. Rationale: Likewise, the options for other directories and hosts needs to be restricted to the minimal options required. A setting of 'None' is recommended, however it is recognized that other options may be needed in some cases: - 'Multiviews' - Is appropriate if content negotiation is required, such as when multiple languages are supported. - 'ExecCGI' - Is only appropriate for special directories dedicated to executable content such as a 'cgi-bin/' directory. That way you will know what is executed on the server. It is possible to enable CGI script execution based on file extension or permission settings, however this makes script control and management almost impossible as developers may install scripts without your knowledge. This may become a factor in a hosting environment. - 'FollowSymLinks' & 'SymLinksIfOwnerMatch' - The following of symbolic links is not recommended and should be disabled if possible. The usage of symbolic links opens up additional risk for possible attacks that may use inappropriate symbolic links to access content outside of the document root of the web server. Also consider that it could be combined with a vulnerability that allowed an attacker or insider to create an inappropriate link. The option 'SymLinksIfOwnerMatch' is much safer in that the ownership must match in order for the link to be used, however keep in mind there is additional overhead created by requiring Apache to check the ownership. - 'Includes' & 'IncludesNOEXEC' - The 'IncludesNOEXEC' option should only be needed when server side includes are required. The full 'Includes' option should not be used as it also allows execution of arbitrary shell commands. See Apache Mod Include for details [https://httpd.apache.org/docs/2.4/mod/mod\_include.html](https://httpd.apache.org/docs/2.2/mod/mod_include.html) - 'Indexes' - The 'Indexes' option causes automatic generation of indexes, if the default index page is missing, and should be disabled unless required." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files ('httpd.conf' and any included configuration files) to find all '' elements. 2. Add or modify any existing 'Options' directive to NOT have a value of 'Includes'. Other options may be set if necessary and appropriate as described above." reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^[\\s]*Options[\\s]+' | /usr/bin/egrep -v '[\\s]*IncludesNOEXEC' | /usr/bin/egrep '[\\s]*Includes' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : RPM_CHECK description : "5.4 Remove Default HTML Content - 'httpd-manual is not installed'" info : "Apache installations have default content that is not needed or appropriate for production use. The primary function for this sample content is to provide a default web site, provide user manuals or to demonstrate special features of the web server. All content that is not needed should be removed. Rationale: Historically these sample content and features have been remotely exploited and can provide different levels of access to the server. In the Microsoft arena, Code Red exploited a problem with the index service provided by the Internet Information Service. Usually these routines are not written for production use and consequently little thought was given to security in their development." solution : "Review all pre-installed content and remove content which is not required. In particular look for the unnecessary content which may be found in the document root directory, a configuration directory such as 'conf/extra' directory, or as a Unix/Linux package 1. Remove the default index.html or welcome page if it is a separate package. If it is part of main Apache 'httpd' package such as it is on Red Hat Linux, then comment out the configuration as shown below. Removing a file such as the 'welcome.conf', is not recommended as it may get replaced if the package is updated. # # This configuration file enables the default \"Welcome\" # page if there is no default index page present for # the root URL. To disable the Welcome page, comment # out all the lines below. # ## ## Options -Indexes ## ErrorDocument 403 /error/noindex.html ## 2. Remove the Apache user manual content or comment out configurations referencing the manual # yum erase httpd-manual 3. Remove or comment out any Server Status handler configuration. # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-status ## Order deny,allow ## Deny from all ## Allow from .example.com ## 4. Remove or comment out any Server Information handler configuration. # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-info ## Order deny,allow ## Deny from all ## Allow from .example.com ## 5. Remove or comment out any other handler configuration such as perl-status. # This will allow remote server configuration reports, with the URL of # http://servername/perl-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler perl-script ## PerlResponseHandler Apache2::Status ## Order deny,allow ## Deny from all ## Allow from .example.com ##" reference : "800-53|CM-7,800-171|3.4.8,CSF|PR.IP-1,CSF|PR.PT-3,ISO/IEC-27001|A.12.6.2,SWIFT-CSCv1|2.3,CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" rpm : "httpd-manual-0.0.0-0" operator : "lte" required : NO system : "Linux" type : FILE_CONTENT_CHECK_NOT description : "5.4 Remove Default HTML Content - 'Server Status handler does not exist'" info : "Apache installations have default content that is not needed or appropriate for production use. The primary function for this sample content is to provide a default web site, provide user manuals or to demonstrate special features of the web server. All content that is not needed should be removed. Rationale: Historically these sample content and features have been remotely exploited and can provide different levels of access to the server. In the Microsoft arena, Code Red exploited a problem with the index service provided by the Internet Information Service. Usually these routines are not written for production use and consequently little thought was given to security in their development." solution : "Review all pre-installed content and remove content which is not required. In particular look for the unnecessary content which may be found in the document root directory, a configuration directory such as 'conf/extra' directory, or as a Unix/Linux package 1. Remove the default index.html or welcome page if it is a separate package. If it is part of main Apache 'httpd' package such as it is on Red Hat Linux, then comment out the configuration as shown below. Removing a file such as the 'welcome.conf', is not recommended as it may get replaced if the package is updated. # # This configuration file enables the default \"Welcome\" # page if there is no default index page present for # the root URL. To disable the Welcome page, comment # out all the lines below. # ## ## Options -Indexes ## ErrorDocument 403 /error/noindex.html ## 2. Remove the Apache user manual content or comment out configurations referencing the manual # yum erase httpd-manual 3. Remove or comment out any Server Status handler configuration. # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-status ## Order deny,allow ## Deny from all ## Allow from .example.com ## 4. Remove or comment out any Server Information handler configuration. # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-info ## Order deny,allow ## Deny from all ## Allow from .example.com ## 5. Remove or comment out any other handler configuration such as perl-status. # This will allow remote server configuration reports, with the URL of # http://servername/perl-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler perl-script ## PerlResponseHandler Apache2::Status ## Order deny,allow ## Deny from all ## Allow from .example.com ##" reference : "CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*[\\s]*" expect : "^[\\s]*[\\s]*" system : "Linux" type : FILE_CONTENT_CHECK_NOT description : "5.4 Remove Default HTML Content - 'Server Information handler does not exist'" info : "Apache installations have default content that is not needed or appropriate for production use. The primary function for this sample content is to provide a default web site, provide user manuals or to demonstrate special features of the web server. All content that is not needed should be removed. Rationale: Historically these sample content and features have been remotely exploited and can provide different levels of access to the server. In the Microsoft arena, Code Red exploited a problem with the index service provided by the Internet Information Service. Usually these routines are not written for production use and consequently little thought was given to security in their development." solution : "Review all pre-installed content and remove content which is not required. In particular look for the unnecessary content which may be found in the document root directory, a configuration directory such as 'conf/extra' directory, or as a Unix/Linux package 1. Remove the default index.html or welcome page if it is a separate package. If it is part of main Apache 'httpd' package such as it is on Red Hat Linux, then comment out the configuration as shown below. Removing a file such as the 'welcome.conf', is not recommended as it may get replaced if the package is updated. # # This configuration file enables the default \"Welcome\" # page if there is no default index page present for # the root URL. To disable the Welcome page, comment # out all the lines below. # ## ## Options -Indexes ## ErrorDocument 403 /error/noindex.html ## 2. Remove the Apache user manual content or comment out configurations referencing the manual # yum erase httpd-manual 3. Remove or comment out any Server Status handler configuration. # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-status ## Order deny,allow ## Deny from all ## Allow from .example.com ## 4. Remove or comment out any Server Information handler configuration. # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-info ## Order deny,allow ## Deny from all ## Allow from .example.com ## 5. Remove or comment out any other handler configuration such as perl-status. # This will allow remote server configuration reports, with the URL of # http://servername/perl-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler perl-script ## PerlResponseHandler Apache2::Status ## Order deny,allow ## Deny from all ## Allow from .example.com ##" reference : "CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*[\\s]*" expect : "^[\\s]*[\\s]*" system : "Linux" type : FILE_CONTENT_CHECK_NOT description : "5.4 Remove Default HTML Content - 'perl-status handler does not exist'" info : "Apache installations have default content that is not needed or appropriate for production use. The primary function for this sample content is to provide a default web site, provide user manuals or to demonstrate special features of the web server. All content that is not needed should be removed. Rationale: Historically these sample content and features have been remotely exploited and can provide different levels of access to the server. In the Microsoft arena, Code Red exploited a problem with the index service provided by the Internet Information Service. Usually these routines are not written for production use and consequently little thought was given to security in their development." solution : "Review all pre-installed content and remove content which is not required. In particular look for the unnecessary content which may be found in the document root directory, a configuration directory such as 'conf/extra' directory, or as a Unix/Linux package 1. Remove the default index.html or welcome page if it is a separate package. If it is part of main Apache 'httpd' package such as it is on Red Hat Linux, then comment out the configuration as shown below. Removing a file such as the 'welcome.conf', is not recommended as it may get replaced if the package is updated. # # This configuration file enables the default \"Welcome\" # page if there is no default index page present for # the root URL. To disable the Welcome page, comment # out all the lines below. # ## ## Options -Indexes ## ErrorDocument 403 /error/noindex.html ## 2. Remove the Apache user manual content or comment out configurations referencing the manual # yum erase httpd-manual 3. Remove or comment out any Server Status handler configuration. # # Allow server status reports generated by mod_status, # with the URL of http://servername/server-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-status ## Order deny,allow ## Deny from all ## Allow from .example.com ## 4. Remove or comment out any Server Information handler configuration. # # Allow remote server configuration reports, with the URL of # http://servername/server-info (requires that mod_info.c be loaded). # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler server-info ## Order deny,allow ## Deny from all ## Allow from .example.com ## 5. Remove or comment out any other handler configuration such as perl-status. # This will allow remote server configuration reports, with the URL of # http://servername/perl-status # Change the \".example.com\" to match your domain to enable. # ## ## SetHandler perl-script ## PerlResponseHandler Apache2::Status ## Order deny,allow ## Deny from all ## Allow from .example.com ##" reference : "CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" # Note: Variable @HANDLER_1@ replaced with "perl-status" in field "regex". regex : "^[\\s]*[\\s]*" # Note: Variable @HANDLER_1@ replaced with "perl-status" in field "expect". expect : "^[\\s]*[\\s]*" system : "Linux" type : FILE_CHECK_NOT description : "5.5 Remove Default CGI Content printenv" info : "Most Web Servers, including Apache installations have default CGI content which is not needed or appropriate for production use. The primary function for these sample programs is to demonstrate the capabilities of the web server. One common default CGI content for Apache installations is the script 'printenv'. This script will print back to the requester all of the CGI environment variables which includes many server configuration details and system paths. Rationale: CGI programs have a long history of security bugs and problems associated with improperly accepting user-input. Since these programs are often targets of attackers, we need to make sure that there are no unnecessary CGI programs that could potentially be used for malicious purposes. Usually these programs are not written for production use and consequently little thought was given to security in their development. The 'printenv' script in particular will disclose inappropriate information about the web server including directory paths and detailed version and configuration information." solution : "Perform the following to implement the recommended state: 1. Locate cgi-bin files and directories enabled in the Apache configuration via 'Script', 'ScriptAlias', 'ScriptAliasMatch', or 'ScriptInterpreterSource' directives. 2. Remove the 'printenv'default CGI in cgi-bin directory if it is installed. # rm $APACHE_PREFIX/cgi-bin/printenv" reference : "800-53|CM-7,CIP|007-6-R1,PCI-DSSv3.1|2.2.2,PCI-DSSv3.1|2.2.3,PCI-DSSv3.2|2.2.2,PCI-DSSv3.2|2.2.3,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @CGI_BIN@ replaced with "/var/www/cgi-bin" in field "file". file : "/var/www/cgi-bin/printenv" system : "Linux" type : FILE_CHECK_NOT description : "5.6 Remove Default CGI Content test-cgi" info : "Most Web Servers, including Apache installations have default CGI content which is not needed or appropriate for production use. The primary function for these sample programs is to demonstrate the capabilities of the web server. A common default CGI content for Apache installations is the script 'test-cgi'. This script will print back to the requester CGI environment variables which includes many server configuration details. Rationale: CGI programs have a long history of security bugs and problems associated with improperly accepting user-input. Since these programs are often targets of attackers, we need to make sure that there are no unnecessary CGI programs that could potentially be used for malicious purposes. Usually these programs are not written for production use and consequently little thought was given to security in their development. The 'test-cgi' script in particular will disclose inappropriate information about the web server including directory paths and detailed version and configuration information." solution : "Perform the following to implement the recommended state: 1. Locate cgi-bin files and directories enabled in the Apache configuration via 'Script', 'ScriptAlias', 'ScriptAliasMatch', or 'ScriptInterpreterSource' directives. 2. Remove the 'test-cgi' default CGI in cgi-bin directory if it is installed. # rm $APACHE_PREFIX/cgi-bin/test-cgi" reference : "800-53|CM-7,CIP|007-6-R1,PCI-DSSv3.1|2.2.2,PCI-DSSv3.1|2.2.3,PCI-DSSv3.2|2.2.2,PCI-DSSv3.2|2.2.3,800-171|3.4.6,800-171|3.4.7,CN-L3|7.1.3.5(c),CN-L3|7.1.3.7(d),CSF|PR.IP-1,CSF|PR.PT-3,ITSG-33|CM-7,SWIFT-CSCv1|2.3,CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @CGI_BIN@ replaced with "/var/www/cgi-bin" in field "file". file : "/var/www/cgi-bin/test-cgi" system : "Linux" type : CMD_EXEC description : "5.7 Limit HTTP Request Methods" info : "Use the Apache ' * ' directive to restrict unnecessary HTTP request methods of the web server to only accept and process the 'GET', 'HEAD', 'POST' and 'OPTIONS' HTTP request methods. Rationale: The HTTP 1.1 protocol supports several request methods which are rarely used and potentially high risk. For example, methods such as 'PUT' and 'DELETE' are rarely used and should be disabled in keeping with the primary security principal of minimize features and options. Also since the usage of these methods is typically to modify resources on the web server, they should be explicitly disallowed. For normal web server operation, you will typically need to allow only the 'GET', 'HEAD' and 'POST' request methods. This will allow for downloading of web pages and submitting information to web forms. The 'OPTIONS' request method will also be allowed as it used to request which HTTP request methods are allowed. Unfortunately, the Apache ' * ' directive does not deny the 'TRACE' request method. The 'TRACE' request method will be disallowed in another benchmark recommendation with the 'TraceEnable' directive." solution : "Perform the following to implement the recommended state: 1. Locate the Apache configuration files and included configuration files. 2. Search for the directive on the document root directory such as: 3. Add a directive as shown below within the group of document root directives. # Limit HTTP methods to standard methods. Note: Does not limit TRACE * Require all denied 4. Search for other directives in the Apache configuration files other than the OS root directory and add the same directives to each. It is very important to understand that the directives are based on the OS file system hierarchy as accessed by Apache and not the hierarchy of the locations within web site URLs. # Limit HTTP methods * Require all denied" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @DIRECTORY_1@ replaced with "\\\\/var\\\\/www\\\\/html" in field "cmd". cmd : "/bin/sed -n '//p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Require\\s+'" expect : "^[\\s]*Require[\\s]+[Aa]ll[\\s]*[Dd]enied[\\s]*" system : "Linux" type : FILE_CONTENT_CHECK description : "5.8 Disable HTTP TRACE Method" info : "Use the Apache 'TraceEnable' directive to disable the HTTP 'TRACE' request method. Rationale: The HTTP 1.1 protocol requires support for the 'TRACE' request method which reflects the request back as a response and was intended for diagnostics purposes. The 'TRACE' method is not needed and is easily subjected to abuse and should be disabled." solution : "Perform the following to implement the recommended state: 1. Locate the main Apache configuration file such as 'httpd.conf'. 2. Add a 'TraceEnable' directive to the server level configuration with a value of 'off'. Server level configuration is the top-level configuration, not nested within any other directives like '' or ''." reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*TraceEnable[\\s]*" expect : "^[\\s]*TraceEnable[\\s]+Off[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "5.9 Restrict HTTP Protocol Versions - 'RewriteEngine configured'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RewriteEngine[\\s]*" expect : "^[\\s]*RewriteEngine[\\s]+On[\\s]*" system : "Linux" type : FILE_CONTENT_CHECK description : "5.9 Restrict HTTP Protocol Versions - 'httpd.conf RewriteCond exists'" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RewriteCond[\\s]*" expect : "^[\\s]*RewriteCond[\\s]*" system : "Linux" type : CMD_EXEC description : "5.9 Restrict HTTP Protocol Versions - 'RewriteCond configuration'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/egrep '^\\s*RewriteCond\\s*' /etc/httpd/conf/httpd.conf | /usr/bin/egrep -v '^\\s*RewriteCond\\s+%{THE_REQUEST}\\s+!HTTP/1\\\\\.1\\\$' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : FILE_CONTENT_CHECK description : "5.9 Restrict HTTP Protocol Versions - 'RewriteCond configuration'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "800-53|SC-7,800-171|3.13.1,ITSG-33|SC-7,CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RewriteCond[\\s]*" expect : "^[\\s]*RewriteCond[\\s]*" system : "Linux" type : FILE_CONTENT_CHECK description : "5.9 Restrict HTTP Protocol Versions - 'RewriteRule configuration'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RewriteRule[\\s]*" expect : "^[\\s]*RewriteRule[\\s]+\\.\\*[\\s]+-[\\s]+\\\[F\\\][\\s]*" system : "Linux" type : CMD_EXEC description : "5.9 Restrict HTTP Protocol Versions - 'httpd.conf RewriteEngine = on'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '/### Section 3: Virtual Hosts/,$p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '( system : "Linux" type : CMD_EXEC description : "5.9 Restrict HTTP Protocol Versions - 'httpd.conf RewriteOptions = inherit'" info : "The Apache modules 'mod_rewrite' or 'mod_security' can be used to disallow old and invalid HTTP protocols versions. The HTTP version 1.1 RFC is dated June 1999 and has been supported by Apache since version 1.2. It should no longer be necessary to allow ancient versions of HTTP such as 1.0 and prior. Rationale: Many malicious automated programs, vulnerability scanners and fingerprinting tools will send abnormal HTTP protocol versions to see how the web server responds. These requests are usually part of the attacker's enumeration process and therefore it is important that we respond by denying these requests. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Perform the following to implement the recommended state: 1. Load the 'mod_rewrite' module for Apache by doing either one of the following: * Build Apache with mod_rewrite statically loaded during the build, by adding the --enable-rewrite option to the ./configure script. ./configure --enable-rewrite. * Or, dynamically loading the module with the LoadModule directive in the httpd.conf configuration file. LoadModule rewrite_module modules/mod_rewrite.so 2. Locate the main Apache configuration file such as 'httpd.conf' and add the following rewrite condition to match HTTP/1.1 and the rewrite rule to the global server level configuration to disallow other protocol versions. RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1\.1$ RewriteRule .* - [F] 3. By default, 'mod_rewrite' configuration settings from the main server context are not inherited by virtual hosts. Therefore, it is also necessary to add the following directives in each section to inherit the main server settings. RewriteEngine On RewriteOptions Inherit" reference : "CSCv6|9.1,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '/### Section 3: Virtual Hosts/,$p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '( system : "Linux" type : CMD_EXEC description : "5.10 Restrict Access to .ht* files" info : "Restrict access to any files beginning with '.ht' using the 'ob体育sMatch' directive. Rationale: The default name for access filename which allows files in web directories to override the Apache configuration is '.htaccess'. The usage of access files should not be allowed, but as a defense in depth a 'ob体育sMatch' directive is recommended to prevent web clients from viewing those files in case they are created. Also a common name for web password and group files are '.htpasswd' and '.htgroup'. Neither of these files should be placed in the document root, but, in the event they are, the 'ob体育sMatch' directive can be used to prevent them from being viewed by web clients." solution : "Perform the following to implement the recommended state: Add or modify the following lines in the Apache configuration file at the server configuration level. Require all denied" reference : "CSCv6|18.3,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '//p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*Require\\s+'" expect : "^[\\s]*Require[\\s]+[Aa]ll[\\s]*[Dd]enied[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "6.1 Configure the Error Log - 'httpd.conf LogLevel = notice info or debug'" info : "The 'LogLevel' directive is used to configure the severity level for the error logs. While the 'ErrorLog' directive configures the error log file name. The log level values are the standard syslog levels of 'emerg', 'alert', 'crit', 'error', 'warn', 'notice', 'info' and 'debug'. The recommended level is 'notice' for most modules, so that all errors from the 'emerg' level through 'notice' level will be logged. The recommended setting for the 'core' module is 'info' so that any 'not found' requests will be included in the error logs. Rationale: The server error logs are invaluable because they can also be used to spot any potential problems before they become serious. Most importantly, they can be used to watch for anomalous behavior such as a lot of 'not found' or 'unauthorized' errors may be an indication that an attack is pending or has occurred. Starting with Apache 2.4 the error log does not include the 'not found' errors except at the 'info' logging level. Therefore, it is important that the log level be set to 'info' for the 'core' module. The 'not found' requests need to be included in the error log for both forensics investigation and host intrusion detection purposes. Monitoring the access logs may not be practical for many web servers with high volume traffic." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogLevel' in the Apache configuration to have a value of 'info' or lower for the core module and 'notice' or lower for all other modules. Note that is it is compliant to have a value of 'info' or 'debug' if there is a need for a more verbose log and the storage and monitoring processes are capable of handling the extra load. The recommended value is 'notice core:info'. LogLevel notice core:info 2. Add an 'ErrorLog' directive if not already configured. The file path may be relative or absolute, or the logs may be configured to be sent to a syslog server. ErrorLog 'logs/error_log' 3. Add a similar 'ErrorLog' directive for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs and needs the skills/training/tools for monitoring the logs." reference : "800-53|AU-12,800-171|3.3.1,800-171|3.3.2,CN-L3|7.1.3.3(a),CN-L3|7.1.3.3(b),CN-L3|7.1.3.3(c),CSF|DE.CM-1,CSF|DE.CM-3,CSF|DE.CM-7,CSF|PR.PT-1,ISO/IEC-27001|A.12.4.1,ITSG-33|AU-12,SWIFT-CSCv1|6.4,TBA-FIISB|45.1.1,CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*LogLevel[\\s]*" expect : "^[\\s]*LogLevel[\\s]+([Nn]otice|[Ii]nfo|[Dd]ebug)[\\s]+core:([Ii]nfo|[Dd]ebug)[\\s]*$" system : "Linux" type : CMD_EXEC description : "6.1 Configure the Error Log - 'ErrorLog 'logs/error_log'" info : "The 'LogLevel' directive is used to configure the severity level for the error logs. While the 'ErrorLog' directive configures the error log file name. The log level values are the standard syslog levels of 'emerg', 'alert', 'crit', 'error', 'warn', 'notice', 'info' and 'debug'. The recommended level is 'notice' for most modules, so that all errors from the 'emerg' level through 'notice' level will be logged. The recommended setting for the 'core' module is 'info' so that any 'not found' requests will be included in the error logs. Rationale: The server error logs are invaluable because they can also be used to spot any potential problems before they become serious. Most importantly, they can be used to watch for anomalous behavior such as a lot of 'not found' or 'unauthorized' errors may be an indication that an attack is pending or has occurred. Starting with Apache 2.4 the error log does not include the 'not found' errors except at the 'info' logging level. Therefore, it is important that the log level be set to 'info' for the 'core' module. The 'not found' requests need to be included in the error log for both forensics investigation and host intrusion detection purposes. Monitoring the access logs may not be practical for many web servers with high volume traffic." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogLevel' in the Apache configuration to have a value of 'info' or lower for the core module and 'notice' or lower for all other modules. Note that is it is compliant to have a value of 'info' or 'debug' if there is a need for a more verbose log and the storage and monitoring processes are capable of handling the extra load. The recommended value is 'notice core:info'. LogLevel notice core:info 2. Add an 'ErrorLog' directive if not already configured. The file path may be relative or absolute, or the logs may be configured to be sent to a syslog server. ErrorLog 'logs/error_log' 3. Add a similar 'ErrorLog' directive for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs and needs the skills/training/tools for monitoring the logs." reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '1,/### Section 3: Virtual Hosts/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^[\\s]*[Ee]rror[Ll]og[\\s]*'" # Note: Variable @ERROR_LOG@ replaced with "logs\\\\/error_log" in field "expect". expect : "^[\\s]*ErrorLog[\\s]*logs\\\\/error_log[\\s]*$" system : "Linux" type : CMD_EXEC description : "6.1 Configure the Error Log - 'httpd.conf ErrorLog is configured'" info : "The 'LogLevel' directive is used to configure the severity level for the error logs. While the 'ErrorLog' directive configures the error log file name. The log level values are the standard syslog levels of 'emerg', 'alert', 'crit', 'error', 'warn', 'notice', 'info' and 'debug'. The recommended level is 'notice' for most modules, so that all errors from the 'emerg' level through 'notice' level will be logged. The recommended setting for the 'core' module is 'info' so that any 'not found' requests will be included in the error logs. Rationale: The server error logs are invaluable because they can also be used to spot any potential problems before they become serious. Most importantly, they can be used to watch for anomalous behavior such as a lot of 'not found' or 'unauthorized' errors may be an indication that an attack is pending or has occurred. Starting with Apache 2.4 the error log does not include the 'not found' errors except at the 'info' logging level. Therefore, it is important that the log level be set to 'info' for the 'core' module. The 'not found' requests need to be included in the error log for both forensics investigation and host intrusion detection purposes. Monitoring the access logs may not be practical for many web servers with high volume traffic. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogLevel' in the Apache configuration to have a value of 'info' or lower for the core module and 'notice' or lower for all other modules. Note that is it is compliant to have a value of 'info' or 'debug' if there is a need for a more verbose log and the storage and monitoring processes are capable of handling the extra load. The recommended value is 'notice core:info'. LogLevel notice core:info 2. Add an 'ErrorLog' directive if not already configured. The file path may be relative or absolute, or the logs may be configured to be sent to a syslog server. ErrorLog 'logs/error_log' 3. Add a similar 'ErrorLog' directive for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs and needs the skills/training/tools for monitoring the logs." reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '/### Section 3: Virtual Hosts/,$p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '( system : "Linux" type : FILE_CONTENT_CHECK description : "6.3 Configure the Access Log - 'httpd.conf LogFormat is configured'" info : "The 'LogFormat' directive defines the format and information to be included in the access log entries. The 'CustomLog' directive specifies the log file, syslog facility or piped logging utility. Rationale: The server access logs are also invaluable for a variety of reasons. They can be used to determine what resources are being used most. Most importantly, they can be used to investigate anomalous behavior that may be an indication that an attack is pending or has occurred. If the server only logs errors, and does not log successful access, then it is very difficult to investigate incidents. You may see that the errors stop, and wonder if the attacker gave up, or was the attack successful." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogFormat' directives in the Apache configuration to use the standard and recommended 'combined' format show as shown below. LogFormat '%h %l %u %t \'%r\' %>s %b \'%{Referer}i\' \'%{User-agent}i\'' combined 2. Add or modify the 'CustomLog' directives in the Apache configuration to use the combined format with an appropriate log file, syslog facility or piped logging utility. CustomLog log/access_log combined 3. Add a similar 'CustomLog' directives for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs as well as the skills/training/tools for monitoring the logs. The format string tokens provide the following information: - '%h' = Remote hostname or IP address if HostnameLookups is set to Off, which is the default. - '%l' =Remote logname / identity. - '%u' =Remote user, if the request was authenticated. - '%t' = Time the request was received, - '%r' = First line of request. - '%>s' = Final status. - '%b' = Size of response in bytes. - '%{Referer}i' = Variable value for Referer header. - '%{User-agent}i' = Variable value for User Agent header." reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" # Note: Variable @LOG_FORMAT@ replaced with "[[:punct:]]*%h %l %u %t [[:punct:]]*%r[[:punct:]]* %>s %b [[:punct:]]*%{[Rr]eferer}i[[:punct:]]* [[:punct:]]*%{[Uu]ser-[Aa]gent}i[[:punct:]]*" in field "regex". regex : "^[\\s]*LogFormat[\\s]+[[:punct:]]*%h %l %u %t [[:punct:]]*%r[[:punct:]]* %>s %b [[:punct:]]*%{[Rr]eferer}i[[:punct:]]* [[:punct:]]*%{[Uu]ser-[Aa]gent}i[[:punct:]]*[\\s]+[Cc]ombined" # Note: Variable @LOG_FORMAT@ replaced with "[[:punct:]]*%h %l %u %t [[:punct:]]*%r[[:punct:]]* %>s %b [[:punct:]]*%{[Rr]eferer}i[[:punct:]]* [[:punct:]]*%{[Uu]ser-[Aa]gent}i[[:punct:]]*" in field "expect". expect : "^[\\s]*LogFormat[\\s]+[[:punct:]]*%h %l %u %t [[:punct:]]*%r[[:punct:]]* %>s %b [[:punct:]]*%{[Rr]eferer}i[[:punct:]]* [[:punct:]]*%{[Uu]ser-[Aa]gent}i[[:punct:]]*[\\s]+[Cc]ombined[\\s]*$" system : "Linux" type : CMD_EXEC description : "6.3 Configure the Access Log - 'httpd.conf CustomLog is configured'" info : "The 'LogFormat' directive defines the format and information to be included in the access log entries. The 'CustomLog' directive specifies the log file, syslog facility or piped logging utility. Rationale: The server access logs are also invaluable for a variety of reasons. They can be used to determine what resources are being used most. Most importantly, they can be used to investigate anomalous behavior that may be an indication that an attack is pending or has occurred. If the server only logs errors, and does not log successful access, then it is very difficult to investigate incidents. You may see that the errors stop, and wonder if the attacker gave up, or was the attack successful." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogFormat' directives in the Apache configuration to use the standard and recommended 'combined' format show as shown below. LogFormat '%h %l %u %t \'%r\' %>s %b \'%{Referer}i\' \'%{User-agent}i\'' combined 2. Add or modify the 'CustomLog' directives in the Apache configuration to use the combined format with an appropriate log file, syslog facility or piped logging utility. CustomLog log/access_log combined 3. Add a similar 'CustomLog' directives for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs as well as the skills/training/tools for monitoring the logs. The format string tokens provide the following information: - '%h' = Remote hostname or IP address if HostnameLookups is set to Off, which is the default. - '%l' =Remote logname / identity. - '%u' =Remote user, if the request was authenticated. - '%t' = Time the request was received, - '%r' = First line of request. - '%>s' = Final status. - '%b' = Size of response in bytes. - '%{Referer}i' = Variable value for Referer header. - '%{User-agent}i' = Variable value for User Agent header." reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '1,/### Section 3: Virtual Hosts/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*CustomLog\\s*'" # Note: Variable @CUSTOM_LOG@ replaced with "logs\\\\/access_log" in field "expect". expect : "^[\\s]*CustomLog[\\s]*logs\\\\/access_log[\\s]+[Cc]ombined[\\s]*$" system : "Linux" type : CMD_EXEC description : "6.3 Configure the Access Log - 'httpd.conf ErrorLog is configured'" info : "The 'LogFormat' directive defines the format and information to be included in the access log entries. The 'CustomLog' directive specifies the log file, syslog facility or piped logging utility. Rationale: The server access logs are also invaluable for a variety of reasons. They can be used to determine what resources are being used most. Most importantly, they can be used to investigate anomalous behavior that may be an indication that an attack is pending or has occurred. If the server only logs errors, and does not log successful access, then it is very difficult to investigate incidents. You may see that the errors stop, and wonder if the attacker gave up, or was the attack successful. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Perform the following to implement the recommended state: 1. Add or modify the 'LogFormat' directives in the Apache configuration to use the standard and recommended 'combined' format show as shown below. LogFormat '%h %l %u %t \'%r\' %>s %b \'%{Referer}i\' \'%{User-agent}i\'' combined 2. Add or modify the 'CustomLog' directives in the Apache configuration to use the combined format with an appropriate log file, syslog facility or piped logging utility. CustomLog log/access_log combined 3. Add a similar 'CustomLog' directives for each virtual host configured if the virtual host will have different people responsible for the web site. Each responsible individual or organization needs access to their own web logs as well as the skills/training/tools for monitoring the logs. The format string tokens provide the following information: - '%h' = Remote hostname or IP address if HostnameLookups is set to Off, which is the default. - '%l' =Remote logname / identity. - '%u' =Remote user, if the request was authenticated. - '%t' = Time the request was received, - '%r' = First line of request. - '%>s' = Final status. - '%b' = Size of response in bytes. - '%{Referer}i' = Variable value for Referer header. - '%{User-agent}i' = Variable value for User Agent header." reference : "CSCv6|6.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '/### Section 3: Virtual Hosts/,$p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '( system : "Linux" type : FILE_CONTENT_CHECK description : "6.4 Log Storage and Rotation - '/etc/logrotate.conf rotate log files = weekly'" info : "It is important that there is adequate disk space on the partition that will hold all the log files, and that log rotation is configured to retain at least 3 months or 13 weeks if central logging is not used for storage. Rationale: Keep in mind that the generation of logs is under a potential attacker's control. So, do not hold any Apache log files on the root partition of the OS. This could result in a denial of service against your web server host by filling up the root partition and causing the system to crash. For this reason, it is recommended that the log files should be stored on a dedicated partition. Likewise consider that attackers sometimes put information into your logs which is intended to attack your log collection or log analysis processing software. So, it is important that they are not vulnerable. Investigation of incidents often require access to several months or more of logs, which is why it is important to keep at least 3 months available. Two common log rotation utilities include 'rotatelogs(8)' which is bundled with Apache, and 'logrotate(8)' commonly bundled on Linux distributions are described in the remediation section." solution : "To implement the recommended state, do either option 'a' if using the Linux 'logrotate' utility or option 'b' if using a piped logging utility such as the Apache 'rotatelogs': a) ob体育 Logging with Logrotate: 1. Add or modify the web log rotation configuration to match your configured log files in '/etc/logrotate.d/httpd' to be similar to the following. /var/log/httpd/*log { missingok notifempty sharedscripts postrotate /bin/kill -HUP 'cat /var/run/httpd.pid 2>/dev/null' 2> /dev/null || true endscript } 2. Modify the rotation period and number of logs to keep so that at least 13 weeks or 3 months of logs are retained. This may be done as the default value for all logs in '/etc/logrotate.conf' or in the web specific log rotation configuration in '/etc/logrotate.d/httpd'to be similar to the following. # rotate log files weekly weekly # keep 13 weeks of backlogs rotate 13 3. For each virtual host configured with its own log files ensure that those log files are also included in a similar log rotation. b) Piped Logging: 1. Configure the log rotation interval and log file names to a suitable interval such as daily. CustomLog '|bin/rotatelogs -l /var/logs/logfile.%Y.%m.%d 86400' combined 2. Ensure the log file naming and any rotation scripts provide for retaining at least 3 months or 13 weeks of log files. 3. For each virtual host configured with its own log files ensure that those log files are also included in a similar log rotation." reference : "800-53|AU-11,CSF|PR.PT-1,ITSG-33|AU-11,CSCv6|6.3,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/logrotate.conf" regex : "^[\\s]*[Ww]eekly[\\s]*$" expect : "^[\\s]*[Ww]eekly[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "6.4 Log Storage and Rotation - '/etc/logrotate.conf rotate > 52'" info : "It is important that there is adequate disk space on the partition that will hold all the log files, and that log rotation is configured to retain at least 3 months or 13 weeks if central logging is not used for storage. Rationale: Keep in mind that the generation of logs is under a potential attacker's control. So, do not hold any Apache log files on the root partition of the OS. This could result in a denial of service against your web server host by filling up the root partition and causing the system to crash. For this reason, it is recommended that the log files should be stored on a dedicated partition. Likewise consider that attackers sometimes put information into your logs which is intended to attack your log collection or log analysis processing software. So, it is important that they are not vulnerable. Investigation of incidents often require access to several months or more of logs, which is why it is important to keep at least 3 months available. Two common log rotation utilities include 'rotatelogs(8)' which is bundled with Apache, and 'logrotate(8)' commonly bundled on Linux distributions are described in the remediation section." solution : "To implement the recommended state, do either option 'a' if using the Linux 'logrotate' utility or option 'b' if using a piped logging utility such as the Apache 'rotatelogs': a) ob体育 Logging with Logrotate: 1. Add or modify the web log rotation configuration to match your configured log files in '/etc/logrotate.d/httpd' to be similar to the following. /var/log/httpd/*log { missingok notifempty sharedscripts postrotate /bin/kill -HUP 'cat /var/run/httpd.pid 2>/dev/null' 2> /dev/null || true endscript } 2. Modify the rotation period and number of logs to keep so that at least 13 weeks or 3 months of logs are retained. This may be done as the default value for all logs in '/etc/logrotate.conf' or in the web specific log rotation configuration in '/etc/logrotate.d/httpd'to be similar to the following. # rotate log files weekly weekly # keep 13 weeks of backlogs rotate 13 3. For each virtual host configured with its own log files ensure that those log files are also included in a similar log rotation. b) Piped Logging: 1. Configure the log rotation interval and log file names to a suitable interval such as daily. CustomLog '|bin/rotatelogs -l /var/logs/logfile.%Y.%m.%d 86400' combined 2. Ensure the log file naming and any rotation scripts provide for retaining at least 3 months or 13 weeks of log files. 3. For each virtual host configured with its own log files ensure that those log files are also included in a similar log rotation." reference : "800-53|AU-11,CSF|PR.PT-1,ITSG-33|AU-11,CSCv6|6.3,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/logrotate.conf" regex : "^[\\s]*[Rr]otate[\\s]+" expect : "^[\\s]*[Rr]otate[\\s]+([1-9][3-9]|[1-9][0-9][0-9]+)" description : "6.5 Apply Applicable Patches" info : "Apply available Apache patches within 1 month of availability. Rationale: Obviously knowing about newly discovered vulnerabilities is only part of the solution; there needs to be a process in place where patches are tested and installed. These patches fix diverse problems, including security issues. It is recommended to use the Apache packages and updates provided by the Linux platform vendor rather than building from source when possible, in order to minimize the disruption and the work of keeping the software up-to-date. NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance." solution : "Update to the latest Apache release available according to either of the following: 1. When building from source: * Read release notes and related security patch information * Download latest source and any dependent modules such as 'mod_security'. * Build new Apache software according to your build process with the same configuration options. * Install and test the new software according to your organizations testing process. * Move to production according to your organizations deployment process. 2. When using platform packages: * Read release notes and related security patch information * Download and install latest available Apache package and any dependent software. * Test the new software according to your organizations testing process. * Move to production according to your organizations deployment process." reference : "CSCv6|4,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" system : "Linux" type : CMD_EXEC description : "7.1 Install mod_ssl and/or mod_nss - 'mod_ssl is loaded'" info : "Secure Sockets Layer (SSL) was developed by Netscape and turned into an open standard and was renamed Transport Layer Security (TLS) as part of the process. TLS is important for protecting communication and can provide authentication of the server and even the client. However contrary to vendor claims, implementing SSL does NOT directly make your web server more secure! SSL is used to encrypt traffic and therefore does provide confidentiality of private information and users credentials. Keep in mind, however that just because you have encrypted the data in transit does not mean that the data provided by the client is secure while it is on the server. Also, SSL does not protect the web server, as attackers will easily target SSL-Enabled web servers, and the attack will be hidden in the encrypted channel. The 'mod_ssl' module is the standard, most used module that implements SSL/TLS for Apache. A newer module found on Red Hat systems can be a compliment or replacement for 'mod_ssl' and provides the same functionality plus additional security services. The 'mod_nss' is an Apache module implementation of the Network Security Services (NSS) software from Mozilla, which implements a wide range of cryptographic functions in addition to TLS. Rationale: It is best to plan for SSL/TLS implementation from the beginning of any new web server. As most web servers have some need for SSL/TLS due to: - Non-public information submitted that should be protected as it's transmitted to the web server. - Non-public information that is downloaded from the web server. - Users are going to be authenticated to some portion of the web server - There is a need to authenticate the web server to ensure users that they have reached the real web server and have not been phished or redirected to a bogus site." solution : "Perform either of the following to implement the recommended state: 1. For Apache installations built from the source, use the option '--with-ssl=' to specify the openssl path, and the '--enable-ssl' configure option to add the SSL modules to the build. The '--with-included-apr' configure option may be necessary if there are conflicts with the platform version. If a new version of Openssl is needed it may be downloaded from [http://www.openssl.org/](http://www.openssl.org/) See the Apache documentation on building from source [http://httpd.apache.org/docs/2.4/install.html](http://httpd.apache.org/docs/2.4/install.html)for details. # ./configure --with-included-apr --with-ssl=$OPENSSL_DIR --enable-ssl 2. For installations using OS packages, it is typically just a matter of ensuring the 'mod_ssl' package is installed. The 'mod_nss'package might also be installed. The following yum commands are suitable for Red Hat Linux. # yum install mod_ssl" reference : "800-53|SC-13,800-171|3.13.11,CSF|PR.DS-5,ITSG-33|SC-13,CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /bin/grep 'ssl_module'" expect : "^[\\s]*ssl_module[\\s]*\\((shared|static)\\)[\\s]*$" system : "Linux" type : CMD_EXEC description : "7.1 Install mod_ssl and/or mod_nss - 'mod_nss is loaded'" info : "Secure Sockets Layer (SSL) was developed by Netscape and turned into an open standard and was renamed Transport Layer Security (TLS) as part of the process. TLS is important for protecting communication and can provide authentication of the server and even the client. However contrary to vendor claims, implementing SSL does NOT directly make your web server more secure! SSL is used to encrypt traffic and therefore does provide confidentiality of private information and users credentials. Keep in mind, however that just because you have encrypted the data in transit does not mean that the data provided by the client is secure while it is on the server. Also, SSL does not protect the web server, as attackers will easily target SSL-Enabled web servers, and the attack will be hidden in the encrypted channel. The 'mod_ssl' module is the standard, most used module that implements SSL/TLS for Apache. A newer module found on Red Hat systems can be a compliment or replacement for 'mod_ssl' and provides the same functionality plus additional security services. The 'mod_nss' is an Apache module implementation of the Network Security Services (NSS) software from Mozilla, which implements a wide range of cryptographic functions in addition to TLS. Rationale: It is best to plan for SSL/TLS implementation from the beginning of any new web server. As most web servers have some need for SSL/TLS due to: - Non-public information submitted that should be protected as it's transmitted to the web server. - Non-public information that is downloaded from the web server. - Users are going to be authenticated to some portion of the web server - There is a need to authenticate the web server to ensure users that they have reached the real web server and have not been phished or redirected to a bogus site." solution : "Perform either of the following to implement the recommended state: 1. For Apache installations built from the source, use the option '--with-ssl=' to specify the openssl path, and the '--enable-ssl' configure option to add the SSL modules to the build. The '--with-included-apr' configure option may be necessary if there are conflicts with the platform version. If a new version of Openssl is needed it may be downloaded from [http://www.openssl.org/](http://www.openssl.org/) See the Apache documentation on building from source [http://httpd.apache.org/docs/2.4/install.html](http://httpd.apache.org/docs/2.4/install.html)for details. # ./configure --with-included-apr --with-ssl=$OPENSSL_DIR --enable-ssl 2. For installations using OS packages, it is typically just a matter of ensuring the 'mod_ssl' package is installed. The 'mod_nss'package might also be installed. The following yum commands are suitable for Red Hat Linux. # yum install mod_ssl" reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @HTTPD_LOCATION@ replaced with "/usr/sbin/httpd" in field "cmd". cmd : "/usr/sbin/httpd -M | /bin/grep 'nss_module'" expect : "^[\\s]*nss_module[\\s]*\\((shared|static)\\)[\\s]*$" system : "Linux" type : CMD_EXEC description : "7.2 Install a Valid Trusted Certificate" info : "The default SSL certificate is self-signed and is not trusted. Install a valid certificate signed by a commonly trusted certificate authority. To be valid, the certificate must be: - Signed by a trusted certificate authority - Not be expired, and - Have a common name that matches the host name of the web server, such as www.example.com. Rationale: A digital certificate on your server automatically communicates your site's authenticity to visitors' web browsers. If a trusted authority signs your certificate, it confirms for the visitor they are actually communicating with you, and not with a fraudulent site stealing credit card numbers or personal information." solution : "Perform the following to implement the recommended state: 1. Decide on the host name to be used for the certificate. It is important to remember that the browser will compare the host name in the URL to the common name in the certificate, so that it is important that all https: URL's match the correct host name. Specifically, the host name 'www.example.com' is not the same as 'example.com' nor the same as 'ssl.example.com'. 2. Generate a private key using openssl. Although certificate key lengths of 1024 have been common in the past, a key length of 2048 is now recommended for strong authentication. The key must be kept confidential and will be encrypted with a passphrase by default. Follow the steps below and respond to the prompts for a passphrase. See the Apache or OpenSSL documentation for details: - [https://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#realcert](https://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#realcert) - [https://www.openssl.org/docs/HOWTO/certificates.txt](https://www.openssl.org/docs/HOWTO/certificates.txt) # cd /etc/pki/tls/certs # umask 077 # openssl genrsa -aes128 2048 > example.com.key Generating RSA private key, 2048 bit long modulus ...+++ ............+++ e is 65537 (0x10001) Enter pass phrase: Verifying - Enter pass phrase: 3. Generate the certificate signing request (CSR) to be signed by a certificate authority. It is important that common name exactly make the web host name. # openssl req -utf8 -new -key www.example.com.key -out www.example.com.csr Enter pass phrase for example.com.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]:US State or Province Name (full name) [Berkshire]:New York Locality Name (eg, city) [Newbury]:Lima Organization Name (eg, company) [My Company Ltd]:Durkee Consulting Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:www.example.com Email Address []:ralph@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: # mv www.example.com.key /etc/pki/tls/private/ 4. Send the certificate signing request (CSR) to a certificate signing authority to be signed, and follow their instructions for submission and validation. The CSR and the final signed certificate are just encoded text and need to be protected for integrity, but not confidentiality. This certificate will be given out for every SSL connection made. 5. The resulting signed certificate may be named 'www.example.com.crt' and placed in '/etc/pki/tls/certs/' as readable by all (mode '0444'). Please note that the certificate authority does not need the private key ('example.com.key') and this file must be carefully protected. With a decrypted copy of the private key, it would be possible to decrypt all conversations with the server. 6. Do not forget the passphrase used to encrypt the private key. It will be required every time the server is started in https mode. If it is necessary to avoid requiring an administrator having to type the passphrase every time the 'httpd' service is started, the private key may be stored in clear text. Storing the private key in clear text increases the convenience while increasing the risk of disclosure of the key, but may be appropriate for the sake of being able to restart, if the risks are well managed. Be sure that the key file is only readable by root. To decrypt the private key and store it in clear text file the following openssl command may be used. You can tell by the private key headers whether it is encrypted or clear text. # cd /etc/pki/tls/private/ # umask 077 # openssl rsa -in www.example.com.key -out www.example.com.key.clear 7. Locate the Apache configuration file for 'mod_ssl' and add or modify the 'SSLCertificateob体育' and 'SSLCertificateKeyob体育'directives to have the correct path for the private key and signed certificate files. If a clear text key is referenced then a passphrase will not be required. You can use the CA's certificate that signed your certificate instead of the CA bundle, to speed up the initial SSL connection as fewer certificates will need to be transmitted. SSLCertificateob体育 /etc/pki/tls/certs/example.com.crt SSLCertificateKeyob体育 /etc/pki/tls/private/example.com.key # Default CA file, can be replaced with your CA's certificate. SSLCACertificateob体育 /etc/pki/tls/certs/ca-bundle.crt 8. Lastly, start or restart the 'httpd' service and verify correct functioning with your favorite browser." reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @SSL_CERT@ replaced with "/usr/local/apache2/conf/ssl.cert/server.crt" in field "cmd". cmd : "/usr/bin/openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt -purpose sslserver /usr/local/apache2/conf/ssl.cert/server.crt 2>&1 | /usr/bin/egrep '^[Ee]rror' | /usr/bin/awk '{print} END {if (NR == 0) print \"none\"}'" expect : "none" system : "Linux" type : FILE_CHECK description : "7.3 Protect the Server's Private Key" info : "It is critical to protect the server's private key. The server's private key is encrypted by default as a means of protecting it. However, having it encrypted means that the passphrase is required each time the server is started up, and now it is necessary to protect the passphrase as well. The passphrase may be typed in when it is manually started up or provided by an automated program. To summarize, the options are: 1. Use 'SSLPassPhraseDialog builtin', - requires a passphrase to be manually entered. 2. Use 'SSLPassPhraseDialog |/path/to/program' to provide the passphrase. 3. Use 'SSLPassPhraseDialog exec:/path/to/program' to provide the passphrase, 4. Store the private key in clear text so that a passphrase is not required. Any of the above options 1-4 are acceptable as long as the key and passphrase are protected as described below. Option 1 has the additional security benefit of not storing the passphrase, but is not generally acceptable for most production web servers, since it requires the web server to be manually started. Options 2 and 3 can provide additional security if the programs providing them are secure. Option 4 is the simplest, is widely used and is acceptable as long as the private key is appropriately protected. Rationale: If the private key were to be disclosed, it could be used to decrypt all of the SSL communications with the web server as well as to impersonate the web server." solution : "Perform the following to implement the recommended state: 1. All private keys must be stored separately from the public certificates. Find all 'SSLCertificateob体育' directives in the Apache configuration files. For any 'SSLCertificateob体育' directives that do not have a corresponding separate 'SSLCertificateKeyob体育' directive, move the key to a separate file from the certificate, and add the 'SSLCertificateKeyob体育' directive for the key file. 2. For each of the 'SSLCertificateKeyob体育' directives, change the ownership and permissions on the server private key to be owned by 'root:root' with permission '0400'." reference : "800-53|CM-6,PCI-DSSv3.1|2.2.4,PCI-DSSv3.2|2.2.4,800-171|3.4.2,CSF|PR.IP-1,ITSG-33|CM-6,SWIFT-CSCv1|2.3,CSCv6|14,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" # Note: Variable @SSL_KEY@ replaced with "/usr/local/apache2/conf/ssl.key/server.key" in field "file". file : "/usr/local/apache2/conf/ssl.key/server.key" owner : "root" mask : "377" group : "root" system : "Linux" type : FILE_CONTENT_CHECK description : "7.4 Disable the SSL v3.0 Protocol" info : "The Apache 'SSLProtocol' directive specifies the SSL and TLS protocols allowed. The SSLv3 protocol should be disabled in this directive as it is outdated and vulnerable to information disclosure. Only TLS protocols should be enabled. Rationale: The SSLv3 protocol was discovered to be vulnerable to the POODLE attack (Padding Oracle On Downgraded Legacy Encryption) in October 2014. The attack allows decryption and extraction of information from the server's memory. Due to this vulnerability disabling the SSLv3 protocol is highly recommended." solution : "Perform the following to implement the recommended state: Search the Apache configuration files for the 'SSLProtocol' directive; add the directive, if not present, or change the value to match one of the following values. The first setting 'TLSv1.1 TLS1.2' is preferred when it is acceptable to also disable the TLSv1.0 protocol. See the level 2 recommendation 'Disable the TLS v1.0 Protocol' for details. SSLProtocol TLSv1.1 TLS1.2 SSLProtocol TLSv1" reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*SSLProtocol[\\s]*" expect : "^[\\s]*SSLProtocol[\\s]+([Tt][Ll][Ss][Vv]1\\.1[\\s]+TLSv1\\.2[\\s]*|TLSv1)[\\s]*$" system : "Linux" type : CMD_EXEC description : "7.5 Restrict Weak SSL/TLS Ciphers - 'httpd.conf SSLHonorCipherOrder = On'" info : "Disable weak SSL ciphers using the 'SSLCipherSuite', and 'SSLHonorCipherOrder' directives. The 'SSLCipherSuite' directive specifies which ciphers are allowed in the negotiation with the client. While the 'SSLHonorCipherOrder' causes the server's preferred ciphers to be used instead of the clients' specified preferences. Rationale: The SSL/TLS protocols support a large number of encryption ciphers including many weak ciphers that are subject to man-in-the middle attacks and information disclosure. Some implementations even support the NULL cipher which allows a TLS connection without any encryption! Therefore, it is critical to ensure the configuration only allows strong ciphers greater than or equal to 128-bit to be negotiated with the client. Stronger 256-bit ciphers should be allowed and preferred. In addition, enabling the 'SSLHonorCipherOrder' further protects the client from man-in-the-middle downgrade attacks by ensuring the server's preferred ciphers will be used rather than the clients' preferences. In addition, the RC4 stream ciphers should be disabled, even though they are widely used and have been recommended in previous Apache benchmarks as a means of mitigating attacks based on CBC cipher vulnerabilities. The RC4 ciphers have known cryptographic weaknesses and are no longer recommended. The IETF has published RFC 7465 standard [2] that would disallow RC4 negotiation for all TLS versions. While the document is somewhat new (Feb 2015) it is expected the RC4 cipher suites will begin to disappear from options in TLS deployments. In the meantime, it is important to ensure that RC4-based cipher suites are disabled in the configuration." solution : "Perform the following to implement the recommended state: Add or modify the following line in the Apache server level configuration and every virtual host that is SSL enabled: SSLHonorCipherOrder On SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!MD5:!RC4:!aNULL It is **not** recommended to add '!SSLv3' to the directive even if the SSLv3 protocol is not in use. Doing so disables ALL of the ciphers that may used with SSLv3, which includes the same ciphers used with the TLS protocols. The !aNULL will disable both the ADH and AECDH ciphers, so the !ADH is not required." reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '1,/### Section 3: Virtual Hosts/p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '^\\s*SSLHonorCipherOrder\\s*'" expect : "^[\\s]*SSLHonorCipherOrder[\\s]+On[\\s]*$" system : "Linux" type : CMD_EXEC description : "7.5 Restrict Weak SSL/TLS Ciphers - 'httpd.conf VirtualHost SSLHonorCipherOrder = On'" info : "Disable weak SSL ciphers using the 'SSLCipherSuite', and 'SSLHonorCipherOrder' directives. The 'SSLCipherSuite' directive specifies which ciphers are allowed in the negotiation with the client. While the 'SSLHonorCipherOrder' causes the server's preferred ciphers to be used instead of the clients' specified preferences. Rationale: The SSL/TLS protocols support a large number of encryption ciphers including many weak ciphers that are subject to man-in-the middle attacks and information disclosure. Some implementations even support the NULL cipher which allows a TLS connection without any encryption! Therefore, it is critical to ensure the configuration only allows strong ciphers greater than or equal to 128-bit to be negotiated with the client. Stronger 256-bit ciphers should be allowed and preferred. In addition, enabling the 'SSLHonorCipherOrder' further protects the client from man-in-the-middle downgrade attacks by ensuring the server's preferred ciphers will be used rather than the clients' preferences. In addition, the RC4 stream ciphers should be disabled, even though they are widely used and have been recommended in previous Apache benchmarks as a means of mitigating attacks based on CBC cipher vulnerabilities. The RC4 ciphers have known cryptographic weaknesses and are no longer recommended. The IETF has published RFC 7465 standard [2] that would disallow RC4 negotiation for all TLS versions. While the document is somewhat new (Feb 2015) it is expected the RC4 cipher suites will begin to disappear from options in TLS deployments. In the meantime, it is important to ensure that RC4-based cipher suites are disabled in the configuration. NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance." solution : "Perform the following to implement the recommended state: Add or modify the following line in the Apache server level configuration and every virtual host that is SSL enabled: SSLHonorCipherOrder On SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!MD5:!RC4:!aNULL It is **not** recommended to add '!SSLv3' to the directive even if the SSLv3 protocol is not in use. Doing so disables ALL of the ciphers that may used with SSLv3, which includes the same ciphers used with the TLS protocols. The !aNULL will disable both the ADH and AECDH ciphers, so the !ADH is not required." reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed -n '/### Section 3: Virtual Hosts/,$p' /etc/httpd/conf/httpd.conf | /usr/bin/egrep '( system : "Linux" type : CMD_EXEC description : "7.5 Restrict Weak SSL/TLS Ciphers - 'httpd.conf SSLCipherSuite'" info : "Disable weak SSL ciphers using the 'SSLCipherSuite', and 'SSLHonorCipherOrder' directives. The 'SSLCipherSuite' directive specifies which ciphers are allowed in the negotiation with the client. While the 'SSLHonorCipherOrder' causes the server's preferred ciphers to be used instead of the clients' specified preferences. Rationale: The SSL/TLS protocols support a large number of encryption ciphers including many weak ciphers that are subject to man-in-the middle attacks and information disclosure. Some implementations even support the NULL cipher which allows a TLS connection without any encryption! Therefore, it is critical to ensure the configuration only allows strong ciphers greater than or equal to 128-bit to be negotiated with the client. Stronger 256-bit ciphers should be allowed and preferred. In addition, enabling the 'SSLHonorCipherOrder' further protects the client from man-in-the-middle downgrade attacks by ensuring the server's preferred ciphers will be used rather than the clients' preferences. In addition, the RC4 stream ciphers should be disabled, even though they are widely used and have been recommended in previous Apache benchmarks as a means of mitigating attacks based on CBC cipher vulnerabilities. The RC4 ciphers have known cryptographic weaknesses and are no longer recommended. The IETF has published RFC 7465 standard [2] that would disallow RC4 negotiation for all TLS versions. While the document is somewhat new (Feb 2015) it is expected the RC4 cipher suites will begin to disappear from options in TLS deployments. In the meantime, it is important to ensure that RC4-based cipher suites are disabled in the configuration." solution : "Perform the following to implement the recommended state: Add or modify the following line in the Apache server level configuration and every virtual host that is SSL enabled: SSLHonorCipherOrder On SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!MD5:!RC4:!aNULL It is **not** recommended to add '!SSLv3' to the directive even if the SSLv3 protocol is not in use. Doing so disables ALL of the ciphers that may used with SSLv3, which includes the same ciphers used with the TLS protocols. The !aNULL will disable both the ADH and AECDH ciphers, so the !ADH is not required." reference : "800-53|SC-8,800-171|3.13.8,CSF|PR.DS-2,CSF|PR.DS-5,ISO/IEC-27001|A.13.2.3,ITSG-33|SC-8,SWIFT-CSCv1|2.1,TBA-FIISB|29.1,CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed '1,/### Section 3: Virtual Hosts/p' /etc/httpd/conf/httpd.conf | /bin/egrep '^\\s*[Ss][Ss][Ll][Cc][Ii][Pp][Hh][Ee][Rr][Ss][Uu][Ii][Tt][Ee]\\s*'" expect : "^[\\s]*SSLCipherSuite[\\s]*ALL:(?=.*!EXP)(?=.*!NULL).*:!LOW:(?=.*!SSLv2)(?=.*!MD5)(?=.*!RC4).*" system : "Linux" type : FILE_CONTENT_CHECK description : "7.6 Disable SSL Insecure Renegotiation" info : "A man-in-the-middle renegotiation attack was discovered in SSLv3 and TLSv1 in November, 2009 ([CVE-2009-3555](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2009-3555 )). First, a work around and then a fix was approved as an Internet Standard as RFC 574, Feb 2010. The work around, which removes the renegotiation, is available from OpenSSL as of version 0.9.8l and newer versions. For details: [https://www.openssl.org/news/secadv_20091111.txt](https://www.openssl.org/news/secadv_20091111.txt) The 'SSLInsecureRenegotiation' directive was added in Apache 2.2.15, for web servers linked with OpenSSL version 0.9.8m or later, to provide backward compatibility to clients with the older, unpatched SSL implementations. Rationale: Enabling the 'SSLInsecureRenegotiation' directive leaves the server vulnerable to man-in-the-middle renegotiation attack. Therefore, the 'SSLInsecureRenegotiation' directive should not be enabled." solution : "Perform the following to implement the recommended state: Search the Apache configuration files for the 'SSLInsecureRenegotiation' directive. If the directive is present modify the value to be off. If the directive is not present then no action is required. SSLInsecureRenegotiation off" reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*SSLInsecureRenegotiation[\\s]+" expect : "^[\\s]*SSLInsecureRenegotiation[\\s]+[Oo]ff[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "7.7 Ensure SSL Compression is not Enabled" info : "The 'SSLCompression' directive controls whether SSL compression is used by Apache when serving content over HTTPS. It is recommended that the 'SSLCompression' directive be set to 'off'. Rationale: If SSL compression is enabled, HTTPS communication between the client and the server may be at increased risk to the CRIME attack. The CRIME attack increases a malicious actor's ability to derive the value of a session cookie, which commonly contains an authenticator. If the authenticator in a session cookie is derived, it can be used to impersonate the account associated with the authenticator." solution : "Perform the following to implement the recommended state: 1. Search the Apache configuration files for the 'SSLCompression' directive. 2. If the directive is present, set it to 'off'." reference : "CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*SSLCompression[\\s]+" expect : "^[\\s]*SSLCompression[\\s]+[Oo]ff[\\s]*$" system : "Linux" type : CMD_EXEC description : "7.8 Restrict Medium Strength SSL/TLS Ciphers" info : "The SSLCipherSuite directive specifies which ciphers are allowed in the negotiation with the client. Disable the medium strength ciphers such as Triple DES (3DES) and IDEA by adding '!3DES' and '!IDEA' in the SSLCipherSuite directive. Rationale: Although Triple DES has been a trusted standard in the past, several vulnerabilities for it have been published over the years and it is no longer considered secure. A somewhat recent vulnerable against 3DES in CBC mode was nicknamed the SWEET32 attack, was published in 2016 as CVE-2016-2183. The IDEA cipher in CBC mode, is also vulnerable to the SWEET32 attack." solution : "Perform the following to implement the recommended state: Add or modify the following line in the Apache server level configuration and every virtual host that is SSL/TLS enabled: SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!MD5:!RC4:!aNULL:!3DES:!IDEA" reference : "800-53|SC-8,800-171|3.13.8,CSF|PR.DS-2,CSF|PR.DS-5,ISO/IEC-27001|A.13.2.3,ITSG-33|SC-8,SWIFT-CSCv1|2.1,TBA-FIISB|29.1,CSCv6|14.2,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" cmd : "/bin/sed '1,/### Section 3: Virtual Hosts/p' /etc/httpd/conf/httpd.conf | /bin/egrep '^\\s*[Ss][Ss][Ll][Cc][Ii][Pp][Hh][Ee][Rr][Ss][Uu][Ii][Tt][Ee]\\s*'" expect : "^[\\s]*SSLCipherSuite[\\s]*ALL:(?=.*!EXP)(?=.*!NULL).*:!LOW:(?=.*!SSLv2)(?=.*!MD5)(?=.*!RC4)(?=.*!3DES)(?=.*!IDEA).*" system : "Linux" type : FILE_CONTENT_CHECK description : "8.1 Set ServerToken to 'Prod'" info : "Configure the Apache 'ServerTokens' directive to provide minimal information. By setting the value to 'Prod' or 'ProductOnly'. The only version information given in the server HTTP response header will be 'Apache' rather than providing detailed on modules and versions installed. Rationale: Information is power and identifying web server details greatly increases the efficiency of any attack, as security vulnerabilities are extremely dependent upon specific software versions and configurations. Excessive probing and requests may cause too much 'noise' being generated and may tip off an administrator. If an attacker can accurately target their exploits, the chances of successful compromise prior to detection increase dramatically. Script Kiddies are constantly scanning the Internet and documenting the version information openly provided by web servers. The purpose of this scanning is to accumulate a database of software installed on those hosts, which can then be used when new vulnerabilities are released." solution : "Perform the following to implement the recommended state: Add or modify the 'ServerTokens' directive as shown below to have the value of 'Prod' or 'ProductOnly': ServerTokens Prod" reference : "CSCv6|18.9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*ServerTokens[\\s]+" expect : "^[\\s]*ServerTokens[\\s]+(Prod|ProductOnly)[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "8.2 Set ServerSignature to 'Off'" info : "Disable the server signatures which generates a signature line as a trailing footer at the bottom of server generated documents such as error pages. Rationale: Server signatures are helpful when the server is acting as a proxy, since it helps the user distinguish errors from the proxy rather than the destination server, however in this context there is no need for the additional information and we want to limit leakage of unnecessary information." solution : "Perform the following to implement the recommended state: Add or modify the 'ServerSignature' directive as shown below to have the value of 'Off': ServerSignature Off" reference : "CSCv6|18,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*ServerSignature[\\s]+" expect : "^[\\s]*ServerSignature[\\s]+Off[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.1 Set TimeOut to 10 or less" info : "Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality. Although there is no 100% solution for preventing DoS attacks, the following recommendation uses the 'Timeout' directive to mitigate some of the risk, by requiring more effort for a successful DoS attack. Of course, DoS attacks can happen in rather unintentional ways as well as intentional and these directives will help in many of those situations as well. Rationale: One common technique for DoS is to initiate many connections to the server. By decreasing the timeout for old connections and we allow the server to free up resources more quickly and be more responsive. By making the server more efficient, it will be more resilient to DoS conditions. The 'Timeout' directive affects several timeout values for Apache, so review the Apache document carefully. [http://httpd.apache.org/docs/2.4/mod/core.html#timeout](http://httpd.apache.org/docs/2.4/mod/core.html#timeout)" solution : "Perform the following to implement the recommended state: Add or modify the Timeout directive in the Apache configuration to have a value of '10' seconds or shorter. Timeout 10" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*Time[Oo]ut[\\s]+" expect : "^[\\s]*Time[Oo]ut[\\s]+(10|[1-9])[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.2 Set the KeepAlive directive to On" info : "The 'KeepAlive' directive controls whether Apache will reuse the same TCP connection per client to process subsequent HTTP requests from that client. It is recommended that the 'KeepAlive' directive be set to 'On'. Rationale: Allowing per-client reuse of TCP sockets reduces the amount of system and network resources required to serve requests. This efficiency gain may improve a server's resiliency to DoS attacks." solution : "Perform the following to implement the recommended state: Add or modify the 'KeepAlive' directive in the Apache configuration to have a value of 'On', so that 'KeepAlive' connections are enabled. KeepAlive On" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*KeepAlive[\\s]+" expect : "^[\\s]*KeepAlive[\\s]+On[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.3 Set MaxKeepAliveRequests to 100 or greater" info : "The 'MaxKeepAliveRequests' directive limits the number of requests allowed per connection when 'KeepAlive' is on. If it is set to '0', unlimited requests will be allowed. Rationale: The 'MaxKeepAliveRequests' directive is important to be used to mitigate the risk of Denial of Service (DoS) attack technique by reducing the overhead imposed on the server. The 'KeepAlive' directive must be enabled before it is effective. Enabling 'KeepAlives' allows for multiple HTTP requests to be sent while keeping the same TCP connection alive. This reduces the overhead of having to setup and tear down TCP connections for each request. By making the server more efficient, it will be more resilient to DoS conditions." solution : "Perform the following to implement the recommended state: Add or modify the 'MaxKeepAliveRequests' directive in the Apache configuration to have a value of '100' or more. MaxKeepAliveRequests 100" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*MaxKeepAliveRequests[\\s]+" expect : "^[\\s]*MaxKeepAliveRequests[\\s]+[1-9][0-9][0-9]+[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.4 Set KeepAliveTimeout Low to Mitigate Denial of Service" info : "The 'KeepAliveTimeout' directive specifies the number of seconds Apache will wait for a subsequent request before closing a connection that is being kept alive. Rationale: The 'KeepAliveTimeout' directive is used mitigate some of the risk, by requiring more effort for a successful DoS attack. By enabling 'KeepAlive' and keeping the timeout relatively low for old connections and we allow the server to free up resources more quickly and be more responsive." solution : "Perform the following to implement the recommended state: Add or modify the 'KeepAliveTimeout' directive in the Apache configuration to have a value of '15' or less. KeepAliveTimeout 15" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*KeepAliveTimeout[\\s]+" expect : "^[\\s]*KeepAliveTimeout[\\s]+(1[0-5]|[1-9])[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.5 Set Timeout Limits for Request Headers" info : "The 'RequestReadTimeout' directive allows configuration of timeout limits for client requests. The header portion of the directive provides for an initial timeout value, a maximum timeout and a minimum rate. The minimum rate specifies that after the initial timeout, the server will wait an additional 1 second for each N bytes received. The recommended setting is to have a maximum timeout of '40' seconds or less. Keep in mind that for SSL/TLS virtual hosts the time for the TLS handshake must fit within the timeout. Rationale: Setting a request header timeout is vital for mitigating Denial of Service attacks based on slow requests. The slow request attacks are particularly lethal and relative easy to perform, because they require very little bandwidth and can easily be done through anonymous proxies. Starting in June 2009 with the Slow Loris DoS attack, which used a slow 'GET' request, was published by Robert Hansen (RSnake) on his blog [http://ha.ckers.org/slowloris/](http://ha.ckers.org/slowloris/). Later in November 2010 at the OWASP App Sec DC conference Wong Onn Chee demonstrated a slow 'POST' request attack which was even more effective. See [https://www.owasp.org/index.php/H.....t.....t....p.......p....o....s....t](https://www.owasp.org/index.php/H.....t.....t....p.......p....o....s....t) for details." solution : "1. Load the 'mod_requesttimeout' module in the Apache configuration with the following configuration. LoadModule reqtimeout_module modules/mod_reqtimeout.so 2. Add a 'RequestReadTimeout' directive similar to the one below with the maximum request header timeout value of '40' seconds or less. RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RequestReadTimeout[\\s]+" expect : "^[\\s]*RequestReadTimeout[\\s]+[Hh]eader=20-[1-4][0-9],MinRate=500[\\s]+[Bb]ody=(20|1[1-9]),MinRate=500[\\s]*$" system : "Linux" type : FILE_CONTENT_CHECK description : "9.6 Set Timeout Limits for the Request Body" info : "The 'RequestReadTimeout' directive also allows setting timeout values for the body portion of a request. The directive provides for an initial timeout value, and a maximum timeout and minimum rate. The minimum rate specifies that after the initial timeout, the server will wait an additional 1 second for each N bytes are received. The recommended setting is to have a maximum timeout of '20' seconds or less. The default value is 'body=20,MinRate=500'. Rationale: It is not sufficient to timeout only on the header portion of the request, as the server will still be vulnerable to attacks like the OWASP Slow 'POST' attack, which provide the body of the request very slowly. Therefore, the body portion of the request must have a timeout as well. A timeout of '20' seconds or less is recommended." solution : "Load the 'mod_requesttimeout' module in the Apache configuration with the following configuration. LoadModule reqtimeout_module modules/mod_reqtimeout.so Add a 'RequestReadTimeout' directive similar to the one below with the maximum request body timeout value of '20' seconds or less. RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500" reference : "CSCv6|9,LEVEL|1S" see_also : "https://workbench.cisecurity.org/files/2056" file : "/etc/httpd/conf/httpd.conf" regex : "^[\\s]*RequestReadTimeout[\\s]+" expect : "^[\\s]*RequestReadTimeout[\\s]+[Hh]eader=20-(40|[1-3][0-9]),MinRate=500[\\s]+[Bb]ody=(20|1[1-9]),MinRate=500[\\s]*$"