This flag causes the Nessus GUI GTK client to load without pixmaps. This is handy when running Nessus on a remote computer over an exported X11 session.

Quiet mode or batch mode. This option causes the Nessus client to run from the command-line only (no GUI). This enables Nessus scans to be performed non-interactively from the command-line, cron, or otherwise.

Specify the client-side Nessus configuration file (.nessusrc) to use. This option is only used when starting the "nessus" client.

If the nmap port scanner is selected, this option enables the Nmap service fingerprinting techniques by passing the -sV flag to Nmap when it is called. From the Nmap manual page: Version detection: Afer TCP and/or UDP ports are discovered using one of the other scan methods, version detection communicates with those ports to try and determine more about what is actually running. A file called nmap-service-probes is used to determine the best probes for detecting various services and the match strings to expect. Nmap tries to determine the service protocol (e.g. ftp, ssh, telnet, http), the application name (e.g. ISC Bind, Apache httpd, Solaris telnetd), the version number, and sometimes miscellaneous details like whether an X server is open to connections or the SSH protocol version). If Nmap was compiled with OpenSSL support, it will connect to SSL servers to deduce the service listening behind the encryption. When RPC services are discovered, the Nmap RPC grinder is used to determine the RPC program and version numbers. Some UDP ports are left in the open or filtered state after a UDP scan is unable to determine whether the port is open or filtered. Version detection will try to elicit a response from these ports (just as it does with open ports), and change the state to open if it succeeds. Note that the Nmap -A option also enables this feature. For a much more detailed description of Nmap service detection, read our paper at http://www.insecure.org/nmap/versionscan.html . There is a related --version_trace option which causes Nmap to print out extensive debugging info about what version scanning is doing (this is a subset of what you would get with --packet_trace).

If BOTH SSH local checks and the netstat scanner are enabled, this option will cause Nessus to connect to the open ports detected by netstat and verify they are listening.

By default, the Nessus server will scan a network of IP addresses incrementally. For example, when scanning the 10.0.0.0/24 network the Nessus server would scan 10.0.0.1, then 10.0.0.2, 10.0.0.3 and so on... up to 10.0.0.254. If this option is set to yes, the Nessus server will not scan a network of IP addresses incrementally. Instead, the Nessus server will slice the network of IPs into smaller portions and then rotate between scanning each slice incrementally. Using the same 10.0.0.0/24 example, enabling this option would cause the Nessus server to scan 10.0.0.1, then 10.0.0.127, then 10.0.0.2, then 10.0.0.128 and so on... up to 10.0.0.126 in the first slice and 10.0.0.254 in the second slice.

Many Nessus plugins have dependencies of other plugins to run properly. This option causes the Nessus client to automatically enable plugins that are 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 upon. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

In versions of Nessus 2.1 and newer, some NASL scripts may be cryptographically by the Nessus team. These are called trusted scripts and the signatures are intended to ensure that the version of the script being loaded by the Nessus server is the authentic version from the Nessus team. If the NASL or signature have changed without being re-signed by the Nessus team, the Nessus server will refuse to load and execute these NASL scripts. However, setting the nasl_no_signature_check option to yes causes the Nessus server to bypass checking any script signatures and the Nessus server will load/execute the scripts, regardless of the authenticity of the signatures.

Enter text used to match against the author of plugins. Only the plugins matching the filter will be selected by the Nessus client.

This option is used with the Nessusd server. Make Nessusd display its version number and exit.

Enter text used to match against the ID number of plugins. Only the plugins matching the filter will be selected by the Nessus client.

Enter text used to match against the category of plugins. Only the plugins matching the filter will be selected by the Nessus client.

Enter text used to match against the BugTraq ID (BID) reference of plugins. Only the plugins matching the filter will be selected by the Nessus client.

This option is used with the local security checks functions of Nessus. The value specified here will be used as the user name when establishing an SSH connection to the target host to login and perform local security checks.

This option changes the sensitivity of some plugins to report potential vulnerabilities on the target host. There are three valid values for this option: Normal, Avoid false alarms, and Paranoid (more false alarms).

** DEPRICATED ** This option enables IDS evasion techniques for the libwhisker-based vulnerability tests. Valid options are X (none), 1 Random URI encoding (non-UTF8), 2 Directory self-reference (/./), 3 Premature URL ending, 4 Prepend long random string, 5 Fake parameter, 6 TAB as request spacer, 7 Random case sensitivity, 8 Use Windows directory seperator (), and 9 Session splicing (slow).

This option is used with the local security checks functions of Nessus. The value specified here will be used as the password when establishing an SSH connection to the target host to login and perform local security checks.

This option is used with the local security checks functions of Nessus. The value specified here will be used as the public key when establishing an SSH connection to the target host to login and perform local security checks.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack LDAP authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack telnet authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack FTP authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack POP3 authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack IMAP authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack Cisco authentication.

This option is used with SSL support between the Nessus client and server. Valid options are 1, 2, or 3. The Nessus client has three "levels of paranoia:" (1.) The certificate hash is matched against what was previously stored in .nessusrc.cert. If the certificate was modified (or is brand new), nessus will ask you if you accept it. Please read it *carefully* and answer "yes" or "no". If "no", the connection will be rejected. If "yes", the certificate SHA1 hash will be stored into .nessusrc.cert and nessus will never bother you again with it, EVEN WHEN THE CERTIFICATE BECOMES OUT OF DATE! (2.) The certificate will be accepted IF AND ONLY IF it is signed by a trusted CA. In .nessusrc, trusted_ca should point to the right CA file. Nessus relies entirely upon OpenSSL for all this, and the certificate will be rejected as soon as it is out of date. Use this level if you manage many Nessus servers. (3.) The certificate MUST be accepted by OpenSSL first, i.e. be valid AND signed by a trusted CA. After that, the behaviour looks like level (1). This level is good for paranoid who manage several servers. For more information, see the nessus-core/README_SSL file in the Nessus source distribution.

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to not re-launch any of the DoS (Denial of Service) plugins against the target hosts with valid knowledge base entries. For more information, please see .

This option is used with the Nessus Save Knowledge Base feature. The value specified here will be used by Nessus to determine if a saved knowledge base entry is recent enough to reuse and/or restore. For more information, please see .

This entry lists the version of the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

The Nessus GTK GUI can open a report file from a previous scan and display the report.

This entry lists the method used to manage threads on the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

Enter text used to match against the list of plugins. Only the plugins matching the filter will be selected by the Nessus client.

This button on the GTK GUI Nessus client begins a new Nessus scan with the settings and configurations selected in the client.

Enter text used to match against the CVE reference of plugins. Only the plugins matching the filter will be selected by the Nessus client.

This button causes all of the plugins to be disabled for the scan.

This option is used to upload plugins from the Nessus client to the Nessus server. The uploaded plugins are only used for the current session and are not installed permanently on the nessus server.

Causes the GTK GUI Nessus client to exit and close, killing all active, attached processes and/or sessions.

The TCP port of the listening nessusd process on the Nessus server.

The password for the username used to login to the nessusd process on the Nessus server. See the nessus-adduser(8) manual page for more information about creating users for the Nessus server.

This is the default selection of plugins to use for the scan. This button causes all the plugins to be enabled for the scan, except the plugins considered "dangerous" are specifically disabled.

This button causes all of the plugins to be enabled for the scan.

Enter text used to match against the name of plugins. Only the plugins matching the filter will be selected by the Nessus client.

Enter text used to match against the description of plugins. Only the plugins matching the filter will be selected by the Nessus client.

Enter text used to match against the summary of plugins. Only the plugins matching the filter will be selected by the Nessus client.

During NNTP testing, Nessus will attempt to post test articles to news groups through the target NNTP server. The value specified here will be used as the maximum number of cross-posts Nessus should attempt during NNTP testing.

This option is used when starting the Nessusd server. Make the server display its compilation options.

If the Brute force HTTP Hydra option is enabled, this option specifies the URL of a web page to attempt to brute-force. The URL specified here should require authentication to access.

Some security tests (plugins) may harm the target hosts, by disabling remote services running on the target, or even potentially causing the target hosts to crash. If this happens, it may be necessary to reboot the target hosts to restore them to a sane state after a Nessus scan. Enabling this option will cause Nessus to rely on reported banners from the target hosts instead of actually performing in-depth securtiy tests. From a security perspective, you should disable this option. From a system administrator perspective, you should enable this option. Choose your poison. 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 toward your network, however this may make you miss important vulnerabilities (as a vulnerability affecting a given service may also affect another one). This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack Cisco enable authentication.

If you enable this option, the target hosts on the local network will be designated by their Ethernet MAC address, insteasd of their IP address. This is particularly useful if you are using Nessus in a dynamic DHCP network. If you are unsure about this option, leave it disabled. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the client configuration file will override any server-specified value.

Scanning a network is a time-consuming and bandwidth-hungry process. If the scanning host crashes after a few hours for some reason, you may not want to restart your scan from scratch. Session-saving allows you to restart a scan where you left it, with minor loss of data. The concept of session saving is that every nessusd user is given a home (usually /usr/local/var/nessus/username/) and the transcript of the data sent to the client is stored there. For more information, please see .

This script performs a labrea tarpit scan, by sending a bogus ACK and ACK-windowprobe to a potential host. It also sends a TCP SYN to test for non-persisting labrea machines.

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to only test target hosts which have a recent knowledge base saved on the Nessus server. For more information, please see .

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to restore and use the saved knowledge bases of the target hosts, if they are recent enough.

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to not re-launch port scanners against the target hosts with valid knowledge base entries. The data in the saved knowledge base will be used as the port scan result information. For more information, please see .

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to not re-launch any of the information gathering plugins against the target hosts with valid knowledge base entries. For more information, please see .

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to not re-launch any of the attack plugins against the target hosts with valid knowledge base entries. For more information, please see .

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to always send two sets of slashes in a request. For example, http://1.2.3.4/foo/bar.html would be translated into http://1.2.3.4//foo//bar.html.

This option specifies the amount of time, in seconds, that the Nessus server will wait between launching plugins against a particular target host.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt reverse traversal techniques through the targets web server. This effectively attempts to discover files outside of the servers web space. Valid options are none, Basic, and Long URL.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt HTTP requests with directories that reference themselves. For example, http://1.2.3.4/foo/./bar.html.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt premature request ending techniques.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt CGI.pm semicolon separator techniques.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt parameter hiding techniques.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt sending requests with a DOS/Windows syntax, instead of the typical UNIX-style syntax.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt null method techniques.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack rexec authentication.

This option enables the Nessus integration with the THC Hydra brute-force network authentication cracker. The value listed here will specify the number of simultaneous connection that Hydra will initiate to the target.

If any of the Hydra brute-force options are selected, this option specifies the path (on the Nessus client side) to the file containing a list of usernames for Hydra to use for brute-force attacking the target. The format of this file is one username per line.

If any of the Hydra brute-force options are selected, this option specifies the path (on the Nessus client side) to the file containing a list of passwords for Hydra to use for brute-force attacking the target. The format of this file is one password per line.

If this option is enabled, Nessus will automatically assume that all ports not specifically scanned are in a CLOSED state. This will result in an incomplete audit, but it will reduce scanning time and prevent Nessus from sending packets to ports you did not specify. If this option is disabled, then Nessus will consider ports that were not scanned as OPEN.

If this option is enabled, Nessus will perform a reverse DNS lookup on the target IP addresses before they are tested.

During SMTP testing, Nessus may attempt to send and/or relay email through the target SMTP server. The value specified here will be used as the third party domain for these attempts.

This option is used in conjunction with the Detached Scan option. Enabling this option will cause Nessus to continually scan the target hosts (non-stop, forever) back-to-back. For more information about this feature, see .

This option is used in conjunction with the Detached Scan and Continuous Scan options. When doing continuous scans, Nessus will wait the specified number of seconds between repeated scans. The value specified here is in seconds. For more information about this feature, see .

The value entered here will be used as the SMB domain (SAMBA, Windows file sharing, Windows domain) to login to the target for SMB testing.

This option specifies the path to a file (on the Nessus client side) that contains the CA (certificate authority) for the SSL certificate used to connect to services on the client.

Causes the Nessus client to display its version number then exit.

Enabling this option will cause Nessus to only use the NTLMv2 protocol for all SMB (SAMBA, Windows file sharing, Windows domain) testing.

This option specifies the password of the SMB (SAMBA, Windows file sharing, Windows domain) account used to login to the target for SMB testing.

This option specifies the username of the HTTP account used to login to the target for HTTP testing. The option listed here will become the %USER% variable in the Prefs - HTTP login page - Login form fields setting.

This option specifies the password of the HTTP account used to login to the target for HTTP testing. The option listed here will become the %PASS% variable in the Prefs - HTTP login page - Login form fields setting.

