If you can crash your daemon, you likely have a security problem

Netcat as well can make an outbound connection and then run a program or script on the originating end, with input and output connected to the same network port. This "inverse inetd" capability could enhance the backup-server concept described above or help facilitate things such as a "network dialback" concept. The possibilities are many and varied here; if such things are intended as security mechanisms, it may be best to modify netcat specifically for the purpose instead of wrapping such functions in scripts.

Speaking of inetd, netcat will function perfectly well *under* inetd as a TCP connection redirector for inbound services, like a "plug-gw" without the authentication step. This is very useful for doing stuff like redirecting traffic through your firewall out to other places like web servers and mail hubs, while posing no risk to the firewall machine itself. Put netcat behind inetd and tcp_wrappers, perhaps thusly:

www stream tcp nowait nobody /etc/tcpd /bin/nc -w 3 realwww 80

and you have a simple and effective "application relay" with access control and logging. Note use of the wait time as a "safety" in case realwww isn't reachable or the calling user aborts the connection -- otherwise the relay may hang there forever.

You can use netcat to generate huge amounts of useless network data for various performance testing. For example, doing

yes AAAAAAAAAAAAAAAAAAAAAA | nc -v -v -l -p 2222 > /dev/null

on one side and then hitting it with

yes BBBBBBBBBBBBBBBBBBBBBB | nc othermachine 2222 > /dev/null

from another host will saturate your wires with A's and B's. The "very verbose" switch usage will tell you how many of each were sent and received after you interrupt either side. Using UDP mode produces tremendously MORE trash per unit time in the form of fragmented 8 Kbyte mobygrams -- enough to stress-test kernels and network interfaces. Firing random binary data into various network servers may help expose bugs in their input handling, which nowadays is a popular thing to explore. A simple example data-generator is given in data/data.c included in this package, along with a small collection of canned input files to generate various packet contents. This program is documented in its beginning comments, but of interest here is using "%r" to generate random bytes at well-chosen points in a data stream. If you can crash your daemon, you likely have a security problem.

The hex dump feature may be useful for debugging odd network protocols, especially if you don't have any network monitoring equipment handy or aren't root where you'd need to run "tcpdump" or something. Bind a listening netcat to a local port, and have it run a script which in turn runs another netcat to the real service and captures the hex dump to a log file. This sets up a transparent relay between your local port and wherever the real service is. Be sure that the script-run netcat does *not* use -v, or the extra info it sends to standard error may confuse the protocol. Note also that you cannot have the "listen/exec" netcat do the data capture, since once the connection arrives it is no longer netcat that is running.

Binding to an arbitrary local port allows you to simulate things like r-service clients, if you are root locally. For example, feeding "^@root^@joe^@pwd^@" [where ^@ is a null, and root/joe could be any other local/remote username pair]into a "rsh" or "rlogin" server, FROM your port 1023 for example, duplicates what the server expects to receive. Thus, you can test for insecure .rhosts files around your network without having to create new user accounts on your client machine. The program data/rservice.c can aid this process by constructing the "rcmd" protocol bytes. Doing this also prevents "rshd" from trying to create that separate standard-error socket and still gives you an input path, as opposed to the usual action of "rsh -n". Using netcat for things like this can be really useful sometimes, because rsh and rlogin generally want a host *name* as an argument and won't accept IP addresses. If your client-end DNS is hosed, as may be true when you're trying to extract backup sets on to a dumb client, "netcat -n" wins where normal rsh/rlogin is useless.

If you are unsure that a remote syslogger is working, test it with netcat. Make a UDP connection to port 514 and type in "<0>message", which should correspond to "kern.emerg" and cause syslogd to scream into every file it has open [and possibly all over users' terminals]. You can tame this down by using a different number and use netcat inside routine scripts to send syslog messages to places that aren't configured in syslog.conf. For example, echo '<38>message' | nc -w 1 -u loggerhost 514 should send to auth.notice on loggerhost. The exact number may vary; check against your syslog.h first.

Netcat provides several ways for you to test your own packet filters. If you bind to a port normally protected against outside access and make a connection to somewhere outside your own network, the return traffic will be coming to your chosen port from the "outside" and should be blocked. TCP may get through if your filter passes all "ack syn", but it shouldn't be even doing that to low ports on your network. Remember to test with UDP traffic as well! If your filter passes at least outbound source-routed IP packets, bouncing a connection back to yourself via some gateway outside your network will create "incoming" traffic with your source address, which should get dropped by a correctly configured anti-spoofing filter. This is a "non-test" if you're also dropping source-routing, but it's good to be able to test for that too. Any packet filter worth its salt will be blocking source-routed packets in both directions, but you never know what interesting quirks you might turn up by 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.