Endpoint Protection

 View Only

Securing Apache 2: Step-by-Step 

Jun 21, 2004 02:00 AM

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.

Functionality requirements

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:

 

  • Only static HTML pages will be served.
  • The server must support the virtual hosting mechanism.
  • Access to some web pages will be restricted to selected IP addresses or users (basic authentication).
  • The server must log all web requests (including information about web browsers).

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.

Security assumptions

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 web server should be protected by a firewall; the rules should accept incoming requests to port 80/tcp and allow outgoing HTTP responses. Except for certain ICMP messages (e.g. source-quench, time-exceed, parameter-problem, destination-unreachable), all other packets should be dropped or denied.
  • An intrusion detection (or prevention) system should be used; Apache's log files should also be monitored.

the operating system

  • The operating system should be hardened as much as possible; all unnecessary components should be removed from the system.
  • If supported, the operating system should not allow executing programs on the stack.
  • All unnecessary network services should be disabled.
  • The number of SUID/SGID files should be minimized.

the Apache web server

  • Only absolutely necessary Apache modules should be enabled; the rest should be disabled during compilation time.
  • All diagnostic web pages and the automatic directory indexing service must be turned off.
  • The server should disclose the least amount of information about itself as possible -- security through obscurity. Although this is not a real security layer, applying it will at least make the attacks a little bit more difficult to perform.
  • The web server must run under a dedicated UID/GID, not one used by any other system process.
  • Apache's processes must have limited access to the file systems (chrooting).
  • In the Apache chrooted environment there cannot be any shell program present (/bin/sh, /bin/csh etc.) -- it makes the process of executing exploits much more difficult to perform.

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:

 

pw groupadd apache pw useradd apache -c "Apache Server" -d /dev/null -g apache -s /sbin/nologin

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.

 

lynx http://httpd.apache.org/download.cgi     <download: httpd-2.0.xx.tar.gz, httpd-2.0.xx.tar.gz.asc, KEYS> gpg --import KEYS gpg httpd-2.0.49.tar.gz.asc     gpg: Good signature from "Sander Striker <striker@apache.org>" tar zxvf httpd-2.0.49.tar.gz cd ./httpd-2.0.49/

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:

 

Module's name
Description

core

The core Apache features, required in every Apache installation.

http_core

The core http support, required in every Apache 2.0 installation.

prefork

Multi-Processing Module (MPM) that implements a non-threaded, pre-forking web server. Can be replaced by other multiprocessing module, e.g. worker , threadpool etc. The MPM module is required in every Apache 2.0 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.

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:

 

./configure \  --prefix=/usr/local/apache2 \  --with-mpm=prefork \  --disable-charset-lite \  --disable-include \  --disable-env \  --disable-setenvif \  --disable-status \  --disable-autoindex \  --disable-asis \  --disable-cgi \  --disable-negotiation \  --disable-imap \  --disable-actions \  --disable-userdir \  --disable-alias \  --disable-so  make  su  umask 022  make install  chown -R root:sys /usr/local/apache2 

After Apache is installed, we should make sure that only the following modules are enabled:

 

/usr/local/apache2/bin/httpd -l  Compiled in modules:    core.c    mod_access.c    mod_auth.c    mod_log_config.c    prefork.c    http_core.c    mod_mime.c    mod_dir.c 

Configuring Apache

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:

 

 # =================================================  # Basic settings  # =================================================  Listen 0.0.0.0:80  User apache  Group apache  ServerAdmin webmaster@www.ebank.lab  UseCanonicalName Off  ServerSignature Off  HostnameLookups Off  ServerTokens Prod  ServerRoot "/usr/local/apache2"  DocumentRoot "/www"  PidFile /usr/local/apache2/logs/httpd.pid  ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard  <IfModule mod_dir.c>      DirectoryIndex index.html  </IfModule>  # =================================================  # HTTP and performance settings  # =================================================  Timeout 300  KeepAlive On  MaxKeepAliveRequests 100  KeepAliveTimeout 15  <IfModule prefork.c>      MinSpareServers 5      MaxSpareServers 10      StartServers 5      MaxClients 150      MaxRequestsPerChild 0  </IfModule>  # =================================================  # Access control  # =================================================  <Directory />  Options None      AllowOverride None      Order deny,allow      Deny from all  </Directory>  <Directory "/www/www.ebank.lab">      Order allow,deny      Allow from all  </Directory>  <Directory "/www/www.test.lab">      Order allow,deny      Allow from all  </Directory>  # =================================================  # MIME encoding  # =================================================  <IfModule mod_mime.c>      TypesConfig /usr/local/apache2/conf/mime.types  </IfModule>  DefaultType text/plain  <IfModule mod_mime.c>      AddEncoding x-compress .Z      AddEncoding x-gzip .gz .tgz      AddType application/x-compress .Z      AddType application/x-gzip .gz .tgz      AddType application/x-tar .tgz  </IfModule>  # =================================================  # Logs  # =================================================  LogLevel warn  LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined  LogFormat "%h %l %u %t \"%r\" %>s %b" common  LogFormat "%{Referer}i -> %U" referer  LogFormat "%{User-agent}i" agent  ErrorLog /usr/local/apache2/logs/error_log  CustomLog /usr/local/apache2/logs/access_log combined  # =================================================  # Virtual hosts  # =================================================  NameVirtualHost *  <VirtualHost *>      DocumentRoot "/www/www.ebank.lab"      ServerName "www.ebank.lab"      ServerAlias "www.e-bank.lab"      ErrorLog logs/www.ebank.lab/error_log      CustomLog logs/www.ebank.lab/access_log combined  </VirtualHost>  <VirtualHost *>      DocumentRoot "/www/www.test.lab"      ServerName "www.test.lab"      ErrorLog logs/www.test.lab/error_log      CustomLog logs/www.test.lab/access_log combined  </VirtualHost> 

