ncat/docs/ncatguide.xml - master - githubmirror/nmap

ncat/docs/ncatguide.xml
2 014 строк87 KB
dmiller
Ncat docs: note danger of unquoted commands on Windows
16 фев 2026, 21:40
16 фев 2026, 21:4092224d5
<indexterm significance="preferred" class="startofrange" id="ncat-indexterm"><primary>Ncat</primary></indexterm>

<sect1 id="ncat-overview">
  <title>Ncat: Your General-Purpose Network Connector</title>

  <para>
  Ncat is a general-purpose command-line tool for reading, writing,
  redirecting, and encrypting data across a network. It aims to be
  your network <ulink role="hidepdf"
  url="http://en.wikipedia.org/wiki/Swiss_Army_knife">Swiss Army
  knife</ulink>, handling a wide variety of security testing and
  administration tasks.  Ncat is suitable for interactive use or as a
  network-connected back end for other tools.  Ncat can:
  </para>

  <itemizedlist>

  <listitem><para>Act as a simple TCP/UDP/SCTP/SSL client for interacting
  with web servers, telnet servers, mail servers, and other TCP/IP
  network services.  Often the best way to understand a service (for
  fixing problems, finding security flaws, or testing custom commands)
  is to interact with it using Ncat. This lets you you control every character
  sent and view the raw, unfiltered responses.</para></listitem>

  <listitem><para>Act as a simple TCP/UDP/SCTP/SSL server for offering
  services to clients, or simply to understand what existing clients
  are up to by capturing every byte they send.</para></listitem>

  <listitem><para>Redirect or proxy TCP/UDP/SCTP traffic to other ports or
  hosts.  This can be done using simple redirection (everything sent
  to a port is automatically relayed somewhere else you specify in
  advance) or by acting as a SOCKS or HTTP proxy so clients
  specify their own destinations.  In client mode, Ncat can
  connect to destinations through a chain of anonymous or
  authenticated proxies.</para></listitem>

  <listitem><para>Run on all major operating systems.  We distribute
  Linux, Windows, and Mac OS X binaries, and Ncat compiles on most
  other systems.  A trusted tool must be available
  whenever you need it, no matter what computer you're
  using.</para></listitem>

  <listitem><para>Encrypt communication with SSL, and transport it over IPv4 or IPv6.</para></listitem>

  <listitem><para>Act as a network gateway for execution of system
  commands, with I/O redirected to the network.  It was designed to work
  like the Unix utility <command>cat</command>, but for the
  network.</para></listitem>

  <listitem><para>Act as a connection broker, allowing two (or far
  more) clients to connect to each other through a third (brokering)
  server.  This enables multiple machines hidden behind NAT gateways
  to communicate with each other, and also enables the simple Ncat
  chat mode.</para></listitem>
  </itemizedlist>

  <para>These capabilities become even more powerful and versatile
  when combined.</para>

  <para>
  Ncat is our modern reinvention of the venerable Netcat (nc) tool released by Hobbit in 1996.  While Ncat is similar to Netcat in spirit, they don't share any source code.  Instead, Ncat makes use of Nmap's well optimized and tested networking
  libraries.  Compatibility with the original Netcat and some well known variants is maintained
  where it doesn't conflict with Ncat's enhancements or cause
  usability problems.  Ncat adds many capabilities not found in
  Hobbit's original nc, including SSL support, proxy connections,
  IPv6, and connection brokering.
  The original nc contained a simple port
  scanner, but we omitted that from Ncat because we have a preferred
  tool for that function.
  </para>

  <para>
  This guide starts with examples of basic Ncat usage, then moves on to more advanced features.  Those are followed by practical sections which use examples to demonstrate how Ncat can solve common real-world problems.  A few neat Ncat tricks are covered as well.
  </para>
</sect1>

<!-- Need a discussion of shell syntax, as it's such a big part of using
the tool? Many of these examples suppose a Unix environment. -->

<sect1 id="ncat-usage">
  <title>Basic usage</title>

  <para>
  Ncat always operates in one of two basic modes:
  <firstterm>connect mode</firstterm><indexterm><primary>connect mode</primary></indexterm> and
  <firstterm>listen mode</firstterm>.<indexterm><primary>listen mode</primary></indexterm>
  In connect mode, Ncat initiates a connection (or sends UDP data) to a service that is
  listening somewhere. For those familiar with socket programming,
  connect mode is like using the <function>connect</function> function.
  In listen mode, Ncat waits for an incoming connection (or data receipt), like using the
  <function>bind</function> and <function>listen</function> functions.
  You can think of connect mode as <quote>client</quote> mode and listen
  mode as <quote>server</quote> mode.
  </para>

  <para>
  To use Ncat in connect mode, run
  <informalexample>
<literallayout>
<command>ncat <replaceable>host</replaceable> <optional><replaceable>port</replaceable></optional></command>
</literallayout>
  </informalexample>
  <replaceable>host</replaceable> may be a hostname or IP
  address, and
  <replaceable>port</replaceable> is a port number. Listen mode is the
  same, with the addition of the
  <option>--listen</option><indexterm><primary><option>--listen</option>
  (Ncat option></primary></indexterm> option (or
  its <option>-l</option><indexterm><primary><option>-l</option> (Ncat
  option)</primary><see><option>--listen</option></see></indexterm>
  alias):
  <informalexample>

<literallayout>
<command>ncat --listen <optional><replaceable>host</replaceable></optional> <optional><replaceable>port</replaceable></optional></command>
<command>ncat -l <optional><replaceable>host</replaceable></optional> <optional><replaceable>port</replaceable></optional></command>
</literallayout>
  </informalexample>
  In listen mode, <replaceable>host</replaceable> controls the address
  on which Ncat listens; if you omit it, Ncat will bind to all local interfaces (INADDR_ANY).  If the port number is omitted, Ncat uses its
  default port
  31337.<indexterm><primary>default port of Ncat</primary></indexterm>
  Typically only privileged
  (root)<indexterm><primary>privileged users</primary></indexterm>
  users may bind to a port number lower than
  1024.<indexterm><primary>ports</primary><secondary>reserved</secondary></indexterm><indexterm><primary>reserved ports</primary></indexterm>
  A listening TCP server normally accepts only one connection and will
  exit after the client disconnects. Combined with the
  <option>--keep-open</option><indexterm><primary><option>--keep-open</option> (Ncat option)</primary></indexterm>
  option, Ncat accepts multiple concurrent connections up
  to the connection limit. With <option>--keep-open</option> (or
  <option>-k</option> for short), the server receives everything sent by
  any of its clients, and anything the server sends is sent to all of
  them.
  </para>

  <para>
  By default, Ncat uses TCP. The option
  <option>--udp</option><indexterm><primary><option>--udp</option> (Ncat option)</primary></indexterm>
  or
  <option>-u</option><indexterm><primary><option>-u</option> (Ncat option)</primary><see><option>--udp</option></see></indexterm>
  enables UDP instead,
  and
  <option>--sctp</option><indexterm><primary><option>--sctp</option> (Ncat option)</primary></indexterm>
  enables SCTP.<indexterm><primary>SCTP</primary><secondary>in Ncat</secondary></indexterm>
  Ncat listens on both IPv4 and IPv6, and connects to either address family as well. The
  <option>-6</option><indexterm><primary><option>-6</option> (Ncat option)</primary></indexterm>
  option forces IPv6-only, and
  <option>-4</option><indexterm><primary><option>-4</option> (Ncat option)</primary></indexterm>
  forces IPv4-only. See <xref linkend="ncat-protocols"/> for more details.
  The rest of this guide documents all the Ncat options through
  descriptions and examples. For a quick summary of options at any time,
  run
  <command>ncat --help</command><indexterm><primary><option>--help</option> (Ncat option)</primary></indexterm>
  or <command>man ncat</command>.
  </para>

  <sect2 id="ncat-connect">
    <title>A Connect Mode Example</title>

    <para>

    A good way to start learning about Ncat (and network protocols in
    general) is to connect to a network service and talk with it. In
    this case we use Ncat to manually retrieve a web page from an HTTP
    server, just as web browsers do in the background when you visit a
    web site.
    <xref linkend="ncat-ex-http" xrefstyle="select: label nopage"/>
    shows a (truncated) sample session. Try it yourself!
    Text in bold is what you type; everything else is what comes
    back. The blank line after the <userinput>GET</userinput> line is
    required&mdash;just hit <keycap>enter</keycap> twice.
    </para>

    <example id="ncat-ex-http">
      <title>Ncat as a web browser</title>
      <indexterm><primary>GET HTTP method</primary></indexterm>
      <indexterm><primary><option>-C</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<screen>
$ <userinput>ncat -C scanme.nmap.org 80</userinput>
<userinput>GET / HTTP/1.0

</userinput>HTTP/1.1 200 OK
Date: Thu, 05 Feb 2009 15:31:40 GMT
Server: Apache/2.2.2 (Fedora)
Last-Modified: Mon, 19 May 2008 04:49:49 GMT
ETag: "fc8c91-2e3-44d8e17edd540"
Accept-Ranges: bytes
Content-Length: 739
Connection: close
Content-Type: text/html; charset=UTF-8

&lt;html&gt;
&lt;head&gt;
&lt;title&gt;Go ahead and ScanMe!&lt;/title&gt;
&lt;/head&gt;
</screen>
    </example>

    <para>
    Here we have instructed Ncat to connect to the host
    scanme.nmap.org<indexterm><primary>scanme.nmap.org</primary></indexterm>
    on port 80, the port for HTTP. The <option>-C</option> option turns
    on CRLF<indexterm><primary>CRLF</primary></indexterm> replacement,
    which replaces any line endings you type with CRLF. CRLF line
    endings are required by many protocols, including HTTP, though many servers will accept a plain newline (LF) character.
    </para>

    <para>
    <userinput>GET / HTTP/1.0</userinput> requests the root document of
    the server; we are retrieving the same document named by the URL
    http://scanme.nmap.org:80/. The web server responds with a status code
    (<computeroutput>HTTP/1.1 200 OK</computeroutput>), followed by the
    HTTP header and the text of the web page. If you try this with other
    web servers, note that many of them are actually virtual hosts and you
    will need to send the <literal>Host</literal> header field. See
    RFC&nbsp;2616<indexterm><primary>RFC 2616</primary></indexterm> for
    more information about HTTP.
    </para>
  </sect2>

  <sect2 id="ncat-listen">
    <title>A Listen Mode Example</title>

    <para>
    So much for using Ncat as a web browser. What about a web server?
    That's possible too; it just takes a bit of preparation. The first
    step is to create the document to serve. Create a text file called
    <filename>hello.http</filename> with these contents:
<screen>
<![CDATA[HTTP/1.0 200 OK

<html>
  <body>
    <h1>Hello, world!</h1>
  </body>
</html>]]>
</screen>
    Now run the command
    <command>ncat -l localhost 8080 &lt; hello.http</command>. This
    instructs Ncat to listen on the local port 8080 and read
    <filename>hello.http</filename> on its input. Ncat is now primed to
    send the contents of the file as soon as it receives a connection.
    Now open a web browser and type in the address
    <userinput>http://localhost:8080/</userinput>.
    <xref linkend="ncat-fig-hello" xrefstyle="select: label nopage"/>
    shows a sample of what will appear.
    </para>

    <figure id="ncat-fig-hello">
      <title>Web page served by Ncat</title>
      <screenshot>
        <mediaobject>
          <imageobject>
            <imagedata fileref="../../book/images/ncat-fig-hello.png"/>
          </imageobject>
        </mediaobject>
      </screenshot>
    </figure>

    <para>
    In the terminal where you ran Ncat, you will see everything the web
    browser sent to request the page. You should see a
    <computeroutput>GET</computeroutput><indexterm><primary>GET HTTP method</primary></indexterm>
    line like the one you sent in
    the connect mode example. This shows that Ncat by default both sends
    and receives.
    </para>

    <para>
    If you try to refresh the page, it won't work. That's because Ncat
    ran out of input; it won't re-send what has already been sent. For
    more information on making a server that continually responds to
    requests, see the examples in
    <xref linkend="ncat-simple-services"/>. More HTTP server tricks can
    be found here in <xref linkend="ncat-httpserv"/>.
    </para>

  </sect2>
</sect1>

<sect1 id="ncat-protocols">
  <title>Protocols</title>

  <indexterm><primary>TLS</primary><see>SSL</see></indexterm>
  <indexterm><primary>Transport Layer Security (TLS)</primary><see>SSL</see></indexterm>

  <para>
  Ncat can use TCP, UDP, SCTP, SSL, IPv4, IPv6, and various combinations
  of these. TCP over IPv4 is the default.
  </para>

  <para>
  TCP,<indexterm significance="preferred"><primary>TCP</primary><secondary>in Ncat</secondary></indexterm>
  the Transmission Control Protocol, is the reliable protocol that
  underlies a great deal of Internet traffic. Ncat makes TCP connections
  by default. TCP may be combined with SSL.
  </para>

  <para>
  UDP,<indexterm significance="preferred"><primary>UDP</primary><secondary>in Ncat</secondary></indexterm>
  the User Datagram Protocol, is an unreliable protocol often used by
  applications that can't afford the overhead of TCP. Use the
  <option>--udp</option><indexterm><primary><option>--udp</option> (Ncat option)</primary></indexterm>
  option to make Ncat use UDP.
  UDP may be secured using the <option>--ssl</option> option, which enables
  Datagram TLS (DTLS)<indexterm><primary>DTLS</primary><secondary>Datagram TLS</secondary></indexterm>.
  </para>

  <para>
  SCTP,<indexterm significance="preferred"><primary>SCTP</primary><secondary>in Ncat</secondary></indexterm>
  the Stream Control Transmission Protocol, is a newer reliable
  protocol. It is selected with the
  <option>--sctp</option><indexterm><primary><option>--sctp</option> (Ncat option)</primary></indexterm>
  option. Ncat uses a TCP-compatible subset of SCTP features, not
  including multiple streams per connection or message boundaries. SCTP
  may be combined with SSL.
  </para>

  <para>
  SSL<indexterm significance="preferred"><primary>SSL</primary><secondary>in Ncat</secondary></indexterm>
  (Secure Sockets Layer) or
  TLS (Transport Layer Security) provides security to network traffic
  when used properly. Use the
  <option>--ssl</option><indexterm><primary><option>--ssl</option> (Ncat option)</primary></indexterm>
  to turn SSL on; it works with TCP or SCTP. See <xref
  linkend="ncat-ssl"/> for instructions and caveats.
  </para>

  <para>
  IPv4,<indexterm significance="preferred"><primary>IPv4</primary><secondary>in Ncat</secondary></indexterm>
  the Internet Protocol version 4, is the most popular version of the
  Internet Protocol in use. Using the
  <option>-4</option><indexterm><primary><option>-4 (Ncat option)</option></primary></indexterm>
  puts Ncat into IPv4-only mode; only IPv4 addresses will be used even
  if, for example, as hostname resolves to IPv6 addresses as well.
  </para>

  <para>
  IPv6<indexterm significance="preferred"><primary>IPv6</primary><secondary>in Ncat</secondary></indexterm>
  is the lesser-used successor to IPv4. Use
  <option>-6</option><indexterm><primary><option>-6</option> (Ncat option)</primary></indexterm>
  to put Ncat into IPv6-only mode.
  By default, Ncat will listen on both IPv4 and IPv6, and will connect to
  resolved addresses in the order they are returned by the operating system.
  </para>
</sect1>

<sect1 id="ncat-broker">
  <title>Connection Brokering</title>

  <para>
  One of Ncat's most useful and unique abilities is called
  connection brokering.  A listening Ncat in broker mode accepts
  connections from multiple clients. Anything received from one of
  the clients is sent back out to all the others.  In this way an
  Ncat broker acts like a network hub, broadcasting all traffic to
  everyone connected.
  </para>

  <para>
  Activate broker mode with the <option>--broker</option> option, which
  must be combined with
  <option>--listen</option>.  It wouldn't make sense for a client to be
  a broker. See <xref linkend="ncat-file-transfer"/> for details on using brokering to transfer files through restrictive firewalls,
  and <xref linkend="ncat-chat"/> for using brokering to set up multi-user chat rooms.
  </para>
</sect1>

<sect1 id="ncat-ssl">
  <title>SSL</title>

  <para>
  Ncat can encrypt its traffic using SSL. In connect mode, simply add the
  <option>--ssl</option><indexterm><primary><option>--ssl</option> (Ncat option)</primary></indexterm>
  option. <option>--ssl</option> works with TCP (the default) and
  SCTP<indexterm><primary>SCTP</primary><secondary>in Ncat</secondary></indexterm>
  (<option>--sctp</option><indexterm><primary><option>--sctp</option> (Ncat option)</primary></indexterm>
  option). Here is the syntax for connecting to
  an HTTPS server:
  <informalexample>
<literallayout>
<command>ncat -C --ssl <replaceable>server</replaceable> 443</command>
</literallayout>
  </informalexample>
  </para>

  <para>
  Sometimes an SSL server will require a client certificate for
  authentication. When this is the case, use the
  <option>--ssl-cert</option><indexterm><primary><option>--ssl-cert</option> (Ncat option)</primary></indexterm>
  and
  <option>--ssl-key</option><indexterm><primary><option>--ssl-key</option> (Ncat option)</primary></indexterm>
  options to give the locations of PEM-encoded files containing the
  certificate and private key, respectively. The certificate and key may
  be in the same file.
  </para>

  <para>
  <indexterm><primary>certificate verification</primary></indexterm>
  <indexterm><primary>trust</primary><see>certificate verification</see></indexterm>
  By default the client will not do any server certificate verification, so it
  will not be detected if the server has the wrong certificate or no
  certificate at all. Use the <option>--ssl-verify</option> option to
  require verification of the certificate and matching of the domain
  name.
  <indexterm><primary><option>--ssl-verify</option> (Ncat option)</primary></indexterm>
<literallayout>
<command>ncat -C --ssl-verify <replaceable>server</replaceable> 443</command>
</literallayout>
  Verification is done using the
  <filename>ca-bundle.crt</filename><indexterm><primary><filename>ca-bundle.crt</filename></primary></indexterm>
  certificate bundle shipped with Ncat, plus whatever trusted
  certificates the operating system may provide. If you want to verify a
  connection to a server whose certificate isn't signed by one of the
  default certification authorities, use the
  <option>--ssl-trustfile</option> to name a file containing
  certificates you trust. The file must be in PEM format.
  <indexterm><primary><option>--ssl-trustfile</option> (Ncat option)</primary></indexterm>
<literallayout>
<command>ncat -C --ssl-verify --ssl-trustfile <replaceable><filename>custom-certs.pem</filename></replaceable> <replaceable>server</replaceable> 443</command>
</literallayout>
  Verification should be done whenever it is feasible. Even with
  encryption, an unverified connection is vulnerable to a
  man-in-the-middle attack. Ncat does not do certificate
  revocation<indexterm><primary>certificate revocation</primary></indexterm><indexterm><primary>CRL</primary><see>certificate revocation</see></indexterm>
  checking.
  </para>

  <para>
    <indexterm><primary>SSL ciphers</primary><secondary>in Ncat</secondary></indexterm>
    SSL connections depend on the client and server agreeing on a common
    ciphersuite: a combination of key exchange, symmetric cipher, and message
    integrity mechanism. The choice of which ciphersuites to offer (as a
    client) or accept (as a server) is a matter of choice between the greatest
    compatibility and the greatest security. The default set, expressed as an
    OpenSSL cipherlist, is
    <literal>ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!MD5:@STRENGTH</literal>, a reasonable balance
    between the two ends of the spectrum. To set a different priority or
    initial choice, use the <option>--ssl-ciphers</option> option.
    <indexterm><primary><option>--ssl-ciphers</option> (Ncat option)</primary></indexterm>
    <literallayout>
      <command>ncat --ssl-ciphers <replaceable>HIGH:!aNULL:!eNULL</replaceable> <replaceable>server</replaceable> 443</command>
    </literallayout>
  </para>
    <indexterm><primary><option>--ssl-ciphers</option> (Ncat option)</primary></indexterm>

  <indexterm><primary>SSL</primary><secondary>in Ncat</secondary></indexterm>
  <indexterm><primary>certificate</primary><secondary>automatic generation of</secondary></indexterm>
  <indexterm><primary>certificate</primary><seealso><option>--ssl-cert</option></seealso></indexterm>
  <indexterm><primary>keys, cryptographic</primary><seealso><option>--ssl-key</option></seealso></indexterm>
  <para>
  Ncat can act as an SSL server as well. The server must provide a
  certificate that clients can verify if they choose. If you start an
  SSL server without using the <option>--ssl-cert</option> and
  <option>--ssl-key</option> options, Ncat will automatically generate a
  certificate and 2,048-bit RSA key. The certificate will of course not
  be trusted by any application doing certificate verification. In
  verbose mode, the key's fingerprint will be printed so you can do
  manual verification if desired.
  <xref linkend="ncat-ex-ssl-gen" xrefstyle="select: label nopage"/>
  shows sample output.
  </para>

  <example id="ncat-ex-ssl-gen">
    <title>Automatic certificate generation</title>
    <indexterm><primary><option>--ssl</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<screen>
$ <userinput>ncat -v --listen --ssl</userinput>
Ncat ( https://nmap.org/ncat )
Generating a temporary 2048-bit RSA key. Use --ssl-key and --ssl-cert to use a <continuation/>permanent one.
SHA-1 fingerprint: F0:13:BF:FB:2D:AA:76:88:22:60:3E:17:93:29:3E:0E:6B:92:C0:2F
</screen>
  </example>

  <para>
  Using an existing certificate and key is recommended whenever possible
  because it allows for robust server authentication. Use the
  <option>--ssl-cert</option> and <option>--ssl-key</option> options to
  pass in PEM-encoded files.
  For testing purposes you can generate a self-signed certificate and
  private key. If you have OpenSSL<indexterm><primary>OpenSSL</primary></indexterm>
  installed, use this command:
  <informalexample>
<literallayout>
<command>openssl req -new -x509 -keyout test-key.pem -out test-cert.pem</command>.
</literallayout>
  </informalexample>
  For purposes of certificate verification, the
  <varname>commonName</varname><indexterm><primary><varname>commonName</varname></primary></indexterm>
  in the certificate should match the fully qualified domain
  name<indexterm><primary>fully qualified domain name</primary></indexterm>
  of the host that will run the server. After generating the files,
  start the server:
  <informalexample>
<literallayout>
<command>ncat --listen --ssl --ssl-cert test-cert.pem --ssl-key test-key.pem</command>.
</literallayout>
  </informalexample>
  To make a verified client connection, copy the
  <filename>test-cert.pem</filename> file somewhere where the client can
  access it, then run
  <informalexample>
<literallayout>
<command>ncat --ssl-verify --ssl-trustfile test-cert.pem</command>.
</literallayout>
  </informalexample>
  </para>
</sect1>

<sect1 id="ncat-exec">
  <title>Command Execution</title>

  <para>
  Ncat can execute an external command after establishing a
  connection. The command's standard input and output<indexterm><primary>standard input</primary></indexterm><indexterm><primary>standard output</primary></indexterm>
  streams are redirected to use Ncat's network connection. Anything received over
  the connection is given to the command's stdin, and anything the
  command writes to stdout is sent back out over the connection. This feature makes
  almost any terminal application accessible over a network (with some
  caveats).
  </para>

  <para>
  There are three ways of running a command:
  <itemizedlist spacing="compact">
  <listitem>
  <option>--exec</option><indexterm><primary><option>--exec</option> (Ncat option)</primary></indexterm>
  runs a command without shell interpretation.
  </listitem>
  <listitem>
  <option>--sh-exec</option><indexterm><primary><option>--sh-exec</option> (Ncat option)</primary></indexterm>
  runs a command by passing a string to a system shell.
  </listitem>
  <listitem>
  <option>--lua-exec</option><indexterm><primary><option>--lua-exec</option> (Ncat option)</primary></indexterm>
  runs a Lua program using Ncat's built-in Lua interpreter.<indexterm><primary>Lua</primary><secondary>in Ncat</secondary></indexterm>
  </listitem>
  </itemizedlist>
  </para>

  <para>
  The
  <option>--exec</option><indexterm><primary><option>--exec</option> (Ncat option)</primary></indexterm>
  option (alias
  <option>-e</option>)<indexterm><primary><option>-e</option> (Ncat option)</primary><see><option>--exec</option></see></indexterm>
  takes the full pathname of a command to execute, along with its
  arguments. The command is executed directly; Ncat does not interpret
  the given string beyond splitting the command and its arguments.
  <xref linkend="ncat-ex-exec" xrefstyle="select: label nopage"/>
  shows an example of usage.
  </para>

  <example id="ncat-ex-exec">
    <title>Running a command with <option>--exec</option></title>
<literallayout><command>ncat -l --exec "/bin/echo Hello."</command></literallayout>
  </example>
  <para>
    On Windows, Ncat uses <code>CreateProcess()</code> to handle the parsing of command and arguments.
    This function will accept unquoted command paths containing spaces, but
    <ulink href="https://cwe.mitre.org/data/definitions/428.html">doing so is a security risk</ulink>.
    A command path that contains spaces <emphasis>must</emphasis> be quoted for safety.
  </para>

  <para>
  The
  <option>--sh-exec</option><indexterm><primary><option>--sh-exec</option> (Ncat option)</primary></indexterm>
  option
  (<option>-c</option>)<indexterm><primary><option>-c</option> (Ncat option)</primary><see><option>--sh-exec</option></see></indexterm>
  works the same as <option>--exec</option>, except that it
  executes the command by passing it to <command>/bin/sh -c</command>
  on Unix or <command>cmd.exe /C</command> on Windows.
  You don't have to use the full pathname of the command if the
  command is in the
  <envar>PATH</envar>.<indexterm><primary><envar>PATH</envar></primary></indexterm>
  Additionally you have access to shell facilities such as pipelines
  and environment variable expansion.
  <xref linkend="ncat-ex-sh-exec" xrefstyle="select: label nopage"/>
  shows a command run with <option>--sh-exec</option>. This server,
  when connected to, sends back the name of its working directory.
  </para>

  <example id="ncat-ex-sh-exec">
    <title>Running a command with <option>--sh-exec</option></title>
<literallayout><command>ncat -l --sh-exec "echo `pwd`"</command></literallayout>
  </example>

  <para>
  The
  <option>--lua-exec</option><indexterm significance="preferred"><primary><option>--lua-exec</option> (Ncat option)</primary></indexterm>
  option takes the filename of a Lua program to run. Ncat runs the
  program using its built-in interpreter and redirects its input and
  output streams. Anything the program writes to standard output (for
  example with <code>print</code> or <code>io.write</code>) is written
  to the connection, and any reads from standard input come from the
  connection. A nice thing about running programs written in Lua is that
  the same interpreter is used on all platforms, in comparison with
  shells that operate differently.
  </para>

  <para>
  That means that the default Ncat build
  is all you need to run a simple network service. To write a program, the
  standard text editor (even a Windows "notepad") is enough; to learn how
  to create programs in Lua, have a look at "Programming in Lua" book
  available for free at
  <ulink role="hidepdf" url="http://www.lua.org/pil/contents.html">Lua.org</ulink>
  website.
  <xref linkend="ncat-ex-lua-exec" xrefstyle="select: label nopage"/>
  shows how to run a program stored in a file called
  <filename>hello-luaexec.lua</filename>. You can find this script - and
  some other ones - in Nmap's source code package, in
  <literal>ncat/scripts</literal> directory - the latest versions of the
  scripts can be found in the
  <ulink role="hidepdf" url="https://svn.nmap.org/nmap/ncat/scripts/">Nmap project public SVN repository</ulink>.
  Here are the contents of the hello-luaexec.lua file, if you would prefer
  to create the file yourself:
  </para>

<programlisting>
--This is a --lua-exec "Hello world" example. In order to send to a client,
--all you need to do is output it to the standard output.

print("Hello, world!")
</programlisting>

  <example id="ncat-ex-lua-exec">
    <title>Running a command with <option>--lua-exec</option></title>
<literallayout><command>ncat -l --lua-exec hello-luaexec.lua</command></literallayout>
  </example>

  <para>
  Now, anyone that connects to our server will see the "Hello, world"
  message. For a script with a bit more capabilities, have a look at
<ulink role="hidepdf" url="https://svn.nmap.org/nmap/ncat/scripts/conditional.lua">conditional.lua</ulink>.
  It shows how to create a simple menu, receive some data from the user
  repeatedly and react according to her decisions. You might want to start
  off your experiments with Lua by making changes to this script. Also see
  <xref linkend="ncat-httpserv"/> for information on how to run a simple
  HTTP server in Lua.
  </para>

  <para>
  The exec options can be used in connect mode and listen mode. In
  listen mode, Ncat accepts one connection, runs the command, and then
  quits, just like listen mode without exec. But when listen mode is
  combined with
  <option>--keep-open</option>,<indexterm><primary><option>--keep-open (Ncat option)</option></primary><secondary>with <option>--exec</option></secondary></indexterm>
  Ncat will accept multiple connections, forking off a new handler for
  each.
  The server will keep running until you press
  <keycombo><keycap>ctrl</keycap><keycap>C</keycap></keycombo> or
  otherwise terminate it externally. In this way Ncat can work much like
  inetd.<indexterm><primary>inetd</primary></indexterm>
  Many examples of the use of <option>--exec</option> and
  <option>--sh-exec</option> in listen mode are found in
  <xref linkend="ncat-simple-services"/>.
  </para>

  <example id="ncat-ex-sh-exec-persistent">
    <title>Running an inetd-like server</title>
<literallayout><command>ncat -l --keep-open --exec "/bin/echo Hello."</command></literallayout>
  </example>

  <para>
  Whatever the exec mode, Ncat sets environment variables in the spawned
  program's environment that describe the connection.

  <variablelist>
  <varlistentry>
    <term><envar>NCAT_REMOTE_ADDR</envar></term><indexterm><primary><envar>NCAT_REMOTE_ADDR></envar> environment variable</primary></indexterm>
    <term><envar>NCAT_REMOTE_PORT</envar></term><indexterm><primary><envar>NCAT_REMOTE_PORT></envar> environment variable</primary></indexterm>
    <listitem>
    <para>
    The IP address and port number of the remote host. In connect mode, it's
    the target's address; in listen mode, it's the client's address.
    </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><envar>NCAT_LOCAL_ADDR</envar></term><indexterm><primary><envar>NCAT_LOCAL_ADDR></envar> environment variable</primary></indexterm>
    <term><envar>NCAT_LOCAL_PORT</envar></term><indexterm><primary><envar>NCAT_LOCAL_PORT></envar> environment variable</primary></indexterm>
    <listitem>
    <para>
    The IP address and port number of the local end of the connection.
    </para>
    </listitem>
  </varlistentry>
  <varlistentry>
    <term><envar>NCAT_PROTO</envar></term><indexterm><primary><envar>NCAT_PROTO></envar> environment variable</primary></indexterm>
    <listitem>
    <para>
    The protocol in use: one of <code>TCP</code>, <code>UDP</code>, and <code>SCTP</code>.
    </para>
    </listitem>
  </varlistentry>
  </variablelist>

  <xref linkend="ncat-ex-exec-env" xrefstyle="select: label nopage"/>
  shows the output of a Lua program that reads these variables.
  You can see these environment variables in action by running this

  </para>

  <example id="ncat-ex-exec-env">
    <title>Exec environment variables</title>
    <para>The contents of the program <filename>env.lua</filename>:
<programlisting>function env(v)
	print(string.format("%s %q", v, os.getenv(v)))
end
env("NCAT_REMOTE_ADDR")
env("NCAT_REMOTE_PORT")
env("NCAT_LOCAL_ADDR")
env("NCAT_LOCAL_PORT")
env("NCAT_PROTO")</programlisting>
    </para>
    <para>The output of running the program:
<screen>
$ <userinput>ncat -l --lua-exec env.lua &amp;</userinput>
$ <userinput>ncat localhost</userinput>
NCAT_REMOTE_ADDR "127.0.0.1"
NCAT_REMOTE_PORT "60179"
NCAT_LOCAL_ADDR "127.0.0.1"
NCAT_LOCAL_PORT "31337"
NCAT_PROTO "TCP"
</screen>
    </para>
  </example>

  <indexterm><primary>--lua-exec portability</primary></indexterm>
  <warning><para>
  When writing your own --lua-exec script, keep in mind that while Lua is
  very portable, there is a caveat related to running your Lua scripts
  written on Windows to Unix systems. For technical reasons, --lua-exec
  on Windows reloads the script every time it is run. Do not rely on this
  behavior on other systems though - on POSIX-compatible systems, the
  script is only loaded once and any modifications to its code will not
  be visible until you restart Ncat.
  </para></warning>

  <para>
  Any program that takes input and produces output can be executed by
  Ncat, but not all programs are suited to this kind of interaction.
  Many programs buffer their input and output,<indexterm><primary>buffering</primary><secondary>effect on Ncat of</secondary></indexterm>
  so if they receive some bytes, they many not process those bytes and
  write output until their input buffer is full, or the output may be
  deferred until the output buffer is full. If another program sends a
  few bytes and then waits for a response, it may hang indefinitely.
  Buffers are flushed when input or output ends, so even those
  programs that don't work interactively will work when run on an
  entire file at a time.
  </para>

  <para>
  Be careful when using the various exec
  options. It can be dangerous to connect a
  new application to a network, especially one that wasn't written
  with potentially hostile input in mind. Any local vulnerabilities in
  an application may become remote vulnerabilities when you execute
  it through Ncat.
  </para>
</sect1>

<sect1 id="ncat-output">
  <title>Output Options</title>

  <indexterm><primary>verbosity</primary><secondary>of Ncat</secondary></indexterm>
  <para>
  Like any proper pipeline utility, Ncat reads from
  standard input<indexterm><primary>standard input</primary></indexterm>
  and writes to
  standard output<indexterm><primary>standard output</primary></indexterm>
  so you can redirect I/O to or from any program or file.  The only
  exception is when Ncat is run with the <option>--exec</option> or
  <option>--sh-exec</option> options, in which case it communicates with
  the subprocess instead.  Nothing in the streams is added, removed, or
  altered, unless you specifically ask for it with an option such as
  <option>-C</option><indexterm><primary><option>-C</option> (Ncat option)</primary></indexterm>
  (CRLF processing) or
  <option>--telnet</option><indexterm><primary><option>-telnet</option> (Ncat option)</primary></indexterm>
  (Telnet negotiation). If Ncat prints any diagnostic messages, they are
  sent to
  standard error<indexterm><primary>standard error</primary></indexterm>
  so as not to interfere with the data stream. By default Ncat does not
  print any such messages, but you can enable them with the
  <option>--verbose</option><indexterm><primary><option>--verbose</option> (Ncat option)</primary></indexterm>
  (<option>-v</option>)<indexterm><primary><option>-v</option> (Ncat option)</primary><see><option>--verbose</option></see></indexterm>
  option. Use <option>-v</option> more than once for even more output.
  </para>

  <indexterm><primary>hex dump</primary></indexterm>
  <indexterm><primary>transcript</primary></indexterm>
  <indexterm><primary>log file</primary><secondary>of Ncat</secondary></indexterm>
  <para>
  Use the
  <option>--output</option><indexterm><primary><option>--output</option> (Ncat option)</primary></indexterm>
  option or its alias
  <option>-o</option><indexterm><primary><option>-o</option> (Ncat option)</primary><see><option>--output</option></see></indexterm>
  to record a transcript of everything sent and received to a file:
  <informalexample>
<literallayout>
<command>ncat -C --output smtp-debug.log mail.example.com 25</command>
</literallayout>
  </informalexample>
  The log contains everything sent and received without differentiation.
  Sometimes a hex dump is more useful than a plain text log; for that
  use
  <option>--hex-dump</option><indexterm><primary><option>--hex-dump</option> (Ncat option)</primary></indexterm>
  or
  <option>-x</option>.<indexterm><primary><option>-x</option> (Ncat option)</primary><see><option>--hex-dump</option></see></indexterm>
  Let's see what happens if we accidentally speak SMTP to an SSH server:
<screen>
$ <userinput>ncat -C --hex-dump ssh-hex.log scanme.nmap.org 22</userinput>
SSH-2.0-OpenSSH_4.3
<userinput>HELO example.com</userinput>
Protocol mismatch.
</screen>
  The <option>--hex-dump</option> log file for this session:
<screen>
[0000]   53 53 48 2D 32 2E 30 2D   4F 70 65 6E 53 53 48 5F   SSH-2.0- OpenSSH_
[0010]   34 2E 33 0A                                         4.3.
[0000]   48 45 4C 4F 20 65 78 61   6D 70 6C 65 2E 63 6F 6D   HELO exa mple.com
[0010]   0D 0A                                               ..
[0000]   50 72 6F 74 6F 63 6F 6C   20 6D 69 73 6D 61 74 63   Protocol  mismatc
[0010]   68 2E 0A                                            h..
</screen>
  Each transmission is dumped separately. There is a break and the
  counter at the left starts over each time there is a new send.
  </para>
</sect1>

<sect1 id="ncat-access">
  <indexterm><primary>access control</primary></indexterm>
  <title>Access Control</title>

  <para>
  A listening Ncat may control which hosts connect to it with the
  <option>--allow</option><indexterm><primary><option>--allow</option> (Ncat option)</primary></indexterm>
  and
  <option>--deny</option><indexterm><primary><option>--deny</option> (Ncat option)</primary></indexterm>
  options. Each of these takes a comma-separated list of host
  specifications. The syntax is almost identical to that recognized by Nmap for
  targets
  (see <ulink url="https://nmap.org/book/man-target-specification.html">the section called <quote>Target Specification</quote></ulink>).
  <!-- (see <xref linkend="host-discovery-specify-targets"/>). -->
  This includes IPv4 and IPv6 addresses, hostnames, IPv4 octet ranges,
  and CIDR netmasks. In Ncat (unlike Nmap), CIDR netmasks are supported for IPv6
  addresses.
  </para>

  <para>
  With <option>--allow</option>, any hosts matching one of the listed specifiers
  are allowed and all others are denied. With <option>--deny</option>,
  those hosts matching the list are denied and all others are accepted.
  If a host matches both the <option>--allow</option> and
  <option>--deny</option> lists, it is denied.
  </para>

  <para>
  Use
  <option>--allowfile</option><indexterm><primary><option>--allowfile</option> (Ncat option)</primary></indexterm>
  and
  <option>--denyfile</option><indexterm><primary><option>--denyfile</option> (Ncat option)</primary></indexterm>
  to allow or deny a list of host/network specifiers stored in a file. Each line of the
  file contains a specification in one of the forms listed above. Any
  file acceptable to Nmap's
  <option>-iL</option><indexterm><primary><option>-iL</option></primary></indexterm>
  and
  <option>--excludefile</option><indexterm><primary><option>--excludefile</option></primary></indexterm>
  options is suitable for <option>--allowfile</option> and
  <option>--denyfile</option>.
  </para>

  <para>
  The following example commands demonstrate various kinds of access control.
  </para>

  <!-- 2001:db8::/32 is an IPv6 prefix reserved for documentation, RFC 3849. -->
  <variablelist>
    <varlistentry>
      <term>Allow one host, deny all others</term>
      <listitem>
<literallayout>
<command>ncat -l --allow 192.168.0.125</command>
<command>ncat -l --allow 2001:db8::7d</command>
<command>ncat -l --allow trusted.example.com</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>Deny one host, allow all others</term>
      <listitem>
<literallayout>
<command>ncat -l --deny 192.168.0.200</command>
<command>ncat -l --deny 2001:db8::c8</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>Allow hosts on a local network, deny all others</term>
      <listitem>
<literallayout>
<command>ncat -l --allow 192.168.0.0/24</command>
<command>ncat -l --allow 192.168.0.0-255</command>
<command>ncat -l --allow 2001:db8::/32</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>Allow or deny hosts from a file</term>
      <listitem>
<literallayout>
<command>ncat -l --allowfile trusted-hosts.txt</command>
<command>ncat -l --denyfile external-hosts.txt</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Be aware that host-based access control is susceptible to spoofing attacks and various other possible failures.  These mechanisms should not be relied on for complete security.
  </para>

  <para>
  Another kind of access control is simply limiting the maximum number
  of connections a listening Ncat will accept. Use the
  <option>--max-conns</option><indexterm><primary><option>--max-conns</option> (Ncat option)</primary></indexterm>
  option or its
  <option>-m</option><indexterm><primary><option>-m</option></primary><see><option>--max-conns</option></see></indexterm>
  alias to do that. The default maximum number of connections is 100, or 60 on Windows.
  <informalexample>
<literallayout>
<command>ncat -l --max-conns 5</command>
</literallayout>
  </informalexample>
  </para>
</sect1>

<sect1 id="ncat-proxy">
  <title>Proxying</title>

  <indexterm><primary>HTTP proxy</primary><see>proxy</see></indexterm>
  <indexterm><primary>proxy</primary><secondary>Ncat as</secondary></indexterm>
  <para>
  Ncat can route its connections through a
  SOCKS&nbsp;4<indexterm><primary>SOCKS proxy</primary></indexterm>, SOCKS&nbsp;5
  or HTTP<indexterm><primary>HTTP proxy</primary></indexterm> proxy. A basic
  connection looks like
  <informalexample>
<indexterm><primary><option>--proxy</option> (Ncat option)</primary></indexterm>
<indexterm><primary><option>--proxy-type</option> (Ncat option)</primary></indexterm>
<literallayout>
<command>ncat --proxy <replaceable>proxyhost</replaceable><optional>:<replaceable>proxyport</replaceable></optional> --proxy-type <group choice="req"><arg choice="plain">http</arg><arg choice="plain">socks4</arg><arg choice="plain">socks5</arg></group> <replaceable>host</replaceable> <optional><replaceable>port</replaceable></optional></command>
</literallayout>
  </informalexample>
  <option>--proxy-type</option> may be omitted; it defaults to
  <literal>http</literal>. If <replaceable>proxyport</replaceable> is
  omitted, it defaults to the well-known port for the chosen proxy type:
  1080 for SOCKS and 3128 for HTTP. An exception to this rule is when
  the proxy host is given by a IPv6 address; in this case the port is
  required because otherwise it would be ambiguous whether the digits
  after the last colon are the port number or part of the address.
  </para>

  <para>
  If the proxy server requires authentication, use the
  <option>--proxy-auth</option><indexterm><primary><option>--proxy-auth</option> (Ncat option)</primary></indexterm>
  option. Use
  <command>--proxy-auth <replaceable>username</replaceable>:<replaceable>password</replaceable></command>
  for HTTP and SOCKS5 proxies and
  <command>--proxy-auth <replaceable>username</replaceable></command>
  for SOCKS4 proxies.
  </para>

  <para>
  Ncat can act as a proxy server itself in listen mode. The only proxy
  type supported in this case is <literal>http</literal>.
  <informalexample>
<literallayout>
<command>ncat -l 3128 --proxy-type http</command>
<command>ncat -l 3128 --proxy-type http --proxy-auth <replaceable>user</replaceable>:<replaceable>pass</replaceable></command>
</literallayout>
  </informalexample>
  In listen mode the proxy port number is not automatically set and will
  be the default of 31337 unless specified. The proxy supports the
  GET,<indexterm><primary>GET HTTP method</primary></indexterm>
  HEAD,<indexterm><primary>HEAD HTTP method</primary></indexterm>
  and POST<indexterm><primary>POST HTTP method</primary></indexterm>
  methods used in web browsing, as well as the
  CONNECT<indexterm><primary>CONNECT HTTP method</primary></indexterm>
  method that allows tunneling arbitrary TCP connections. (When Ncat
  connects as a client, it uses CONNECT.) Use
  <option>--proxy-auth</option> to make the server require
  authentication with a specific username and password.
  </para>

  <para>
  For HTTP, both the Basic<indexterm><primary>Basic authentication (HTTP)</primary></indexterm>
  and Digest<indexterm><primary>Digest authentication (HTTP)</primary></indexterm>
  authentication schemes are supported, as both a client and a server.
  Digest is more secure, so the Ncat client will use that in preference
  to Basic when it is available. The server offers both schemes to its
  clients. See
  RFC&nbsp;2617,<indexterm><primary>RFC 2617</primary></indexterm>
  section 4 for security considerations of HTTP authentication. Basic
  sends credentials in the clear and Digest does not. Ncat's
  implementation of Digest authentication allows replay attacks for up
  to 10 seconds (replay and other attacks are always possible with
  Basic).
  </para>

  <indexterm><primary>open proxy</primary></indexterm>
  <warning><para>
  Ncat's HTTP proxy is designed to stay out of your way and help you
  make temporary network connections. It shouldn't be used as an
  everyday proxy exposed to the Internet. You can limit who connects
  using <option>--allow</option>,<indexterm><primary><option>--allow</option></primary></indexterm>
  <option>--deny</option>,<indexterm><primary><option>--deny</option></primary></indexterm> and
  <option>--proxy-auth</option>, but these are not strong forms of
  authentication. An unauthenticated proxy is dangerous because it may
  enable others to perform attacks or help them evade detection. The
  CONNECT<indexterm><primary>CONNECT HTTP method</primary><secondary>danger of</secondary></indexterm>
  capability is especially dangerous because it enables any kind
  of traffic, not just HTTP.
  </para></warning>
</sect1>

<sect1 id="ncat-other-options">
  <title>Other Options</title>

  <para>
  This section contains descriptions of all options that haven't been
  discussed so far.
  </para>

  <para>
  The
  <option>--nodns</option><indexterm><primary><option>--nodns</option> (Ncat option)</primary></indexterm>
  option (and its short form
  <option>-n</option>)<indexterm><primary><option>-n</option> (Ncat option)</primary><see><option>--nodns</option></see></indexterm>
  instructs Ncat never to resolve names into addresses. All hosts must
  appear as IPv4 or IPv6 addresses.
  </para>

  <para>
  Ncat can be used as a Telnet client or server with the
  <option>--telnet</option><indexterm><primary><option>--telnet</option> (Ncat option)</primary></indexterm>
  option
  (<option>-t</option>).<indexterm><primary><option>-t</option> (Ncat option)</primary><see><option>--telnet</option></see></indexterm>
  This simply causes Ncat to respond negatively to any questions asked
  by the other host in the binary Telnet protocol, removing such
  negotiations from the stream seen by the user. The primary use of this
  option is to allow running canned Telnet scripts.
  </para>

  <para>
  The
  <option>--send-only</option><indexterm><primary><option>--send-only</option> (Ncat option)</primary></indexterm>
  and
  <option>--recv-only</option><indexterm><primary><option>--send-only</option> (Ncat option)</primary></indexterm>
  options do what their names imply, turning Ncat into a one-way
  communications channel instead of its default two-way channel. A usage example is gathering data from a server
  without the possibility of accidentally sending something typed at the
  keyboard. <option>--send-only</option> in both connect and listen
  modes causes Ncat to quit when its input runs out. Normally it will
  not quit until the network connection is closed because the remote
  side may still send something, but in the case of
  <option>--send-only</option> there's no reason to receive anything
  more.
  </para>

  <sect2 id="ncat-source">
    <title>Source Options</title>

    <para>
    In connect mode, you may set the source address and port used for
    the connection with the
    <option>--source</option><indexterm><primary><option>--source</option> (Ncat option)</primary></indexterm>
    (<option>-s</option>)<indexterm><primary><option>-s</option> (Ncat option)</primary><see><option>--source</option></see></indexterm>
    and
    <option>--source-port</option><indexterm><primary><option>--source-port</option> (Ncat option)</primary></indexterm>
    (<option>-p</option>).<indexterm><primary><option>-p</option> (Ncat option)</primary><see><option>--source-port</option></see></indexterm>
    The <option>-s</option> option only works for locally configured
    addresses; it doesn't work like Nmap's
    <option>-S</option><indexterm><primary><option>-S</option></primary></indexterm>
    option. The value of <option>-p</option> is that sometimes firewalls
    will allow traffic that comes from certain source ports (such as 20 or 53).
    <!-- See <xref linkend="defeating-firewalls-source-port"/>. -->
    </para>

    <indexterm><primary>source routing</primary><secondary>in Ncat</secondary></indexterm>
    <para>
    The
    <option>-g</option><indexterm><primary><option>-g</option> (Ncat option)</primary></indexterm>
    option allows hops selection for IPv4 loose source routing. List the
    hops in order by giving <option>-g</option> multiple times or by
    separating the hops with commas. By default the source routing
    pointer is 4 in the packets sent, indicating the first hop in the
    list. You may set the pointer to another value with the
    <option>-G</option><indexterm><primary><option>-G</option> (Ncat option)</primary></indexterm>
    option. The pointer value must be a multiple of 4 between 4 and 28,
    but some operating systems only support 4.
    </para>
  </sect2>

  <sect2 id="ncat-timing">
    <title>Timing</title>

    <para>
    Ncat offers various options to control timing. Each of them take an
    argument that is assumed to be in seconds, unless followed by
    <quote>ms</quote> for milliseconds,
    <quote>s</quote> for seconds, <quote>m</quote> for minutes, or
    <quote>h</quote> for hours. <quote>30s</quote> means 30 seconds.  This format should already be familiar to Nmap users.
    </para>

    <para>
    The
    <option>--delay</option><indexterm><primary><option>--delay</option> (Ncat option)</primary></indexterm>
    option and its short form
    <option>-d</option><indexterm><primary><option>-d</option> (Ncat option)</primary><see><option>--delay</option></see></indexterm>
    make Ncat wait the given amount of time between each discrete read
    or write operation. For example, <command>--delay 500ms</command>
    enforces a delay of half a second.
    </para>

    <para>
    The
    <option>--idle-timeout</option><indexterm><primary><option>--idle-timeout</option> (Ncat option)</primary></indexterm>
    option and it synonym
    <option>-i</option><indexterm><primary><option>-i</option> (Ncat option)</primary><see><option>--idle-timeout</option></see></indexterm>
    allow setting a timeout for reads and writes in connect mode. If the
    client fails to read or write for the given time period, the
    connection is dropped. These options do not work in listen mode.
    </para>

    <para>The
    <option>--wait</option><indexterm><primary><option>--wait</option></primary></indexterm> (or <option>-w</option> for short)<indexterm><primary><option>-w</option> (Ncat option)</primary><see><option>--wait</option></see></indexterm>
    option sets how long Ncat will wait for a connection to be established in
    connect mode. The default is 10 seconds.
    </para>
  </sect2>
</sect1>

<sect1 id="ncat-file-transfer">
  <title>File Transfer</title>
  <indexterm><primary>file transfer with Ncat</primary></indexterm>

  <para>
  There is no shortage of ways to transfer a file over a network. Most
  file transfers are ably handled by email, network file systems, HTTP,
  SFTP, or other protocols. What do you do, though, when that file is
  too big to email, the transfer is between two machines not connected
  to the Internet, or you just need to do one quick file transfer
  without having to set up and tear down a file server? In these and
  other situations Ncat can be the right tool for the job. Some tricky
  file transfer scenarios can really make you appreciate the flexibility
  of a raw network pipe.
  </para>

  <para>
  As you know, Ncat by default sends all its traffic without encryption,
  so it is possible for someone to intercept files in transit. See
  <xref linkend="ncat-ssl"/> for one method of encrypting traffic.
  </para>

  <para>
  By default, Ncat doesn't close its connection until it is closed by
  the remote end, even after it has exhausted its input. That is because
  (as far as Ncat knows) the remote server may still have data to send
  back. The
  <option>--send-only</option><indexterm><primary><option>--send-only</option> (Ncat option)</primary></indexterm>
  option, when applicable, changes this behavior to close the connection
  and quit at the end of input. This is normally what you want when
  doing a one-way file transfer.
  </para>

  <para>
  A basic file transfer is very simple: Start Ncat in listen mode on one
  end, start Ncat in connect mode on the other end, and pipe the file
  over the connection. There are two ways to do this that differ only in
  which end listens, the sender or the receiver. Sometimes you can't
  create a listening socket on one end of the transfer because of a lack
  or permissions, NAT, or filtering. As long as you can listen on at
  least one end, though, you can use this technique.
  </para>

  <para>
  These examples show how to transfer <filename>inputfile</filename> on
  host1 to <filename>outputfile</filename> on host2. Here no port number
  was specified so Ncat will use its default
  port<indexterm><primary>default port of Ncat</primary></indexterm> of
  31337. To use a different port just list it on the command line.
  </para>

  <variablelist>
    <varlistentry>
      <term>Transfer a file, receiver listens</term>
      <listitem>
<indexterm><primary><option>--listen</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<indexterm><primary><option>-l</option> (Ncat option)</primary><see><option>--listen</option></see></indexterm>
<literallayout>
host2$ <userinput>ncat -l &gt; outputfile</userinput>
host1$ <userinput>ncat --send-only host2 &lt; inputfile</userinput>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>Transfer a file, sender listens</term>
      <listitem>
<literallayout>
host1$ <userinput>ncat -l --send-only &lt; inputfile</userinput>
host2$ <userinput>ncat host1 &gt; outputfile</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Note the order of the commands. The listener must be started first,
  regardless of the direction of transfer, or else the client will not
  have anything to connect to.
  </para>

  <para>
  The above technique works fine for sending a single file. One way to
  send multiple files is to bundle them up with <command>tar</command>
  or <command>zip</command> and send the archive file. But there's an
  even easier way. Just pipe the output of <command>tar</command>
  directly into Ncat on the sending side, and pipe Ncat's output into
  <command>tar</command> on the receiving side. This is especially
  useful when the sending computer doesn't have enough free disk space
  to hold the archive file. Here's how to transfer
  <replaceable>files</replaceable> using the <quote>receiver
  listens</quote> method, though of course the <quote>sender
  listens</quote> method works just as well.
  </para>

  <variablelist>
    <varlistentry>
      <term>Transfer a bundle of files</term>
      <listitem>
<literallayout>
host2$ <userinput>ncat -l | tar xzv</userinput>
host1$ <userinput>tar czv <replaceable>files</replaceable> | ncat --send-only host2</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Not only tar files but any stream of bytes can be transferred in this
  way. Here is an example of transferring an entire disk image from host1
  to host2. Naturally, the disk should be unmounted or mounted
  read-only.
  </para>

  <variablelist>
    <varlistentry>
      <term>Transfer a disk image</term>
      <listitem>
<literallayout>
host2$ <userinput>ncat -l &gt; host1-hda.image</userinput>
host1$ <userinput>ncat --send-only host2 &lt; /dev/hda</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Disk images are typically large files that take a long time to
  transfer. You can compress the image on the fly while sending and
  decompress it on the other end. Whether this makes an improvement
  depends on the speed of the network and the compression program.
  </para>

  <variablelist>
    <varlistentry>
      <term>Transfer a disk image with compression</term>
      <listitem>
<literallayout>
host2$ <userinput>ncat -l | bzip2 -d &gt; host1-hda.image</userinput>
host1$ <userinput>cat /dev/hda | bzip2 | ncat --send-only host2</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  The basic file transmission technique described at the beginning of
  this section fails if neither participating host is capable of
  listening, or the two hosts can't communicate directly. This situation
  has become common with the prevalence of network address translation.
  A way to work around it is to use a third host as an intermediary. The
  intermediate host listens in connection brokering mode and the other
  two hosts connect to it. Recall from <xref linkend="ncat-broker"/>
  that in connection brokering mode any input received on one socket is
  copied and sent out to all other sockets. With just two hosts
  connected this is especially simple: anything coming from one host
  gets forwarded to the other. This example shows host1 sending
  <filename>inputfile</filename> to <filename>outputfile</filename> on
  host2, using host3 as an intermediary.
  </para>

  <variablelist>
    <varlistentry>
      <term>Transfer a file through an intermediary</term>
      <listitem>
<indexterm><primary><option>--broker</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
host3$ <userinput>ncat -l --broker</userinput>
host2$ <userinput>ncat host3 &gt; outputfile</userinput>
host1$ <userinput>ncat --send-only host3 &lt; inputfile</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Note that it's important for host2 (the receiving host) to connect to
  the broker before host1 (the sending host) does. The broker does not
  buffer received data to send to hosts that connect later. After the
  file is transferred, it is necessary to forcibly disconnect the Ncat
  on host2 with
  <keycombo><keycap>ctrl</keycap><keycap>C</keycap></keycombo>. The
  broker never disconnects any of its clients.
  </para>
</sect1>

<sect1 id="ncat-chat">
  <title>Chatting</title>

  <para>
  In its most basic form, Ncat simply moves bits from one place to
  another. This is all that is needed to set up a simple chat system. By
  default, Ncat reads from
  standard input<indexterm><primary>standard input</primary></indexterm>
  and writes to
  standard output,<indexterm><primary>standard output</primary></indexterm>
  meaning that it will send whatever is typed at the keyboard and will
  show on the screen whatever is received.
  </para>

  <variablelist>
    <varlistentry>
      <term>Two-user chat</term>
      <listitem>
<literallayout>
host1$ <userinput>ncat -l</userinput>
host2$ <userinput>ncat host1</userinput>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  With this setup, two users can communicate with each other. Whatever
  one types will appear on the screen of the other. Be aware that
  standard input is probably line-buffered so it may be necessary to press
  <keycap>enter</keycap> before a line is sent. Which side listens
  and which side connects is not important in this situation, except that the listener must start ncat first.
  </para>

  <para>
  The above technique is limited to one-on-one conversations. If more
  users connect to the server, each one will effectively create a new
  chat channel with the server; none of the connecting users will hear
  each other. Multi-user chatting is easily supported using connection
  brokering with the <option>--broker</option> option (see
  <xref linkend="ncat-broker"/>). In broker mode, anything received on
  one connection is sent out to all other connections, so everyone can
  talk with everyone else.
  </para>

  <indexterm><primary>chat mode (Ncat)</primary></indexterm>
  <para>
  When many users are chatting through a connection broker, it can be
  hard to know who is saying what. For these cases Ncat provides a simple
  hack to tell users apart. When the
  <option>--chat</option><indexterm><primary><option>--chat</option> (Ncat option)</primary></indexterm>
  option is given, connection brokering is automatically enabled. Each
  message received is prefixed with an ID before being relayed to all
  other clients. The ID is unique for each client connection, and
  therefore functions something like a username. Also, in chat mode any
  control characters are escaped so they won't mess up your terminal.
  The server is started with
<literallayout>
server$ <userinput>ncat -l --chat</userinput>
</literallayout>
  </para>

  <para>
  Once the server is started, this is how the chat appears to one of the
  connected users. The lines that begin with
  <literal>&lt;user<replaceable>n</replaceable>&gt;</literal> are from
  other connected users. The line beginning with
  <literal>&lt;user0&gt;</literal> was sent by the listening broker.
  </para>

<screen>
client$ <userinput>ncat server</userinput>
&lt;user6&gt; Is anyone there?
<userinput>I'm here.</userinput>
&lt;user5&gt; Me too.
&lt;user0&gt; Go away, all of you.
</screen>

  <para>
  The user IDs generated by Ncat are based on the file descriptor for
  each connection, and must be considered arbitrary. There is no way to
  choose a particular ID or make one persist across sessions.
  Nevertheless, <option>--chat</option> can come in handy for those
  quick multi-user conversations.
  </para>
</sect1>

<sect1 id="ncat-tricks">
  <title>Neat Tricks</title>

  <sect2 id="ncat-smtp">
    <title>Send Mail</title>

    <para>
    It is great fun to interact with text-based network protocols with
    nothing more than Ncat and a keyboard. Here's a short example
    showing how to send email by talking to an SMTP server. SMTP is
    described in
    RFC&nbsp;5321,<indexterm><primary>RFC 5321</primary></indexterm>
    but you don't need to know much about the protocol to send a simple
    message. The service's assigned port number is 25, and we use
    <option>-C</option> because it requires CRLF line endings.
    <xref linkend="ncat-ex-smtp" xrefstyle="select: label nopage"/>
    contains a transcript of a session.
    </para>

    <example id="ncat-ex-smtp">
      <title>Ncat as mail client</title>
<indexterm><primary><option>--crlf</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<screen>
$ <userinput>ncat -C mail.example.com 25</userinput>
220 mail.example.com ESMTP
<userinput>HELO client.example.com</userinput>
250 mail.example.com Hello client.example.com
<userinput>MAIL FROM:a@example.com</userinput>
250 OK
<userinput>RCPT TO:b@example.com</userinput>
250 Accepted
<userinput>DATA</userinput>
354 Enter message, ending with "." on a line by itself
<userinput>From: a@example.com
To: b@example.com
Subject: Greetings from Ncat

Hello. This short message is being sent by Ncat.
.</userinput>
250 OK
<userinput>QUIT</userinput>
221 mail.example.com closing connection
</screen>
    </example>

    <para>
    To make this example work for you, change
    <literal>mail.example.com</literal> to your SMTP server and
    <literal>client.example.com</literal> to your domain
    name. Naturally you'll want to change the email addresses and
    message too. It will likely only work when using your normal mail
    server with your real email address, or when using the recipient's
    mail server (look up the MX record for the domain name in their
    email address).
    </para>

    <para>
    Obviously this technique can be used for more than just sending
    mail. Ncat is a great interactive debugging tool for any text-based
    protocol. Such debugging is sometimes done with the
    <command>telnet</command> command, because it provides something
    like a raw text stream. Ncat offers a few advantages over
    <command>telnet</command>, though. Ncat doesn't print anything
    except what is sent by the remote host. Telnet isn't suitable for
    arbitrary binary data because it reserves some bytes as control
    characters. The <command>telnet</command> command quits when its
    input runs out, so you may not see what the other end sends. And
    finally, <command>telnet</command> doesn't do UDP.
    </para>
  </sect2>

  <sect2 id="ncat-httpserv">
    <title>Turn Ncat into a simple web server</title>

    <para>
    Continuing the example from <xref linkend="ncat-listen"/>, we can
    create a simple HTTP server that serves the
    <literal>index.html</literal> file using the following command:
    </para>

<literallayout>
<command>ncat -lk -p 8080 --sh-exec "echo -e 'HTTP/1.1 200 OK\r\n'; cat index.html"</command>
</literallayout>

    <para>
    Or, if you're a Windows user:
    </para>

<literallayout>
<command>ncat -lk -p 8080 --sh-exec "echo HTTP/1.1 200 OK&amp; echo(&amp;type index.html"</command>
</literallayout>

    <para>
    This will start the HTTP server, serving the <literal>index.html</literal>
    file from your current working directory. To try it out, visit
    <userinput>http://localhost:8080/</userinput> using
    your web browser. You can also skip <literal>:8080</literal> from the
    URL if you specified <literal>-p 80</literal> instead of
    <literal>-p 8080</literal> in the command above. Note that it will send
    this file regardless of the entered URL - to change the file being sent,
    you need to change the Ncat command or use the httpd.lua script (see
    below).
    </para>

    <para>
    Since Ncat v6.40, it is possible to use --lua-exec feature to run a Lua
    script turning Ncat into a web server. In order to do that, need the
    httpd.lua script which is bundled with the Ncat source in the
    <literal>ncat/scripts/</literal> directory. With the httpd.lua script in
    your working directory, run Ncat in listening mode:</para>

<literallayout>
<command>ncat --lua-exec httpd.lua --listen 8080 --keep-open</command>
</literallayout>

    <para>
    This will spawn a HTTP server on TCP port 8080. Unlike the previous
    example though, the httpd.lua script works without modification on all
    POSIX-compatible systems and also on Windows. Moreover, you can specify
    in the URL any other file from the current directory or one of its
    subdirectories and it will be sent to the user, unlike the
    <literal>--sh-exec</literal> example.
    </para>

    <indexterm><primary>Ncat HTTP server on production</primary></indexterm>
    <warning><para>
    The Ncat HTTP server examples shown above are very simple and may be not
    as  powerful as complete HTTP servers, such as Apache HTTPD. It is not
    advised to use them in production environments (such as public website
    hosting). It might be useful, though, if you need to quickly spawn a HTTP
    server to copy some files or for educational purposes.
    </para></warning>

  </sect2>

  <sect2 id="ncat-chain">
    <title>Chain Ncats Together</title>

    <para>
    Ncat is designed to work within a pipeline, so naturally the output
    of one instance of Ncat can be fed into the input of another. Here
    is one way to send a log file from host1 to host3 by way of host2:
<screen>
host3$ <userinput>ncat -l &gt; log.txt</userinput>
host2$ <userinput>ncat -l | ncat host3</userinput>
host1$ <userinput>ncat --send-only host2 &lt; log.txt</userinput>
</screen>
    </para>

    <para>
    A possible problem with this technique is that it is one-way: host1 can
    send to host3 but there is no way for host3 to send anything back to
    host1. In this case it doesn't matter, but it can be done with a
    small change. Consider this:
<screen>
host3$ <userinput>ncat -l &gt; log.txt</userinput>
host2$ <userinput>ncat -l --sh-exec "ncat host3"</userinput>
host1$ <userinput>ncat --send-only host2 &lt; log.txt</userinput>
</screen>
    The Ncat listening on host2, upon receiving a connection, creates a
    new Ncat to speak to host3 and connects the inputs and outputs of
    the programs running on host1 and host3 together. The same trick can
    be used on the local host too. This example forwards the local port
    8080 to the web server on example.org:
    <informalexample>
<literallayout>
<command>ncat -l localhost 8080 --sh-exec "ncat example.org 80"</command>
</literallayout>
    </informalexample>
    </para>
  </sect2>

  <sect2 id="ncat-unwrap-ssl">
    <title>Unwrap SSL</title>

    <!-- This trick was suggested by Brandon Enright.
         https://seclists.org/nmap-dev/2009/q1/379 -->
    <para>
    Suppose you need to connect to an
    IMAP<indexterm><primary>IMAP</primary></indexterm> server that
    requires SSL, but your mail reader doesn't support SSL. Ncat can act
    as the encrypted bridge to connect the client and server. You will
    connect the mail client to a local port and Ncat will forward the
    traffic, encrypted, to the server. Here's how to connect IMAP (port
    143) on the local host to
    IMAP over SSL (port 993)<indexterm><primary>IMAPS</primary></indexterm>
    on <literal>imap.example.com</literal>.
<literallayout>
<command>ncat -l localhost 143 --sh-exec "ncat --ssl imap.example.com 993"</command>
</literallayout>
    Once this is in place, instruct the mail client to connect to the
    IMAP server on localhost.
    </para>

    <para>
    This trick works for protocols that pass traffic strictly between
    two hosts. It doesn't work well for
    HTTP<indexterm><primary>HTTP</primary></indexterm>
    because HTTP is usually aware of hostnames and often involves
    multiple hosts.
    </para>
  </sect2>

  <sect2 id="ncat-ssh-tunnel">
    <title>Use SSH Through an Ncat Tunnel</title>

    <!-- This trick was suggested by Greg Darke.
         https://seclists.org/nmap-dev/2009/q1/403 -->
    <para>
    With Ncat and OpenSSH<indexterm><primary>OpenSSH</primary></indexterm>
    you can SSH to a host behind a NAT<indexterm><primary>network address translation</primary></indexterm>
    router without having to forward ports on the router. The router
    must have Ncat installed. Here is how to SSH to
    <filename><replaceable>host</replaceable></filename> through
    <filename><replaceable>router</replaceable></filename>:
<literallayout>
<command>ssh -o ProxyCommand="ssh -q <replaceable>router</replaceable> ncat %h %p" <replaceable>host</replaceable></command>
</literallayout>
    </para>
    <para>
    The <varname>ProxyCommand</varname> option of <command>ssh</command>
    tells how to open the SSH connection to
    <filename><replaceable>host</replaceable></filename>. It does this
    by opening another SSH session to
    <filename><replaceable>router</replaceable></filename> and
    connecting it to
    <filename><replaceable>host</replaceable></filename> with Ncat.
    </para>

    <para>
    If your SSH server administrator did not disable tunneling (which is
    enabled in most default configurations), you can use the proxy server
    built into SSH. Use the following command to spawn a proxy server on
    TCP port 8080 of your local machine that tunnels the traffic through
    the SSH connection:
    </para>

<literallayout>
<command>ssh router -D 8080</command>
</literallayout>

    <para>
    Now you can make connections inside the network using Ncat's proxy client
    capabilities. For example, to connect to host with IP address
    192.168.1.123 that is behind the router, you can use the following
    command if you spawned the tunnel:
    </para>

<literallayout>
<command>ncat --proxy localhost:8080 --proxy-type socks4 192.168.1.123</command>
</literallayout>

  </sect2>

  <sect2 id="ncat-nmap-version">
    <title>Watch What Nmap's Version Detection is Doing</title>

    <para>
    <!-- <xref linkend="vscan"/> tells all about Nmap's version detection
    system. --> Ncat can show you at a low level what's going on when Nmap
    version-scans a service. We'll make a service that only listens and
    instruct Nmap to use every version probe in the book. Set up Ncat to
    listen and record a hex dump log. The
    <option>--keep-open</option><indexterm><primary><option>--keep-open</option> (Ncat option)</primary></indexterm>
    option will make Ncat keep listening and accepting more connections
    after the first one is finished, contrary to the normal listen mode
    behavior of quitting when the first connection ends. Some version
    probes are binary so redirect standard output to
    <filename>/dev/null</filename><indexterm><primary><filename>/dev/null</filename></primary></indexterm>
    to avoid writing them to the screen.
    <informalexample>
<indexterm><primary><option>--hex-dump</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<indexterm><primary><option>--keep-open</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<command>ncat -l --keep-open 5200 --hex-dump vscan.log &gt; /dev/null</command>
</literallayout>
    </informalexample>
    Now scan the open port you made:
    <informalexample>
<indexterm><primary><option>--version-all</option></primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>nmap -d -sV --version-all localhost -p 5200</command>
</literallayout>
    </informalexample>
    An except of the hex dump is shown in
    <xref linkend="ncat-ex-nmap-version" xrefstyle="select: label nopage"/>.
    </para>

    <example id="ncat-ex-nmap-version">
      <title>Hex dump of Nmap version detection</title>
<screen><![CDATA[[0000]   0D 0A 0D 0A                                         ....
[0000]   47 45 54 20 2F 20 48 54   54 50 2F 31 2E 30 0D 0A   GET / HT TP/1.0..
[0010]   0D 0A                                               ..
[0000]   4F 50 54 49 4F 4E 53 20   2F 20 48 54 54 50 2F 31   OPTIONS  / HTTP/1
[0010]   2E 30 0D 0A 0D 0A                                   .0....
[0000]   4F 50 54 49 4F 4E 53 20   2F 20 52 54 53 50 2F 31   OPTIONS  / RTSP/1
[0010]   2E 30 0D 0A 0D 0A                                   .0....
[0000]   80 00 00 28 72 FE 1D 13   00 00 00 00 00 00 00 02   ...(r... ........
[0010]   00 01 86 A0 00 01 97 7C   00 00 00 00 00 00 00 00   .......| ........
[0020]   00 00 00 00 00 00 00 00   00 00 00 00               ........ ....
[0000]   00 1E 00 06 01 00 00 01   00 00 00 00 00 00 07 76   ........ .......v
[0010]   65 72 73 69 6F 6E 04 62   69 6E 64 00 00 10 00 03   ersion.b ind.....
[0000]   00 0C 00 00 10 00 00 00   00 00 00 00 00 00         ........ ......
[0000]   45 48 4C 4F 0D 0A                                   EHLO..
[0000]   48 45 4C 50 0D 0A                                   HELP..]]></screen>
    </example>

    <para>
    At the beginning, Nmap would have sent its
    NULL probe<indexterm><primary>NULL probe</primary></indexterm>,
    which isn't shown in the log file because the NULL probe doesn't
    send anything<!-- (see <xref linkend="vscan-technique"/>)-->. At the top of
    the log is the GenericLines probe
    (<computeroutput>0D&nbsp;0A&nbsp;0D&nbsp;0A</computeroutput>, or
    <computeroutput>\r\n\r\n</computeroutput>). After that is our old
    friend the HTTP GET<indexterm><primary>GET HTTP method</primary></indexterm>
    request. Then come all the other probes in the
    <filename>nmap-service-probes</filename><indexterm><primary><filename>nmap-service-probes</filename></primary></indexterm>
    file. In this excerpt are shown probes designed to get a response
    from RPC, DNS, and SMTP.
    </para>

  </sect2>
</sect1>

<sect1 id="ncat-simple-services">
  <title>Emulating Diagnostic Services</title>

  <para>
  There are a number of simple Internet protocols intended for testing
  and measurement purposes. Because they deal with simple, fundamental
  network operations they are a good match for Ncat's capabilities. This
  section shows how to to emulate services of increasing complexity:
  discard, echo, daytime, qotd, and chargen.  These particular commands assume you are on a UNIX system such as Linux or Mac OS X, and using a <filename>/bin/sh</filename> compatible shell, such as Bash.
  </para>

  <para>
  The discard service,<indexterm><primary>discard service</primary></indexterm>
  defined in
  RFC&nbsp;863,<indexterm><primary>RFC 863</primary></indexterm> simply
  ignores anything sent to it. It runs on TCP or UDP port&nbsp;9. By
  default, Ncat doesn't send any information unless instructed to, so
  nothing special is needed to emulate discard. Send Ncat's output to
  <filename>/dev/null</filename><indexterm><primary><filename>/dev/null</filename></primary></indexterm>
  to avoid filling the screen with characters received, or just let it
  write to the terminal if you're curious to see what's there. Use the
  <option>--recv-only</option><indexterm><primary><option>--recv-only</option> (Ncat)</primary></indexterm>
  option to prohibit sending any characters that might be entered at the
  terminal.
  </para>

  <variablelist>
    <varlistentry>
      <term>TCP discard server</term>
      <listitem>
<indexterm><primary><option>--recv-only</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<indexterm><primary><option>--keep-open</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l --keep-open 9 --recv-only > /dev/null</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>UDP discard server</term>
      <listitem>
<literallayout>
<command>ncat --udp -l --keep-open 9 --recv-only > /dev/null</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
    Ncat in UDP mode uses all the same options as TCP. The caveat here is that
    connections can't be closed, only timed out, so you will eventually run out
    of sockets if you do not use a timeout. Currently, none of the timeout
    options do the appropriate thing in this instance.
  </para>

  <para>
  The echo service<indexterm><primary>echo service</primary></indexterm>
  is defined in
  RFC&nbsp;862.<indexterm><primary>RFC 862</primary></indexterm> It runs
  on TCP or UDP port&nbsp;7. One step more advanced than discard, it
  sends back any data received until the connection is closed. How do
  you instruct Ncat to return what it receives? One easy way is to run
  everything through <filename>/bin/cat</filename>.
  </para>

  <variablelist>
    <varlistentry>
      <term>TCP echo server</term>
      <listitem>
<indexterm><primary><option>--exec</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l 7 --keep-open --exec "/bin/cat"</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>UDP echo server</term>
      <listitem>
<indexterm><primary><option>--udp</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l 7 --keep-open --udp --exec "/bin/cat"</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  The daytime service,<indexterm><primary>daytime service</primary></indexterm>
  defined in
  RFC&nbsp;867,<indexterm><primary>RFC 867</primary></indexterm>
  sends a human-readable date and time string over TCP or UDP
  port&nbsp;13. It ignores any input. The format of the date and time
  string is left unspecified, so we are free to use the output of
  <filename>/bin/date</filename>. Because we are not interested in
  anything sent by the client we use the
  <option>--send-only</option><indexterm><primary><option>--send-only</option> (Ncat option)</primary></indexterm>
  option.
  </para>

  <variablelist>
    <varlistentry>
      <term>TCP daytime server</term>
      <listitem>
<indexterm><primary><option>--send-only</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<indexterm><primary><option>--exec</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l 13 --keep-open --send-only --exec "/bin/date"</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>UDP daytime server</term>
      <listitem>
<indexterm><primary><option>--udp</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l 13 --keep-open --udp --send-only --exec "/bin/date"</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Nmap comes with a
  <filename>daytime.nse</filename><indexterm><primary><filename>daytime.nse</filename> script</primary></indexterm>
  script that works with the daytime service. Here is its output running
  against Ncat daytime servers on TCP and UDP.
  </para>

  <example id="ncat-ex-daytime">
  <title><filename>daytime.nse</filename> against an Ncat daytime server</title>
  <indexterm><primary><option>--script</option></primary><secondary>example of</secondary></indexterm>
<screen>
# <userinput>nmap -sSU -p 13 --script=daytime localhost</userinput>
Starting Nmap ( https://nmap.org )

Nmap scan report for localhost (127.0.0.1)
PORT   STATE SERVICE
13/tcp open  daytime
|_daytime: Mon Jan 19 17:43:18 MST 2009
13/udp open  daytime
|_daytime: Mon Jan 19 17:43:18 MST 2009

Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
</screen>
  </example>

  <para>
  The qotd<indexterm><primary>qotd service</primary></indexterm>
  (quote of the day) service is defined in
  RFC&nbsp;865.<indexterm><primary>RFC 865</primary></indexterm> When a
  connection is made to TCP or UDP port 17, it sends back a short
  message, ignoring any input. Ncat can do this by invoking a program
  that generates messages. A traditional choice is
  <filename>/usr/games/fortune</filename>, though there are many
  possibilities. <filename>/usr/bin/uptime</filename>, for example,
  could be useful.
  </para>

  <variablelist>
    <varlistentry>
      <term>TCP qotd server</term>
      <listitem>
<indexterm><primary><option>--exec</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>ncat -l 17 --keep-open --send-only --exec "/usr/games/fortune"</command>
</literallayout>
      </listitem>
    </varlistentry>
    <varlistentry>
      <term>UDP qotd server</term>
      <listitem>
<indexterm><primary><option>--udp</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<literallayout>
<command>do ncat -l 17 --keep-open --udp --send-only --exec "/usr/games/fortune"</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  In this example it's instructive to consider the difference between
  <command>ncat -l 17 --exec "/usr/games/fortune"</command> and
  <command>/usr/games/fortune | ncat -l 17</command>. Think about why the
  second command stops working after the first connection.
  </para>

  <para>
  The chargen service<indexterm><primary>chargen service</primary></indexterm>
  from
  RFC&nbsp;864<indexterm><primary>RFC 864</primary></indexterm> rounds
  out our tour of diagnostic services. It runs on TCP and UDP port 19.
  With TCP, chargen ignores any input and sends a never-ending stream of
  data. Never-ending, that is, until the connection is closed by the
  user, who the RFC suggests may have <quote>had enough</quote>. There
  are many ways of generating the characters; reading from
  <filename>/dev/zero</filename><indexterm><primary><filename>/dev/zero</filename></primary></indexterm>
  and running <command>yes</command> come to mind.
  </para>

  <variablelist>
    <varlistentry>
      <term>TCP chargen server</term>
      <listitem>
<literallayout>
<command>yes "chargenchargenchargen" | ncat -l --keep-open 19 --send-only</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Notice that in this case the program pipes its output into
  <command>ncat</command> rather than being invoked with
  <option>--exec</option>. For chargen either method would work,
  because the output of <command>yes</command> never changes.
  Using a pipe requires only one process other than
  <command>ncat</command>, but all users connected simultaneously will
  see the same output stream in synchrony. If the contents must be
  independent for each stream, then use the <option>--exec</option>
  method, with the understanding that a new process will be started for
  each connection.
  </para>

  <para>
  The UDP chargen protocol is a little different. When a datagram is
  received, it sends back one datagram containing a random number of
  characters. Implementing this is starting to get away from Ncat, but
  one way it could be done with the
  Bash shell<indexterm><primary>Bash shell</primary></indexterm>
  is this:
  </para>

  <variablelist>
    <varlistentry>
      <term>UDP chargen server</term>
      <listitem>
<indexterm><primary><option>--udp</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<indexterm><primary><option>--sh-exec</option> (Ncat option)</primary><secondary>example of</secondary></indexterm>
<indexterm><primary><option>-c</option> (Ncat option)</primary><see><option>--sh-exec</option></see></indexterm>
<literallayout>
<command>ncat -l 19 --keep-open --udp --send-only --sh-exec \
  "yes chargenchargenchargen | dd count=1 bs=$(($RANDOM % 512)) 2> /dev/null"</command>
</literallayout>
      </listitem>
    </varlistentry>
  </variablelist>

  <para>
  Notice the use of
  <option>--sh-exec</option><indexterm><primary><option>--sh-exec</option> (Ncat option)</primary></indexterm>
  rather than
  <option>--exec</option><indexterm><primary><option>--exec</option> (Ncat option)</primary></indexterm>
  to allow the use of the shell's environment variables and arithmetic
  evaluation. Standard
  error<indexterm><primary>standard error</primary><secondary>in Ncat subprocesses</secondary></indexterm>
  is redirected to
  <filename>/dev/null</filename><indexterm><primary><filename>/dev/null</filename></primary></indexterm>
  to avoid including <command>dd</command>'s summary lines
  (<computeroutput>1+0 records out</computeroutput>), which would
  otherwise be included by Ncat.
  </para>

  <para>
  This completes the tour of simple diagnostic services. These have been
  easy to implement with Ncat because (with the exception of UDP
  chargen) they all map directly onto a familiar command-line program.
  As services become more complex it gets harder to do everything in the
  shell. For complicated services it's better to write a separate
  program and have Ncat exec it directly.
  </para>

</sect1>

<indexterm class="endofrange" startref="ncat-indexterm"/>