home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3802 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.4 KB

  1. Path: sparky!uunet!olivea!hal.com!decwrl!sdd.hp.com!think.com!spdcc!dyer
  2. From: dyer@spdcc.com (Steve Dyer)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
  5. Message-ID: <1992Jul23.164314.4722@spdcc.com>
  6. Date: 23 Jul 92 16:43:14 GMT
  7. References: <BrruC8.FEo@spock.dis.cccd.edu> <BrsM1C.36v@cs.columbia.edu> <1992Jul23.142026.20112@sci34hub.sci.com>
  8. Organization: S.P. Dyer Computer Consulting, Cambridge MA
  9. Lines: 52
  10.  
  11. I was always under the opinion that "firewalls" and "mailbridges" (as they
  12. were originally proposed for use when the ARPAnet and MILNET split) were a
  13. Bad Thing.  To a certain extent I still agree.  However, after my experience
  14. with this most recent Sun hacker/cracker who was meandering around the net
  15. a few months ago invading hundreds of Suns and Ultrix machines, I have a
  16. different opinion.  I was in the unfortunate situation of being responsible
  17. for a group of Suns which were being invaded, and the loss of time and the
  18. disruption which the research group experienced due to this was more than
  19. annoying; it disrupted and sometimes destroyed real work.  I was doing
  20. this strictly pro-bono in an informal capacity with a group I am associated
  21. with, but at least I'm pretty familiar with the kinds of problems there are.
  22. God help the burgeoning majority of workstation users who are totally
  23. ignorant of issues like security as it relates to networks.
  24.  
  25. Listen, unless someone has a dedicated system manager who does nothing
  26. else, and is a security fiend, it is very difficult to be protected
  27. against someone who has infinite time, machine-like patience and an
  28. encyclopedic knowledge of existing security holes in the binary distributions
  29. of systems as shipped from companies like Sun.  Oh, and did I mention Sun?
  30. These days, the situation is much more likely to be an autonomous
  31. researcher taking a commodity out of a box and plugging it into their
  32. institution's 10-Base-T connector in the wall.  Their interests are not
  33. security; they've purchased this box to get their job done.  You can't hand
  34. them a 20 page paper giving them instructions on how to FTP and then apply
  35. the 30 most recent program patches to their version of the OS, that is,
  36. once they've determined that patch #8 doesn't conflict with patch #1
  37. and if they haven't upgraded their OS and wiped out earlier patches which
  38. never got into subsequent commercial releases.  And few sites are large
  39. enough and deem it important enough to provide support for this endeavor
  40. centrally.
  41.  
  42. The creation of CERT was a good idea, but it's so far been mainly
  43. reactive.  That's not a criticism, mind you--right now, that's a
  44. full time job as it is.
  45.  
  46. I see the use of gateways and other technologies to provide a firewall
  47. as inevitable and, for some sites, essential to their use of internetworks
  48. today.  It's not just big multi-billion companies worrying about the loss
  49. of trade secrets anymore, it's a matter of allowing unsophisticated users
  50. to get their work done without interference from some sociopath with too
  51. much time on his hands.
  52.  
  53. There are some real structural problems here.  Just one part of this
  54. is the attention to security in their distributed products by the OS
  55. vendors, which is remarkably lackluster.  Of course, what do you expect
  56. when they don't warrant their software to actually DO anything anyway
  57. except take up space on a distribution medium? :-)
  58.  
  59.  
  60. -- 
  61. Steve Dyer
  62. dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
  63.