Chapter 2 - Debugging NASLs

Abstract

There are two methods of debugging newly created or existing Nessus Attack Scripting Languages (NASLs): one is to use the command-line interpreter and the other is to run it using the Nessus daemon. Each has its shortcomings; for example, running it using the command-line interpreter doesn't allow to debug any interaction between two tests that might be required, while debugging it using the Nessus daemon requires a longer startup process than simply providing the command-line interpreter with a hostname or Internet Protocol (IP) address and the name of the script to execute. Debugging a NASL script can be composed of two main components; the easier part is testing the validity of the code and the difficult part is testing the validity of the vulnerability test itself. Testing the validity of the code (that is, ensuring that the code can be understood by the NASL interpreter) can be done by either running the NASL script with the command-line interpreter accompanied by the option “-p,” which, in essence, instructs the NASL interpreter to just parse and not execute the code found inside it. However, there is more than one approach where external tools, such as packet sniffers, are utilized to determine the type of traffic traversing the medium between the Nessus daemon and the tested host. This chapter also provides a glimpse of the way Nessus communicates with a remote Web server and the way it detects Web servers that support keep-alive.