Even though the Apache HTTP server is one of the most mature and safe server applications included in CentOS 7, there is always room for improvement and a large number of options and techniques are available to harden your web server's security even more. While we cannot show the user every single security feature as it is outside of the scope this book, in this recipe, we will try to teach what is considered to be good practice when it comes to securing your Apache web server for a production system.
To complete this recipe, you will require a working installation of the CentOS 7 operating system with root privileges and a console-based text editor of your choice. It is expected that your server will be using a static IP address and Apache is installed and currently running, and that your server supports one or more domains or subdomains.
Most of the security options and techniques have to be set up in the main Apache configuration file, so we will begin this recipe by opening it in our favorite text editor.
vi /etc/httpd/conf/httpd.conf
<Directory "/var/www/html">
<Directory "/var/www/html">
and closing </Directory>
tags find the line Options Indexes FollowSymLinks
, then disable (comment out) this line by putting a #
in front of it, so it reads:# Options Indexes FollowSymLinks
# Supplemental configuration
. We do not want our server to leak any detailed information through the header, so we type:ServerTokens Prod
apachectl configtest && systemctl reload httpd
Even the most stable, mature, and well-tested programs can include bugs and cause vulnerabilities, as the latest news about the Heartbleed bug in OpenSSL or Shellshock in Bash have shown, and the Apache web server is no exception. Therefore, it is often beneficial to remove all unneeded software to limit the functionality, and thus the likelihood of security problems in your system. For the Apache web server, we can remove all unneeded modules to increase security (this can also increase performance and memory consumption). Let's start this process by reviewing all the currently installed Apache modules.
httpd -M
/etc/httpd/conf.modules.d
folder where they are grouped together by their primary target into the following files:00-base.conf, 00-dav.conf, 00-lua.conf, 00-mpm.conf, 00-proxy.conf, 00-ssl.conf, 00-systemd.conf, 01-cgi.conf, 10-php.conf
conf.modules.d
folder can make our life much easier because we can disable/enable whole groups of modules. For example, if you know that you will not need any Apache DAV modules because you will not provide any WebDAV server, you can disable all DAV-related modules by renaming the extension of the 00-dav.conf
configuration file since only files with the ending .conf
are read and loaded automatically by Apache. In order to do so, type:mv /etc/httpd/conf.modules.d/00-dav.conf /etc/httpd/conf.modules.d/00-dav.conf.BAK
apachectl configtest && systemctl reload httpd
00-base.conf
in your favorite text editor and disable a single line by adding a #
to the beginning of the line of choice you want to disable. For example:# LoadModule userdir_module modules/mod_userdir.so
.BAK
file to the original file name or remove the #
in a specific module config file before reloading httpd
once again.Another really simple way to increase the security of your Apache web server is to protect your server-side scripts and configurations. In our scenario, we have one user (root) who alone is responsible and maintains the complete Apache web server, websites (for example, uploading new HTML pages to the server), server-side scripts, and configurations. Therefore, we will give him/her full file permissions (read/write/execute). The apache
user still needs proper read and execute permissions to serve and access all Apache related files, thus minimizing the risk that your Apache web server is exposing some potential security risks to other system users or can get compromised through HTTP hacks. Do this in two steps:
root
and group apache
:chown -R root:apache /var/www/html /etc/httpd/conf*
apache
user (and also root
) can read those files:chmod 750 -R /var/www/html /etc/httpd/conf*
We began this recipe by opening the main Apache configuration file httpd.conf
to change settings for our main Apache root web content directory /var/www/html
. Here we disabled the complete Options
directive which included the Indexes
as well as the FollowSymLinks
parameter. As we have learned, if you request a directory instead of a file from the Apache server, index.html
or the index.htm
file within this directory will be sent automatically. Now the Indexes
option configures the Apache web server in such a way that if no such file can be found in the requested directory, Apache will auto-generate a listing of the directory's content, as if you had typed ls
(for list directory) in that directory on the command line, and show it to the user as a HTML page. We don't want this feature in general because it can expose secret or private data to unauthorized users and a lot of system administrators will tell you that indexing is considered to be a security threat in general. The FollowSymLinks
directive should also not be used in production systems because if you make a mistake with it, it can easily expose parts of the file system, such as the complete root directory. Finally, we add another measurement to increase the server's base security and this is done by disabling the server version banner information. When the Apache web server generates either a web page or an error page, valuable information, for example the Apache server version and the activated modules, is sent automatically to the browser and a possible attacker can gain valuable information about your system. We stopped this from happening by simply setting ServerTokens
to Prod
. Afterwards, we showed you how to disable Apache modules to reduce the general risk of bugs and exploitations of your system. Finally, we showed how to adjust your Apache file permissions which can also be a good general protection.
There are lots of other things to consider when it comes to hardening your Apache web server but most of these techniques, such as Limiting HTTP request methods, TraceEnable
, setting cookies with HttpOnly
and secure flags, disabling the HTTP 1.0 protocol or SSL v2, or modifying the HTTP header with useful security-related HTTP or custom headers such as X-XSS-Protection
, are much more advanced concepts and can restrict a general purpose Apache web server too much.