You can now start the server and check that everything has worked properly. The best way of doing this is through the script called apachectl, located in the $PREFIX/bin (in my case, /usr/local/apache2/bin). This script is “designed to allow an easy command-line interface to controlling Apache” (quoting the script itself ). By running it you will see the options it accepts:

In order to check that the server has actually started, you can run a ps command:

[root@merc httpd-2.0.48]# ps ax | grep httpd
17072 ?     S 0:00   /usr/local/apache2/bin/httpd -k start
17073 ?     S 0:00   [httpd]
17074 ?     S 0:00   [httpd]
17075 ?     S 0:00   [httpd]
17076 ?     S 0:00   [httpd]
17077 ?     S 0:00   [httpd]
17079 pts/2 S 0:00   grep httpd
[root@merc httpd-2.0.48]#

A better way of checking it is through its log file:

[root@merc httpd-2.0.48]# tail -f
/usr/local/apache2/logs/error_log
[Sun Aug 03 14:30:24 2003] [notice] Digest: generating secret for digest authentication ...
[Sun Aug 03 14:30:24 2003] [notice] Digest: done
[Sun Aug 03 14:30:24 2003] [notice] Apache/2.0.48 (Unix) DAV/2 configured
-- resuming normal operations

The server is now listening to port 80 on your computer, and waiting for connections...

You should periodically check whether your Apache server is secure or not. To do this by hand can be very hard, as there can be problems that simply slip through. Fortunately, there are several tools for Unix whose sole purpose is testing a server from a security point of view. For example:

• Nessus (http://www.nessus.org). This is probably the best known and most powerful vulnerability assessment tool existing today.
  
• SAINT (http://www.saintcorporation.com/products/saint_engine.html). A commercial assessment tool for Unix.

• SARA (http://www-arc.com/sara/). An assessment tool derived from SATAN (a now obsolete system security tool that came out in 1995). It’s free.

• Nikto (http://www.cirt.net/code/nikto.shtml). A scanner that concentrates exclusively on web servers.

As far as Apache is concerned, the most interesting free solution is Nikto, a tool based on LibWisker(http://www.wiretrip.net/rfp/). In this section I will show you how to install Nikto, and run it against the Apache server you just installed.

First of all, you will need to install Net_SSLeay (http://search.cpan.org/author/SAMPO/Net_SSLeay.pm-1.23), used by Nikto to establish SSL connections. The installation procedure is the same as with any other Perl module:

[root@merc root]# tar xvzf Net_SSLeay.pm-1.23.tar.gz
Net_SSLeay.pm-1.23/
Net_SSLeay.pm-1.23/ptrcasttst.c
[...]
Net_SSLeay.pm-1.23/Credits
Net_SSLeay.pm-1.23/typemap
[root@merc root]# cd Net_SSLeay.pm-1.23
[root@merc Net_SSLeay.pm-1.23]# perl Makefile.PL
Checking for OpenSSL-0.9.6j or 0.9.7b or newer...
[...]
Writing Makefile for Net::SSLeay::Handle
Writing Makefile for Net::SSLeay
[root@merc Net_SSLeay.pm-1.23]# make
cp ptrtstrun.pl blib/lib/Net/ptrtstrun.pl
[...]
chmod 644 blib/arch/auto/Net/SSLeay/SSLeay.bs 
Manifying blib/man3/Net::SSLeay.3pm
[root@merc Net_SSLeay.pm-1.23]# make install
make[1]: Entering directory `/mnt/hda6/home/merc/Net_SSLeay.pm-1.23/Net-SSLeay-Handle-0.50'
make[1]: Leaving directory `/mnt/hda6/home/merc/Net_SSLeay.pm-1.23/Net-SSLeay-Handle-0.50'
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Writing /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Net/SSLeay/.packlist
Appending installation info to /usr/lib/perl5/5.8.0/i386-linux-thread-multi/perl-local.pod
[root@merc Net_SSLeay.pm-1.23]#

You will need OpenSSL (http://www.openssl.org) for this module to install. You will then need to download and uncompress Nikto:

[root@merc root# tar xvzf ../nikto-current.tar.gz
nikto-1.30/
nikto-1.30/config.txt
nikto-1.30/docs/
nikto-1.30/docs/CHANGES.txt
[...]
nikto-1.30/plugins/servers.db
[root@merc root]# cd nikto-1.30/
[root@merc nikto-1.30]# ls -l
total 20
-rw-r--r--   1 root sys 2999 May 31 06:52  config.txt
drwxrwxrwx   2 root sys 4096 Jun 19 06:17  docs
-rwxr-xr-x   1 root sys 5997 May 31 06:21  nikto.pl
drwxrwxrwx   2 root sys 4096 Jun 19 06:17  plugins
[root@merc nikto-1.30]#

Nikto doesn’t need to be installed: it’s ready to go as soon as you uncompress it. However, two steps are recommended. The first one is downloading the latest LibWisker from http://www.wiretrip.net/rfp/lw.asp. (Although Nikto comes with LibWisker, it may not be the latest version available).

LibWisker comes as a single LW.pm file. Assuming that you downloaded it and placed it in your home directory, you can copy the new LW.pm file over the existing one in Nikto:

[root@merc nikto-1.30]# cd plugins/
[root@merc plugins]# cp ~merc/LW.pm .

cp: overwrite `./LW.pm'? y
[root@merc plugins]#

The second step is to update Nikto’s database with the latest database and vulnerability files available from Nikto’s web sites. You can do this automatically with Nikto’s -update option:

[root@merc nikto-1.30]# ./nikto.pl -update
+ Retrieving 'realms.db'
+ Retrieving 'server_msgs.db'
+ Retrieving 'nikto_headers.plugin'
+ Retrieving 'nikto_httpoptions.plugin'
+ Retrieving 'servers.db'
+ Retrieving 'nikto_core.plugin'
+ Retrieving 'scan_database.db'
+ Retrieving 'outdated.db'
+ Retrieving 'CHANGES.txt'getting:/nikto/UPDATES/1.30/CHANGES
_nikto.txt
+ www.cirt.net message: Please report any bugs found in the 1.30 version
[root@merc nikto-1.30]#

You can now run Nikto, specifying your freshly installed Apache server as the target. In my case, this is the result:

[root@merc nikto-1.30]# ./nikto.pl -host localhost
---------------------------------------------------------
-Nikto 1.30/1.13       -        www.cirt.net
+ Target IP:       127.0.0.1
+ Target Hostname: localhost
+ Target Port:     80
+ Start Time:      Sat Aug 16 21:38:43 2003
---------------------------------------------------------
-Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/2.0.48 (Unix) DAV/2
+ IIS may reveal its internal IP in the Content-Location header. The value is "index.html.en". CAN-2000-0649.
+ Allowed HTTP Methods: GET,HEAD,POST,OPTIONS,TRACE
+ HTTP method 'TRACE' may allow client XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details.
+ /icons/ - Directory indexing is enabled, it should only be enabled for specific directories (if required). If indexing is not used all, the /icons directory should be removed. (GET)
+ /index.html.ca - Apache default foreign language file found. All default filesshould be removed from the web server as they may give an attacker additional system information. (GET)
[...]
+ /index.html.var - Apache default foreign language file found. All default filesshould be removed from the web server as they may give an attacker additional system information. (GET)
+ /manual/images/ - Apache 2.0 directory indexing is enabled, it should only beenabled for specific directories (if required). Apache's manual should be removed and directory indexing disabled. (GET)
+ / - TRACE option appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE) 
+ /manual/ - Web server manual? tsk tsk. (GET)
+ 1688 items checked - 30 items found on remote host
+ End Time: Sat Aug 16 21:41:08 2003 (145 seconds)
[root@merc nikto-1.30]#

Apache was only just installed, and it already has several problems! Nikto pointed out the following issues:

• The method TRACE is enabled; this could lead to cross-site scripting attacks. (Chapter 4 in this book covers this type of attack.) The report points to http://www.betanews.com/whitehat/WHWhitePaper_XST_ebook.pdf (if the link doesn’t work, you should search on Google using the keywords WH-WhitePaper_XST_ebook.pdf or WhitePaper_screen.pdf). It’s a very clear document that explains the issue in detail. Many system administrators consider it a non-issue, because it’s used to tell the clients what they already know. If you want extra peace of mind, disable TRACE (the next section describes how to do this).

• The directories /icons and /manual/images allow indexing. This should be disabled for production servers (remember that both these directories reside under ServerRoot, and not in the machine’s root directory /).

• Apache’s manual is still installed. It should be deleted on production servers for three reasons. The main one is that you don’t want to give away too much information on the server you are running (a cracker can work out at least if you are running Apache 1.3. x or Apache 2.0. x by seeing the manual). Also, you want to be fully in control of what your web server is actually serving. Finally, it’s a matter of style: the presence of the manual often means that the system administrator didn’t spend too long configuring the server properly.

• Several default HTML index pages were found.

Most of the problems came from the fact that absolutely nothing was done after installing Apache—the manual and the default index.html files weren’t even deleted.

Nikto has several more options. You can, for example, enable one or more intrusion detection system (IDS) evasion techniques, or scan a predefined port range, use a proxy server, and so on. Please refer to Nikto’s documentation for more information.

You should keep Nikto handy, and run it periodically (and after any server upgrades). You should also consider using other vulnerability assessment tools as well as Nikto (see Appendix A for a list of some of these tools).

This chapter is from Hardening Apache, by Tony Mobily. (Apress, 2004, ISBN: 1590593782). Check it out at your favorite bookstore today. Buy this book now.

Next: Secure Configuration >>
 

More Apache Articles
More By Apress Publishing

Comments On: Secure Installation and Configuration

· It's amazing to see how many books about security take the installation for granted...   >>> Post your comment now!