During FTP testing, Nessus may attempt to detect writable directories and/or upload test files to the FTP server. The directory specified here will be used as the upload/writable directory on the target FTP server.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack VNC authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack SOCKS 5 authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack NNTP authentication

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack HTTP authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack ICQ authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack PCNFS authentication.

This option enables Nessus integration with the THC Hydra network authentication brute force cracker. Enabling this option will cause Hydra to attempt to brute-force crack SMB (SAMBA, Windows file sharing) authentication.

This option specifies how Nessus will determine if a directory on the targets FTP server is writable. Valid options are Trust the permissions (drwxrwx---) and Attempt to store a file.

If the HTTP server on the target requires authentication, this option would specify the HTTP path (not the file system path) of the login page. Nessus willl use this page to authentice to the HTTP server before performing testing.

If the HTTP server on the target requires authentication, this option would specify the HTTP form for login. Nessus will use this information to authenticate to the HTTP server before performing testing.

If the HTTP server on the target requires authentication, this option would specify the form field names for login. Nessus will use this information to authenticate to the HTTP server before performing testing. The %USER% and %PASS% variables are defined in the Prefs - Login configurations - HTTP account and HTTP password sections.

This option is used with the Nessus Save Knowledge Base feature. Enabling this option will cause Nessus to only test target hosts which either do not have any, or have an outdated, knowledge base saved on the Nessus server. For more information, please see .

This option is used with the Nikto.pl CGI vulnerability scanning option within Nessus. Enabling this option will cause Nessus to pass the -ssl option to Nikto when it is called. Note that Nikto attempts to determine if a port is HTTP or HTTPS automatically, but this can be slow if the server fails to respond or is slow to respond to the incorrect one. This sets SSL usage for all hosts and ports.

This option is used with the Nikto.pl CGI vulnerability scanning option within Nessus. Enabling this option will cause Nessus to pass the -allcgi option to Nikto when it is called.

** DEPRICATED ** This option is used with the Nikto.pl CGI vulnerability scanning option within Nessus. Enabling this option will cause Nessus to pass the -evasion method flag to Nikto when it is called. Valid options are X (none), 1 Random URI encoding (non-UTF8), 2 Directory self-reference (/./), 3 Premature URL ending, 4 Prepend long random string, 5 Fake parameter, 6 TAB as request spacer, 7 Random case sensitivity, 8 Use Windows directory seperator (), and 9 Session splicing.

This option is used with the Nikto.pl CGI vulnerability scanning option within Nessus. Enabling this option will cause Nessus to pass the -generic option to Nikto when it is called. This forces a full scan rather than trusting the Server: identification string, as many servers allow this to be changed.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt requests with a tab character seperator.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to attempt requests using the HTTP/0.9 format.

This option is used with the NIDS evasion techniques and HTTP/0.9 requests method within Nessus. Setting information here will cause Nessus to always use the specificed protocol string for HTTP NIDS evasion requests.

This option is used with the NIDS evasion techniques within Nessus. Setting information here will cause Nessus to send the specified User-Agent information for all requests.

This option is used with NIDS evasion techniques within Nessus. At this time, this particular option is only supported by the Nikto CGI vulnerability scanner. Selecting this option will cause Nikto to attempt random case sensitivity with HTTP requests in an effort to avoid a NIDS on the target network.

This option specifies the username of the SMB (SAMBA, Windows file sharing, Windows domain) account used to login to the target for SMB testing.

This option specifies the username of the NNTP account used to login to the target for NNTP testing.

This option specifies the password of the FTP account used to login to the target for FTP testing.

This option specifies the password of the IMAP account used to login to the target for IMAP testing.

This option specifies the username of the POP3 account used to login to the target for POP3 testing.

This option specifies the username of the FTP account used to login to the farget for FTP testing.

This option specifies the password of the POP2 account used to login to the target for POP2 testing.

This option specifies the username of the IMAP account used to login to the target for IMAP testing.

This option is used with the Nessusd server. Make the server display a summary of the commands and exit.

If the nmap port scanner is selected, this option causes the range of ports for port scanning to be only the ports listed in the nmap-services file (comes with nmap). From the nmap manual page: This option specifies what ports you want to specify. For example "-p 23" will only try port 23 of the target host(s). "-p 20-30,139,60000-" scans ports between 20 and 30, port 139, and all ports greater than 60000. The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. For IP protocol scanning (-sO), this specifies the protocol number you wish to scan for (0-255). When scanning both TCP and UDP ports, you can specify a particular protocol by preceding the port numbers by "T:" or "U:". The qualifier lasts until you specify another qualifier. For example, the argument "-p U:53,111,137,T:21-25,80,139,8080" would scan UDP ports 53,111,and 137, as well as the listed TCP ports. Note that to scan both UDP & TCP, you have to specify -sU and at least one TCP scan type (such as -sS, -sF, or -sT). If no protocol qualifier is given, the port numbers are added to all protocol lists.

This option specifies the SNMP community name that Nessus will use to authenticate to the SNMP server for testing SNMP-based attacks on the target.

This option specifies the password of the NNTP account used to login to the target for NNTP testing.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to send a fake RST packet when establishing a new TCP connection.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to use the HTTP HEAD method for requests instead of the typical GET method.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to encode URLs using a different character set. Valid options are none, Hex, UTF-16 (double byte), UTF-16 (MS %u), and Incorrect UTF-8.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to always send requests with the specified URI type. Valid options are none, file, gopher, and http.

This option is used with NIDS evasion techniques within Nessus. Selecting this option will cause Nessus to always send requests to the specified URI host. Valid options are none, host name, host IP, random name, and random IP.

This option causes Nessus to implement NIDS evasion techniques for TCP packets. Valid options are none, split, injection, and short ttl.

During NNTP testing, Nessus will attempt to post test articles to news groups through the target NNTP server. The value specified here will be used as the From address in these test postings.

During NNTP testing, Nessus will attempt to post test articles to news groups through the target NNTP server. The value specified here will be used as a regular expression match to find the names of news groups for posting test messages.

During NNTP testing, Nessus will attempt to post test articles to news groups through the target NNTP server. If this option is enabled, Nessus will attempt to limit test NNTP postings for local distribution on the target NNTP server only.

During NNTP testing, Nessus will attempt to post test articles to news groups through the target NNTP server. If this option is enabled, Nessus will attempt to have the test NNTP postings not archived.

This option specifies the password of the POP3 account used to login to the target for POP3 testing.