Compared to the default configuration file, the following important changes have been made:

 

  • The number of enabled modules has been reduced to minimum.
  • Apache's processes (except for the root process) are set to be executed with unique regular user/group privileges.
  • Apache discloses the least information about itself as possible.
  • Access rights to the website's content are set to be more restrictive.

According to our functionality requirements, the above configuration assumes that there are two virtual hosts supported by Apache:

 

  • www.ebank.lab (alias: www.e-bank.lab)
  • www.test.lab

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:

 

mkdir -p /www/www.ebank.lab mkdir -p /www/www.test.lab echo "<html><head><title>eBank.lab</title></head><body>eBank.lab       works!</body></html>" > /www/www.ebank.lab/index.html echo "<html><head><title>test.lab</title></head><body>Test.lab       works!</body></html>" > /www/www.test.lab/index.html chmod -R 755 /www  chown -R root:sys /www 

We must also prepare directories for storing our log files:

 

mkdir -p /usr/local/apache2/logs/www.ebank.lab  mkdir -p /usr/local/apache2/logs/www.test.lab  chmod -R 755 /usr/local/apache2/logs  chown -R root:sys /usr/local/apache2/logs 

Finally, we can try to run Apache, and test if everything works properly:

 

/usr/local/apache2/bin/apachectl start

If the www.ebank.lab website is accessible from a web browser, we can shutdown Apache:

 

/usr/local/apache2/bin/apachectl stop 

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:

 

truss /usr/local/apache2/bin/httpd 

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:

 

mkdir -p /chroot/httpd/dev  mkdir -p /chroot/httpd/etc  mkdir -p /chroot/httpd/var/run  mkdir -p /chroot/httpd/usr/lib  mkdir -p /chroot/httpd/usr/libexec  mkdir -p /chroot/httpd/usr/local/apache2/bin  mkdir -p /chroot/httpd/usr/local/apache2/lib  mkdir -p /chroot/httpd/usr/local/apache2/logs/www.ebank.lab  mkdir -p /chroot/httpd/usr/local/apache2/logs/www.test.lab  mkdir -p /chroot/httpd/usr/local/apache2/conf  mkdir -p /chroot/httpd/usr/local/lib  mkdir -p /chroot/httpd/www 

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:

 

chown -R root:sys /chroot/httpd  chmod -R 0755 /chroot/httpd

Next, we will create the special device file, /dev/null:

 

ls -al /dev/null    crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null  mknod /chroot/httpd/dev/null c 2 2  chown root:sys /chroot/httpd/dev/null  chmod 666 /chroot/httpd/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 :

 

syslogd_flags="-l /chroot/httpd/dev/log" 

In order for the changes to take effect, we also need to restart the syslogd daemon with the new parameter:

 

kill `cat /var/run/syslog.pid`  /usr/sbin/syslogd -ss -l /chroot/httpd/dev/log 

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:

 

cp /usr/local/apache2/bin/httpd /chroot/httpd/usr/local/apache2/bin/  cp /usr/local/apache2/lib/libaprutil-0.so.9 /chroot/httpd/usr/local/apache2/lib/  cp /usr/local/apache2/lib/libapr-0.so.9 /chroot/httpd/usr/local/apache2/lib/  cp /usr/local/apache2/conf/mime.types /chroot/httpd/usr/local/apache2/conf/  cp /usr/local/apache2/conf/httpd.conf /chroot/httpd/usr/local/apache2/conf/  cp /usr/local/lib/libexpat.so.4 /chroot/httpd/usr/local/lib/  cp /usr/lib/libc.so.5 /chroot/httpd/usr/lib/  cp /usr/lib/libcrypt.so.2 /chroot/httpd/usr/lib/  cp /usr/lib/libm.so.2 /chroot/httpd/usr/lib/  cp /usr/libexec/ld-elf.so.1 /chroot/httpd/usr/libexec/  cp /var/run/ld-elf.so.hints /chroot/httpd/var/run/  cp /etc/hosts /chroot/httpd/etc/  cp /etc/nsswitch.conf /chroot/httpd/etc/  cp /etc/resolv.conf /chroot/httpd/etc/  cp /etc/group /chroot/httpd/etc/  cp /etc/master.passwd /chroot/httpd/etc/passwords 

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:

 

cd /chroot/httpd/etc  pwd_mkdb -d /chroot/httpd/etc passwords  rm -rf /chroot/httpd/etc/master.passwd 

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:

 

cp -R /www/* /chroot/httpd/www/ 

and test if the Apache web server runs correctly:

 

chroot /chroot/httpd /usr/local/apache2/bin/httpd 

Final steps

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:

 

#!/bin/sh  CHROOT=/chroot/httpd  HTTPD=/usr/local/apache2/bin/httpd  PIDFILE=/usr/local/apache2/logs/httpd.pid  echo -n " apache"  case "$1" in  start)        /usr/sbin/chroot $CHROOT $HTTPD        ;;  stop)        kill `cat ${CHROOT}/${PIDFILE}`        ;;  *)        echo ""        echo "Usage: `basename $0` {start|stop}" >&2        exit 64        ;;  esac  exit 0 

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:

 

chown root:sys /usr/local/etc/rc.d/apache.sh  chmod 711 /usr/local/etc/rc.d/apache.sh 

Summary

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.

Relevant links

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.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Sep 25, 2010 03:11 PM

Hi guys,

This howto is great but there's just a little problem with the end of lines...

Regards,

DL

Related Entries and Links

No Related Resource entered.