Introduction

When I initially announced the use of the Nessus Attack Scripting Language (NASL) within Nessus, many users disapproved, since it was not a known language such as Perl or Python. Over time, the use of a dedicated language turned out to be a good design decision, since it gives us, as developers, full control of the virtual machine used by the individual plugins. The use of NASL dramatically simplifies the maintenance of the plugins; bug fixes and enhancements can be applied to the NASL interpreter itself, avoiding the need to modify each and every plugin. For example, each of the network-related functions such as connecting to a system or receiving data from it are defined at the scripting engine level, not the plugin level. If we want to improve the way in which network connections are made, we only need to modify the NASL interpreter, and not the thousands of plugins that use these functions.

In this chapter, I explain why the NASL language was written, how it works, and why it is best suited for vulnerability detection. Then I explain how to write a NASL script for use within Nessus, how the Knowledge Base (KB) can be used, and how the contribution process works if you want to submit your own plugins to the community.

Why NASL?

In 1998, the first version of Nessus was released with around 50 security checks, otherwise known as plugins. These plugins were implemented as shared libraries, written in the C programming language, and renamed...