Introduction

To really understand Nessus, you have to know how its internal logic works and how it behaves on your network. This chapter describes how each stage of a Nessus scan is performed, with particular attention to the internal programming design of Nessus. Once you understand the logic behind the code, you will find it easier to diagnose problems relating to your scan, to create custom plugins, and to answer questions about why Nessus did or did not find a particular vulnerability. In this chapter, we look at the logical and behavioral guts of Nessus, how it works, and how it scans. We also give you a glimpse on how Nessus uses the Nessus Attack Scripting Language (NASL) to accomplish these tasks. By taking this view, you will end up with a much deeper understanding of Nessus under the hood, and be able to more easily understand where and how additional Nessus plugins should fit into the logic of the program.

Like many other vulnerability assessment tools, Nessus divides the process of detecting vulnerabilities on the network into a few major milestones, where each is dependent on the success of a previous major milestone. This process is further segregated by the plugins themselves. Each plugin that is part of a major milestone might require additional minor milestones to be passed prior to it being successful in testing the vulnerability that it will later report. Behind each major milestone, you can find one or more plugins, depending on the complexity of the major milestones. A major or minor milestone doesn’t necessarily indicate vulnerability. Some of the major and minor milestones used by Nessus are required for the sole purpose of allowing other plugins to detect vulnerabilities; such is the case with Microsoft HotFixes enumeration (this minor milestone is officially called “Installed Windows Hotfixes”). The port-scanning milestone is usually done by a single plugin, while the Microsoft HotFixes enumeration requires about eight or more different plugins to succeed.