Securing Apache: Step-by-Step

This article shows in a step-by-step fashion, how to install and configure the Apache 1.3.x Web server in order to mitigate or avoid successful break-in when new vulnerabilities in this software are found.

Functionality

Before we start securing Apache, we must specify what functionality we expect from the server. Variety of Apache's use makes it difficult to write a universal procedure to secure the server in every case. That's why in this article we'll base on the following functionality:

The Web server will be accessible from the Internet; and,

Only static HTML pages will be served

the server will support name-based virtual hosting mechanism

specified Web pages can be accessible only from selected IP addresses or users (basic authentication)

the server will log all the Web requests (including information about Web browsers)

It is worth emphasizing that the above model doesn't support PHP, JSP, CGI or any other technologies that make it possible to interact with Web services. The use of such technologies may pose a large security threat, so that even a small, inconspicuous script can radically decrease the server's security level. Why? Primarily, ASP/CGI applications may contain security vulnerabilities (e.g. SQL injection, cross-site-scripting). Secondarily, the technology itself can be dangerous (vulnerabilities in PHP, Perl modules etc.). That's why I strongly recommend using such technologies only when an interaction with a Web site is absolutely necessary.

Security Assumptions

One of the most important elements of every computer project is the specification of security assumptions. This must be fulfilled before the project is implemented. The security assumptions for our Web server are as follows:

The operating system must be hardened as much as possible, both against local and remote attacks;

The server must not offer any network services except HTTP: (80/TCP);

Remote access to the server must be controlled by a firewall, which should block all outbound connections, and allow inbound connections only to the 80/TCP port of the Web server;

The Apache Web server must be the only service available on the system;

Only absolutely necessary Apache modules should be enabled;

Any diagnostic Web pages and automatic directory indexing service must be turned off;

The server should disclose the least amount of information about itself (security by obscurity);

The Apache server must run under a unique UID/GID, not used by any other system process;

Apache's processes must have limited access to the file systems (chrooting); and,

No shell programs can be present in the Apache's chrooted environment (/bin/sh, /bin/csh etc.).

Installing the Operating System

Before installing Apache we must choose an operating system, upon which the server will run. We've got a broad choice here, because Apache can be compiled and installed on almost every operating system. The rest of the article instructs how to secure the Apache Web server on FreeBSD (4.7), however the described methods are possible to apply in case of most UNIX/Linux systems. The only operating system I do not recommend using is MS Windows - mainly because of the limited capabilities of securing the Apache.

The first step in securing the Web server is hardening the operating system. A discussion of hardening the operating system is beyond the scope of this article. However, there are a lot of documents on the Net describing how to perform that. Readers are encouraged to conduct their own issue on this topic.

After the system is installed and hardened, we have to add a new group and regular user called "apache" like this (an example from FreeBSD):

By default, Apache processes run with privileges of user nobody (except the main process, which runs with root privileges) and GID of group nogroup. This might pose a significant security threat. In case of successful break-in, the intruder can obtain access to all other processes that run under the same UID/GID. Hence, the optimum solution is to run Apache under the UID/GID of a unique regular user/group, dedicated to that software.

Preparing the Software

Apache's Modules

The choice of modules is one of the most important steps of securing Apache. We should go by the rule: the less the better. To fulfill the functionality and security assumptions, the following modules must remain enabled:

Module's name

Description

httpd_core

The core Apache features, required in every Apache installation.

mod_access

Provides access control based on client hostname, IP address, or other characteristics of the client request. Because this module is needed to use "order", "allow" and "deny" directives, it should remain enabled.

mod_auth

Required in order to implement user authentication using text files (HTTP Basic Authentication), which was specified in functionality assumptions.

mod_dir

Required to search and serve directory index files: "index.html", "default.htm", etc.

mod_log_config

Required to implement logging of the requests made to the server.

mod_mime

Required to set the character set, content- encoding, handler, content-language, and MIME types of documents.

All other Apache's modules must be disabled. We can safely turn them off, mainly because we do not need them. By disabling unneeded modules, we can avoid potential break-ins when new security vulnerabilities are found in one of them.

It is also worth to note that two of Apache's modules can be more dangerous than others: mod_autoindex and mod_info. The first module provides for automatic directory indexing, and is enabled by default. It is very easy to use this module in order to check if Apache runs on a server (e.g. http://server_name/icons/) and to get the content of the Web server's directories, when no index files are found in them. The second module, mod_info, should never be accessible from the Internet, mainly because it reveals the Apache server's configuration.

The next question is how to compile modules. The static method seems to be a better choice. If new vulnerabilities in Apache are found, we will probably recompile not just the vulnerable modules, but the whole software. By choosing the static method, we eliminate the need of one more module - mod_so.

Compiling the software

First of all - if exist - any security patches must be applied. Then, the server should be compiled and installed as follows:

