readme

very comprehensive example, windows WDM driver development ex The use of drive technology can s

playing around with source ports and addresses and watching the wires with a
network monitor.

You can use netcat to protect your own workstation's X server against outside
access.  X is stupid enough to listen for connections on "any" and never tell
you when new connections arrive, which is one reason it is so vulnerable.  Once
you have all your various X windows up and running you can use netcat to bind
just to your ethernet address and listen to port 6000.  Any new connections
from outside the machine will hit netcat instead your X server, and you get a
log of who's trying.  You can either tell netcat to drop the connection, or
perhaps run another copy of itself to relay to your actual X server on
"localhost".  This may not work for dedicated X terminals, but it may be
possible to authorize your X terminal only for its boot server, and run a relay
netcat over on the server that will in turn talk to your X terminal.  Since
netcat only handles one listening connection per run, make sure that whatever
way you rig it causes another one to run and listen on 6000 soon afterward, or
your real X server will be reachable once again.  A very minimal script just
to protect yourself could be

	while true ; do
	  nc -v -l -s <your-addr> -p 6000 localhost 2
	done

which causes netcat to accept and then close any inbound connection to your
workstation's normal ethernet address, and another copy is immediately run by
the script.  Send standard error to a file for a log of connection attempts.
If your system can't do the "specific bind" thing all is not lost; run your
X server on display ":1" or port 6001, and netcat can still function as a probe
alarm by listening on 6000.

Does your shell-account provider allow personal Web pages, but not CGI scripts?
You can have netcat listen on a particular port to execute a program or script
of your choosing, and then just point to the port with a URL in your homepage.
The listener could even exist on a completely different machine, avoiding the
potential ire of the homepage-host administrators.  Since the script will get
the raw browser query as input it won't look like a typical CGI script, and
since it's running under your UID you need to write it carefully.  You may want
to write a netcat-based script as a wrapper that reads a query and sets up
environment variables for a regular CGI script.  The possibilities for using
netcat and scripts to handle Web stuff are almost endless.  Again, see the
examples under scripts/.

Example uses -- the dark side
=============================

Equal time is deserved here, since a versatile tool like this can be useful
to any Shade of Hat.  I could use my Victorinox to either fix your car or
disassemble it, right?  You can clearly use something like netcat to attack
or defend -- I don't try to govern anyone's social outlook, I just build tools.
Regardless of your intentions, you should still be aware of these threats to
your own systems.

