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