This option specifies which SSL-based services should be tested on the target. Valid options are All, Known SSL ports, and None.

If the nmap port scanner is selected, this option enables the "Normal" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

If the nmap port scanner is selected, this option enables the "Normal" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

From the nmap manual page: Normally Nmap sends minimalistic packets that only contain a header. So its TCP packets are generally 40 bytes and ICMP echo requests are just 28. This option tells Nmap to append the given number of random bytes to most of the packets it sends. OS detection (-O) packets are not affected, but most pinging and portscan packets are. This slows things down, but can be slightly less conspicuous.

If the nmap port scanner is selected, this option sets the source port number used in scans. From the nmap manual page: Many naive firewall and packet filter installations make an exception in their ruleset to allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection. Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port. Obviously for a UDP scan you should try 53 first and TCP scans should try 20 before 53. Note that this is only a request -- nmap will honor it only if and when it is able to. For example, you can't do TCP ISN sampling all from one host:port to one host:port, so nmap changes the source port even if you used -g.

From the nmap manual page: Specifies the maximum number of scans Nmap is allowed to perform in parallel. Setting this to one means Nmap will never try to scan more than 1 port at a time. It also effects other parallel scans such as ping sweep, RPC scan, etc.

When the "Custom Timing Policy" is selected for the nmap port scanner, this option specifies the initial probe timeout. This is generally only useful when scanning firewalled hosts with -P0. Normally Nmap can obtain good RTT estimates from the ping and the first few probes. The default mode uses 6000.

When the "Custom Timing Policy" is selected for the nmap port scanner, this option specifies the minimum amount of time Nmap must wait between probes. This is mostly useful to reduce network load or to slow the scan way down to sneak under IDS thresholds.

If this option is enabled, Nessus will attempt to query information about the SMB (SAMBA, Windows file sharing, Windows domain) domain during SMB testing.

If the nmap port scanner is selected, this option enables fingerprinting the operating system (OS) of the target host. From the nmap manual page: This option activates remote host identification via TCP/IP fingerprinting. In other words, it uses a bunch of techniques to detect subtleties in the underlying operating system network stack of the computers you are scanning. It uses this information to create a "fingerprint" which it compares with its database of known OS fingerprints (the nmap-os-fingerprints file) to decide what type of system you are scanning. If Nmap is unable to guess the OS of a machine, and conditions are good (e.g. at least one open port), Nmap will provide a URL you can use to submit the fingerprint if you know (for sure) the OS running on the machine. By doing this you contribute to the pool of operating systems known to nmap and thus it will be more accurate for everyone. Note that if you leave an IP address on the form, the machine may be scanned when we add the fingerprint (to validate that it works). The -O option also enables several other tests. One is the "Uptime" measurement, which uses the TCP timestamp option (RFC 1323) to guess when a machine was last rebooted. This is only reported for machines which provide this information. Another test enabled by -O is TCP Sequence Predictability Classification. This is a measure that describes approximately how hard it is to establish a forged TCP connection against the remote host. This is useful for exploiting source-IP based trust relationships (rlogin, firewall filters, etc) or for hiding the source of an attack. The actual difficulty number is based on statistical sampling and may fluctuate. It is generally better to use the English classification such as "worthy challenge" or "trivial joke". This is only reported in normal output with -v. When verbose mode (-v) is on with -O, IPID Sequence Generation is also reported. Most machines are in the "incremental" class, which means that they increment the "ID" field in the IP header for each packet they send. This makes them vulnerable to several advanced information gathering and spoofing attacks.

If the nmap port scanner is selected, this option enables the range of ports for port scanning to be manually specified. From the nmap manual page: This option specifies what ports you want to specify. For example "-p 23" will only try port 23 of the target host(s). "-p 20-30,139,60000-" scans ports between 20 and 30, port 139, and all ports greater than 60000. The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. For IP protocol scanning (-sO), this specifies the protocol number you wish to scan for (0-255). When scanning both TCP and UDP ports, you can specify a particular protocol by preceding the port numbers by "T:" or "U:". The qualifier lasts until you specify another qualifier. For example, the argument "-p U:53,111,137,T:21-25,80,139,8080" would scan UDP ports 53,111,and 137, as well as the listed TCP ports. Note that to scan both UDP & TCP, you have to specify -sU and at least one TCP scan type (such as -sS, -sF, or -sT). If no protocol qualifier is given, the port numbers are added to all protocol lists.

If the nmap port scanner is selected, this option causes the range of ports for port scanning to be nmap's default range. This includes all the ports listed in the nmap-services file (comes with nmap) and all the privileged ports (1-1024). From the nmap manual page: This option specifies what ports you want to specify. For example "-p 23" will only try port 23 of the target host(s). "-p 20-30,139,60000-" scans ports between 20 and 30, port 139, and all ports greater than 60000. The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. For IP protocol scanning (-sO), this specifies the protocol number you wish to scan for (0-255). When scanning both TCP and UDP ports, you can specify a particular protocol by preceding the port numbers by "T:" or "U:". The qualifier lasts until you specify another qualifier. For example, the argument "-p U:53,111,137,T:21-25,80,139,8080" would scan UDP ports 53,111,and 137, as well as the listed TCP ports. Note that to scan both UDP & TCP, you have to specify -sU and at least one TCP scan type (such as -sS, -sF, or -sT). If no protocol qualifier is given, the port numbers are added to all protocol lists.

When the "Custom Timing Policy" is selected for the nmap port scanner, this option specifies the maximum round-trip time (RTT) per nmap probe packet. From the nmap manual page: Specifies the maximum amount of time Nmap is allowed to wait for a probe response before retransmitting or timing out that particular probe. The default mode sets this to about 9000.

If the "Ping the remote host" scanner option is enabled, and the TCP ping method is selected, this setting specifies the TCP ports to attempt to ping on the target.

This option specifies the filesystem path on the Nessus server where it will find information about Nessus users.

This entry lists the version of the operating system of the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

If this option is enabled, the Nessus server will log information about every plugin used during a scan of every target. The information is logged in the nessusd.messages file on the Nessus server. If this option is disabled, then only the beginning and end of the attack is logged, and not the time each plugin takes to execute.

This option specifies the full path and filename to the trusted certificate authority for SSL support between the Nessus client and server. For more information, see the nessus-core/README_SSL file in the Nessus source distribution.

This option specifies the username of the POP2 account used to login to the target for POP2 testing.

If the SNMP Port Scan option is enabled, this setting specifies which UDP or TCP port will be used to try and gather information from the target via SNMP.

