home *** CD-ROM | disk | FTP | other *** search
/ Caldera Network Desktop 1.0 / caldera-network-desktop-1.0.bin / doc / HOWTO / mini / Term-Firewall < prev    next >
Text File  |  1995-09-12  |  8KB  |  228 lines
  1. ** HOWTO: Using Term to Pierce an Internet Firewall
  2. Revision of 11-Sep-1995.
  3.  
  4.  
  5. * Abstract:
  6.  
  7. Directions for using "term" to do network stuff through a TCP firewall
  8. that you're not supposed to be able to.
  9.  
  10.  
  11. * Table of contents:
  12.  
  13.  Disclaimer
  14.  Introduction
  15.  The basic procedure
  16.  Detailed directions
  17.  Multiple term sockets
  18.  The ~/.term/termrc.telnet init file
  19.  Direction
  20.  Security
  21.  Telnet mode
  22.  Bugs and term wish list
  23.  Tricks that don't seem to work
  24.  
  25.  
  26. * Disclaimer * <------- !!! READ THIS IMPORTANT SECTION !!!
  27.  
  28. I hereby disclaim all responsibility for this hack.  If it backfires
  29. on you in any way whatsoever, that's the breaks.  Not my fault.  If
  30. you don't understand the risks inherent in doing this, don't do it.
  31. If you use this hack and it allows vicious hackers to break into your
  32. company's computers and costs you your job and your company millions
  33. of dollars, well that's just tough nuggies.  Don't come crying to me.
  34.  
  35.  
  36. * Author
  37.  
  38. This HOWTO-term-firewall file was written by
  39. Barak Pearlmutter <bap@scr.siemens.com>
  40. *who disclaims all responsibility for it!*
  41.  
  42.  
  43. * Copyright
  44.  
  45. This document is released under the GPL.  This basically means you may
  46. copy and modify it at will, but may not prevent others from doing so.
  47.  
  48.  
  49. * Introduction
  50.  
  51. The term program is normally used over a modem or serial line, to
  52. allow various host-to-host services to flow along this simple serial
  53. connection.  However, sometimes it is useful to establish a term
  54. connection between two machines that communicate via telnet.  The most
  55. interesting instance of this is for connecting two hosts which are
  56. separated by ethernet firewalls or SOCKS servers.  Such firewalls
  57. provides facilities for establishing a telnet connection through the
  58. firewall, typically by using the SOCKS protocol to allow inside
  59. machines to get connections out, and requiring outside users to telnet
  60. first to a gateway machine which requires a one-time password.  These
  61. firewalls make it impossible to, for instance, have X clients on an
  62. inside machine communicate with an X server on an outside machine.
  63. But, by setting up a term connection, these restrictions can all be
  64. bypassed quite conveniently, at the user level.
  65.  
  66.  
  67. * The basic procedure
  68.  
  69. Setting up a term connection over a telnet substrate is a two-phase
  70. process.  First your usual telnet client is used to set up a telnet
  71. connection and log in.  Next, the telnet client is paused and control
  72. of the established telnet connection is given to term.
  73.  
  74.  
  75. * Detailed directions
  76.  
  77. In detail, the process goes like this.
  78.  
  79. First, from a machine inside the firewall, telnet to a target machine
  80. outside the firewall and log in.
  81.  
  82. Unless you are under linux and will be using the proc filesystem (see
  83. below) make sure your shell is an sh style shell.  Ie if your default
  84. shell is a csh variant, invoke telnet by
  85.  
  86. (setenv SHELL /bin/sh; telnet machine.outside)
  87.  
  88. After logging in, on the remote (outside) machine invoke the command
  89.  
  90.     term -r -n off telnet
  91.  
  92. Now break back to the telnet prompt on the local (inside) machine,
  93. using ^] or whatever, and use the telnet shell escape command ! to
  94. invoke term,
  95.  
  96.     telnet> ! term -n on telnet <&3 >&3
  97.  
  98. E voila!!!
  99.  
  100. (If you have a variant telnet, you might have to use some other file
  101. descriptor than 3; easy to check using trace.  But three seems to work
  102. on all bsd descendent telnet clients I've tried, under both sunon 4.x
  103. and the usual linux distributions.)
  104.  
  105. Alternatively, under linux you can pause the telnet with ^]^z, figure
  106. out its pid, and invoke
  107.  
  108.     term -n on -v /proc/<telnetpid>/fd/3 telnet
  109.  
  110.  
  111. * Multiple term sockets
  112.  
  113. It is a good idea to give the term socket an explicit name.  This is
  114. the "telnet" argument in the invocations of term above.  Unless you
  115. have the TERMSERVER environment variable set to telnet as appropriate,
  116. you invoke term clients with the -t switch, eg "trsh -t telnet".
  117.  
  118.  
  119. * The ~/.term/termrc.telnet init file
  120.  
  121. I have checked line clarity using linecheck over this medium.  I
  122. expected it to be completely transparent, but it is not.  However, the
  123. only bad character seems to be 255.  The ~/.term/termrc.telnet I use
  124. (the .telnet is the name of the term connection, see above) contains:
  125.  
  126.     baudrate off
  127.     escape 255
  128.     ignore 255
  129.     timeout 600
  130.  
  131. Perhaps it could be improved by diddling, I am getting a throughput of
  132. only about 30k cps over a long-haul connection through a slow
  133. firewall.  Ftp can move about 100k cps over the same route.  A
  134. realistic baudrate might avoid some timeouts.
  135.  
  136.  
  137.  
  138. * Direction
  139.  
  140. Obviously, if you are starting from outside the firewall and zitching
  141. in using a SecureID card or something, you will want to reverse the
  142. roles of the remote vs local servers given above.  (If you don't
  143. understand what this means, perhaps you are not familiar enough with
  144. term to use the trick described in this file responsibly.)
  145.  
  146.  
  147. * Security
  148.  
  149. This is not much more of a vulnerability than the current possibility
  150. of having a telnet connection hijacked on an unsecured outside
  151. machine.  The primary additional risk comes from people being able to
  152. use the term socket you set up without you even being aware of it.  So
  153. be careful out there.  (Personally, I do this with an outside machine
  154. I know to be pretty secure, namely a linux laptop I maintain myself
  155. that does not accept any incoming connections.)
  156.  
  157. Another possibility is to add "socket off" to the remote
  158. ~/.term/termrc.telnet, or add "-u off" to invocation of term.  This
  159. prevents the socket from being hijacked from the remote end, with only
  160. a minor loss of functionality.
  161.  
  162.  
  163. * Telnet mode
  164.  
  165. Be sure the remote telnetd is not in some nasty seven-bit mode.  Or if
  166. it is, you have to tell term about it when you invoke term, by adding
  167. the -a switch at both ends.  (I sometimes use "^] telnet> set outbin"
  168. or "set bin" or invoke telnet with a -8 switch to put the connection
  169. into eight-bit mode.)
  170.  
  171.  
  172. * Bugs and term wish list
  173.  
  174. The linecheck program has some problems checking telnet connections
  175. sometimes.  This is sometimes because it doesn't check the return code
  176. of the read() call it makes.  For network connections, this call to
  177. read() can return -1 with an EINTR (interrupted) or EAGAIN (try again)
  178. error code.  Obviously this should be checked for.
  179.  
  180. There are a number of features that could ease the use of term over
  181. telnet.  These primarily relate to an assumption that influenced the
  182. design of term, namely that the connection is low bandwidth, low
  183. latency, and somewhat noisy.
  184.  
  185. A telnet connection is in general high bandwidth, high latency, and
  186. error free.  This means that the connection could be better utilized
  187. if (a) the maximum window size was raised, well above the limit
  188. imposed by term's N_PACKETS/2=16, (b) there was an option to turn off
  189. sending and checking packet checksums, and (c) larger packets were
  190. permitted when appropriate.
  191.  
  192. Also, to enhance security, it would be nice to have a term option to
  193. log all connections through the socket it monitors to a log file, or
  194. to stderr, or both.  This would allow one to see if one's term
  195. connection is being subverted by nasty hackers on the outside insecure
  196. machine.
  197.  
  198.  
  199. * Tricks that don't seem to work
  200.  
  201. Some telnet clients and servers agree to encrypt their communications,
  202. to prevent evesdropping on the connection.  Unfortunately, the hack
  203. used above (using the network connection that the telnet client has
  204. set up while the telnet client is idle) won't work in that case.
  205. Instead, one really must go through the telnet client itself, so it
  206. can do its encryption.  It seems like that requires a simple hack to
  207. the telnet client itself, to add a command that runs a process with
  208. its stdin and stdout are connected to the live telnet connection.
  209. This would also be useful for various 'bots, so perhaps someone has
  210. already hacked it up.
  211.  
  212.  
  213. * Acknowledgments
  214.  
  215. Thanks for valuable suggestions from:
  216. Gary Flake <flake@scr.siemens.com>
  217. Bill Riemers <bcr@physics.purdue.edu>
  218.  
  219.  
  220. * Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!
  221.  
  222. I hereby disclaim all responsibility for this hack.  If it backfires
  223. on you in any way whatsoever, that's the breaks.  Not my fault.  If
  224. you don't understand the risks inherent in doing this, don't do it.
  225. If you use this hack and it allows vicious hackers to break into your
  226. company's computers and costs you your job and your company millions
  227. of dollars, well that's just tough nuggies.  Don't come crying to me.
  228.