Apache Security - Ivan Ristic [16]
Apache backdoors do not need to open new ports since they can reuse the open port 80. A small fragment of code will examine incoming HTTP requests, opening "the door" to the attacker when a specially crafted request is detected. This makes Apache backdoors stealthy and dangerous.
A quick search on the Internet for "apache backdoor" yields three results:
http://packetstormsecurity.org/UNIX/penetration/rootkits/apachebd.tgz
http://packetstormsecurity.org/advisories/b0f/mod_backdoor.c
http://packetstormsecurity.org/web/mod_rootme-0.2.tgz
The approach in the first backdoor listed is to patch the web server itself, which requires the Apache source code and a compiler to be available on the server to allow for recompilation. A successful exploitation gives the attacker a root shell on the server (assuming the web server is started as root), with no trace of the access in the log files.
The second link is for a dynamically loadable module that appends itself to an existing server. It allows the attacker to execute a shell command (as the web server user) sent to the web server as a single, specially crafted GET request. This access will be logged but with a faked entry for the home page of the site, making it difficult to detect.
The third link is also for a dynamically loadable module. To gain root privileges this module creates a special process when Apache starts (Apache is still running as root at that point) and uses this process to perform actions later.
The only reliable way to detect a backdoor is to use host intrusion detection techniques, discussed in Chapter 9.
* * *
Folder Locations
In this chapter, I will assume the following locations for the specified types of files:
Binaries and supporting files
/usr/local/apache
Public files
/var/www/htdocs (this directory is referred to throughout this book as the web server tree)
Private web server or application data
/var/www/data
Publicly accessible CGI scripts
/var/www/cgi-bin
Private binaries executed by the web server
/var/www/bin
Log files
/var/www/logs
Installation locations are a matter of taste. You can adopt any layout you like as long as you use it consistently. Special care must be taken when deciding where to store the log files since they can grow over time. Make sure they reside on a partition with enough space and where they won't jeopardize the system by filling up the root partition.
Different circumstances dictate different directory layouts. The layout used here is suitable when only one web site is running on the web server. In most cases, you will have many sites per server, in which case you should create a separate set of directories for each. For example, you might create the following directories for one of those sites:
/var/www/apachesecurity.net/bin
/var/www/apachesecurity.net/cgi-bin
/var/www/apachesecurity.net/data
/var/www/apachesecurity.net/htdocs
/var/www/apachesecurity.net/logs
A similar directory structure would exist for another one of the sites:
/var/www/modsecurity.org/bin
/var/www/modsecurity.org/cgi-bin
/var/www/modsecurity.org/data
/var/www/modsecurity.org/htdocs
/var/www/modsecurity.org/logs
Installation Instructions
Before the installation can take place Apache must be made aware of its environment. This is done through the configure script:
$ ./configure --prefix=/usr/local/apache
The configure script explores your operating system and creates the Makefile for it, so you can execute the following to start the actual compilation process, copy the files into the directory set by the --prefix option, and execute the apachectl script to start the Apache server:
$ make
# make install
# /usr/local/apache/bin/apachectl start
Though this will install and start Apache, you also need to configure your operating system to start Apache when it boots. The procedure differs from system to system on Unix platforms but is usually done by creating a symbolic link to the apachectl script for the relevant runlevel (servers typically use run