home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3936 < prev    next >
Encoding:
Text File  |  1992-07-31  |  2.9 KB  |  55 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
  3. From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
  4. Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
  5. Message-ID: <1992Jul31.140039.28094@decuac.dec.com>
  6. Sender: news@decuac.dec.com (USENET News System)
  7. Nntp-Posting-Host: hussar.dco.dec.com
  8. Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
  9. References: <17011@ulysses.att.com> <1992Jul31.000924.7528@decuac.dec.com> <nvi8dlo@rhyolite.wpd.sgi.com>
  10. Date: Fri, 31 Jul 1992 14:00:39 GMT
  11. Lines: 42
  12.  
  13. >The meaning I infer for "piggy-back blockin" seems formally
  14. >impossible.  Does it mean preventing people from using permitted
  15. >facilities for impermissible things?  Such as piggy-backing a full
  16. >featured "gateway" on top of rlogin?
  17.  
  18.     Right. I was referring to using one service to piggy-back another
  19. one. Such as running an interactive login session over an FTP command
  20. stream. ;) Or tunnelling X-windows packets in a telnet session. In general
  21. one may need to block that kind of thing, especially in the case where
  22. the piggy-backing is being done to make an unsecure protocol (like X)
  23. available.
  24.  
  25.     I'm not a theorist of any type, so I can't say anything about
  26. formalisms. ;) On the other hand, I do know that ad hack methods can
  27. go a long way towards preventing these kinds of things, *if it is necessary*.
  28. Not all sites will *care* about preventing people from tunnelling X over
  29. telnet, for example. At that point the problem ceases to be a technical
  30. one, and becomes a policy matter - and many of the gateway admins I know
  31. don't set the policy; they are just stuck with enforcing it.
  32.  
  33.     My telnet application gateway, for example, has a rate limiter
  34. in it that will adjust the baud rate of an outgoing telnet session to
  35. a (low) settable value. That way you can run an interactive session nicely,
  36. but if you try to run kermit over it, it'll be unacceptably slow. My
  37. FTP application gateway has rate limiting on the command stream, and also
  38. fires off warnings if commands are sent over the command stream that are
  39. not recognizable telnet commands. Yes, one could encode X packets in the
  40. pathnames of "GET" commands, but then the rate limiter will choke you.
  41. All these interesting events are logged.
  42.  
  43.     The main thing here is not to subscribe to some (imho useless)
  44. formal model of security, but to just try to be reasonable and to make
  45. sure that if someone does Something Bad to your gateway, it leaves
  46. tracks that you can follow. Gateway admins are often in a really nasty
  47. spot - they have to enforce sets of rules that sometimes don't make
  48. a whole lot of sense. I try to enforce them sensibly, and to do anything
  49. I can to make sure that if someone launches a *real* attack on my gateway,
  50. I'll have a chance of catching them, or at least I'll have enough
  51. information about what happened that I can deduce what they were
  52. trying to do, and check for holes.
  53.  
  54. mjr.
  55.