An abundance of security tools tout their wares on the Internet these days, making it difficult to sift the wheat from the chaff. Many such tools are proprietary, some are unquestionably good value for the money, and some tools are overpriced but marketed well. When surrounded by all these options, however, remember that a sizeable number of highly sophisticated open source tools are available as well.

In this article, I'm going to use a Docker container running the sophisticated open source web scanner, Nikto to, among other things, look for files and directories that could potentially be considered security holes. By fixing these misconfigurations or previously unknown issues on your web servers, you can cover your tracks to provide a more robust security posture.

Setting Sail

Nikto [1] holds nothing back and explicitly declares that it's never been designed for stealth. It's an all-out, no holds barred scanner that will leave a noisy footprint. Among Nikto's many features are trying to guess credentials, scanning as quickly as possible, logging to Metasploit [2], replaying findings that flagged an issue, and running over multiple servers or specific network ports.

Rest assured that Nikto is comprehensive. Its scans boast "tests against web servers for … over 6700 potentially dangerous files/programs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers" [3].

However, please be aware that you need permission before scanning a web server. The footprint you'll leave behind will be very obvious: Logfiles will contain a heap of HTTP requests, perhaps hundreds, and you might see some Apache error log entries, too. A number of security findings by Nikto that an owner wouldn't want you to know about will be highlighted, as well, so don't just point the comprehensive tool at a website and hope for the best. Consider yourself suitably warned.

Shipping Containers

Maik Ellerbrock, who goes by "frapsoft" on social media and has a number of GitHub pages, has kindly containerized a number of useful security tools. You can check him out on the GitHub pages for Docker container penetration testing and security tool images [4].

I have opted for the built-in Docker package on Linux Mint (that harks from 16.04 LTS Ubuntu) as opposed to doing things properly with Docker Community Edition (CE). To get started with Docker CE for Debian, you should read the installation notes [5].

To get going in the swiftest possible fashion, I ran the command:

$ apt install docker.io

Before trusting the Docker image, I looked at the Dockerfile (Listing 1) and Docker Hub, per Ellerbrook's GitHub page [6]. As you can see, Nikto uses the Alpine operating system for its base image. A Perl script (nitko.pl) runs on launch.

01 FROM alpine:edge
02 MAINTAINER Maik Ellerbrock (https://github.com/ellerbrock)
03
04 RUN apk update && apk add --no-cache nikto perl-net-ssleay && rm -f /tmp/* /etc/apk/cache/*
05
06 ENTRYPOINT ["nikto.pl"]
07 CMD [ "-Help"]

Next, I pull down the Docker image with the simple command in Listing 2. To see a list of options for Nikto inside the Docker container, just run the container without arguments, which defaults to the -Help option. The command-line output is so easy to read, I just redirect output to a text file with a > at the end of a docker run command.

$ docker pull frapsoft/nikto
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
frapsoft/nikto      latest              e88e5f35b954        15 months ago       56.4MB

Ready the Cannons

As Nikto targets, I used some personal web servers, whose URLs I will redact, for obvious reasons. To scan a particular host, you can use the super-simple command:

$ docker run frapsoft/nikto -host https://chrisbinnie.tld

After a few minutes, Nikto finishes. As you can see in Figure 1, a few alerts have been flagged on my web server. The top issue, the ETags, might be a false positive. As discussed on Stack Exchange, "Nikto reports this issue 'Server leaks inodes via ETags' if there is a dash in the ETag header, which is by itself not an indication of anything." You can check out the full answer online [7].

Figure 1: The mighty Nikto has finished its scanning. Host details are redacted.

For the next finding of interest, X-Frame-Options header is not present , you can find a useful explanation here [8]. If you're not familiar with X-Frame headers, in short, by enabling such a header you're stopping an HTML <IFRAME> being confused with a <FRAME> and therefore reducing the chances of nefarious content being displayed to a visiting browser. This is called "clickjacking." Note that not all web browsers support these headers in the same way; you can find more on that topic on the OWASP page, as well.

Flagrantly skipping some other findings, note that the /linux/ directory has been discovered. I've seen other security tools parse massive lists (thousands of lines long) of common file and directory names to then scan a target web server to see what secrets are potentially hidden on the filesystem. If you're intentionally hiding files in this way you're using what's called "security through obscurity." It's probably okay for a website with pictures of your cat, but it's not really wise to employ this method for any website of greater value.

At the bottom of Figure 1 you can see how long the scan took to run. Another host I checked with Nikto took a little over 13 minutes. This scan only focused on HTTP on port 80 and not HTTPS, although the scan did highlight a TLS certificate, and didn't have much HTML to trawl through.