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.

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.

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).

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 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.

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.

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.

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.

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 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.

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 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 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 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 password of the POP2 account used to login to the target for POP2 testing.

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 causes Nessus to implement NIDS evasion techniques for TCP packets. Valid options are none, split, injection, and short ttl.

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

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.

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.

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 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 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.

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 option forces the Nessus client to not check the Nessus server's SSL certificate when connecting.

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

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 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.

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

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

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.

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.

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.

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.

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 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.

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.

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 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.

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.

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.

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 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.

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 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.