Nessus (NST v1.2.0)

Nessus is a powerful network security scanner which will audit a given host or network and determine if any detected network services are vulnerable or can be misused by an intruder. This tool is much more than a network port scanner, it test for numerous current exploits, and it identifies and test services running on nonstandard ports. Nessus is built using a client/server architecture allowing an entire network segment to be tested and analyzed at once.

An external plug-in architecture is used for each security test plugin. As new tests are developed, they can be added without upgrading the core nessus client/server application. The security plugins are developed in a native nessus language called: NASL (Nessus Attack Scripting Language).

There are a number of ways for the NST user to work with nessus. The command line interface is used to launch the nessusd server daemon. Control of the nessus server can be through the command line or the X Windows interface. Getting fancier, one can also use a Secure Virtual Computing tunnel (Chapter 8, Virtual Computing) to perform a nessus scan remotely. Scan results produced by nessus can be stored in HTML format. Access to these results can be accomplished using the firefox web browser or the Apache web server running on NST.

NST is configured with a startup script for running the nessus application. The first form of the script: /usr/local/sbin/start_nessusd creates a nessus runtime environment along with setting up a file directory structure for the external nessus security test plugins. The nessusd daemon is also started. The second form of this script can be used to terminate the nessusd daemon and optionally remove the external nessus security test plugins.

NST's Web User Interface found in Chapter 2, The Web User Interface (WUI) can also be used to launch this script and run a default scan on a selected host, a number of hosts, or an entire network. Information on how to start nessus via NST's WUI can be found in the section called “Probing With Nessus”.

The following caption displays the documentation usage for the /usr/local/sbin/start_nessusd script:

[root@probe root]# /usr/local/sbin/start_nessusd -h

Usage: start_nessusd -p <local | remote> [-s] [-d] [-rd <RAM device>]
                     [-rds <RAM disk size (MB)>] [-rmp <RAM mount point>]
                     [-rdir <runtime directory>] [-v] [-h]

       start_nessusd -s [-d [-rdir <runtime directory>]] [-v] [-h]

     The first form of this script is used to create a runtime execution
     environment for nessus and start the nessusd daemon. nessus is a powerful,
     up-to-date and easy to use remote security scanner. The default configuration
     will create a 64MB RAM disk for nessus and its associated external security
     plugins at directory location: "/mnt/ram4/nessus/plugins".

     The second form of this script is used to terminate a nessusd daemon and
     optionally remove the complete nessus runtime directory.

     Access to scanned results produced by nessus in HTML format can be made
     remotely available via the NST Apache Web Server or viewed locally by the
     firefox web browser.

  -p <local | remote> | --plugins <local | remote>
     This parameter specifies the location for which external security plugins to
     be used for this instance of nessusd. The location can be <local> - security
     plugins found with the NST distribution, or <remote> - use the latest security
     plugins that can be downloaded from the nessus web site.

  -s | --stop
     First form:
     Use this optional parameter to stop an already running nessusd daemon. If this
     option is not used and a nessusd daemon is already in progress, this script will
     terminate normally leaving the existing nessusd daemon running.
     Second form:
     This parameter is used stop a currently running nessusd daemon. The script will
     terminate once the nessusd daemon is stopped.

  -d | --delete
     First form:
     Use this optional parameter to delete a previous nessus runtime directory file
     structure (plugins) prior to starting up the nessusd daemon.
     Second form:
     Use this optional parameter to delete a previous nessus runtime directory file
     structure (plugins) when terminating a nessusd daemon.

  -rd <RAM device> | --ram-device <RAM device>
     Use this optional parameter to change the default RAM device that will be used
     for this instance of nessusd. The available RAM device names on NST are:
     "/dev/ram0 - /dev/ram9". A cooresponding mount point: "/mnt/ram0 - /mnt/ram9"
     will be automatically selected for the RAM device. One can use the following
     optional parameter: "-rmp <mount point>" to change mount point location for the
     selected RAM device.
     Default: "/dev/ram4"

  -rds <RAM dsk size (MB)> | --ram-disk-size <RAM disk size (MB)>
     Use this optional parameter to change the default RAM disk size in MegaBytes (MB)
     that will be used for nessus and the external security plugins.
     Default: "64"
     ** Note: Use a reasonable value and make sure you to not exceed your available
              system RAM. The system memory utility: "free" can be used to help make
              your determination.

  -rmp <mount point> | --ram-mount-point <mount point>
     Use this optional parameter to change the selected RAM device's: "-rd <RAM device>"
     mount point for nessus and the external security plugins.
     Default: "/mnt/ram4"

  -rdir <runtime directory> | --runtime-directory <runtime directory>
     First Form:
     One can use this optional parameter to force the setup script to use an existing
     directory on a locally attached disk drive or a mounted network file system and
     bypass the creation of a RAM disk. To do this, make sure the directory initially
     exists prior to running this script.
     Example:  Mount Point: "/dev/hda1" mount at: "/probe1" type ext3 (rw)
                 Directory: "/probe1/nessus_scan_data"
                       Use: "-rdir /probe1/nessus_scan_data" to create the top level
                            runtime directory structure for nessus and the external
                            security plugins.
       Directory Structure: nessus  => /probe1/nessus_scan_data/nessus
                            plugins => /probe1/nessus_scan_data/nessus/plugins
     Second form:
     Use this optional parameter with the delete nessus file directory structure
     option (-d or --delete) for the location of the nessus runtime directory to
     remove when terminating a nessesd daemon.

  -v | --verbose
     This optional switch will enable verbose output. Without this switch set, minimal
     output from the execution of this script will be displayed.

  -h | --help
     Displays this help information.

      

