Cover Your Tracks

Shot Across My Bow

You might find that some defenses stop your scan dead in its tracks (one of my hosts did, I'm pleased to say, after a handful of tests); log analysis tools also might come into play. For example, when I check the daily report generated by the mighty Logwatch [9], which is ideal for a relatively small number of hosts, I am greeted with many alerts. The scanning alerts courtesy of Logwatch are so numerous that there's far too many to display here, but one alert was:

405 Method Not Allowed
     /: 7 Time(s)
     /nikto-test-0kquC9tm.html: 1 Time(s)
     /nikto-test-O7SQXv49.html: 1 Time(s)
     /nikto-test-k19h6AMS.html: 1 Time(s)

The Method Not Allowed error was logged on the server a few times. HTTP response codes in the 400s are generally considered client-side error responses.

In terms of Apache logs, Nikto tries a number of different scans. Figure 2 shows a few such entries.

Figure 2: A taster of the many log entries on Apache after a Nikto scan.

If you're a fan of Apple, take a look at MacNikto (Figure 3) [10], an AppleScript GUI shell script wrapper for Nikto that is released under the GPL.

Figure 3: The gooey version of Nikto for Macs; source: http://www.informationgift.com/macnikto.

The End Is Nigh

Fortunately, a number of highly functional open source security tools are available to anyone that's interested. Many focus on specific areas and follow the "do one thing well" Unix mantra. If you run Nikto yourself, I'm sure you'll appreciate its level of sophistication.

Suffice it to say that I really enjoy the portability of containers, and few arguments hold water against testing your own servers with security tools. The ability to integrate containerized tools like Nikto into DevOps-style continuous integration and continuous delivery tests is also of great benefit.

Remember that sophisticated tools like Nikto can get you into trouble if used inappropriately: Make sure you have permission before running them.