mirror of
https://github.com/nmap/nmap.git
synced 2026-08-03 22:29:06 +00:00
Merge and format documentation for functions in nselib/nmap.luadoc. A lot of
functions are missing, notable the socket methods. I'll add those next.
This commit is contained in:
david
parent
16052f05e5
commit
77374fb284
2 changed files with 132 additions and 299 deletions
|
|
@ -1079,243 +1079,8 @@ action refer to <xref linkend="nse-tutorial-action"/>.
|
|||
</variablelist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Scripts also have access to some of Nmap’s functions and state
|
||||
variables that are exposed through functions in the <literal>nmap</literal>
|
||||
table.
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>nmap.debugging()</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the
|
||||
debugging level<indexterm><primary>debugging</primary><secondary>in NSE</secondary></indexterm>
|
||||
as a non-negative integer. The
|
||||
debugging level can be set with the
|
||||
<option>-d</option><indexterm><primary><option>-d</option></primary></indexterm>
|
||||
option<bookex> (see <xref linkend="port-scanning-options-output"/>)</bookex>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><option>nmap.have_ssl()</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns true if Nmap was compiled with
|
||||
SSL support,<indexterm><primary>SSL</primary><secondary>in NSE</secondary></indexterm>
|
||||
false
|
||||
otherwise. This can be used to avoid sending SSL probes
|
||||
when SSL is not available.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><option>nmap.verbosity()</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the
|
||||
verbosity level<indexterm><primary>verbosity</primary><secondary>in NSE</secondary></indexterm>
|
||||
as a non-negative integer. The
|
||||
verbosity level can be set with the
|
||||
<option>-v</option><indexterm><primary><option>-v</option></primary></indexterm>
|
||||
option<bookex> (see <xref linkend="port-scanning-options-output"/>)</bookex>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<option>nmap.fetchfile(filename)</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<indexterm><primary>data files</primary><secondary>access to from NSE</secondary></indexterm>
|
||||
<para>
|
||||
Allows access to Nmap's data files. <literal>fetchfile()</literal>
|
||||
searches for the specified file and returns a string containing
|
||||
it's path if it is found and readable (to the process). If the
|
||||
file is not found, not readable, or is a directory,
|
||||
<literal>nil</literal> is returned. The call
|
||||
<programlisting>
|
||||
nmap.fetchfile("nmap-rpc")
|
||||
</programlisting>
|
||||
will search for the data file <filename>nmap-rpc</filename> and,
|
||||
assuming it's found (which it should be), return a location like
|
||||
<filename>/usr/local/share/nmap/nmap-rpc</filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><option>nmap.timing_level()</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<indexterm><primary>timing templates</primary><secondary>access to from NSE</secondary></indexterm>
|
||||
<para>
|
||||
Returns the timing level as a non-negative integer. Possible return
|
||||
values vary from 0 to 5, corresponding to the six built-in Nmap
|
||||
timing templates. The timing level can be set with the
|
||||
<option>-T</option> option<bookex> (see <xref linkend="man-performance"/>)</bookex>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="nse-api-portmethods">
|
||||
<title>Target Information Retrieval by a Script</title>
|
||||
<para>
|
||||
Often the information passed to the script is not enough. Sometimes
|
||||
a script might want to correct target information or set it in the
|
||||
first place. The following API methods handle this.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>nmap.get_port_state(host, port, protocol)</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>get_port_state()</literal> call takes a
|
||||
host table, a port table and a protocol
|
||||
(<literal>tcp</literal> or <literal>udp</literal>) and
|
||||
returns a port table for the queried port. The host
|
||||
and port table are similar in structure to the ones
|
||||
passed to the rule and action functions. The host
|
||||
table should have an IP address field. The port table
|
||||
needs a port number and a protocol field. A call could
|
||||
look like this:
|
||||
<programlisting>
|
||||
nmap.get_port_state({ip="127.0.0.1"}, {number="80", protocol="tcp"})
|
||||
</programlisting>
|
||||
You can of course reuse the host and port tables
|
||||
passed to the port rule function. The purpose of this
|
||||
call is to be able to match scripts against more than
|
||||
one open port. For example if the target host has an
|
||||
open port 22 and a running identd server, then you can
|
||||
write a script which will only fire if both ports are
|
||||
open and there is an identification server on port
|
||||
113. While it is possible to specify IP addresses
|
||||
different to the currently scanned target, the result
|
||||
will only be correct if the target is in the currently
|
||||
scanned group of hosts.
|
||||
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>nmap.set_port_state(host, port, state)</option>
|
||||
</term>
|
||||
<listitem>
|
||||
|
||||
|
||||
<para>The <literal>set_port_state()</literal> call takes a host table,
|
||||
a port table, and a port state (<literal>open</literal>
|
||||
or <literal>closed</literal>). Using this method the final port state,
|
||||
reflected in Nmap's results, can be changed for a target. This is
|
||||
useful when Nmap detects a port as <literal>open|filtered</literal>
|
||||
(i.e. unable to determine which), but the script successfully connects
|
||||
to that port. In this case the script can set the port state
|
||||
to <literal>open</literal>. Note that the port.state value, which was
|
||||
passed to the script's action function will not be changed by this
|
||||
call.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>nmap.set_port_version(host, port, probestate)</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
NSE scripts are sometimes able to determine the
|
||||
service name and application version listening on a
|
||||
port. A whole script category
|
||||
(<literal>version</literal>) was designed for this
|
||||
purpose, as described in <xref linkend="nse-vscan"/>.
|
||||
The <literal>set_port_version</literal> function is
|
||||
used to record version information when it is
|
||||
discovered.</para>
|
||||
|
||||
<para>This method takes a host and a port
|
||||
table as arguments. The third argument describes the
|
||||
state in which the script completed. It is a string
|
||||
which is one of:
|
||||
<literal>hardmatched</literal>,
|
||||
<literal>softmatched</literal>,
|
||||
<literal>nomatch</literal>,
|
||||
<literal>tcpwrapped</literal>, or
|
||||
<literal>incomplete</literal>.
|
||||
The <literal>hardmatched</literal> argument is almost
|
||||
always used, as it signifies a successful match. The
|
||||
other possible states are generally only used for
|
||||
standard version detection rather than the NSE
|
||||
enhancement.</para>
|
||||
|
||||
<para>The host and port arguments to this function
|
||||
should either be the tables passed to the
|
||||
<literal>action</literal> method or they should have
|
||||
the same structure. The version detection fields this
|
||||
function looks at are <literal>name</literal>,
|
||||
<literal>product</literal>,
|
||||
<literal>version</literal>,
|
||||
<literal>extrainfo</literal>,
|
||||
<literal>hostname</literal>,
|
||||
<literal>ostype</literal>,
|
||||
<literal>devicetype</literal>, and
|
||||
<literal>service_tunnel</literal>. All values in this
|
||||
table are optional. It is possible to pass a table in
|
||||
which all these values are set to
|
||||
<literal>nil</literal> or not to set the values at
|
||||
all.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="nse-aux-raw-packet">
|
||||
<title>Various Utility Functions for Raw Packet Support</title>
|
||||
<indexterm><primary>raw packets</primary><secondary>in NSE</secondary></indexterm>
|
||||
<para>
|
||||
NSE has support for sending raw ethernet frames and capturing
|
||||
packets. The following two functions may be handy in this context:
|
||||
</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>nmap.clock_ms()</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns a number representing the current time as milliseconds
|
||||
since the start of the epoch (on most systems this is 01/01/1970).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><option>nmap.get_interface_link("interface_name")</option>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
For the provided
|
||||
dnet-style<indexterm><primary>libdnet</primary></indexterm>
|
||||
<literal>interface_name</literal>,
|
||||
<literal>nmap.get_interface_link()</literal> returns
|
||||
what kind of link level hardware the interface
|
||||
belongs. Return values are:
|
||||
<literal>ethernet</literal>,
|
||||
<literal>loopback</literal> or
|
||||
<literal>p2p</literal>. If the provided
|
||||
<literal>interface_name</literal> is not one of
|
||||
those types, <literal>nil</literal> is returned.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="nse-api-networkio">
|
||||
<title>Network I/O API</title>
|
||||
<para>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue