Security Testing your Apache Configuration with Nikto

Want to support HowtoForge? Become a subscriber!
 
Submitted by xenlab (Contact Author) (Forums) on Fri, 2006-08-11 06:44. :: Apache | Security

Security Testing your Apache Configuration with Nikto

Introduction

By now you've got the perfect setup for your new Ubuntu 6.0.6 (Dapper Drake) box. You may have even followed the excellent Intrusion Detection and Prevention with BASE and Snort tutorial. And as an added precaution you installed DenyHosts to prevent hack attempts via ssh. But now that you've got your new LAMP server on the internet, how can you tell that your new web server is secure? You test it, of course!

This tutorial, inspired by one of the chapters in Hardening Apache by Tony Mobily (APress), will show you how to set up the free web server security scanner tool, Nikto. This tool will probe your Apache set-up for vulnerabilities, so you can get an idea of what holes may exist in your configuration. This tutorial will only get you so far as installing the tool, and running your first scan. A google search or the afore mentioned book will give you plenty of information on actually securing your Apache server.

Remember, only scan servers you own or that you have permission to scan, or you could easily risk legal action and jail time.

Let's get started.

1.1 Installing Net_SSLeay

Net_SSLeay is a Perl Module that adds the ability to connect over SSL connections. The latest version is 1.30 (as of this writing), and can be downloaded from the CPAN repository. This will be required by Nikto if you plan on testing SSL enabled servers.

I generally create a /src directory to download all my source files into, and will be doing that first.

mkdir /src
cd /src

Now we can download the Net_SSLeay Perl Module source:

wget http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Net_SSLeay.pm-1.30.tar.gz

Once it finishes downloading, let's extract it and enter the unarchived folder:

tar -xzvf Net_SSLeay.pm-1.30.tar.gz
cd ./Net_SSLeay.pm-1.30

Now, Let's install this module with a few simple commands:

perl Makefile.PL
make
make install

1.2 Installing Nikto

First we download the latest version of Nikto. This can be retrieved from the web site of the security experts that wrote the software at CIRT.net.

Go back to the /src directory:

cd /src

And now get the Nikto software (current version 1.35, but the link below should always download the latest stable release), unarchive it:

wget http://www.cirt.net/nikto/nikto-current.tar.gz
tar -xzvf nikto-current.tar.gz

Nikto is built on top of rfp's LibWhisker (for all of it's base network functionality). It's included with Nikto, but let's go ahead and update it to the latest version (of the 1.x branch).

wget http://www.wiretrip.net/rfp/libwhisker/LW.pm
cp LW.pm ./nikto-1.35/LW.pm

Since Nikto is just a perl script, it doesn't need to be installed, but we should go ahead and move it to a more permanent location such as /usr/local

mv nikto-1.35/ /usr/local/nikto

Now, let's change into this directory so we can update Nikto's database.

cd /usr/local/nikto
perl nikto.pl -update

1.3 Using Nikto

Now that we're all up to date, let's take it out for a test drive.

