Package: nessusd
Version: 2.2.7-2
Severity: minor
Tags: patch

Found some typos in '/usr/share/man/man8/nessusd.8.gz', see attached '.diff'.

Hope this helps...

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages nessusd depends on:
ii  libc6                         2.3.6-7    GNU C Library: Shared libraries
ii  libnasl2                      2.2.7-2    Nessus Attack Scripting Language, 
ii  libnessus2                    2.2.7-1    Nessus shared libraries
ii  libssl0.9.8                   0.9.8a-8   SSL shared libraries
ii  libwrap0                      7.6.dbs-9  Wietse Venema's TCP wrappers libra
ii  nessus-plugins                2.2.7-1    Nessus plugins
ii  openssl                       0.9.8a-8   Secure Socket Layer (SSL) binary a

nessusd recommends no packages.

-- debconf information excluded
--- nessusd.8   2006-03-21 19:56:59.000000000 -0500
+++ /tmp/nessusd.8      2006-05-11 20:00:18.000000000 -0400
@@ -85,7 +85,7 @@
 .B "-P, --no-plugin-server"
 By default, nessusd starts a 
 .B plugin server
-which is in charge of pre-loading every compiled plugin in memory and 
distribute them among all the nessusd processes. As a result, loading a plugin 
in memory becomes a very inexpensive operation, at the expense of wasting ~ 40 
megs of memory to pre-load them all in binary form. By specifying the -P 
option, it is possible to disable this functionnality and save this amount of 
memory.
+which is in charge of pre-loading every compiled plugin in memory and 
distribute them among all the nessusd processes. As a result, loading a plugin 
in memory becomes a very inexpensive operation, at the expense of wasting ~ 40 
megs of memory to pre-load them all in binary form. By specifying the -P 
option, it is possible to disable this functionality and save this amount of 
memory.
 
 .TP
 .B "-h, --help"
@@ -122,7 +122,7 @@
 
 .IP be_nice
 If this option is set to 'yes', then each child forked by nessusd will
-nice(2) itself to a very low priority. This may speed up your scan as the main 
nessusd process will be able to continue to spew processes, and this garantees 
that nessusd does not deprives other important processes from their resources.
+nice(2) itself to a very low priority. This may speed up your scan as the main 
nessusd process will be able to continue to spew processes, and this guarantees 
that nessusd does not deprive other important processes from their resources.
 
 .IP log_whole_attack
 If this option is set to 'yes', nessusd will store the name, pid, date and 
target of each plugin launched. This is helpful for monitoring and debugging 
purpose, however this option might make nessusd fill your disk rather quickly. 
@@ -147,16 +147,16 @@
 Number of seconds that the security checks will wait for when doing a recv(). 
You should increase this value if you are running nessusd across a slow network 
slink (testing a host via a dialup connection for instance)
 
 .IP non_simult_ports
-Some services (in particular SMB) do not appreciate multiple connections at 
the same time coming from the same host. This option allows you to prevent 
nessusd to make two connections on the same given ports at the same time. The 
syntax of this option is "port1[, port2....]". Note that you can use the KB 
notation of nessusd to designate a service formaly. Ex: "139, Services/www", 
will prevent nessusd from making two connections at the same time on port 139 
and on every port which hosts a web server.
+Some services (in particular SMB) do not appreciate multiple connections at 
the same time coming from the same host. This option allows you to prevent 
nessusd to make two connections on the same given ports at the same time. The 
syntax of this option is "port1[, port2....]". Note that you can use the KB 
notation of nessusd to designate a service formally. Ex: "139, Services/www", 
will prevent nessusd from making two connections at the same time on port 139 
and on every port which hosts a web server.
 
 .IP plugins_timeout
 This is the maximum lifetime, in seconds of a plugin. It may happen that some 
plugins are slow because of the way they are written or the way the remote 
server behaves. This option allows you to make sure your scan is never caught 
in an endless loop because of a non-finishing plugin.
 
 .IP safe_checks
-Most of the time, nessusd attempts to reproduce an exceptional condition to 
detemermine if the remote services are vulnerable to certain flaws. This 
includes the reproduction of buffer overflows or format strings, which may make 
the remote server crash. If you set this option to 'yes', nessusd will disable 
the plugins which have the potential to crash the remote services, and will at 
the same time make several checks rely on the banner of the service tested 
instead of its behavior towards a certain input. This reduces false positives 
and makes nessusd nicer towards your network, however this may make you miss 
important vulnerabilities (as a vulnerability affecting a given service may 
also affect another one).
+Most of the time, nessusd attempts to reproduce an exceptional condition to 
determine if the remote services are vulnerable to certain flaws. This includes 
the reproduction of buffer overflows or format strings, which may make the 
remote server crash. If you set this option to 'yes', nessusd will disable the 
plugins which have the potential to crash the remote services, and will at the 
same time make several checks rely on the banner of the service tested instead 
of its behavior towards a certain input. This reduces false positives and makes 
nessusd nicer towards your network, however this may make you miss important 
vulnerabilities (as a vulnerability affecting a given service may also affect 
another one).
 
 .IP auto_enable_dependencies
