Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Nowadays, firewalls, intrusion detections systems (IDS), and other security devices are a necessary part of any corporate network infrastructure. Such systems have even become commonplace in many homes.
But even with security gear installed, don’t let your guard down. Security requires vigilance, multiple layers of defense, and a heavy dose of paranoia. It also takes knowledge of what the “bad” guys — or in many cases, employees who may not necessarily have bad intentions — will do to try to subvert the measures you have put into place. You’d be surprised just how crafty some people in your organization may become when trying to circumvent a firewall rule or corporate policy they don’t think is fair.
In this month’s “Tech Support,” let’s look at a couple of applications that let you tunnel data in ways that may surprise you and catch your firewall off guard. Let’s look too at an application that may help you track down data tunnels (but be aware that a well hidden tunnel can be nearly impossible to find). As is often the case with security tools, these applications can be used for nefarious purposes, so use your best judgment. And while this article doesn’t cover netcat ( http://netcat.sourceforge.net/ ), the swiss army knife of all network tunneling apps, it’s a tool that every network administrator should be aware of.
The first utility is httptunnel, which creates a bidirectional virtual data connection tunneled via HTTP requests. Available from http://www.nocrew.org/software/httptunnel.html and written by Lars Brinkhoff, httptunnel is licensed under the GPL. Installation is the usual ./configure&&make&&make install. httptunnel consists of two binaries: hts listens for incoming httptunnel connections on the machine you want to connect to, and htc initiates a connection from the machine you want to send from.
For example, to configure hts to listen on port 80 and forward I/O to port 8080 on localhost, type:
# hts ––forward-port localhost:8080 80
Here, localhost is just an example. hts can forward traffic to a remote machine as well. Additionally, you can use ––device instead of ––forward-port to redirect I/O directly to a device.
Now that you have hts listening on the server, it’s time to setup htc on the client. To get the client to forward all traffic destined for port 2000 on the client to port 80 on the server, use the following command:
$ htc ––forward-port 2000 remote.host.net:80
Now, any data you send to port 2000 on the client gets tunneled to port 80 on the remote server, which is then redirected to port 8080.
Remember that all data in this setup is unencrypted, so be mindful of what you transfer via the tunnel. And if you’re required to browse through a proxy, add ––proxy proxy.domain:port to the htc command. htc even supports proxy authentication via the optional ––proxy-authorization parameter.
The next tool is ICMP Shell, which allows users to connect to a remote host and to open a shell using only ICMP to send and receive data. Licensed under the GPL and written by Peter Kieltyka, ICMP Shell is available for download from http://icmpshell.sourceforge.net/.
Much like httptunnel, ICMP Shell requires a daemon listening on the remote server and a client application on the local machine. By default, ICMP type 0 (ICMP_ECHO_REPLY) packets are used to send and receive, but you can specify other types, such as ICMP_ECHO_REQUEST. Use the –t parameter to change the ICMP type.
To compile ICMP Shell, simply type make linux in the directory created by unpacking the source tarball. You can then copy the two resulting binaries to any location. ICMP Shell uses raw sockets on both the client and server side, so root privileges are required. To setup the server side of the connection, run the following command as root:
# ishd –i 1515 –p 1024
This sets the session id to 1515 and the packet size to 1024. Both of these options must be the same on both sides of the connection. Now, on the client, run:
# ish –i 1515 –p 1024 remote.host
This drops you into a root shell on the remote machine, which you can verify by running commands such as uname –n and id –a. Perhaps strangely, you only get a command prompt before the first command, but you may run as many commands as you’d like.
While there isn’t enough room in this column to cover the myriad of tunneling programs, two more utilities deserve mention. The first is shadyshell, a lightweight UDP portshell. Unlike the first two utilities mentioned above, you run shadyshell only on the remote server and then send client data using netcat.
Finally, there is Stegtunnel, which operates in a much different way than all of the previous tools. Stegtunnel hides data within TCP/IP header fields. It does this over normal TCP connections and uses unmodified clients and servers to provide the TCP conversation. Sessions look completely normal, and detection, even for those familiar with what is happening, is extremely difficult.
Now that you know how easy tunneling data can be, what should you do?
First, make sure everyone on your staff knows your network usage policies and is aware of what the repercussions of breaking those policies are. The next step is detecting the tunnels. One key is to always look for anomalies on your network: increased bandwidth consumption, increased use of specific ports, or anything else outside the norm. There are many tools available to set this baseline, but the key is having the baseline available for comparison. Beyond that, you can use a tool such as tcpstatflow to attempt to detect a tunnel. tcpstatflow relies on the fact that many of the popular protocols people use to tunnel data (HTTP, FTP, and SMTP, among others) are extremely asymmetric, trafficking more data in one side of the connection. Using HTTP as an example, you send a tiny GET request and get back a relatively large amount of data in the form of images, files, or text. tcpstatflow analyzes the incoming and outgoing packets of each TCP connection and generates alarms when certain thresholds are surpassed. You can then determine exactly what is causing the anomaly.
The duty of securing a network is an arduous one and tunneling data is just one way people attempt to circumvent the policies that you’ve put in place. Of course, tunneling can also be used for benevolent purposes and is occasionally the only way to get something accomplished. By understanding how tunneling works, you can better defend against it and utilize it to your advantage.