The standard test (assuming you've installed Nikto directly on your :

perl nikto.pl -h localhost

When running this test on a standard installation based on the Perfect Set-Up how-to, I found 5 errors. Nothing too critical, 3 out of date notices (Apache, PHP, OpenSSL) and 2 Apache configuration errors (Manual and Icon directories still accessible, letting potential malicious hackers know that you haven't done much to reconfigure Apache).

If you want to give Snort a run for it's money, you can add the -evasion flag, and have it try to sidestep your IDS systems, like so:

perl nikto.pl -h example.com -evasion 1

Substitute example.com in the example above with the URL or IP address of your web server. There are 9 different options for the -evasion flag. 1 is for Random URI encoding (non-UTF8). This scan is decidedly slower, so you may want to go make a sandwich. For more information on the available options that Nikto has to offer, study the README file (located in the ... /nikto/docs/nikto_usage.html, or online).

Conclusion

Security is a state of being, not a state to be achieved. By testing your configurations, you can find holes that you may have missed. However, no tool is a path to a secure system, but only a guide. It is highly recommended that you keep educating yourself and subscribe to security alerts from a respected authority on the subject. Only then will you hope to stay ahead of the baddies, and keep you and your server from being compromised.

Happy Scanning!


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Vivek (not registered) on Sun, 2011-09-11 16:30.

Here is a small article that I have written about Nikto

 http://brainfry.in/administration/scanning-website-vulnerabilities-nikto-examples/

Submitted by Peter (not registered) on Wed, 2011-05-04 13:10.

Keep in mind that although Nikto is an excellent tool it is primarily useful for poor web server configuration and checking for default files and paths that may create vulnerable systems.

 It is one tool to use during a vulnerability assessment but should be used in conjunction with other tools to ensure your systems are secure.

 

Submitted by David A. (not registered) on Wed, 2011-05-11 13:34.
Expanding upon what Peter said above, there are also other Apache tools which could be used to take even more preventative measures to ensure security.
Submitted by Ran2004 (registered user) on Sat, 2006-08-26 11:52.

A simple mod_rewrite rule to disable the TRACE HTTP method:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* [F]

Submitted by Alon Ben David (not registered) on Wed, 2010-10-27 23:41.

Since Apache 2 you can disable trace by adding this line to your Apache configuration:

TraceEnable off 

Don't forget to restart Apache. ;)

Submitted by Anonymous (not registered) on Tue, 2006-08-15 00:01.

That's what I want!

Submitted by Anonymous (not registered) on Sun, 2006-08-13 21:40.

apt-get nikto

There goes two thirds of your howto.

Apart from that, Nikto appears to be searching mostly for PHP cross-site scripting attacks, only reaffirming my reasons not to use that terrible language.

Anyway, it seems to interpret the 500 status codes returned by my Trac site to most of the URL's as meaning that something executed. So it claims all sorts attacks on my site that I know don't exist. Still, it did make me aware of the "TRACE" method.

Submitted by Ran2004 (registered user) on Mon, 2006-08-14 17:17.

apt-get is all fine and well if you don't want control over where it goes and what version you use. In addition it makes you beholden to the package mantainer to keep you in the most up to date versions. Especially for LibWhisker, which should be updated to take advantage of it's performance and bug tweaks.

php is not the issue, it's always the coder that creates insecure code. XSS is even an issue in static pages served by an insecure configuration of Apache. So not only is your statement clearly false, but is a gross misinterpretation of web server security.

I'm glad you got something out of the tutorial. 

Submitted by Anonymous (not registered) on Tue, 2006-08-15 15:43.

"apt-get is all fine and well if you don't want control over where it goes and what version you use. In addition it makes you beholden to the package mantainer to keep you in the most up to date versions."

 I think you've made a mistake in your suggestion there. You should not encourage the use of non-packaged methods for installing software considering the audience your article seems to aim for - beginner as a majority, intermediate at most. You are not dealing with Enterprise solutions here, so suggesting that users should use or compile it for themselves when the main reason for package management is to keep the system clean. If you're encouraging people to maintain the software themselves, they do not get the ciritical updates provided by package managers as and when they are available. Compiling and installing themselves is dangerous if you're a beginner.

Submitted by Ran2004 (registered user) on Fri, 2006-08-18 17:55.

My intended audience was those that have followed along with the other tutorials and wanted to see what kind of system it left them with. Providing them instructions that required them to think about such things as file system storage, updating Libraries, etc. gets them thinking in Linux terms, instead of just parroting Linux commands. This is how people learn (at least I do).

Personally I use apt-get when I'm lazy, or just what to play with a new tool to see what it can do and do for me. Doing things the "long way" or the "hard way" promotes critical thinking skills, and keeps you closer to the metal of your system. I want to know the why and the how to, and humbly tried to supply that in my short howto.

 And I agree with the previous poster. Public servers should not be run without adequate knowledge of what you're doing. These howtos get you up and running, but that's about all. They don't teach you to keep it running and to keep it safe. Only experience and additional training/reading will get you that.