The first obvious thing is scanning someone *else's* network for vulnerable
services.  Files containing preconstructed data, be it exploratory or
exploitive, can be fed in as standard input, including command-line arguments
to netcat itself to keep "ps" ignorant of your doings.  The more random the
scanning, the less likelihood of detection by humans, scan-detectors, or
dynamic filtering, and with -i you'll wait longer but avoid loading down the
target's network.  Some examples for crafting various standard UDP probes are
given in data/*.d.

Some configurations of packet filters attempt to solve the FTP-data problem by
just allowing such connections from the outside.  These come FROM port 20, TO
high TCP ports inside -- if you locally bind to port 20, you may find yourself
able to bypass filtering in some cases.  Maybe not to low ports "inside", but
perhaps to TCP NFS servers, X servers, Prospero, ciscos that listen on 200x
and 400x...  Similar bypassing may be possible for UDP [and maybe TCP too] if a
connection comes from port 53; a filter may assume it's a nameserver response.

Using -e in conjunction with binding to a specific address can enable "server
takeover" by getting in ahead of the real ones, whereupon you can snarf data
sent in and feed your own back out.  At the very least you can log a hex dump
of someone else's session.  If you are root, you can certainly use -s and -e to
run various hacked daemons without having to touch inetd.conf or the real
daemons themselves.  You may not always have the root access to deal with low
ports, but what if you are on a machine that also happens to be an NFS server?
You might be able to collect some interesting things from port 2049, including
local file handles.  There are several other servers that run on high ports
that are likely candidates for takeover, including many of the RPC services on
some platforms [yppasswdd, anyone?].  Kerberos tickets, X cookies, and IRC
traffic also come to mind.  RADIUS-based terminal servers connect incoming
users to shell-account machines on a high port, usually 1642 or thereabouts.
SOCKS servers run on 1080.  Do "netstat -a" and get creative.

There are some daemons that are well-written enough to bind separately to all
the local interfaces, possibly with an eye toward heading off this sort of
problem.  Named from recent BIND releases, and NTP, are two that come to mind.
Netstat will show these listening on address.53 instead of *.53.  You won't
be able to get in front of these on any of the real interface addresses, which
of course is especially interesting in the case of named, but these servers
sometimes forget about things like "alias" interface addresses or interfaces
that appear later on such as dynamic PPP links.  There are some hacked web
servers and versions of "inetd" floating around that specifically bind as well,
based on a configuration file -- these generally *are* bound to alias addresses
to offer several different address-based services from one machine.

Using -e to start a remote backdoor shell is another obvious sort of thing,
easier than constructing a file for inetd to listen on "ingreslock" or
something, and you can access-control it against other people by specifying a
client host and port.  Experience with this truly demonstrates how fragile the
barrier between being "logged in" or not really is, and is further expressed by
scripts/bsh.  If you're already behind a firewall, it may be easier to make an
*outbound* connection and then run a shell; a small wrapper script can
periodically try connecting to a known place and port, you can later listen
there until the inbound connection arrives, and there's your shell.  Running
a shell via UDP has several interesting features, although be aware that once
"connected", the UDP stub sockets tend to show up in "netstat" just like TCP
connections and may not be quite as subtle as you wanted.  Packets may also be
lost, so use TCP if you need reliable connections.  But since UDP is
connectionless, a hookup of this sort will stick around almost forever, even if
you ^C out of netcat or do a reboot on your side, and you only need to remember
the ports you used on both ends to reestablish.  And outbound UDP-plus-exec
connection creates the connected socket and starts the program immediately.  On
a listening UDP connection, the socket is created once a first packet is
received.  In either case, though, such a "connection" has the interesting side
effect that only your client-side IP address and [chosen?] source port will
thereafter be able to talk to it.  Instant access control!  A non-local third
party would have to do ALL of the following to take over such a session:

	forge UDP with your source address [trivial to do; see below]
	guess the port numbers of BOTH ends, or sniff the wire for them
	arrange to block ICMP or UDP return traffic between it and your real
	  source, so the session doesn't die with a network write error.

The companion program data/rservice.c is helpful in scripting up any sort of
r-service username or password guessing attack.  The arguments to "rservice"
are simply the strings that get null-terminated and passed over an "rcmd"-style
connection, with the assumption that the client does not need a separate
standard-error port.  Brute-force password banging is best done via "rexec" if
it is available since it is less likely to log failed attempts.  Thus, doing
"rservice joe joespass pwd | nc target exec" should return joe's home dir if
the password is right, or "Permission denied."  Plug in a dictionary and go to
town.  If you're attacking rsh/rlogin, remember to be root and bind to a port
between 512 and 1023 on your end, and pipe in "rservice joe joe pwd" and such.

Netcat can prevent inadvertently sending extra information over a telnet
connection.  Use "nc -t" in place of telnet, and daemons that try to ask for
things like USER and TERM environment variables will get no useful answers, as
they otherwise would from a more recent telnet program.  Some telnetds actually
try to collect this stuff and then plug the USER variable into "login" so that
the caller is then just asked for a password!  This mechanism could cause a
login attempt as YOUR real username to be logged over there if you use a
Borman-based telnet instead of "nc -t".

Got an unused network interface configured in your kernel [e.g. SLIP], or
support for alias addresses?  Ifconfig one to be any address you like, and bind
to it with -s to enable all sorts of shenanigans with bogus source addresses.
The interface probably has to be UP before this works; some SLIP versions
need a far-end address before this is true.  Hammering on UDP services is then
a no-brainer.  What you can do to an unfiltered syslog daemon should be fairly
obvious; trimming the conf file can help protect against it.  Many routers out
there still blindly believe what they receive via RIP and other routing
protocols.  Although most UDP echo and chargen servers check if an incoming
packet was sent from *another* "internal" UDP server, there are many that still
do not, any two of which [or many, for that matter] could keep each other
entertained for hours at the expense of bandwidth.  And you can always make
someone wonder why she's being probed by nsa.gov.

Your TCP spoofing possibilities are mostly limited to destinations you can
source-route to while locally bound to your phony address.  Many sites block
source-routed packets these days for precisely this reason.  If your kernel
does oddball things when sending source-routed packets, try moving the pointer
around with -G.  You may also have to fiddle with the routing on your own
machine before you start receiving packets back.  Warning: some machines still
send out traffic using the source address of the outbound interface, regardless
of your binding, especially in the case of localhost.  Check first.  If you can
open a connection but then get no data back from it, the target host is
probably killing the IP options on its end [this is an option inside TCP
wrappers and several other packages], which happens after the 3-way handshake
is completed.  If you send some data and observe the "send-q" side of "netstat"
for that connection increasing but never getting sent, that's another symptom.
Beware: if Sendmail 8.7.x detects a source-routed SMTP connection, it extracts
the hop list and sticks it in the Received: header!

SYN bombing [sometimes called "hosing"] can disable many TCP servers, and if
you hit one often enough, you can keep it unreachable for days.  As is true of
many other denial-of-service attacks, there is currently no defense against it
except maybe at the human level.  Making kernel SOMAXCONN considerably larger
than the default and the half-open timeout smaller can help, and indeed some
people running large high-performance web servers have *had* to do that just to
handle normal traffic.  Taking out mailers and web servers is sociopathic, but
on the other hand it is sometimes useful to be able to, say, disable a site's
identd daemon for a few minutes.  If someone realizes what is going on,
backtracing will still be difficult since the packets have a phony source
address, but calls to enough ISP NOCs might eventually pinpoint the source.
It is also trivial for a clueful ISP to watch for or even block outgoing
packets with obviously fake source addresses, but as we know many of them are
not clueful or willing to get involved in such hassles.  Besides, outbound
packets with an [otherwise unreachable] source address in one of their net
blocks would look fairly legitimate.

Notes
=====

A discussion of various caveats, subtleties, and the design of the innards.

As of version 1.07 you can construct a single file containing command arguments
and then some data to transfer.  Netcat is now smart enough to pick out the
first line and build the argument list, and send any remaining data across the
net to one or multiple ports.  The first release of netcat had trouble with
this -- it called fgets() for the command line argument, which behind the
scenes does a large read() from standard input, perhaps 4096 bytes or so, and
feeds that out to the fgets() library routine.  By the time netcat 1.00 started
directly read()ing stdin for more data, 4096 bytes of it were gone.  It now
uses raw read() everywhere and does the right thing whether reading from files,
pipes, or ttys.  If you use this for multiple-port connections, the single
block of data will now be a maximum of 8K minus the first line.  Improvements
have been made to the logic in sending the saved chunk to each new port.  Note
that any command-line arguments hidden using this mechanism could still be
extracted from a core dump.

When netcat receives an inbound UDP connection, it creates a "connected socket"
back to the source of the connection so that it can also send out data using
normal write().  Using this mechanism instead of recvfrom/sendto has several
advantages -- the read/write select loop is simplified, and ICMP errors can in
effect be received by non-root users.  However, it has the subtle side effect
that if further UDP packets arrive from the caller but from different source
ports, the listener will not receive them.  UDP listen mode on a multihomed
machine may have similar quirks unless you specifically bind to one of its
addresses.  It is not clear that kernel support for UDP connected sockets
and/or my understanding of it is entirely complete here, so experiment...

You should be aware of some subtleties concerning UDP scanning.  If -z is on,
netcat attempts to send a single null byte to the target port, twice, with a
small time in between.  You can either use the -w timeout, or netcat will try
to make a "sideline" TCP connection to the target to introduce a small time
delay equal to the round-trip time between you and the target.  Note that if
you have a -w timeout and -i timeout set, BOTH take effect and you wait twice
as long.  The TCP connection is to a normally refused port to minimize traffic,
but if you notice a UDP fast-scan taking somewhat longer than it should, it
could be that the target is actually listening on the TCP port.  Either way,
any ICMP port-unreachable messages from the target should have arrived in the
meantime.  The second single-byte UDP probe is then sent.  Under BSD kernels,
the ICMP error is delivered to the "connected socket" and the second write
returns an error, which tells netcat that there is NOT a UDP service there.
While Linux seems to be a fortunate exception, under many SYSV derived kernels
the ICMP is not delivered, and netcat starts reporting that *all* the ports are