   .       .         
   \`-"'"-'/
    } 6 6 {    
   ==. Y ,==   
     /^^^\  .
    /     \  )           
   (  )-(  )/     _
   -""---""---   /
  /   Ncat    \_/
 (     ____
  \_.=|____E


README for Ncat 
---------------

Ncat is a reimplementation of the currently splintered 
and reasonably unmaintained Netcat family. Ncat will
do pretty much everything that all the other Netcat's
do; however it does this all in one place. Plus it has 
the added benefit of spanky new features and ongoing
development.

Ncat was designed with the original Netcat interface
in mind. Rather than replacing the old Netcat interface
with a brand new (and subsequently more convoluted) set of
options, the Ncat interface was intentionally kept clean 
and simple to use, as in the original product.

Ncat is a subset of features from the original Netcat but with
a complete overhaul and rewrite, along with completely new features 
and also a combination of other well received features of other
Netcat products, such as IPv6 support, SSL support, etc.

The port scanning support has been entirely removed from Ncat.
The reason for this is fairly obvious; there is a better port 
scanner out there already. Mentioning no names. :)

Under the hood of Ncat, there is IPv4, IPv6 support as well
as support for TCP and UDP in both listen and connect modes.
There is also SSL support for both listen and connect operations
too. As well as a new "Connection Brokering" feature which
enables two or more hosts to connect that previously were 
unable to directly communicate with each other.

For example: "Host A" can connect to "Host B" but not "Host C"
             "Host C" can connect to "Host B" but not "Host A"

It is clear, then, that if you could connect to "Host B"
then "Host A" and "Host C" could directly communicate...

[HostA] <------> [HostB-with-Ncat-Broker] <------> [HostC]

Ncat's connection brokering will allow you to connect between 
Host A and Host C via Host B without the trouble of having to 
have SOCKS support, etc. This, incidentally, is still fairly
experimental behaviour.

Additionally, the Ncat broker process owner can also see the 
current connection, live, as it happens. This is similar to 
a third party style wire tap. This can be disabled with a 
command line option, if it's found annoying.

Ncat has support for HTTP "CONNECT" via an HTTP proxy server
such as Squid. It will also connect via a SOCKS4 server and 
is very flexible in terms of how it shuffles your data around.

Ncat can also spawn it's own it's own SOCKS4 server for 
your own relaying requirements.

Ncat has the ability to execute a program and handle the I/O for this
applications data, over the socket. Ncat will fully handle the I/O 
for the executed program so has the added benefit of "adding" 
networking support to applications that currently have none.

For example, you could:

./ncat --exec "/bin/bash" -l 5000

** WARNING ** This is exceptionally dangerous behaviour, as it 
leaves an open shell sitting directly accessible to anyone who 
is able to connect to port 5000.
* See the --allow, --deny and --allowfile/--denyfile options later on for securing 
your Ncat processes.

Ncat has a TCP and UDP "redir"-style redirection feature to allow
the user to redirect traffic from one host to another.

For example:

./ncat --exec "./ncat www.example.com 80" -l 8888

This command binds Ncat to the local machine on port 8888,
connections to port 8888 are accepted and redirected 
off to www.example.com -- You may also find uses for this
as a "host hiding" system. Similar to SOCKS4 but without
any of the hassle of having to have SOCKS support in the
application.

This also begs the question of, "What would happen if you
decided you wanted to pass the "--udp" flag in to the above
command somewhere?"

In this case, you would have a TCP to UDP "gender changer". 

If you have an application that only makes only TCP connections, 
for example, you could spawn a Ncat process to listen on a the applications
TCP port and then redirect the TCP connection out to the final 
destination, only over UDP.

Similarly, SOCKS4 is also supported in Ncat in both directions. 
In otherwords, there is built-in SOCKS4 client support as well 
as SOCKS4 server support.

$ ncat --socks4-server -l 5001

This command would make Ncat start a SOCKS4 server on port 5001.
And that's it. No complicated configuration files, etc. It Just Works.

WARNING: This will be a publically accessible SOCKS4 server and 
potentially could be abused by automated scanners, idiots, etc.

To prevent unauthorised access to any Ncat process that is listening
on a port, the --allow, --deny options are most useful.

The --allow/--deny options are additionally paired with the 
--allowfile and --denyfile options, similar in behaviour to Nmap.

Therefore, a minor change to our parameters issued 
to Ncat drastically improve our security concerns:

./ncat --allow 127.0.0.1/32 --socks4-server -l 5001

This blocks everyone except localhost/127.0.0.1 from accessing
your newly spawned SOCKS4 server.

The allow and deny family of functions accept IP
addresses in a number of different formats for maximum 
flexibility:

These formats are:

A single IP address, of the format:

	ip.ip.ip.ip

EG: 127.0.0.1 

A CIDR-style IP address range, of the format:
 
	ip.ip.ip.ip/cidr 

EG: 127.0.0.1/32

An IP and full netmask, of the format:

	ip.ip.ip.ip:nm.nm.nm.nm

EG: 127.0.0.1:255.255.255.255

An IP address with wildcards:

	ip.ip.ip.*
	ip.ip.*.*
	ip.*.*.*

These rules may also be used in a flat file, delimited
by newlines. An example of a full ACL is included in docs/examples/
labelled 'iplist'. Also note that comments start with a # and are
perfectly acceptable for use in the ACL's.

For example, the file "ipaccess" might look like:

# Abuse from ADSL user.
88.223.14.1/32

# This guy is scanning us for SOCKS4
# servers to abuse, block his /24
194.213.167.*

To implement this IP address ACL simply run:

./ncat --denyfile /path/to/file/ipaccess --socks4-server -l 7000

For further documentation, please see the man page.

--Chris Gibson, <chris@linuxops.net>