-Nessus plugins use the result of each other to execute their job. For 
instance, a plugin which logs into the remote SMB registry will need the 
results of the plugin which finds the SMB name of the remote host and the 
results of the plugin which attempts to log into the remote host. If you want 
to only select a subset of the plugins availaible, tracking the dependencies 
can quickly become tiresome. If you set this option to 'yes', nessusd will 
automatically enable the plugins that are depended on.
+Nessus plugins use the result of each other to execute their job. For 
instance, a plugin which logs into the remote SMB registry will need the 
results of the plugin which finds the SMB name of the remote host and the 
results of the plugin which attempts to log into the remote host. If you want 
to only select a subset of the plugins available, tracking the dependencies can 
quickly become tiresome. If you set this option to 'yes', nessusd will 
automatically enable the plugins that are depended on.
 
 .IP use_mac_addr
 Set this option to 'yes' if you are testing your local network and each local 
host has a dynamic IP address (affected by DHCP or BOOTP), and all the tested 
hosts will be referred to by their MAC address.
@@ -219,7 +219,7 @@
 or
 .I default
 
-In addition to this, the IP adress may be preceded by
+In addition to this, the IP address may be preceded by
 an exclamation mark (!) which means: \*(lqnot\*(rq
 There are three sources of rules:
 
@@ -270,21 +270,21 @@
 Bear in mind that Nessus can be quite network intensive. Even if the
 Nessus developers have taken every effor to avoid packet loss (including
 transparently resending UDP packets, waiting for data to be received
-in TCP connections, etc.) so bandwith use should always be closely monitored, 
-with current server hardware, bandwith is usually the bottleneck in 
-a Nessus scan. It might not became too aparent in the final reports,
+in TCP connections, etc.) so bandwidth use should always be closely monitored, 
+with current server hardware, bandwidth is usually the bottleneck in 
+a Nessus scan. It might not became too apparent in the final reports,
 scanners will still run, holes might be detected, but you will risk to
 run into \fIfalse negatives\fR (i.e. Nessus will not report a security
 hole that is present in a remote host)
 
 Users might need to tune Nessus configuration if running the server in
-low bandwith conditions (\fIlow\fR being 'less bandwith that the one your
+low bandwidth conditions (\fIlow\fR being 'less bandwidth that the one your
 hardware system can produce) or otherwise will get erratic results. There are
 several parameters that can be modified to reduce network load:
 
 .IP checks_read_timeout
 (Introduced in Nessus 0.99.4) The default value is set to 5 seconds, that can
-(should) be increased if network bandwith is low in the
+(should) be increased if network bandwidth is low in the
 nessus.conf or nessusrc configuration files. Notice that it is recommended
 to increase this this value, if you are running a test outside your LAN 
 (i.e. to Internet hosts through an Internet connection), to over 10 seconds.
@@ -292,7 +292,7 @@
 .IP max_threads
 The default value is set to 15 threads, reducing that in
 nessus.conf or nessusrc configuration files.
-will eat less bandwith and also improve performance.
+will eat less bandwidth and also improve performance.
 
 .IP max_hosts
 Number of hosts to test at the same time (this value is set by the Nessus
@@ -300,16 +300,16 @@
 (obviously 1 is the minimum)
 
 .IP max_checks
-Number of checkst to test at the same time (this value is also set by 
+Number of checks to test at the same time (this value is also set by 
 the Nessus GUI client or by .nessusrc ) it can be as low as you want it
 to be and it will also reduce network load and improve performance
 (obviously 1 is the minimum)
 Notice that the Nessus server will spawn max_hosts * max_checks processes.
 
 Other options might be using the QoS features offered by your server
-operating system or your network to improve the bandwith use.
+operating system or your network to improve the bandwidth use.
 
-It is not easy to give a bandwith estimate for a Nessus run, you will
+It is not easy to give a bandwidth estimate for a Nessus run, you will
 probably need to make your own counts. However, assuming you test 65536 
 TCP ports. This will require at least a single packet per port that is 
 at least 40 bytes large. Add 14 bytes for the ethernet header and you 

Reply via email to