home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3820 < prev    next >
Encoding:
Text File  |  1992-07-25  |  5.0 KB  |  99 lines

  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!ddsw1!karl
  3. From: karl@ddsw1.mcs.com (Karl Denninger)
  4. Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
  5. Message-ID: <1992Jul25.040558.23776@ddsw1.mcs.com>
  6. Summary: Firewalls
  7. Organization: Macro Computer Solutions, Inc., Chicago, IL
  8. References: <BrruC8.FEo@spock.dis.cccd.edu> <BrsM1C.36v@cs.columbia.edu> <1992Jul23.142026.20112@sci34hub.sci.com>
  9. Date: Sat, 25 Jul 1992 04:05:58 GMT
  10. X-Disclaimer:  Material posted in this article is the sole responsibility of
  11.                 the poster and does not represent MCSNet or the system owners.
  12. Lines: 85
  13.  
  14. In article <1992Jul23.142026.20112@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
  15. >In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
  16. >>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
  17. >>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
  18. >>>I receive a "no route to host" error?  ....
  19. >
  20. >>The site you are trying to ping is running a firewall gateway, because
  21. >>they're too lazy to beef up their host security and are relying on the
  22. >>firewall to protect themselves against external attacks.
  23. >
  24. >I have to take exception to this remark. Use of a firewall doesn't indicate
  25. >laziness on the part of a site; it most probably means that the persons
  26. >responsible for the Internet connection and security of the sites' net are
  27. >either too understaffed to maintain all the hosts on their site, or they
  28. >don't have control over all the hosts, and are therefore not able to make
  29. >them secure. And there are doubtless many sites that suffer from both 
  30. >problems.
  31.  
  32. There are a number of reasons other than laziness or overwork that an
  33. organization may firewall (seeing as I put these things in, I'll explain):
  34.  
  35. 1)    The company may have rather loose security internally (i.e. Runs NIS
  36.     for password validation) and doesn't like the idea of someone doing
  37.     a ypset/ypcat on their password files, or its moral equivalent.
  38.     This "rather loose" part may be a >requirement< by some of their
  39.     hardware or software that they cannot control (see some of the major
  40.     system vendors for some of the worst offenders here, and their utter
  41.     failure to provide off-the-shelf secure alternatives.  KERBEROS is
  42.     >NOT< adaquate in most commercial environments, as tickets expire,
  43.     and for most people in these environments that is plain unacceptable).
  44.     Organizationally it may be deemed acceptable to have this security
  45.     level for employees, but not against outsiders.
  46.  
  47. 2)    The organization may have a large number of MAC and PC desktops, all
  48.     or any of which may be able to be compromised to someone's extreme
  49.     detriment with no good way to stop the abuse.  Not all the world's a
  50.     Unix.
  51.  
  52. 3)    The organization may want to run NFS, and either has too many hosts
  53.     to do individual host validation in the exports file, or just can't
  54.     for other reasons.  This is a real bitch with the NFS mount
  55.     protocols; there is >no< good way to stop this from being a
  56.     potential problem in many organizations.  The ability to wild-card
  57.     domain names in the export list as in "allow anyone from "mcs.com"
  58.     access), along with a local name server (which prevents spoofing the
  59.     reverse lookups) would solve this easily -- but it isn't happening
  60.     these days with the major vendors -- again.  The NETGROUP paradigm
  61.     does >not< help in many of these cases, especially when combined
  62.     with the NIS problem.
  63.  
  64. 4)    The organization may not like the idea of the local (or
  65.     long-distance) teen-age hacker crowd taking pot-shots at their 
  66.     security on a daily basis across several hundred or thousand hosts.  
  67.     It is much easier to watch, and defend, one entry point.
  68.  
  69. 5)    Change the offender in #4 to some corporate espionage types, and add
  70.     a company that has significant computer-based assets, and you have
  71.     yet another argument.
  72.  
  73. >>I wish I had a transcript of Dave Clark's talk at the IETF last week.
  74. >>He said some great things about firewall gateways and mailbridges, and
  75. >>how they've essentially destroyed the whole purpose of having an IP
  76. >>internet, and have forced a lot of us to use mail as a transport-level
  77. >>protocol.
  78.  
  79. Hogwash.  If it is that important to an organization, the firewall can 
  80. provide proxy service for it.  It is >not< that big a deal to provide a
  81. proxy connection for these kinds of things, >provided< that you have a nice
  82. clean requirement.  The generic "anyone can do anything" doesn't cut it in
  83. Corporate America anyway.
  84.  
  85. >Yeah, I'd probably enjoy reading it myself. Unfortunantly, with the explosive
  86. >growth of the net, it's no longer an approximation of an ideal world. In
  87. >an ideal world, we wouldn't need locks on our doors, keyswitches in our 
  88. >cars, or firewalls on our nets. 
  89. >
  90. >Flaming admins as being "lazy" because a firewall is in place is *way*
  91. >out of line.
  92.  
  93. Agreed.
  94.  
  95. --
  96. Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
  97. Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
  98. Request file: /u/public/sources/DIRECTORY/README for instructions
  99.