Securing Apache 2: Step-by-Step
by Artur Maj
When choosing a web server, Apache very often wins against its competitors because of stability, performance, that fact that it's open source, and many other advantages. But when deciding on which version of Apache to use, the choice is not always so simple. On the one hand there is a very popular, stable version used by millions of users, version 1.3, and on the other hand, there is an enhanced and re-designed version 2.0.
And even if the new version has got a lot more extensions and features, some people still decide to use version 1.3, because in their opinion this branch is more stable and secure. As a matter of fact, there is some truth in this statement. Since version 1.3 has been used by millions of users for a long time, most security holes in this version are very likely to be already discovered. At the same time version 2.0 may have many more as-yet undiscovered vulnerabilities, just sleeping and waiting to be found.
Continuing the step-by-step fashion from the previous series (Securing Apache, Securing PHP, and Securing MySQL), this article shows how to install and configure Apache 2.0 to minimize the risk of unauthorized access or successful break-in, even if new security vulnerabilities in Apache web server are found. Thus, it will be possible to enjoy the new features of Apache 2.0 without worrying too much about its security bugs, regardless if they are only imaginary, or are in fact real and serious threats.
In the world of security, there are a few golden principles that should always be followed. One such principle is the rule which says that only absolutely required parts of the software should be used. All other components should be disabled, made inaccessible or not even be installed at all.
The logic behind this rule is very simple -- if there is software with dozens of components that are enabled by default, finding only one security vulnerability in any one of these components can put the whole system at risk of a successful break-in. On the other hand, if only a few absolutely necessary components are enabled, finding a new security bug doesn't necessary mean that the software is vulnerable -- because the discovered bug may affect components that are not enabled, or are not installed. The probability of a successful break-in in this case is obviously much lower than in case of the default installation.
Therefore, before starting to secure Apache 2, it is very important to know what functionality we really expect from the web server. This will allow us to prepare the list of modules that we will leave enabled, while the rest will be disabled during compilation time.
According to this rule, this article assumes that very basic functionality of Apache will be used:
One can note that the above functionality doesn't support CGI scripts, the SSL protocol or other useful Apache features. This is because the main purpose of the article is to present a general method of securing Apache 2.0, without focusing on a particular implementation. If there is a need for additional functionality, readers can still use the presented solution as a starting point, and enhance it by enabling additional modules, for example, mod_ssl, mod_cgi or others.
To provide as many security layers as possible, and at the same time keep this solution portable among many different Linux/BSD systems, the following layers of security will be used:
the network environment
the operating system
the Apache web server
Installing the operating system
First and foremost, we must choose an operating system upon which the web server will run. The rest of article presents how to secure Apache on FreeBSD (5.1), however readers are free to use their favorite Unix, BSD, Linux or Linux-like operating system.
With regards to our security assumptions, after installing the operating system it must be hardened against both remote and local attacks. Regardless of the chosen UNIX/Linux/BSD distribution, it is very important to install only the core operating system, remove any redundant packages and apply up-to-date patches to the kernel and all installed software.
It is also recommended to periodically synchronize the local clock against a trusted time server, using the Network Time Protocol (NTP), and to send log files to a remote, dedicated log server.
After the system is prepared, we can start installing Apache 2.0. The first step is to add a new group and regular user called apache. An example from FreeBSD has been shown below:
The Apache child processes will run with the privileges of the group and user apache. Since the above account will be dedicated to the Apache web server, this will provide separation of privileges and avoid potential security problems when several different processes are being run under the same account, e.g. user nobody.
Downloading the software
Next, the latest version of Apache 2.0 software should be downloaded from the Apache website, and then unpacked. Since we want to disable unnecessary modules during compilation time, it is very important to download the source code, not binaries. It is also important to test the downloaded software against a PGP signature, to make sure that the downloaded version is complete and unmodified.
Choosing Apache's modules
After the Apache source code is unpacked, we must choose which modules will remain enabled, and which will be removed. A short description of all modules available in Apache 2.0 can be found at http://httpd.apache.org/docs-2.0/mod/.
To fulfill the functionality and security requirements assumed at the beginning of this article, we will compile only the following modules:
Since we want to enable only the minimal number of modules, we will compile all the modules statically. Thanks to that, we will eliminate possibility of occurring vulnerabilities in one more module -- mod_so.
Compiling and installing the software
In this step we will configure, compile, and install the Apache web server as follows:
After Apache is installed, we should make sure that only the following modules are enabled:
Before running Apache for the first time, we also need to modify the Apache configuration file. We need to do this because the default configuration file uses modules that we disabled, and without modifications Apache will not run.
Thus, we must remove the /usr/local/apache2/conf/httpd.conf file and create a new httpd.conf in its place, with the following content:
Compared to the default configuration file, the following important changes have been made:
According to our functionality requirements, the above configuration assumes that there are two virtual hosts supported by Apache:
The content of the above virtual hosts will be physically kept under the /www directory, so before running Apache we also need to create the corresponding directories with sample web pages:
We must also prepare directories for storing our log files:
Finally, we can try to run Apache, and test if everything works properly:
If the www.ebank.lab website is accessible from a web browser, we can shutdown Apache:
and then proceed to chroot the server. If there are problems, log files should be analyzed, or the truss command (for BSD and Solaris users) should be used, as follows:
Note that for Linux users, the equivalent command is strace. Either way, analyzing the output of the truss (or strace) command should help with finding the reason of failure.
Chrooting the server
The next step is to limit the Apache processes' access to the filesystems. The chrooting technique was described in detail in the previous article, so at this point we will simply create a directory structure for our new Apache:
The owner of all the above directories should be root, and access rights should not allow regular users to perform any changes in these directories:
Next, we will create the special device file, /dev/null:
We also need to create a /chroot/httpd/dev/log device that is needed for the server to work properly. In the case of our FreeBSD system, the following line should be added to /etc/rc.conf :
In order for the changes to take effect, we also need to restart the syslogd daemon with the new parameter:
The next step is to copy all necessary programs, libraries and configuration files into the new directory tree. In the case of FreeBSD 5.1 the list of required files is as follows:
In the case of other Unix, BSD, Linux and Linux-like systems, the list of required files can be determined by using commands like ldd, strace, truss or strings, as was described in the previous article.
After the above steps are done, we need to prepare the password database that must be present in the chrooted filesystem. Thus, from /chroot/httpd/etc/passwords and /chroot/httpd/etc/group we have to remove all the lines except apache. Next, we should build the password database as follows:
The above commands should be executed when using FreeBSD. In other systems it may be sufficient to edit the /chroot/httpd/etc/passwd and /chroot/httpd/etc/shadow files.
Finally, we can copy the sample website content to the chrooted environment:
and test if the Apache web server runs correctly:
If your Apache now works properly, the only thing that is left to do is to create a script that will start Apache during system boot. In order to do this, the apache.sh script can be used, with the following content:
The above script should be copied to the directory where by default startup scripts are held. In the case of FreeBSD it is the /usr/local/etc/rc.d directory. The access rights to that file should be set as follows:
The main goal of this article was to present a method of securing Apache 2.0 that lets readers mitigate the risk of a successful break-in, even if new vulnerabilities in this software are found. It has been shown how to install Apache with a minimal number of modules, how to set up a more restrictive configuration, and how to implement protection against a large number of exploits by running the web server in a chrooted environment, without the use of any shell programs. And although no method can assure a 100% security, applying the above recommendations will at least make performing a web attack against Apache 2.0 much more difficult, as compared to the default installation.
Securing Apache: Step-by-Step: http://www.securityfocus.com/infocus/1694
Securing PHP: Step-by-Step: http://www.securityfocus.com/infocus/1706
Securing MySQL: Step-by-Step: http://www.securityfocus.com/infocus/1726
Apache HTTP Server Project: http://httpd.apache.org
Sample httpd.conf: httpd.conf
Sample apache.sh: apache.sh
About the author
Artur Maj works as a Principal Software Engineer for Oracle Corporation, in the EMEA Mobile, Wireless & Voice Center of Expertise. He is experienced in designing computer systems, performing security audits as well as providing security training. He is also author of many articles and publications devoted to securing computer systems and software against intruders.
View all articles by Artur Maj on SecurityFocus.
|Comments or reprint requests can be sent to the editor.|
This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.