The tutorial below is a prerequisite for this mini tutorial. It does have outdated information so I will give you the updated content now. Please read all the new content here all the info in the old tutorial. Life will be much easier for you.

In the Getting The Software Section of the old tut
Go to and follow the instructions for downloading the installation script. This is done in place of using the FTP method mentioned in the tutorial.

For the NessusWX client, the windows front-end to the Nessus engine, go to and download the windows binary. As of this writing 1.4.5b is the latest release.

In the Installation of Nessus Engine Section
Tennable has gone to a licensing model which means that at the end of the installation, it will ask you for a serial number that you must register to receive via e-mail.

Note that the SharUtils RPM must be installed before Nessus will compile properly. Do an rpm qi sharutils before you attempt to install the engine to verify that you have the RPM installed.

Ignore step 3. The Nessus daemon is added in such a way that you can now enable/disable it from the service menu when you type setup at the command line. If at any time you want to fire up Nessus without enabling it to start at boot (it takes the service a long time to fire up because it loads the plugins when you start the process) simply go to /usr/local/sbin and type nessusd D. This will start the process and load the plugins and will not load Nessus the next time you boot. Personally, this is how I do it as I dont need to use Nessus continuously on my lab host.

Mini tut starts here:
Sometimes you may want to tweak or run nasls from the the command line. There are several ways you can go about doing this. Were going to assume you simply want to run a single nasl.

/usr/local/lib/nessus/plugins is where my .nasl files are stored on the Nessus server. In most cases, this is where you will find them unless you used an RPM build of Nessus for installation. There are close to 8,000 plugins in this directory. If you ls this directory, be prepared to see a whole lot of stuff fly by. Its not very practical. I typically use the W32 NessusWX GUI to find a plugin that I want to run/modify and then jump over to the Nessus server to run it at the command prompt. Please do not confuse what Im about to demonstrate as a scheduling a Nessus job on the console.

[root@localhost]#nasl h

nasl -- Copyright (C) 2002 - 2004 Tenable Network Security

Usage : nasl [-vh] [-p] [ -t target ] [-T trace_file] [-SX] script_file ...
-h : shows this help screen
-p : parse only - do not execute the script
-D : run the 'description part' only
-L : 'lint' the script (extended checks)
-t target : Execute the scripts against the target(s) host
-T file : Trace actions into the file (or '-' for stderr)
-s : specifies that the script should be run with 'safe checks' enabled
-v : shows the version number
-S : sign the script
-X : Run the script in 'authenticated' mode.

As you can see, there are just a hand full of options. Most are self explanatory.

We are going to do assume that you want to run the HALO server detection NASL. This is a very simple NASL used to find a HALO game server.

NOTE: Some NASLs have dependencies and may not fire properly when run individually. Keep this in mind when selecting individual NASLs for testing or modifying.

[root@localhost]#pico halo_detection.nasl
# Copyright (C) 2004 Tenable Network Security

  script_version ("$Revision: 1.1 $");

  name["english"] = "HALO Network Server Detection";

  desc["english"] = "
The remote host is running a version of HALO Network Server.
The Server is used to host Internet and Local Area Network (LAN)

Solution: Ensure that this sort of network gaming is in alignment
with Corporate and Security Policies. 

Risk Factor: Low";

  summary["english"] = "Detects HALO Tournament Server";

  script_copyright(english:"This script is Copyright (C) 2004 Tenable Network Security");

  family["english"] = "General";

# start script
port = 2302;

sock = open_sock_udp(port);
if ( ! sock ) exit(0);

send (socket:sock, data:raw_string(0x5C, 0x73, 0x74, 0x61, 0x74, 0x75, 0x73, 0x5C) );

r = recv(socket:sock, length:512, timeout:3);

if ( ! r ) exit(0);

# OK, there are two modes...mode 1 is when the server is actively serving up a game
# in which case you'll get a long verbose reply from the server
# in mode 2, the server is in IDLE state and is not actively serving a game
# in mode 2, the server will just send back a quick 5 byte error msg to client

# mode 1
if (egrep(string:r, pattern:"hostname.*gamever.*maxplayers")) {

# mode 2
if ( (strlen(r) == 5) && (ord(r[0]) == 0xFE) && (ord(r[0]) == 0xFE) ) security_note(port);
For those familiar with PERL regular expressions, youll notice similarities in the NASL (Nessus Attack Scripting Language) language. Looking at this example we can see that it checks port 2302 and establishes a connection. Once connected it sends the string of data expecting a certain response. Within that response the script looks for static values seen in the mode 1 section (hostname, maxplayers, etc.) if the server is in use. In mode 2, if the server is sitting idle, the plugin looks for the error message via raw data strings and the value of 5.

When modifying NASLs to suit a custom need, you must change a few things. The first is the plugin ID. Typically when I modify a NASL, I change the Plugin ID to something in the 50,000 range. If you submit your NASL to Tennable and they publish it, they will assign it a plugin ID typically in the 10,000 19,000 range. Second, the name must obviously change so you dont harm the original (the name field within the NASL and the actual file name). Next, change the script revision number. This is more for completeness rather than need. Make a note to the NASL that you modified it under the copyright section. DO NOT remove the original copyright. You can (and should) modify the plugin description to reflect what it does now. You can also edit the family the plugin belongs to so it can be used as a safe check, destructive test, etc.. All of these values are listed in the above NASL.

Now for some fun:
Lets say that we have reports that someone is running a bunch of HALO gaming servers and an NMAP scan (or whatever scanner) shows that some hosts have something unusual running on port 5400 instead of the default halo port. Simply change the port values as such:

port = 2302;

should read

port = 5400;

and your nasl will now search for halo on port 5400. You can save your nasl as halo_detect_5400.nasl and you can now test it by typing the following on the Nessus server:

[root@localhost]#nasl t halo_detect_5400.nasl T

This tells Nessus to scan host with your modified halo NASL and report the result to the screen. You can send the output to a file if you wish but this is a little quicker.

Now, lets say that you like the results and want to use this NASL in the NessusWX W32 client. Two things must be done. The first is that you must restart the Nessus service so it reads your plugin for use. I typically HUP the service as such:

[root@localhost]#ps ef | grep nessus

root 23875 1 0 04:29? 00:00:00 nessusd:waiting for incoming connections
[root@localhost]# kill HUP 23875

The Nessus service will now restart (takes some time on older hosts) and your plugin will be ready to use.

On the NessusWX client, you must reconnect to the Nessus server once it returns to a normal state. You can search for your plugin using the description or expanding the tree where you identified the family. I simply search for the plugin ID I assigned it and enable it when I get the search results.

At this point you can configure the scan range within the NessusWX client that you wish to let your NASL loose on. Running a single NASL will be fast as all hell (usually) and your results can be seen and manipulated a number of ways.

I hope this mini tut gives you an idea of how to modify, run and include custom NASLs using the nasl command and the NessusWX client.

Any errors, comments, etc., please let me know.