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

  1. Path: sparky!uunet!darwin.sura.net!mips!pacbell.com!att!att!ulysses!ulysses.att.com!smb
  2. From: smb@ulysses.att.com (Steven Bellovin)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Firewall usage
  5. Message-ID: <17013@ulysses.att.com>
  6. Date: 28 Jul 92 19:13:56 GMT
  7. References: <Bs3vCz.K13@cs.columbia.edu>
  8. Sender: netnews@ulysses.att.com
  9. Lines: 43
  10.  
  11. In article <Bs3vCz.K13@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
  12. [lots of reasons why firewalls are a bandaid, and how we should fix the
  13. real problem, including getting vendors to ship secure systems]
  14.  
  15. John is, of course, absolutely right (except where he called firewall
  16. users ``communist'', which may or may not be true (the Internet reaches
  17. lots of places these days...), but is irrelevant and seemed to be
  18. intended as an insult).  Vendors should ship secure systems, internal
  19. security measures are necessary in any event, and users and system
  20. administrators should do a better job.  I strongly suspect that every
  21. firewall developer is fighting all of those battles, and many more.  I
  22. certainly do -- when I worry about TCP/IP security, for example, it's
  23. because AT&T uses it internally, and wants to secure its internal
  24. networks and products.
  25.  
  26. The problem with John's conclusions are that I have to live in the real
  27. world, which includes people who *must* run old versions of various
  28. operating systems, users who don't pick good passwords, and
  29. administrators who are careless.  I can't do anything about any of
  30. those things, except to exhort people to do better.  In the mean time,
  31. I try to keep the dragons away from their doors, while hoping for a
  32. better world tomorrow.
  33.  
  34.  
  35.         --Steve Bellovin
  36.  
  37. P.S.  It occurs to me that John is also wrong when he says that firewalls
  38. only defend against known problems.  That's precisely wrong.  Fixing holes
  39. only works until some chracker finds a new hole.  A good firewall keeps out
  40. anything but a very few services.  The network behind the firewall can
  41. be attacked, but only through bugs in either those few services or in
  42. the firewall itself.
  43.  
  44. While host security can -- and should -- be improved, I'm quite dubious
  45. that it can ever be made good enough.  Never mind bad administration --
  46. I don't think the state of the art of software engineering is up to the
  47. task.  I take it as axiomatic that all large programs have bugs, and
  48. that therefore security servers will have security bugs.  Yes, good design
  49. can minimze the odds and/or the impact -- but I doubt that the holes
  50. can ever be eliminated completely.  Looking at it another way, firewalls
  51. are precisely an example of good software engineering practice -- they're
  52. (presumably) small, simple pieces of code, and hence are much less likely
  53. to have bugs.
  54.