If the nmap port scanner is selected, this option enables the "Sneaky" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

If the nmap port scanner is selected, this option enables the "Paranoid" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

If the nmap port scanner is selected, this option uses the TCP connect() method for the port scan. This option is similar to the "Scan Options - Port Scanner - TCP connect() scan" option. Enabling either option will generate the same results. The only difference is that this option uses nmap to port scan, while the other option does the port scan directly from Nessus. Enabling both options is not necessary - it would simply cause the target host to be port scanned twice. Doing so would also make the scan take significantly longer to complete. From the nmap manual page: This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port is not reachable. One strong advantage to this technique is that you do not need any special privileges. Any user on most UNIX boxes is free to use this call. This sort of scan is easily detectable as target host logs will show a bunch of connection and error messages for the services which accept() the connection just to have it immediately shutdown.

If the nmap port scanner is selected, this option uses the SYN scan method for the port scan. This option is similar to the "Scan Options - Port Scanner - SYN scan" option. Enabling either option will generate the same results. The only difference is that this option uses nmap to port scan, while the other option does the port scan directly from Nessus. Enabling both options is not necessary - it would simply cause the target host to be port scanned twice. Doing so would also make the scan take significantly longer to complete. From the nmap manual page: This technique is often referred to as "half-open" scanning, because you do not open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and you wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a non-listener. If a SYN|ACK is received, a RST is immediately sent to tear down the connection (actually our OS kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it.

Enabling this option tells the Nessus server to perform a differential scan for the current set of target hosts. A diff scan does not produce a complete report, but rather just shows what has changed since the last Nessus report. New issues (a new security flaw, a port that has just been opened) can easily be pointed out, and thus they can be resolved more quickly. For more information, please see .

This entry lists the version of libnessus on the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

This entry lists the operating system of the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

If the nmap port scanner is selected, this option causes nmap to try to ICMP echo ping the target before starting the port scan. If the ping fails, nmap will not port scan the target. This option is similar to the "Scan Options - Port Scanner - Ping the Remote Host" option. Enabling either option will generate the same results. The only difference is that this option uses nmap to ping, while the other option does the ping directly from Nessus. Enabling both options is not necessary - it would simply cause the target host to be pinged twice.

If the nmap port scanner is selected, this option enables the "Normal" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

If the nmap port scanner is selected, this option enables the "Polite" timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

When the "Custom Timing Policy" is selected for the nmap port scanner, this option specifies the minimum round-trip time (RTT) per nmap probe packet. From the nmap manual page: When the target hosts start to establish a pattern of responding very quickly, Nmap will shrink the amount of time given per probe. This speeds up the scan, but can lead to missed packets when a response takes longer than usual. With this parameter you can guarantee that Nmap will wait at least the given amount of time before giving up on a probe.

If this option is enabled, the Nessus server will perform a reverse DNS lookup on every target specified, then try to find every possible host in every targets domain. This expanded list of targets will be scanned by the Nessus server.

This entry lists the version of libnasl on the Nessus server. The information here is automatically reported by the Nessus server when the client initially connects. There is no need to manually edit this value.

This option specifies a comma-seperated list of filename suffixes that users will be allowed to upload to the Nessus server as plugins.

This option specifies which language Nessus will use. Valid options are english and french.

This option forces the Nessus client to not check the Nessus server's SSL certificate when connecting.

If the nmap port scanner is selected, this option uses the FIN SYN scan method for the port scan. From the nmap manual page: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

This option will enable plugin #10841. This plugin runs snmpwalk(1) on the TCP and UDP MIB.

If the SNMP Port Scan option is enabled, this option specifies the version of the SNMP protocol to use to connect to the target.

If the SNMP Port Scan option is enabled, this setting specifies whether UDP or TCP will be used to try and gather information from the target via SNMP.

If the nmap port scanner is selected, this option uses the Null scan method for the port scan. From the nmap manual page: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

If the nmap port scanner is selected, this option enables RPC identd scanning. From the nmap manual page: This turns on TCP reverse ident scanning. As noted by Dave Goldsmith in a 1996 BugTraq post, the ident protocol (RFC 1413) allows for the disclosure of the username that owns any process connected via TCP, even if that process didn't initiate the connection. So you can, for example, connect to the http port and then use identd to find out whether the server is running as root. This can only be done with a full TCP connection to the target port (i.e. the -sT scanning option). When -I is used, the remote host's identd is queried for each open port found. Obviously this won't work if the host is not running identd.

If the nmap port scanner is selected, this option enables RPC port scanning. From the nmap manual page: This method works in combination with the various port scan methods of Nmap. It takes all the TCP/UDP ports found open and then floods them with SunRPC program NULL commands in an attempt to determine whether they are RPC ports, and if so, what program and version number they serve up. Thus you can effectively obtain the same info as "rpcinfo -p" even if the target's portmapper is behind a firewall (or protected by TCP wrappers). Decoys do not currently work with RPC scan, at some point nmap may add decoy support for UDP RPC scans.

Enter text used to match against the cross-references (XREF) of plugins. Only the plugins matching the filter will be selected by the Nessus client.

Causes the Nessus client to display a help message, then exit.

If the nmap port scanner is selected, this option uses the FIN scan method for the port scan. From the nmap manual page: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

During SMB (SAMBA, Windows file sharing, Windows domain) testing, Nessus will attempt to enumerate domain users on the target SMB server. The value specified here will be used as the starting user ID (UID) to enumerate.

When the "Custom Timing Policy" is selected for the nmap port scanner, this option specifies the amount of time Nmap is allowed to spend scanning a single host before giving up on that IP. The default timing mode has no host timeout.

This option causes the Nessus client to only use, display, and enable specific plugins that specifically match a filtered pattern.

If the nmap port scanner is selected, this option uses the Xmas Tree scan method for the port scan. From the nmap manual page: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

If the nmap port scanner is selected, this option enables UDP port scanning. From the nmap manual page: This method is used to determine which UDP (User Datagram Protocol, RFC 768) ports are open on a host. The technique is to send 0 byte UDP packets to each port on the target machine. If we receive an ICMP port unreachable message, then the port is closed. Otherwise we assume it is open. Unfortunately, firewalls often block the port unreachable messages, causing the port to appear open. Sometimes an ISP will block only a few specific dangerous ports such as 31337 (back orifice) and 139 (Windows NetBIOS), making it look like these vulnerable ports are open. So don't panic immediately. Unfortunately, it isn't always trivial to differentiate between real open UDP ports and these filtered false-positives. Some people think UDP scanning is pointless. I usually remind them of the recent Solaris rcpbind hole. Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn't matter that 111 is blocked by the firewall. But can you find which of the more than 30,000 high ports it is listening on? With a UDP scanner you can! There is also the cDc Back Orifice backdoor program which hides on a configurable UDP port on Windows machines. Not to mention the many commonly vulnerable services that utilize UDP such as snmp, tftp, NFS, etc. Unfortunately UDP scanning is sometimes painfully slow since most hosts implement a suggestion in RFC 1812 (section 4.3.2.8) of limiting the ICMP error message rate. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. Solaris has much more strict limits (about 2 messages per second) and thus takes even longer to scan. nmap detects this rate limiting and slows down accordingly, rather than flood the network with useless packets that will be ignored by the target machine. As is typical, Microsoft ignored the suggestion of the RFC and does not seem to do any rate limiting at all on Win95 and NT machines. Thus we can scan all 65K ports of a Windows machine very quickly.

Enabling this option will cause Nessus to never send SMB (SAMBA, Windows file sharing, Windows domain) login and password credentials in clear text over the network during testing.

During SMB (SAMBA, Windows file sharing, Windows domain) testing, Nessus will attempt to enumerate domain users on the target SMB server. The value specified here will be used as the ending user ID (UID) to enumerate.

During SMTP testing, Nessus may attempt to send and/or relay email through the target SMTP server. The value specified here will be used as the From address for these attempts.

This option uses Nessus' built-in port scanner with the SYN scan method for the port scan.

If the nmap port scanner is selected, this option uses the SYN FIN scan method for the port scan. From the nmap manual page: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. Unfortunately Microsoft (like usual) decided to completely ignore the standard and do things their own way. Thus this scan type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms. If the scan finds open ports, you know the machine is not a Windows box. If a -sF,-sX,or -sN scan shows all ports closed, yet a SYN (-sS) scan shows ports being opened, you are probably looking at a Windows box. This is less useful now that nmap has proper OS detection built in. There are also a few other systems that are broken in the same way Windows is. They include Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above send resets from the open ports when they should just drop the packet.

This option uses Nessus' built-in port scanner with the TCP Connect() scan method for the port scan.

The values entered here will be used as the target host(s) for Nessus to scan. Multiple targets can be entered as a comma-seperated list (ex. 192.168.1.55,172.16.11.12), a range in the last octet (ex. 192.168.1.55-75), or in CIDR notation (ex. 192.168.1.64/27). In addition to IP addresses, targets can be DNS-resolvable hostnames or IP addresses with virtual hosting names. The latter allows Nessus to scan an IP address that may host many web services for several domains, and direct web-based data to a particular name-based virtual host. The format for this function is IP_Address[Virtual_Domain_Name] (ex. 192.168.1.1[virtual.example.com]).

This option is related to the Target Selection - Save Sessions option. Enabling this option will cause Nessus to save session information about a scan, even if the session is empty. For more information, see .

This option specifies a file path (on the Nessus client side) for a SSL certificate to use to connect toe services on the target.

If the "SNMP port scan" option is enabled, the SNMP community name configured here will be used. This community name is passed to the snmpwalk command to try and gather information about the target via SNMP. See the snmpwalk (1) manual page for more information.

This option specifies a file path (on the Nessus client side) for a private key file for the SSL certificate to be used to connect to services on the target.

If the nmap port scanner is selected, this option causes nmap to fragment IP packets during the port scan in an attempt to bypass some firewall devices. From the nmap manual page: This option causes the requested SYN, FIN, XMAS, or NULL scan to use tiny fragmented IP packets. The idea is to split up the TCP header over several packets to make it harder for packet filters, intrusion detection systems, and other annoyances to detect what you are doing. Note that this option is not yet working on all systems. It works fine for Linux, FreeBSD, and OpenBSD boxes and some people have reported success with other *NIX variants.

This option specifies the PEM password for the SSL certificate/key used to connect to services on the target.

Uses the Nessus client to obtain the list of server and plugin preferences from the Nessus server.

Causes the Nessus client to generate SQL syntax for the output of the '-p' (show plugins on the server) and '-P' (show server/plugin preferences) commands.

Define what format should be used for the report data from a scan. Options are: nbe, html, html_graph, text, xml, old-xml, tex, or nsr.

If the nmap port scanner is selected, this option enables a custom timing policy for the port scanning. From the nmap manual page: These are canned timing policies for conveniently expressing your priorities to Nmap. Paranoid mode scans very slowly in the hopes of avoiding detection by IDS systems. It serializes all scans (no parallel scanning) and generally waits at least 5 minutes between sending packets. Sneaky is similar, except it only waits 15 seconds between sending packets. Polite is meant to ease load on the network and reduce the chances of crashing machines. It serializes the probes and waits at least 0.4 seconds between them. Note that this is generally at least an order of magnitude slower than default scans, so only use it when you need to. Normal is the default Nmap behavior, which tries to run as quickly as possible without overloading the network or missing hosts/ports. Aggressive This option can make certain scans (especially SYN scans against heavily filtered hosts) much faster. It is recommended for impatient folks with a fast net connection. Insane is only suitable for very fast networks or where you don't mind losing some information. It times out hosts in 15 minutes and won't wait more than 0.3 seconds for individual probes. It does allow for very quick network sweeps though.

If the "Ping the remote host" scanner option is enabled, this setting enables the ICMP ping method.

If the nmap port scanner is selected, this option enables the "--osscan_guess" or "--fuzzy" command-line options when nmap is called. If nmap attempts to fingerprint the target's operating system, and is unable to correctly identify it, these options will cause nmap to be more aggressive in trying to identify the remote OS. This option should now be depreciated, as nmap now attempts to guess the remote OS automatically if a good fingerprint match is not discovered. Nessus also has built-in OS fingerprinting (os_fingerprint.nasl). Consider using this plugin in Nessus - it should be less intrusive to the target host.

This option is used with the local security checks functions of Nessus. The value specified here will be used as the private key when establishing an SSH connection to the target host to login and perform local security checks.

If the "Ping the remote host" scanner option is enabled, this setting enables the TCP ping method.

If the Ping the Remote Host scanner option is enabled, and the ICMP ping method is selected, this setting will specify the number of ICMP packets to send to the target host.

This option is used with the local security checks functions of Nessus. The value specified here will be used as the SSH key passphrase when establishing an SSH connection to the target host to login and perform local security checks.

In addition to the Nmap built-in timing policies, Nessus also provides this "auto" policy. Selecting this option causes Nessus to run some network tests on the target attempting to discover its response characteristics. Based on these tests, Nessus will create a custom Nmap timing policy for the target.

The IP address, or hostname, of the system running the Nessus server process (nessusd).

The username to login to the Nessus server (nessusd). See the nessus-adduser(8) manual page for information about creating user accounts for the Nessus server process.

This value defines the SSL version that will be used for all Nessus client/server communications. Setting this option to NONE will disable SSL for all client/server communications (including authentication credentials).

Uses the Nessus client to obtain the list of plugins available on the Nessus server.

It is possible to check for the presence of CGIs in multiple paths (like /cgi, /cgi-bin, /home-cgis, etc...) on the target web server. Nessus will use all the paths specified here to search for CGIs on the target. Multiple paths can be seperated by a colon, in the same format as a standard UNIX $PATH environment variable. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

This option is used in the Nessusd server configuration file (nessusd.conf). Specify the location of the folder containing all of the Nessus plugins that the server will load and use during scanning.

The value specified here will be used as the range of ports to scan during the port scan portion of the Nessus scan. This field allows a special value of "default" which is expanded to the port range of 1-15000. The value specified here is used by either the Nessus built-in port scanner(s), or Nessus will also pass this value with the -p flag to the external nmap port scanner. Of note, for this value to be passed to the external nmap port scanner, the Prefs - Nmap - Port range - User specified range option needs to be selected. To scan alll the TCP ports on the target host, enter "1-65535" in this field. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

Some security tests (plugins) may ask the Nessus server to launch them if, and ONLY if, some information gathered by another security test exists in the Nessus knowledge base, or if a certain port is open. Enabling this option enables this behavior, while disabling this option causes the Nessus server to launch all requested security tests against the target. By default, nessusd does not trust the remote host banners. It means that it will check a webserver claiming to be IIS for Apache flaws, and so on. This behavior might generate false positives and will slow the scan down. If you are sure the banners of the remote host have not been tampered with, you can safely enable this option, which will force the plugins to perform their job only against the services they have been designed to check. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

The Nessus server typically connects to several ports in parallel on the target hosts when performing the scans. However, the Nessus server will not perform any simultaneous connections to the same target host for any TCP port numbers specified in this option (in a comma-seperated list). 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 from making two connections on the same given port(s) 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. For example, "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. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

This option specifies the amount of time, in seconds, that the Nessus server will wait for any given plugin to complete its testing. If the plugin does not finish within this specified time, the Nessus server will kill the process for the timed out plugin. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

Set this option to "yes" if you want to let nessusd users upload their own plugins. Note that the plugins they will upload will end up in their nessusd home directory, so they will not be shared among users (except if the user who uploads the plugins is the one declared in the option "admin_user"). This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

The user listed in this option will upload his plugins into the global nessus plugins directory, and they will be shared by all the other users of the Nessusd server.

This option specifies the path to the rules database that Nessusd will apply to all users of the Nessusd server.

This option specifies the amount of time, in seconds, that the Nessus server will wait for replies from target hosts for each connection from each plugin. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

This option specifies the number of seconds Nessus will wait for a response from a network connection to the target.

This option specifies the number of seconds Nessus will wait for a response from a read or write request to the target.

This option is used when starting the Nessusd server. Force the source IP of the connections established by Nessusd during scanning to . This option is only useful if you have a multi-homed machine with multiple public IP addresses that you would like to use instead of the default one. Example: nessusd -S 192.168.1.1,192.168.1.2,192.168.1.3,192.168.1.4 ...will make nessusd establish connections with a source IP of one among those listed above. For this setup to work, the host running nessusd should have multiple NICs with these IP addresses set.

This option is used when starting the Nessusd server. Tell the server to listen for client connections on the port rather than listening on port 1241/tcp (default).

This option is used when starting the Nessusd server. Make the server run in background (daemon mode).

This option is used in the Nessusd server configuration file (nessusd.conf). Specify the path to the logfile Nessusd should use for logging messages. Optionally, instead of the path to a log file, you can also enter syslog or stderr, causing nessusd to log to either the standard syslog or directly to stderr.

This value is the maximum number of target hosts that the Nessus server will test at the same time (in parallel). This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

This value is the maximum number of security checks that the Nessus server will launch at the same time (in parallel) against each target host. With a minimum value of "1," this setting can be as low as you want it to be and it will also reduce network load and improve performance. Other options might be using the QoS features offered by your server operating system or your network to improve the bandwith use. It is not easy to give a bandwith 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 will send 65536 * (40 + 14) = 3670016 bytes. So for just probing all TCP ports we may need a multitude of this as nmap will try to resend the packets twice if no response is received. A very rough estimate is that a full scan for UDP, TCP and RPC as well as all NASL scripts may result in 8 to 32 MB wrth of traffic per scanned host. This option can be specified in either (or both) the Nessus client configuration file (.nessusrc) and the Nessusd server configuration file (nessusd.conf). The entry in the server configuration file will override any client-specified value.

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 deprive other important processes running on the Nessusd server from their resources.

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 purposes, however this option might make nessusd fill your disk rather quickly.

If this option is set to yes, nessusd will log the name of each plugin being loaded at startup, or each time it receives the HUP signal.

Some plugins might issue messages, most of the time to inform you that something went wrong. If you want to read these messages, set this value to a given file name. If you want to save space, set this option value to /dev/null.

Enabling this option will cause Nessus to TCP ping the target host and report to the plugins knowledge base whether the remote host is dead or alive. The technique used is the TCP ping, that is, this script sends to the remote host a packet with the flag ACK, and the host will reply with a RST. This scanner will also support traditional ICMP ping methods. This option is similar to the "Prefs - Nmap - Ping the remote host" option. Enabling either option will generate the same results. The only difference is that this option uses Nessus built-in functions to ping while the other option uses the Nmap scanner to ping. Enabling both options is not necessary - it would simply cause the target host to be pinged twice.

Enabling this option will cause Nessus to skip scanning a target host if the host shows as a wildcard on some top-level domain(s).

This plugin determines which TCP ports are open on the remote host by utilizing the remote FTP server to attempt to connect to TCP ports. This method is known as the FTP bounce scan technique.

This option is used when starting the Nessusd server. Tell the server to only listen to connections on the address

which is an IP, not a machine name. For instance, "nessusd -a 192.168.1.1" will make nessusd only listen to client connection requests going to 192.168.1.1 This option is useful if you are running nessusd on a gateway and if you don't want people on the outside to connect to your nessusd server. By default, if the "-a" option is not used, Nessusd will listen on all active interfaces.

This option causes some Nessus plugins to perform extra thorough tests.

This option has three possible states: Normal, Quiet, and Verbose. The Normal setting causes plugins to generate the standard amount of information in the reports. The Quiet setting causes plugins to only generate minimal information in the reports. The Verbose setting causes plugins to generate the maximum amount of information in the reports.

This option has four possible states: Normal, Quiet, Verbose, and Debug. The Normal setting causes plugins to generate the standard amount of logging information on the Nessus server. The Quiet setting causes plugins to generate the minimal amount of logging information on the Nessus server. The Verbose setting causes plugins to generate additional logging information on the Nessus server. The Debug setting causes plugins to generate the maximum amount of logging information on the Nessus server.

If the Ping the Remote Host scanner option is enabled, this setting will cause Nessus to include in the report the names/IPs of the targets that successfully responded to the pings.

This option specifies the number of connections, per service, that Nessus will open in parallel to the target.

This option specifies the number of seconds Nessus will wait for a response from a wrapped service on the target.

Enabling this option will cause Nessus to save all of the collected information about the target hosts. The information is saved on the Nessus server and can be re-used in the future for re-scanning the same targets. The knowledge base is the list of information gathered about a tested host. It contains the list of open ports, the operating system type of the host, and many more information. Its first purpose was to reduce the redundancy of the tests, so that a plugin which finds a fact (for instance, a way to log into the remote FTP server) can share its result with the other plugins (for instance, a plugin which needs to log into the remote FTP server will look in the KB if there is a way to do so). After a test, the KB would be freed from memory, and would be rebuilt from scratch during the next test. The idea behind the saving of the knowledge base is to re-use it for another audit, to reduce the bandwidth consumption of a test.

Specify the output file for the Nessus client to create when converting between two report formats. You can use nessus to do conversion between formats used for reports. Nessus can take any NSR or NBE reports and change them into HTML, XML, NSR or NBE reports. Please note that the XML report usually provides more information about the scan than the NSR or NBE formats include in the report. Basically, XML is a merge between the .nbe reports and the .nessusrc configuration file. You won't get extra verbosity or diagnosis info in the XML report, but you'll know which plugins (and which version of these plugins) have been enabled during the scan. For more information on the report formats please read the files nsr_file_format.txt and nbe_file_format.txt provided along with the documentation.

Specify the server-side Nessusd configuration file (nessusd.conf) to use, instead of the standard /usr/local/etc/nessus/nessusd.conf. This option is only used when starting the "nessusd" server process.

Setting this option to 0 disables any debugging code in the Nessus plugins. Setting this option to higher intergers enables additional debugging code in the Nessus plugins. Any additional debugging code in the plugins will be executed by the Nessus server at the time each plugin is run.

During SMB (SAMBA, Windows file sharing, Windows domain) testing, Nessus will attempt to enumerate local users on the target SMB server. The value specified here will be used as the starting user ID (UID) to enumerate.

If the nmap port scanner is selected, this option tells Nmap NOT to randomize the order in which ports are scanned.

During SMB (SAMBA, Windows file sharing, Windows domain) testing, Nessus will attempt to enumerate local users on the target SMB server. The value specified here will be used as the ending user ID (UID) to enumerate.

This option enables the newer (Nessus 2.2.x and greater) NASL implementation of the nmap port scanner. When this option is selected, see the "Prefs - Nmap (NASL wrapper)" options to configure the nmap port scan.

This option will look to the specified file for the results of the nmap port scan. Thus, Nessus will not launch nmap, but rather read a file containing the results of a previously-run nmap session. The act of generating this nmap result file must be done manually, before running the Nessus scan.

During SMTP testing, Nessus may attempt to send and/or relay email through the target SMTP server. The value specified here will be used as the To address for these attempts. This field allows a special variable name called AUTO_REPLACED_IP. If used, that name will be automatically expanded to the IP address of the target.

If the SNMP Port Scan option is enabled, this setting specifies the number of retries snmpwalk will be use to try and gather information from the target via SNMP.

If the SNMP Port Scan option is enabled, this setting specifies the timeout (in seconds) between each attempt by snmpwalk to try and gather information from the target via SNMP.

During testing, Nessus will attempt to identify CGIs on the target web server and send arguments to those CGIs to test for vulnerabilities. However, if Nessus is not able to accurately identify a particular CGI on the target web server, it does not always know what arguments the CGI will, or will not, accept. Enabling this option will cause Nessus to blindly send various POST requests to unidentified CGIs in an attempt to discover vulnerabilities.

If the Ping the Remote Host scanner option is enabled, this setting will cause Nessus to include in the report the names/IPs of the targets that failed to respond to the pings.

During HTTP testing, Nessus will attempt to mirror pages from the target web server. This option specifies the number of unique pages that Nessus should attempt to mirror.

During HTTP testing, Nessus will attempt to mirror pages from the target web server. This option specifies the starting HTTP path that Nessus will use to begin mirroring attempts.

Enabling this option causes the Nessus server to execute plugins deemed experimental against the target.

When using the Nessus command-line client (the '-q' option), this option causes the client to display status messages to the screen.

Specify the input file for the Nessus client to read when converting between two report formats. You can use nessus to do conversion between formats used for reports. Nessus can take any NSR or NBE reports and change them into HTML, XML, NSR or NBE reports. Please note that the XML report usually provides more information about the scan than the NSR or NBE formats include in the report. Basically, XML is a merge between the .nbe reports and the .nessusrc configuration file. You won't get extra verbosity or diagnosis info in the XML report, but you'll know which plugins (and which version of these plugins) have been enabled during the scan. For more information on the report formats please read the files nsr_file_format.txt and nbe_file_format.txt provided along with the documentation.

This option causes Nessus to run the scan detached. A detached scan is a scan that runs in the background, disconnected from the Nessus client. This option is deprecated and is no longer supported. This option has been removed from Nessus versions 2.3.x and greater.

This option is used in conjunction with the Detached Scan option. The value specified here should contain an email address where Nessus will email the results of a detached scan. This option is deprecated and is no longer supported. This option has been removed from Nessus versions 2.3.x and greater.

This option enables the NES implementation of the nmap port scanner. When this option is selected, see the "Prefs - Nmap" options to configure the nmap port scan.