Chrooting the server

The next step is to limit Apache processes' access to the filesystems. We can achieve that by chrooting it's main daemon (httpd). Generally, the chrooting technique means creating a new root directory structure, moving all daemon files to it, and running the proper daemon in that new environment. Thanks to that, the daemon (and all child processes) will have access only to the new directory structure.

We'll start this process by creating a new root directory structure under the /chroot/httpd directory:

The owner of all above directories must be root, and the access rights should be set to the 0755. Next, we'll create the special device file: /dev/null:

A different method must be used to create a /chroot/httpd/dev/log device, which is also needed for the server to work properly. In case of the FreeBSD system, the following line should be added to the /etc/rc.conf:

We must restart the system or the syslogd daemon itself for the changes to take effect. In order to create a /chroot/httpd/dev/log device on other operating systems, we must take a look at the proper manuals (man syslogd).

The next step is to copy the main httpd program into the new directory tree with all necessary binaries and libraries. In order to do that, we must prepare the list of all required files. We can make such list by using the following commands (their presence depends on particular operating system):

Command

Availability

Descript ion

ldd

All

Lists dynamiic dependencies of executable files or shared libraries

ktrace/ktruss/kdump

*BSD

Enables kernal process tracing, Displays kernal trace data

sotruss

Solaris

Traces shared library procedure calls

strace/ltrace

Linux

Traces system calls and signals

strings

Finds the printable strings in binary files

trace

AIX

Records selected system events

trace (freeware)

HP-UX <10.20

Print system call and kernal traces of processes

truss

FreeBSD, Solaris, AIX 5L, SCO Unixware

tusc (freeware)

HP-UX>11

Traces the system calls a process invokes in HP-UX 11

Examples of using ldd, strings and truss commands are shown below:

The above commands should be applied not only to the httpd program, but also to all of the libraries and binaries required (libraries often require other libraries). In case of FreeBSD system, the following files have to be copied to the new root directory structure:

By using the truss command we can also discover that the following configuration files must be present in the chrooted environment as well:

Note, that from /chroot/httpd/etc/passwords we have to remove all the lines except "nobody" and "apache". In a similar way, we must remove all the lines except "apache" and "nogroup" from /chroot/httpd/etc/group. Next, we have to build the password database as follows:

The next step is to test if the httpd server runs correctly in the new chrooted environment. In order to perform that, we have to copy the default Apache configuration file and sample index.html:

After copying the aforementioned files, we must change the DocumentRoot directive as presented below (in /chroot/httpd/usr/local/apache/conf/httpd.conf):

Next, we can try to run the server:

If any problems occur, I recommend analyzing Apache's log files precisely (/chroot/httpd/usr/local/apache/logs). Alternatively, the following command can be used:

The truss program should show the cause of the problems. After eliminating any eventual faults, we can configure the Apache server.

Configuring Apache

The first step is to remove the /chroot/httpd/usr/local/apache/conf/httpd.conf file and create a new one in its place, with content similar to the following:

The above configuration includes only the commands that are necessary to fulfill the functionality and security assumptions. In the configuration presented, there are two virtual hosts supported by the Web server:

- www.ebank.lab (www.e-bank.lab)

- www.test.lab

The content of the above Web sites is physically present in the following directories:

Each Web site has its own log files, which are present in the following directories:

The above directories must be created before running the Apache for the first time - otherwise the Apache will not run correctly. The owner of the above directories should be root:sys, and the rights should be set to 0755.

Compared with the default Apache configuration file, the following changes have been made:

the number of enabled modules has been significantly reduced

Apache doesn't disclose information about its version number (directives: ServerTokens, ServerSignature)

Apache's processes (except the root process) are set to be executed with unique regular user's/group's privileges (directives: User, Group)

Apache will allow access only to the directories, subdirectories and files, which are explicitly specified in the configuration file (directives: Directory, Allow); all other requests will be denied by default

Apache will log more information about HTTP requests

Final steps

At the end we should create a start-up script "apache.sh", the content of which will be similar to the following:

The above script should be copied to the proper directory (depends on particular UNIX system), where by default startup scripts are held. In case of FreeBSD it is the /usr/local/etc/rc.d directory.

Summary

The above method allows achieving a higher security level of the Apache server than the one, offered in the default installation.

Thanks to enabling only the absolutely necessary Apache modules, finding a new vulnerability in one of them doesn't have to indicate that our server is vulnerable. Hiding the Apache's version number, turning off the directory indexing service, chrooting and restricted configuration make a successful break-in very difficult. A chrooted environment has also one more important advantage - immunity to the large number of exploits, mainly because of lack of the shell (/bin/sh, /bin/csh etc.). Even if an intruder will success in executing system commands, escaping the chrooted environment could turn out to be quite a problem.