diff --git a/docs/scripting.xml b/docs/scripting.xml index d40a5f45d..c8b03629c 100644 --- a/docs/scripting.xml +++ b/docs/scripting.xml @@ -34,7 +34,7 @@ The Nmap version detection system () is able to recognize thousands of different services through - its probe and regular expression based matching system, but it + its probe and regular expression signature based matching system, but it cannot recognize everything. For example, identifying the Skype v2 service requires two independent probes, which version detection isn't flexible enough to handle. Nmap could also recognize more SNMP services if it tried a few hundred different community names by brute @@ -57,8 +57,7 @@ before the bad guys do. While Nmap isn't a comprehensive vulnerability scanner, NSE is powerful enough to handle even demanding vulnerability - checks. Many vulnerability detection scripts have already been - written and we plan to distribute more as they are written. + checks. Many vulnerability detection scripts are already available and we plan to distribute more as they are written. @@ -67,17 +66,17 @@ Backdoor detection - Many attackers and some automated worms leave - backdoors to enable later reentry. Some of these can be - detected by Nmap's regular expression based version detection. - For example, within hours of the MyDoom worm hitting the - Internet, - Jay MoranMoran, Jay - posted an Nmap version detection probe and - signature so that others could quickly scan their networks. - For more complex worms and backdoors, NSE is needed - for reliable detection. + Many attackers and some automated worms leave backdoors to + enable later reentry. Some of these can be detected by + Nmap's regular expression based version detection. For + example, within hours of the MyDoom worm hitting the + Internet, Jay MoranMoran, + Jay posted an Nmap version detection + probe and signature so that others could quickly scan their + networks for MyDoom infections. NSE is needed to reliably + detect more complex worms and backdoors. + @@ -90,23 +89,17 @@ for some people (particularly penetration testers),penetration testing though we aren't - planning to turn Nmap into an exploitation framework like + planning to turn Nmap into an exploitation framework such as Metasploit.Metasploit - The listed items were our initial goals, but we expect that Nmap - users will come up with inventive uses for NSE. + These listed items were our initial goals, and we expect Nmap + users to come up with even more inventive uses for NSE. - The Nmap Scripting Engine is a new Nmap feature - which already works well, but is under active development. To - provide the latest NSE news and updates, this chapter has been - updated and posted for free online at - . - Scripts are written in the embedded @@ -146,10 +139,10 @@ The reference manual is also and produce results below the port table. shows a typical script scan. Examples of service scripts producing output are: - sshv1.nse, saying that SSH-1 is supported; - and html-title.nse, + sshv1, saying that SSH-1 is supported; + and html-title, which simply grabs the title of the root path of any web servers - found. A sample host script is ripeQuery.nse, + found. A sample host script is ripeQuery, which looks up and reports target IP ownership information.script names, examples of @@ -194,85 +187,91 @@ Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds option. The two remaining options, and , - are generally only used for script debugging and development. + are generally only used for script debugging and development. Script scanning is also included as part of the (aggressive scan) option. Script Categories script categories NSE scripts define a list of categories they belong to. - Currently defined categories are safe, - intrusive, malware, - version, discovery, - vuln, auth, - external and default. - Category names are not case - sensitive. The following list describes each category. + Currently defined categories + are auth, default, discovery, external, +intrusive, malware, safe, version, +and vuln. Category names are not case sensitive. The following list describes each category. + - “safe” script category - + “auth” script category + - Scripts - which weren't designed to crash services, use large - amounts of network bandwidth or other resources, or - exploit security holes. These are less likely to offend - remote sysadmins. Of course (as with all other Nmap - features) we cannot guarantee that they won't ever cause - adverse reactions. Most of these perform general - network discovery. Examples are - ssh-hostkey.nse (gets an SSH host key) and - html-title.nse (grabs the title from a - web page). + These scripts try to determine authentication credentials + on the target system, often through a brute-force attack. Examples include snmp-brute, http-auth, and ftp-anon. - “intrusive” script category - + “default” script category + - These are scripts that cannot be classified in the - safe category because the risks are too high that they - will crash the target system, use up significant resources - on the target host (such as bandwidth or CPU time), or - otherwise be perceived as malicious by the target's - system administrators. - + These scripts are the default set and are run when + using the or + options rather than listing scripts + with . This category can also be + specified explicitly like any other + using . Many factors are + considered in deciding whether a script should be run by + default: + + + + + Speed + A default scan must finish quickly, which excludes brute force authentication crackers, web spiders, and any other scripts which can take minutes or hours to scan a single service. - - “malware” script category - - - - These scripts test whether the target platform is - infected by malware or backdoors. - + Usefulness + Default scans need to produce valuable and actionable information. If even the script author has trouble explaining why an average networking or security professional would find the output valuable, the script should not run by default. The script may still be worth including in Nmap so that administrators can run for those occasions when they do need the extra information. - - “version” script category - version detection“version” script category - - - + Verbosity + Nmap output is used for a wide variety of + purposes and needs to be readable and concise. A script which + frequently produces pages full of output should not be added + to the default category. When there is no + important information to report, NSE scripts (particularly + default ones) should return nothing. Checking for an obscure + vulnerability may be OK by default as long as it only produces output + when that vulnerability discovered. + - The scripts in this category are an extension to the - version detection option and cannot be selected - explicitly. They are selected to run only if version - detection () was requested. Their - output cannot be distinguished from version detection - output and they do not produce service or host script - results. + + Reliability + Many scripts use heuristics and fuzzy signature matching to reach conclusions about the target host or service. Examples include sniffer-detect and sql-injection. If the script is often wrong, it doesn't belong in the default category where it may confuse or mislead casual users. Users who specify a script or category directly are generally more advanced and likely know how the script works or at least where to find its documentation. + + + Intrusiveness + Some scripts are very intrusive because they use significant resources on the remote system, are likely to crash the system or service, or are likely to be perceived as an attack by the remote administrators. The more intrusive a script is, the less suitable it is for the default category. + + + + Privacy + Some scripts, particularly those in the external category described later, divulge information to third parties by their very nature. For example, the whois script must divulge the target IP address to regional whois registries. We have also considered (and decided against) adding scripts which check target SSH and SSL key fingerprints against Internet weak key databases. The more privacy-invasive a script is, the less suitable it is for default category inclusion. + + + + We don't have exact thresholds for each of these criteria, + and many of them are subjective. All of these factors are + considered together when making a decision whether to promote a + script into the default category. A few default scritps are identd-owners (determines the username running remote services using identd), http-auth (obtains authentication scheme and realm of web sites requiring authentication), and ftp-anon (tests whether an FTP server allows anonymous access). @@ -282,31 +281,9 @@ Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds - These scripts try to actively learn more about the + These scripts try to actively discover more about the network by querying public registries, SNMP-enabled - devices, directory services, and the like. - - - - - - “vuln” script category - - - - These scripts check for specific known vulnerabilities and - generally only report results if they are found. - - - - - - “auth” script category - - - - These scripts try to determine authentication credentials - on the target system, often through a brute-force attack. + devices, directory services, and the like. Examples include html-title (obtains the title of the root path of web sites), smb-enum-shares (enumerates Windows shares), and snmp-sysdescr (extracts system details via SNMP). @@ -318,11 +295,11 @@ Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds Scripts in this category may send data to a third-party database or other network resource. An example - of this is whois.nse, which makes a - connection to a - whoiswhois server + of this is whois, which makes a + connection to + whoiswhois servers to learn about the address of the target. There is always - the possibility that the operators of the third-party + the possibility that operators of the third-party database will record anything you send to them, which in many cases will include your IP address and the address of the target. Most scripts involve traffic strictly between @@ -333,17 +310,93 @@ Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds - “default” script category - + “intrusive” script category + - These scripts are the default set and are run when - using or without - listing scripts with . This - category can also be specified explicitly like any other - using . + + These are scripts that cannot be classified in the + safe category because the risks are too + high that they will crash the target system, use up + significant resources on the target host (such as + bandwidth or CPU time), or otherwise be perceived as + malicious by the target's system administrators. Examples + are http-open-proxy (which attempts to + use the target server as an HTTP proxy) + and snmp-brute (which tries to guess a + device's SNMP comunity string by sending common values + such + as public, private, + and cisco). + + + + + “malware” script category + + + + These scripts test whether the target platform is + infected by malware or backdoors. Examples include smtp-strangeport, which watches for SMTP servers running on unusual port numbers, and auth-spoof, which detects identd spoofing daemons which provide a fake answer before even receiving a query. Both of these behaviors are commonly associated with malware infections. + + + + + + + “safe” script category + + + + Scripts + which weren't designed to crash services, use large + amounts of network bandwidth or other resources, or + exploit security holes are categorized as safe. These are less likely to offend + remote administrators, though (as with all other Nmap + features) we cannot guarantee that they won't ever cause + adverse reactions. Most of these perform general + network discovery. Examples are + ssh-hostkey (retrieves an SSH host key) and + html-title (grabs the title from a + web page). + + + + + + “version” script category + version detection“version” script category + + + + + The scripts in this special category are an + extension to the version detection feature and cannot be + selected explicitly. They are selected to run only if + version detection () was requested. + Their output cannot be distinguished from version + detection output and they do not produce service or host + script results. Examples + are skypev2-version, pptp-version, + and iax2-version. + + + + + + + + “vuln” script category + + + + These scripts check for specific known vulnerabilities and + generally only report results if they are found. Examples include realvnc-auth-bypass and xampp-default-auth. + + + @@ -362,7 +415,7 @@ Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds Performs a script scan using the default set of scripts. It is equivalent to . Some of the - scripts in this category are considered intrusive and should + scripts in this default category are considered intrusive and should not be run against a target network without permission. @@ -405,7 +458,7 @@ which lists the category or categories in which each script belongs. Give the argument all to execute all scripts in the Nmap script database. -Malicious scripts are not run in a sandbox and thus could damage your system or invade your privacy. Never run scripts from third parties unless you trust the authors or have carefully audited the scripts yourself. +Scripts are not run in a sandbox and thus could accidentally or maliciously damage your system or invade your privacy. Never run scripts from third parties unless you trust the authors or have carefully audited the scripts yourself. @@ -438,6 +491,8 @@ Nmap script database. protocol, source and target addresses, and the transmitted data. If more than 5% of transmitted data is unprintable, hex dumps are given instead. + Specifying enables script + tracing too. @@ -456,30 +511,30 @@ Nmap script database. you have added or removed NSE scripts from the default scripts directory or if you have changed the categories of any script. This option is - generally used by - itself: nmap --script-updatedb. + used by + itself without arguments: nmap --script-updatedb. - Some of the Nmap options have effects on script scans. The most + Some other Nmap options have effects on script scans. The most prominent of these is . - A version scan executes + A version scan automatically executes the scripts in the version category.“version” script category The scripts - in this category are slightly different than other scripts. Their - output blends in with the version scan and they do not produce any + in this category are slightly different than other scripts because their + output blends in with the version scan results and they do not produce any script scan output. - Another option which has effect on the scripting engine is + Another option which affects the scripting engine is .features enabled by - The advanced/aggressive mode of Nmap implies - the option . + The aggressive Nmap mode implies + the option. @@ -490,16 +545,15 @@ Nmap script database. Arguments to Scripts script arguments - You can pass arguments to NSE scripts via the - option. The script-arguments generally are - name-value pairs, which are provided to the script as a Lua table called - args inside the nmap.registry with - the names as keys for the corresponding values. The values can either be - strings or tables. Subtables can be used to pass arguments to - scripts with a finer granularity (e.g. pass different usernames for - different scripts). A typical nmap invocation with script arguments may - look like: + Arguments may be passed to NSE scripts using the + option. The script arguments are generally + name-value pairs. They are provided to scripts as a Lua table named + args inside nmap.registry. + The argument names are keys for the corresponding values. The values can be + either strings or tables. Subtables can be used to pass arguments to + scripts with finer granularity, such as passing different usernames for + different scripts. Here is a typical Nmap invocation with script arguments: example of @@ -509,19 +563,19 @@ $ nmap -sC --script-args user=foo,pass=bar,whois={whodb=nofollow+ripe} - which would result in the Lua table: + The aforementioned command results in this Lua table: {user="foo",pass="bar",whois={whodb="nofollow+ripe"}} - You could therefore access the username ("foo") - inside your script as - local username= nmap.registry.args.user. - As a general rule the subtables used to override - options for scripts should be named after the script, - otherwise scripts won't know where to - retrieve their arguments. + You could therefore access the username (foo) + inside your script with this statement: + + local username = nmap.registry.args.user + + Subtables used to override + options for scripts are usually named after the script to ease retrieval. @@ -529,7 +583,7 @@ $ nmap -sC --script-args user=foo,pass=bar,whois={whodb=nofollow+ripe} Usage Examples - A simple script scan using the default set of scripts + A simple script scan using the default set of scripts: example of @@ -538,7 +592,7 @@ $ nmap -sC --script-args user=foo,pass=bar,whois={whodb=nofollow+ripe} - Tracing a specific script. + Executing a specific script with tracing enabled: example of @@ -549,7 +603,7 @@ $ nmap -sC --script-args user=foo,pass=bar,whois={whodb=nofollow+ripe} - All scripts in a subdirectory named mycustomscripts in addition to all of Nmap's included scripts which are in the safe category. + Execute all scripts in the mycustomscripts directory as well as all default scripts in the safe category: @@ -560,18 +614,13 @@ $ nmap -sC --script-args user=foo,pass=bar,whois={whodb=nofollow+ripe} Script Format - NSE scripts consist of five descriptive fields along with either a port or host rule defining when the script should be executed and an action block containing the actual script instructions. Values can be assigned to these fields just as you would assign any other Lua variables. Their names must be lowercase as shown here. + NSE scripts consist of two–five descriptive fields along with either a port or host rule defining when the script should be executed and an action block containing the actual script instructions. Values can be assigned to the descriptive fields just as you would assign any other Lua variables. Their names must be lowercase as shown in this section. <literal>description</literal> Field “description” script variable - The description field describes what the script is testing - for and any critical notes the user must be aware of. A good - example is this description from a user-contributed recursive - DNS script: -Checks if a DNS server allows queries for third-party names. - -It is expected that recursion will be enabled on your own internal nameservers. + The description field describes what a script is testing + for and any important notes the user should be aware of. Depending on script complexity, the description may vary from a few sentences to a few paragraphs. The first paragraph should be a brief synopsis of the script function suitable for stand-alone presentation to the user. Further paragraphs may provide much more script detail. @@ -581,7 +630,7 @@ It is expected that recursion will be enabled on your own internal nameservers.< The categories field defines one or more categories to which a script belongs (see - ). The categories are case-insensitive and may be specified in any order. They are listed in an array-like Lua table as in this example: + ). The categories are case-insensitive and may be specified in any order. They are listed in an array-style Lua table as in this example: categories = {"default", "discovery", "safe"} @@ -593,7 +642,7 @@ categories = {"default", "discovery", "safe"} <literal>author</literal> Field “author” script variable - The author field contains the script authors name and contact information. If you are worried about spam, you might want to omit or obscure your email address, or give your home page URL instead. This optional field is not used by NSE, but is important for giving script authors due credit or blame. + The author field contains the script authors' names and contact information. If you are worried about spam, feel free to omit or obscure your email address, or give your home page URL instead. This optional field is not used by NSE, but gives script authors due credit or blame. @@ -605,7 +654,7 @@ categories = {"default", "discovery", "safe"} Nmap is a community project and we welcome all sorts of code contributions, including NSE scripts. So if you write a valuable script, don't keep it to yourself! - The license field helps ensure that we have + The optional license field helps ensure that we have legal permission to distribute all the scripts which come with Nmap. All of those scripts currently use the standard Nmap license (described in ). They include @@ -627,18 +676,14 @@ that. run level of scripts This optional field determines script execution order. When - this section is absent the run level defaults to 1.0. A script - with the run level 1.0 is run before any scripts with runlevel set to - 2.5, which in turn runs before any scripts - with runlevel 2.55. Scripts with the same run level are run - concurrently. One + this section is absent, the run level defaults to 1.0. Scripts with a given runlevel execute after any with a lower runlevel and before any scripts with a higher runlevel against a single target machine. The order of scripts with the same runlevel is undefined and they often run concurrently. One application of run levels is allowing scripts to depend on each other. If script A relies on some information gathered by script B, give B a lower run level than A. Script B can store information in the NSE registry for A to - retrieve later. For information on the NSE registry see to + retrieve later. For information on the NSE registry, see . @@ -655,13 +700,13 @@ against a target. A script contains either a port rule, which governs which ports of a target the scripts may run against, or a host rule, which specifies that the script should be run only once against a target IP and only if -certain conditions are met. A rule is a Lua function that returns +the given conditions are met. A rule is a Lua function that returns either true or false. The -script action is only performed if the rule -evaluates to true. The host rule accepts a host -table as an argument and may test, for example, the IP address or +script action is only performed if its rule +evaluates to true. Host rules accept a host +table as their argument and may test, for example, the IP address or hostname of the target. A port rule accepts both host and port tables -as arguments for any TCP or UDP port in either the +as arguments for any TCP or UDP port in the openopen port state, open|filteredopen|filtered port state, or unfilteredunfiltered port state port states. Port rules generally test factors such as the port number, port state, or listening service name in deciding whether to run against a port. Example rules are shown in . @@ -720,29 +765,26 @@ action refer to . During the planning stages, we considered several programming - languages as the bases for Nmap scripting. One option was to - implement a completely new programming language. The criteria - imposed on the options were strict, NSE needed to be easy to + languages as the base for Nmap scripting. Another option was to + implement a completely new programming language. Our criteria + were strict: NSE had to be easy to use, small in size, compatible with the Nmap license, - scalable, fast and parallelizable. There have been several - efforts to design a security auditing language from scratch - which have resulted in well-known awkward solutions. It was - clear from the beginning that we would not go down this - road. For a while the Guile Scheme interpreter was considered - but the preference drifted towards Elk in favor of its more - liberal license. But parallelizing Elk scripts would have been - difficult. In addition, the subset of Nmap users familiar with - functional programming is regarded too small to consider - Scheme as an option. Larger interpreters like Perl, Python or + scalable, fast and parallelizable. Several + previous efforts (by other projects) to design their own security auditing language from scratch + resulted in awkward solutions, so we decided early not to follow that + route. First the Guile Scheme interpreter was considered, + but the preference drifted towards the Elk interpreter due to its more + favorable license. But parallelizing Elk scripts would have been + difficult. In addition, we expect that most Nmap users prefer procedural programming over functional languages such as Scheme. Larger interpreters such as Perl, Python, and Ruby are well-known and loved, but are difficult to embed - efficiently. In the end, Lua exceeded in all criteria for - NSE. It is small, distributed under the MIT license, has + efficiently. In the end, Lua excelled in all of our criteria. + It is small, distributed under the liberal MIT open source license, has coroutines for efficient parallel script execution, was designed with embeddability in mind, has excellent documentation, and is actively developed by a large and committed community. - Lua is even embedded in popular applications including - Wireshark and Second Life. + Lua is now even embedded in other popular open source security tools including + the Wireshark sniffer and Snort IDS. @@ -752,20 +794,27 @@ action refer to . Nmap Scripting Engine (NSE)list of scripts NSE Scripts - - This is a list of the scripts packaged with Nmap as of this writing. - This documentation comes straight from the source code of the - scripts thanks to the NSEDoc documentation system, described in - . - Of course no paper documentation can hope to stay current with - software that is developed as actively as NSE is. - - For the latest documentation see the online NSE documentation portal - at . + This section lists (alphabetically) all NSE scripts packaged + with Nmap as the time of this writing. It comes straight from the + script source code thanks to the NSEDoc documentation system + described in . Of course no + paper documentation can stay current with software developed as + actively as NSE is. For the most comprehensive and up-to-date + documentation, see the online NSE Documentation Portal at + . &nse-scripts; + + + + This section (a long list of NSE scripts with brief + summaries) is only provided in the printed edition of this book + because we already provide a better online interface to the + information at the NSE + Documentation Portal. + @@ -773,7 +822,7 @@ action refer to . NSE Libraries In addition to the significant built-in capabilities of Lua, we have written or integrated many extension libraries which make - script writing more powerful and convenient. These libraries (sometimes called modules) are compiled and installed along with + script writing more powerful and convenient. These libraries (sometimes called modules) are compiled if necessary and installed along with Nmap. They have their own directory, nselib, which is installed in the configured datadir. Scripts need only @@ -810,7 +859,7 @@ action refer to . An effective Nmap scripting engine requires more than just a Lua interpreter. Users need easy access to the information Nmap has learned about the target hosts. This data is passed - as arguments to the NSE + as arguments to the NSE script's action method.“action” script variable The arguments, host and port, are Lua tables which contain @@ -890,7 +939,7 @@ action refer to . A Boolean value indicating whether or not the target host is - directly connected (i.e. on the same network segment). + directly connected to (i.e. on the same network segment as) the host running Nmap. @@ -947,11 +996,9 @@ action refer to . - The port table is passed to the Lua script in the same + The port table is passed to an NSE service script (i.e. only those with a portrule rather than a hostrule) in the same fashion as the host table. It contains information about the port - against which the script is running. If the script is run - according to a host rule, then no port table is passed to the - script. Port states on the target can still be requested from Nmap + against which the script is running. While this table is not passed to host scripts, port states on the target can still be requested from Nmap using the nmap.get_port_state() call. @@ -962,7 +1009,7 @@ action refer to . - Contains the number of the currently scanned port. + Contains the port number of the target port. @@ -973,7 +1020,7 @@ action refer to . - Defines the protocol of the port. Valid values are + Defines the protocol of the target port. Valid values are "tcp" and "udp". @@ -988,8 +1035,8 @@ action refer to . Contains a string representation of the service running on port.number as detected by the Nmap service detection. If the port.version field is - nil then Nmap has guessed the service based - only on the port number. Otherwise this field is equal to + nil, Nmap has guessed the service based + on the port number. Otherwise version detection was able to determine the listening service and this field is equal to port.version.name. @@ -1002,10 +1049,10 @@ action refer to . This entry is a table which contains information retrieved by the Nmap version scanning engine. Some - of the values (like service name, service type - confidence, RPC related values) may be retrieved by - Nmap even if a version scan was not required. Values - which were not retrieved default to + of the values (such as service name, service type + confidence, and the RPC-related values) may be retrieved by + Nmap even if a version scan was not performed. Values + which were not determined default to nil. The meaning of each value is given in the following table: @@ -1020,12 +1067,12 @@ action refer to . name - Contains the service name Nmap will use for the port. + Contains the service name Nmap determined for the port. name_confidence - Evaluates how confident the version detection is about the accuracy of name, from 1 (least confident) to 10. + Evaluates how confident Nmap is about the accuracy of name, from 1 (least confident) to 10. @@ -1108,7 +1155,7 @@ action refer to . The I/O parallelism is fully transparent to authors of NSE scripts. In NSE you can either program as if you were using a single non-blocking socket or you can program as if your connection is - blocking. Seemingly blocking I/O calls still return once a + blocking. Even blocking I/O calls return once a specified timeout has been exceeded. Two flavors of Network I/O are supported: connect-style and raw packet. @@ -1117,23 +1164,23 @@ action refer to . sockets in NSE This part of the network API should be suitable for most classical network uses: Users create a socket, connect it to a - remote address, send and receive data and close the socket again. + remote address, send and receive data and finally close the socket. Everything up to the Transport layer (which is either TCP, UDP or SSL) is handled by the library. An NSE socket is created by calling - nmap.new_socket(), which returns a socket object. + nmap.new_socket, which returns a socket object. The socket object supports the usual connect, send, receive, and close methods. Additionally the functions receive_bytes, receive_lines, and - receive_buf allow greater control of the - receiving of data. + receive_buf allow greater control + over data reception. shows the use of connect-style network operations. The - try function is for error handling; see + try function is used for error handling, as described in . @@ -1222,10 +1269,10 @@ socket:close() threads in NSE mutexes in NSE - Each thread made for a script (e.g. ftp-anon.nse) will yield to other + Each thread made for a script (e.g. ftp-anon) will yield to other scripts whenever it makes a call on network objects (sending/receiving data). Some scripts need finer control over threads' execution. An - example is the whois.nse script which queries + example is the whois script which queries whoiswhois servers for each target. Because many concurrent queries often result in getting one's IP banned for abuse and a query may return additional @@ -1239,7 +1286,7 @@ socket:close() usable by scripts. The mutex allows for only one thread to be working on an object. Threads waiting to work on this object are put in the waiting queue until they can get a "lock" on the mutex. A solution for - the whois.nse problem above is to have each thread + the whois problem above is to have each thread block on a mutex using a common string, thus ensuring only one thread is working so its results can be shared with other scripts which may not need to run and so queries @@ -1475,7 +1522,7 @@ try(socket:send(result)) The description field should contain a sentence or two describing what the script does. If anything about the script results might confuse or mislead users, and you can't eliminate the issue by improving the script or results text, it should be documented in the description string. -identd-owners.nse +identd-owners “description” script variable description = [[