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 process, 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 Start With: What Do You Need?
To complete this process, 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.
The Process
Most of the security options and techniques have to be set up in the main Apache configuration file, so we will begin this process by opening it in our favorite text editor.
Configuring httpd.conf to provide better security
- To begin, log in as root and open the main Apache config file:
vi /etc/httpd/conf/httpd.conf - Now go to your main document root. To do so, search the directive called:
<Directory "/var/www/html"> - Within the beginning <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 - Now scroll down to the end of the configuration file and insert the following line one line before the line # Supplemental configuration. We do not want our server to leak any detailed information through the header, so we type:
ServerTokens Prod - Afterwards, reload the Apache configuration to apply your changes:
apachectl configtest && systemctl reload httpd
Removing unneeded httpd modules
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.
- To show all currently installed and loaded Apache modules, type as user root:
httpd -M - All the modules outputted by the preceding command are loaded into the Apache web server by special configuration files in the /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, 00ssl.conf, 00-systemd.conf, 01-cgi.conf, 10-php.conf - So instead of going through all the modules individually, this file structure in the 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/00dav.conf.BAK - Afterwards, reload the Apache configuration to apply your changes to the modules directory:
apachectl configtest && systemctl reload httpd - If you need more fine-grained control, you can also enable/disable single modules in all the configuration files in this directory as well. For example, open 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 - If you decide to use some disabled modules files later, just rename the .BAK file to the original file name or remove the # in a specific module config file before reloading httpd once again.
Protecting your Apache files
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:
- First we will change or reset the ownership of the complete Apache configuration directory and the standard web root directory to owner root and group apache:
chown -R root:apache /var/www/html /etc/httpd/conf* - Afterwards, we will change the file permissions so no one other than our dedicated apache user (and also root) can read those files:
chmod 750 -R /var/www/html /etc/httpd/conf*
How Does It Work?
We began this process 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.
