Table of Contents
This section of the FAQ describes some useful tricks when using the tools bundled with the Network Security Toolkit.
When Nessus peforms its scans, it can perform multiple
tests on multiple hosts simultaneously. This can put a rather
large load on your NST system. If you are running from a
Live CD on a system with too little
RAM, its possible to run out of memory and
lock your system. You can reduce the load by adjusting the
"max_hosts",
"max_checks", and
"be_nice" settings found in the
"/etc/nessus/nessusd.conf" file. The
following snip of the
"/etc/nessus/nessusd.conf" file
demonstrates values one might use to reduce the load:
# Maximum number of simultaneous hosts tested : max_hosts = 3 # Maximum number of simultaneous checks against each host tested : max_checks = 5 # Niceness. If set to 'yes', nessusd will renice itself to 10. be_nice = yes
If you use the Nessus client, you'll be required to
enter a user name and password when you connect to the
Nessus server. By default, you will need to enter
root as the user ID and the value of
NSTCTPASSWD found in
/etc/nst.conf.
This password is not set by the
nstpasswd script which is used to set many
of the encrypted passwords found on they system. The
Nessus client/server installation on the NST requires
a "clear text" password. The Nessus server uses the
value of NSTCTPASSWD found in
/etc/nst.conf. Alternatively, you can use
grep and sed commands to
examine and change it. All changes need to be done PRIOR to
starting up Nessus server.
[root@probe root]# grep NSTCTPASSWD /etc/nst.conf
# - You may want to modify NSTCTPASSWD prior to starting
NSTCTPASSWD="shoth7pheigh"
[root@probe root]# sed -i -e 's/^NSTCTPASSWD=.*/NSTCTPASSWD="NEWPASSWORD"/' /etc/nst.conf
[root@probe root]# grep NSTCTPASSWD /etc/nst.conf
# - You may want to modify NSTCTPASSWD prior to starting
NSTCTPASSWD="NEWPASSWORD"
[root@probe root]#
We discovered that the Nessus daemon now likes to
create very large log and dump files under the
/var/nessus/logs directory. Unfortunately,
this can fill the root RAM file system. This
can cause your NST probe to slow to a crawl or even lock up (the
NST becomes quite unhappy if you run out of space on
/).
In order to prevent this, you will need to modify the
following lines in your
/etc/nessus/nessusd.conf configuration
file. The /etc/nessus/nessusd.conf file is
much larger than shown - we are only showing the portion to be
modified.
# Log file (or 'syslog') : logfile = /var/nessus/logs/nessusd.messages # Shall we log every details of the attack ? log_whole_attack = yes # Log the name of the plugins that are loaded by the server ? log_plugins_name_at_load = no # Dump file for debugging output, use `-' for stdout dumpfile = /var/nessus/logs/nessusd.dump
The trick is to change logfile and
dumpfile settings to
/dev/null. This causes all of the output to
be discarded. We're also going to set
log_whole_attack to
no. The modifed section of the
/etc/nessus/nessusd.conf file would then
look like:
# Log file (or 'syslog') : logfile = /dev/null # Shall we log every details of the attack ? log_whole_attack = no # Log the name of the plugins that are loaded by the server ? log_plugins_name_at_load = no # Dump file for debugging output, use `-' for stdout dumpfile = /dev/null
Unfortunately, this condition was not detected until after the 1.2.0 release of the NST. In future releases, you will only need to edit this configuration file if you need to enable the logging or dump features.
It is possible to run Nessus within the NST Virtual Machine. This has several advantages over a Live CD boot (permanent disk storage for one). However, there is apparently a big performance hit as shown in the output below:
[root@nic /]#service nessusd startStarting Nessus services: **** This host seems to be running under VMware. **** Nessus performance is abysmal when running under VMware **** We do not recommand you use this setup in production [ OK ][root@nic /]#
After setting up Nessus on a NST probe with the local rule set, one may decide that they would like to register their Nessus installation. This will greatly increase the number of rules Nessus will have at its disposal. In order to register your Nessus installation, you will need to request a registration code from the Nessus web site (http://www.nessus.org). You will then need to run the nessus-fetch command as shown below:
[root@nic /]#nessus-fetch --register 9732-2C31-316C-7C06-5A32Your activation code has been registered properly - thank you. Now fetching the newest plugin set from plugins.nessus.org... Your Nessus installation is now up-to-date. Make sure to call regularly use the command 'nessus-update-plugins' to stay up-to-date To automate the update process, please visit <http://www.nessus.org/documentation/index.php?doc=cron>[root@nic /]#
Alternatively, one can use the NST WUI. The NST WUI allows one to specify their activation code when updating the Nessus rules. The activation code only needs to be specified the first time one updates their rules (leave the field blank on subsequent updates).
There are several ways to keep you Nessus plugins up to date.
Set up Inprotect on your system (it will update the Nessus plugins for you each night).
Run the nessus-update-plugins to manually update the plugins.
Add a cron entry, or symbolic link to run the nessus-update-plugins automatically (NOTE: the crond service must be running). The following would enable the updates once per day.
[root@nic ~]ln -s /usr/local/sbin/nessus-update-plugins /etc/cron.daily[root@nic ~]service crond startStarting crond: [ OK ][root@nic ~]
These instructions have never been fully verified, but should be enough to get one started. If you find that the instructions work for you (or if your find errors in these instructions), please let us know on the NST Forum.
The 3.0.4 version of Nessus has a license which prevents it from being included in the NST distribution. If you would like to install this newer version of Nessus on your system, here are the recommended steps:
From the Nessus web site (http://www.nessus.org), you will need to
download the
Nessus-3.0.4-fc5.i386.rpm for a
1.5.0 release of the NST (if you have a
1.4.X release of the NST, look for the
Fedora Core 4 version of the
RPM).
Copy the RPM file to the
/tmp directory on your NST
probe.
Run the following commands to extract the RPM, update the shared library search path, and your PATH settings.
[root@nic ~]#cd /[root@nic /]#rpm2cpio /var/nst/Nessus-3.0.4-fc5.i386.rpm | \ cpio --extract --make-directories76507 blocks[root@nic /]#echo "/opt/nessus/lib" >| /etc/ld.so.conf.d/nessus.conf[root@nic /]#ldconfig[root@nic /]#export PATH="/opt/nessus/sbin:/opt/nessus/bin:${PATH}";[root@nic /]#
If you're working with a hard disk installation of
the NST, you may want to replace the old nessus
executables (under /usr/local/sbin
and /usr/local/bin) with symbolic
links to the new executables found under
/opt/nessus/sbin and
/opt/nessus/bin. This should only be
required if you plan on using Nessus through the
NST WUI.
Follow the installation instructions at the Nessus web site to finish your installation.
This is only recommended after performing a hard disk installation of the NST.
Paul introduced a bug in the
start_nessusd script, which prevents it
from working properly if the -rdir
DIRECTORY option is omitted. These instructions
allow users of the 1.2.2 release to work around the bug which
was introduced.
The start_nessusd script included in the 1.2.2 release of the NST has a bug which prevents it from automatically creating a RAM disk at the time of invocation. There are two different ways to work around this particular bug.
You can use the create_ramdisk
command to allocate your RAM disk prior
to starting the Nessus server. You then use the
-rdir DIRECTORY option to the
start_nessusd script to indicate the
location of the RAM disk. The following
example creates a 96MB RAM disk mounted
at /mnt/ram5 and then instructs
start_nessusd to make use of it:
[root@probe root]# create_ramdisk -s 96 -d /dev/ram5
*** Successfully created a 98304KB RAM Disk: "/dev/ram5" at mount point: "/mnt/ram5"...
[root@probe root]# start_nessusd -v -rdir /mnt/ram5
... A lot of output (which has been omitted from this document) ...
*** Starting up nessusd...
/usr/local/sbin/nessusd -D
All plugins loaded
nessusd successfully started...
[root@probe root]#
Instead of allocating a RAM disk,
use the /dev/shm memory device (that
has at least 160MB free), or an existing disk partition
(that has at least 96MB free).
You can use the df command to check
the amount of space left on particular directory. For
example, the command sequence below shows that there is
enough space available on /dev/shm, but
not on /var and then invokes
startup_nessus making use of
/dev/shm.
[root@probe root]# df -m /dev/shm
Filesystem 1M-blocks Used Available Use% Mounted on
none 252 0 252 0% /dev/shm
[root@probe root]# df -m /var
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/ram1 62 29 34 46% /
[root@probe root]# start_nessusd -v -rdir /dev/shm
... A lot of output (which has been omitted from this document) ...
*** Starting up nessusd...
/usr/local/sbin/nessusd -D
All plugins loaded
nessusd successfully started...
[root@probe root]#
You can include the
-rdir /dev/shm on
Options line in the NST Web based
User Interface (if you are managing the NST probe via a
web browser).
More free space is required if
/dev/shm is used, as it is also used
for the temporary retrieval of updates for
Nessus.