home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3930 < prev    next >
Encoding:
Text File  |  1992-07-30  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!wupost!sdd.hp.com!mips!odin!fido!sgi!rhyolite!vjs
  3. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  4. Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
  5. Message-ID: <nvi8dlo@rhyolite.wpd.sgi.com>
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. References: <DRW.92Jul27143657@jordan.mit.edu> <17011@ulysses.att.com> <1992Jul31.000924.7528@decuac.dec.com>
  8. Date: Fri, 31 Jul 1992 05:11:55 GMT
  9. Lines: 39
  10.  
  11. In article <1992Jul31.000924.7528@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
  12. > drw@euclid.mit.edu (Dale R. Worley) writes:
  13. > 
  14. > >I haven't studied the matter, but I believe that the more
  15. > >sophisticated firewalling routers actually *do* track connections.
  16. > 
  17. >     I prefer to use a somewhat different approach in general. First
  18. > you determine the services that your users have a clear business need
  19. > for. Then you develop an application gateway that "knows" that protocol
  20. > and can give you decent access control, logging, and piggy-back blocking.
  21. > This is much more secure (in my opinion) since you preserve the "that which
  22. > is not expressly permitted is prohibited" doctrine and you can incorporate
  23. > appropriate per-protocol authentication or authorization as needed.
  24.  
  25.  
  26. The meaning I infer for "piggy-back blockin" seems formally
  27. impossible.  Does it mean preventing people from using permitted
  28. facilities for impermissible things?  Such as piggy-backing a full
  29. featured "gateway" on top of rlogin?
  30.  
  31. Consider the recent talk of running SLIP over email over UUCP over
  32. DECNET over x.25 over mirrors, or some such.
  33.  
  34.  
  35. There is code floating around that does what its name, "gateway,"
  36. implies with an rlogin or telnet session through a firewall.  We
  37. recently encountered a version with a different name (it's trivial to
  38. write from scratch) that a "security expert" (sic) from a major network
  39. provided had "helped" a naive, trusting, related employee install.  The
  40. thing let people from that network provider's network by pass the
  41. sgi.com firewall.  The turkey could not understand why we considered
  42. him no different from any other bad guy who had tried to punch a hole
  43. through the firewall.  He only admitted guilt in having his code
  44. go crazy and eat up all of the processes allowed "guest".
  45.  
  46. Who will guard the guardians?
  47.  
  48.  
  49. Vernon Schryver,  vjs@sgi.com
  50.