home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / novell / 9763 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.9 KB  |  98 lines
  1. Newsgroups: comp.sys.novell
  2. Path: sparky!uunet!sci34hub!gary
  3. From: gary@sci34hub.sci.com (Gary Heston)
  4. Subject: Re: Hack.exe
  5. Message-ID: <1992Nov23.151958.19631@sci34hub.sci.com>
  6. Reply-To: gary@sci34hub.sci.com (Gary Heston)
  7. Organization: SCI Systems, Inc., Huntsville, Al.
  8. References: <jdsmith.50.722206331@novell.com> <7212@news.duke.edu> <1992Nov21.110530.22022@novell.com>
  9. Date: Mon, 23 Nov 1992 15:19:58 GMT
  10. Lines: 86
  11.  
  12. In article <1992Nov21.110530.22022@novell.com> donp@novell.com (don provan) writes:
  13. >In article <7212@news.duke.edu> low00001@bullnext.mc.duke.edu (Richard Low) writes:
  14. >>Ah, but as Eric J. Schwertfeger pointed out in his follow up posting,  
  15. >>physicall access to a server is the determining factor.  Even if the console  
  16. >>is secured, I can kill the power (and probably some files) to bring the  
  17. >>server down.  Then all I need is a boot floppy with SERVER.EXE and my set  
  18. >>password NLM on it and I can do my thing.
  19.  
  20. Actually, you don't even need SERVER.EXE on the floppy; once you've 
  21. booted off the floppy, you can run it off the hard drive. The AUTOEXEC.NCF
  22. is what you need to intercept/modify.
  23.  
  24. >Isn't this just a characteristic of your hardware purchase?  I mean,
  25. >all you're saying is that you can get control of your machine before
  26. >NetWare does.  It's hard to fault NetWare for not doing something
  27. >before it gets control.
  28.  
  29. Not the hardware purchase, but the installation. No matter what fancy
  30. hardware you buy, if it's set out in the middle of an open area, it's 
  31. not secure. *Access* to the hardware is the concern; not anything the
  32. OS does. I don't think anyone is faulting NetWare for not being able to
  33. do anything about this; just trying to avoid giving inexperienced users
  34. and admins a false sense of security. The security aspects of NetWare
  35. are only protection against attacks through the wire, and they seem to
  36. be fairly adequate for that. A very determined intruder will eventually
  37. get through, but the average bozo will be stopped.
  38.  
  39. >I don't know if any PC manufactures have done this, but it wouldn't be
  40. >too hard to prevent this type of attack.  Most PCs nowadays have a
  41. >CMOS configuration switch to force booting off the hard disk.  Just
  42. >require a password to change CMOS, and then without the password the
  43. >server should be unstoppable, shouldn't it?
  44.  
  45. I've seen some BIOS implementations that have a programmable boot 
  46. sequence, that will allow the hard drive to be selected as the first
  47. choice. There are also boot passwords, although I haven't seen one
  48. for simply changing the CMOS.
  49.  
  50. The problem that arises here is: what do you do when it's *necessary*
  51. to break in? I've seen several "help, the supervisor quit/got fired and
  52. nobody has the password" requests; if you make the server/NOS combination
  53. impenetrable, how can this be recovered from? Or, if SERVER.EXE gets
  54. damaged, and hangs the server on attempting to boot? These situations
  55. are remidied by booting from a floppy, and using a password NLM (or
  56. reinstalling damaged files).
  57.  
  58. I don't expect NetWare to protect from physical attacks; that's effectively
  59. impossible to do and still have a usable server.
  60.  
  61. >Once you get this far, the direct break-ins would tend to be physical.
  62. >There's no end of physical escalation, so i tend not to worry about it
  63. >myself.  Even with solid software protection, "all" the enemy has to
  64. >do is open up the box, remove the hard disk, and put it in a machine
  65. >that's more "friendly".  Put a lock on the case, and the enemy has to
  66. >pick, pry, or burn it open.  Lock it in a room, he breaks into the
  67. >room...and the building!  Heck, put armed guards around it...he
  68. >*kills* them.  Ad infinitum.
  69.  
  70. Yes; I've read a posting describing a gutted server (drives, boards,
  71. NICs, etc. pulled and carried out in a sports bag). I've heard of a
  72. similar incident with a non-networked system. 
  73.  
  74. There are limits to physical security; however, a locked room will 
  75. deter the overwhelming majority of attacks. Because someone might 
  76. kill an armed guard to steal a copy of Windows 3.1 off the server
  77. doesn't mean it's pointless to implement *any* physical security. 
  78. Rather than "not to worry about it", I'll make a reasonable attempt to
  79. secure the hardware, inside a locked room if possible, a locked cabinet,
  80. or *something*. No security system is impenetrable; if someone wants
  81. in, they'll get in. I just need to make it not worth their while.
  82.  
  83. >This reminds me of Craig Everhart's axiom: *Never* put anything into a
  84. >computer or a network that you don't want anyone else to see.  Too bad
  85. >his advice isn't practical, even if it is sage.
  86.  
  87. Better yet, embed the computer in concrete and drop it in the Mariannas
  88. Trench. I don't know of anyone that wants to go under several thousand
  89. feet of water to crack a server.
  90.  
  91. About as practical....
  92.  
  93. -- 
  94. Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
  95. The Chairman of the Board and the CFO speak for SCI. I'm neither.
  96. "Data sheet: HSN-3000 Nuclear Event Detector. The [NED] senses the gamma
  97. radiation pulse [from a] nuclear weapon." As if we wouldn't notice...
  98.