Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: March 23rd, 2015
Linux Advisory Watch: March 20th, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

Understanding the problem

3. Understanding the problem

Understanding a problem is the first half of the path to solving it.

3.1. Giving names to things

If you want this hack to work for you, you'll have to get an idea of how it works, so that in case anything breaks, you know where to look for.

The first step toward understanding the problem is to give a name to relevant concepts.

As usual, we'll herein call "client" the machine that decides to initiate the connection, as well as programs and files on that machine. Conversely, we'll call "server" that waits for connections and accepts them, as well as programs and files on that machine. Firewall piercing is useful when the two machines are separated by a firewall, such that it is possible for the server to accept some kind of connections, whereas the client might or might not be able to accept any. A tunnel will be created between the two machines that allows full IP traffic despite the firewall.

Usually, when piercing firewalls, the client is the machine behind a firewall: it has limited access to the internet, but can somehow open some kind of connection to the server. The server is a machine with full internet access, that will serve as a proxy for the client to access all of the internet. In a VPN, the firewall the roles might be reversed, with the client being on the internet, and the server serving as a proxy for the client to access some private network.

3.2. The main problem

The main problem with firewall piercing is to create a tunnel: a continuous connection from the client machine to a server machine on the other side of the firewall, that allows for bidirectional exchange of information. Optionally, this connection should be a secure one. The secondary problem is to transform this connection into a full IP access for normal programs to use transparently.

For the main problem, we'll assume that either (1) you can establish normal TCP/IP connections from the client side of the firewall to some port on a server machine where a sshd runs or can be set to run, or (2) you can somehow establish a telnet connection through a telnet proxy. In case you cannot, we will give you pointers to other software that allows you to pierce a tunnel accross a firewall. Although we only give a secure solution in the first case, you can hack your own secure solution in the other cases, if you understand the principle (if you don't, someone, e.g. I, can do it for you in exchange for money).

3.3. The secondary problem

For the secondary problem, IP emulators (pppd or SLiRP) are run on each side of the tunnel.

On the side that wants full IP access to the other side, you'll want to run pppd. On the other side, you want to run pppd if you also want full IP access to the first side, or SLiRP if you want to prevent any access. Go to your usual pppd or SLiRP documentation for more information, if you have specific needs not covered by the examples given below.

Although this is conceptually trivial, it nonetheless requires a few silly tricks, so as to work, since (a) in case you're using some kind of programmed interactive shell session to start the server's IP emulator on either side, you need to correctly synchronize the start of the IP emulator on the other side, so as not to send garbage into the shell session, and (b) IP emulators are designed to be run on a "tty" interface so you have to convert your tunnel's interface into a tty one.

Issue (a) is just your usual synchronization problem, and doesn't even exist if you use ssh, that transparently handles server's command launching.

Issue (b) requires the use of a simple external utility. We wrote one, cotty just for that purpose.


Among the silly problems caused by pppd maintainers' shortmindedness (no more true in recent Linux versions), you can only run it through either a device in /dev or the current tty. You cannot run it through a pair of pipe (which would be the obvious design). This is fine for the server's pppd if any, as it can use the telnet or ssh session's tty; but for the client's pppd, this conflicts with the possible use of telnet as a way to establish a connection.

Indeed, telnet, too wants to be on a tty; it behaves almost correctly with a pair of pipe, except that it will still insist on doing ioctl's to the current tty, with which it will interfere; using telnet without a tty also causes race conditions, so that the whole connection will fail on "slow" computers (fwprc 0.1 worked perfectly on a P/MMX 233, one time out of 6 on a 6x86-P200+, and never on a 486dx2/66). All in all, when using telnet, you need cotty to run as a daemon to copy output from one tty on which runs pppd into another tty on which runs telnet, and conversely.

If I find the sucker (probably a MULTICS guy, though there must have been UNIX people stupid enough to copy the idea) who invented the principle of "tty" devices by which you read and write from a "same" pseudo-file, instead of having clean pairs of pipes, I strangle him!




Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Tech Companies, Privacy Advocates Call for NSA Reform
Google warns of unauthorized TLS certificates trusted by almost all OSes
How Kevin Mitnick hacked the audience at CeBIT 2015
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.