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

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: April 7th, 2014
Linux Advisory Watch: April 4th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Unsecure solution: piercing using telnet

5. Unsecure solution: piercing using telnet

5.1. Principle

If all you can do is telnet (because of a telnet proxy), then this solution might be fit for you.

The firewall-piercing program, fwprc, will use a "tty proxy", cotty, that opens two pseudo-tty devices, launches some command on each of those devices' slaves, and stubbornly copies every character that one outputs to the tty that serves as input of the other command. One command will be telnet connection to server site, and the other will be the client's pppd. pppd can then open and control the telnet session with a chat script as usual.

Actually, if your telnet proxy allows connection to an arbitrary port, and if you can reliably run a daemon on the server host (with a cron job to relaunch it in case of breakage), then you'd better write some program that will just connect a client side port to the server side port through the proxy, so you can use the above secure solution, possibly using some variant of

ssh -t -o "ProxyCommand ..."
(if you submit it to me, I'll gladly integrate such a solution to the fwprc distribution).

Note: if you must use the unsecure telnet-based solution, be sure that nothing lies in your target account that you want to keep secret or untampered, since the password will be sent in clear text accross the Internet. If you can control these things, a one-time-password system, or an explicit cryptographic challenge system will enhance your security, although it will make automated connection scripts much more complex.

5.2. fwprc

I wrote a very well self-documented script to pierce firewalls, fwprc, available from my site, together with cotty (which is required by fwprc 0.2 and later). At the time of my writing these lines, latest versions are fwprc 0.3e and cotty 0.4c.

The name "fwprc" is voluntarily made unreadable and unpronounceable, so that it will confuse the incompetent paranoid sysadm who might be the cause of the firewall that annoys you (of course, there can be legitimate firewalls, too, and even indispensable ones; security is all a matter of correct configuration). If you must read it aloud, choose the worst way you can imagine.

CONTEST! CONTEST! Send me an audio file with a digital audio recording of how you pronounce "fwprc". The worst entry will win a free upgrade and his name on the fwprc 1.0 page!

I tested the program in several settings, by configuring it through resource files. But of course, by Murphy's law, it will break for you. Feel free to contribute enhancements that will make life easier to other people who'll configure it after you.

5.3. .fwprcrc

fwprc can be customized through a file .fwprcrc meant to be the same on both sides of the firewall. Having several alternate configurations to choose from is sure possible (for instance, I do it), and is left as an exercise to the reader.

To begin with, copy the appropriate section of fwprc (the previous to last) into a file named .fwprcrc in your home directory. Then replace variable values with stuff that fits your configuration. Finally, copy to the other host, and test.

Default behavior is to use pppd on the client, and slirp on the server. To modify that, you can redefine the appropriate function in your .fwprcrc with such a line as:

remote_IP_emu () { remote_pppd }

Note that SLiRP is safer than pppd, and easier to have access to, since it does not require being root on the server machine, and needn't additional firewall configuration to prevent connections from the outside world into the firewalled network. The basic functionality in SLiRP works quite well, but I haven't managed to get some advertised pluses to work (like run-time controllability). Of course, since it is free software, feel free to hack the source so as to actually implement or fix whichever feature you need.

    
Partner

 

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
Heartbleed: Security experts reality-check the 3 most hysterical fears
Open source trounces proprietary software for code defects, Coverity analysis finds
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 2014 Guardian Digital, Inc. All rights reserved.