One can chose to either use the external security plugins that come with the NST distribution or select the latest plugins from the Nessus web site. Internet access will be required for obtain the remote external security plugins.

Lets show an example of starting up a nessusd server daemon using local external security plugins, creation of a 72 MByte RAM disk using device: /dev/ram9, and enable verbose mode during script execution.

[root@probe root]# /usr/local/sbin/start_nessusd -p local -rd /dev/ram9 -rds 72 -v

*** Creating a 72MByte RAM disk at mount point: "/mnt/ram9"...
/root/bin/create_ramdisk -s 72 -d /dev/ram9 -m /mnt/ram9 -v

============================================================
= Creating a 73728KB RAM disk at mount point: /mnt/ram9... =
============================================================

*** Zeroing out RAM device: "/dev/ram9"...
/bin/dd if=/dev/zero of=/dev/ram9 bs=1k count=73728
73728+0 records in
73728+0 records out

*** Creating a 73728KB Linux ext2 file system on RAM device: "/dev/ram9"...
/sbin/mke2fs -vm 0 /dev/ram9 73728
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
18432 inodes, 73728 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
9 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

*** Mounting RAM disk device: "/dev/ram9" at mount point: "/mnt/ram9"...
/bin/mount -t ext2 /dev/ram9 /mnt/ram9

*** Show all current mounts...
/bin/df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/ram                 63461     31505     31956  50% /
none                    127024         0    127024   0% /dev/shm
/dev/cdrom              473440    473440         0 100% /mnt/cdrom
/dev/ram9                71395        13     71382   1% /mnt/ram9

*** Successfully created a 73728KB RAM Disk: "/dev/ram9" at mount point: "/mnt/ram9"...


Creating a nessus user: root...
printf "root\npass\n********\n********\ndefault accept\n" | /usr/local/sbin/nessus-adduser 2>&1 | /bin/grep 'user added.'
Is that ok ? (y/n) [y] user added.

*** Successfully added a nessus user: root...


*** Extracting NST local nessus external security plugins to : /mnt/ram9/nessus/plugins...
/bin/tar -C /mnt/ram9/nessus -xj -f /usr/local/lib/nessus/plugins/nessus_plugins.tar.bz2

*** Creating a new quick nessus SSL certificate...
/usr/local/sbin/nessus-mkcert -q

*** Successfully generated a quick nessus SSL certificate...

*** Starting up nessusd...
/usr/local/sbin/nessusd -D

nessusd successfully started...

[root@probe root]# ps -ef | grep nessusd
root      1286     1  0 08:31 ?        00:00:00 nessusd: waiting for incoming connections
[root@probe root]# 

    

At this point one can now perform security scans using this NST host as a nessus server.

The screen shot below (Figure 3.6, “Nessus X Client (NST v1.2.0)”) shows the nessus X client rendered by a VNC client on a Windows XP desktop.

Figure 3.6. Nessus X Client (NST v1.2.0)

Nessus X Client (NST v1.2.0)

Note:

The NessusWX client for Win32 can also be used to attach to a nessusd server daemon running on a NST probe for security scanning sessions.