dbielik@sunb.mqcc.mq.oz.au (Danny Bielik) (12/04/90)
I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up so that there is an account whose sole purpose is to wait for 1am and then do a full backup to tape. Now, I have this problem, where, whilst it is waiting for a backup, someone can come along and CTRL-C and break into an account with full supervisor priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to stop anyone from doing this. I also don't want any TSR memory overhead, so it has to be a program that is run then finished, not stay-resident. Please don't tell me that I should be using a TSR backup program, because that is what I am trying to avoid by having the backup a/c. ******************************************************************************* * Danny Bielik J U S T * * dbielik@mqccsuna.mqcs.mq.oz.au S A Y * * Macquarie University - Sydney Australia N O ! ! * * Phone (W) +61-2-212-6699 Fax +61-2-281-7394 * *******************************************************************************
ddg@intuit.intuit.COM (David DelGreco) (12/06/90)
dbielik@sunb.mqcc.mq.oz.au (Danny Bielik) writes: >I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up so that there is an account whose sole purpose is to wait for 1am and then do a >full backup to tape. >Now, I have this problem, where, whilst it is waiting for a backup, someone >can come along and CTRL-C and break into an account with full supervisor >priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to >stop anyone from doing this. I also don't want any TSR memory overhead, so it >has to be a program that is run then finished, not stay-resident. >Please don't tell me that I should be using a TSR backup program, because that >is what I am trying to avoid by having the backup a/c. Why not just disconnect the keyboard? If it's sole purpose is to wait for a certain time at which point to backup, then no one should be using it anyway, should they?
leonard@qiclab.uucp (Leonard Erickson) (12/06/90)
dbielik@sunb.mqcc.mq.oz.au (Danny Bielik) writes:
<I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up so
<that there is an account whose sole purpose is to wait for 1am and then do a
<full backup to tape.
<Now, I have this problem, where, whilst it is waiting for a backup, someone
<can come along and CTRL-C and break into an account with full supervisor
<priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to
<stop anyone from doing this. I also don't want any TSR memory overhead, so it
<has to be a program that is run then finished, not stay-resident.
Well, our solution is rather simple. We *physically* secure the system
that is running the backup. In our case, it's inside a *locked* office.
You may be able to get away with merely locking the keyboard.
Never try to use software for a job more reasonably done by hardware!
--
Leonard Erickson leonard@qiclab.uucp
personal: CIS: [70465,203] 70465.203@compuserve.com
business: CIS: [76376,1107] 76376.1107@compuserve.comabrams@cs.columbia.edu (Steven Abrams) (12/07/90)
dbielik@sunb.mqcc.mq.oz.au (Danny Bielik) writes:
<I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up so
<that there is an account whose sole purpose is to wait for 1am and then do a
<full backup to tape.
<Now, I have this problem, where, whilst it is waiting for a backup, someone
<can come along and CTRL-C and break into an account with full supervisor
<priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to
<stop anyone from doing this. I also don't want any TSR memory overhead, so it
<has to be a program that is run then finished, not stay-resident.
A solution would be to run a program which waits until 1:00 AM and
then logs in as the backup account -- the backup account then gets
its login script re-written a bit so that it doesn't wait -- it just
always does the full backup. This solves the problem of having the
machine hang out logged into supervisor, although if you bang on ^C
enough during backup, you can get out and be supervisor.
There's another security issues you might want to consider for this
setup:
If a user sets the clock on his personal machine to be 12:58 AM and
logs in as this backup user, the backup software may abort in a way
that permits him/her to ^C out of it before the login script logs him
out. Voila, anyone can use this account to become supervisor.
Solution: Use the setup described above, where the account doesn't
wait, it does the backup, and restrict this account to be able to
login ONLY between 12:55 AM and 1:05 AM and ONLY from the machnine(s)
with the tape drive. Time and Station account restrictions were new
in Novell ANW 286 v2.15, and I believe they exist in ELS as well. I
never touched the stuff, so I'm not sure.
As for solving the Ctrl-C problkeem, try this:
Write a program that installs a bogus keyboard driver (latch on to the
keyboard hardware interrupt at the lowest level) that chucks any keys
typed and does nothing with them. This would be an absolutely TINY
TSR, i.e. < 1k, if written in ASM. The first command in the login
script for this backup user should load this bogus driver. Also, you
might want to put this in the batch file that logs in as the backup
account. Afterwards, run a de-install program that restores the
keyboard driver.
Cobining all methods described above leaves one remaining security
hole, which is:
A user gets physical access to the machine with the tape backup
between 12:05 and 1:05 AM, logs in as the backup user and manages to
bang on ^C sufficiently hard and often to cause the login to be broken
out of sometime after connection established and BEFORE the login
script is actually started.
Of course, station+time restrictions on the account plus a locked door
on the machine is probably the best solution...
~~~Steve
--
/*************************************************
*
*Steven Abrams abrams@cs.columbia.edu
*
**************************************************/
#include <std/dumquote.h>
#include <std/disclaimer.h>karinc@isc.intel.com (Karin Coffee) (12/07/90)
dbielik@sunb.mqcc.mq.oz.au writes: > I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up > so that there is an account whose sole purpose is to wait for 1am and then do > a full backup to tape. > Now, I have this problem, where, whilst it is waiting for a backup, someone > can come along and CTRL-C and break into an account with full supervisor > priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to > stop anyone from doing this. I also don't want any TSR memory overhead, so it > has to be a program that is run then finished, not stay-resident. > Please don't tell me that I should be using a TSR backup program, because that > is what I am trying to avoid by having the backup a/c. I use Keyworks. Although keyworks is a TSR, it only becomes a TSR when it loads and it removes itself from memory when it quits. I am using an ancient Mountain Tape drive with streamer tapes to backup. Part of the Mountain Tape software contains a file called autoset. It takes the data for what day and time to run whatever command line you add to the autorun.dat file. My command lines all happen to be keyworks commands. I have one that deletes a group of temporary files (that don't auto delete) just prior to the complete backup each week. From within my keyworks file I log in as user "backup" and then issue the command that runs the tape drive to backup all of my data files. My backup runs at 2am. I do an incremental backup on Monday, Wednesday, Thursday, and Friday mornings. I do a complete backup of the volume on Tuesday. By the way, my user backup does not have supervisor privileges. Backup is simply mapped so that M: goes to SYS: and N: goes to SYS1: (which is my data volume). Backup has (and this is in NetWare 386, but I did it the same way in 286) Read, Write, Create, Erase, Modify, File Scan, and Access Control rights in M: and N:. This is everything except Supervisory rights. I know that names are different in 286, but the meanings are similar. I am currently looking for a better tape system, probably an exabyte drive, so that my complete backup can run at night without the need to swap tapes. I hope this helps. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Karin Coffee Intel Supercomputer Systems Division Network/System Administration 15201 NW Greenbrier Parkway The LAN Lords Beaverton, OR 97201 karinc@isc.intel.com (503) 629-7693 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
csmith@plains.NoDak.edu (Carl D. Smith) (12/07/90)
In article <368@intuit.intuit.COM> ddg@intuit.intuit.COM (David DelGreco) writes: >dbielik@sunb.mqcc.mq.oz.au (Danny Bielik) writes: > >>I am running Novell ELS II V2.12 in Non-dedicated mode, and I have it set up so that there is an account whose sole purpose is to wait for 1am and then do a >>full backup to tape. > >>Now, I have this problem, where, whilst it is waiting for a backup, someone >>can come along and CTRL-C and break into an account with full supervisor >>priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to >>stop anyone from doing this. >Why not just disconnect the keyboard? If it's sole purpose is to wait >for a certain time at which point to backup, then no one should be using >it anyway, should they? If you just unplug the keyboard, someone could plug in a keyboard from another machine, and use the account with supervisor privilages. If you have a computer with a keyboard lock, you can lock the keyboard, but that is not very secure, since the key locks are not very strong, and could be turned with almost anything like a screwdriver, etc. Also, there aren't very many different kinds of keys used for keyboard locks, so it's very likely that someone else has an identical key. One solution might be to find a TSR that disables control break and control alt delete key combinations. I don't know of any method that would make the computer completely safe, other than locking it in a room that nobody can get into. But, if nobody is using the computer, it doesn't matter if some RAM is used for one of these TSR auto backup routines that logs itself in to the network at the time of the backup. Then the machine is not logged in as a supervisor until the time of the backup. But someone could stop the backup and exit the program, and still get access to the supervisor account. The only sufficient solution that I can think of is to lock the computer in a room that only supervisors have keys to. Carl Smith .signature? A
ddg@intuit.intuit.COM (David DelGreco) (12/09/90)
>>>Now, I have this problem, where, whilst it is waiting for a backup, someone >>>can come along and CTRL-C and break into an account with full supervisor >>>priveleges. Now I need a way to disable CTRL-C and CTRL_BREAK in order to >>>stop anyone from doing this. >>Why not just disconnect the keyboard? If it's sole purpose is to wait >>for a certain time at which point to backup, then no one should be using >>it anyway, should they? >If you just unplug the keyboard, someone could plug in a keyboard from >another machine, and use the account with supervisor privilages. If you >have a computer with a keyboard lock, you can lock the keyboard, but that >is not very secure, since the key locks are not very strong, and could be >turned with almost anything like a screwdriver, etc. Also, there aren't >very many different kinds of keys used for keyboard locks, so it's very >likely that someone else has an identical key. >The only sufficient solution that I can think of is to lock the computer in a >room that only supervisors have keys to. You are absolutely right. I was not clear. I should have said "take the keyboard with you", but someone could still plug a keyboard in. Putting the machine in a locked room, like a phone room that people normally stay out of, is the best solution. And if people are determined to get into your system via the backup machine, then it is your ONLY solution. If you use a TSR that locks the keyboard until a certain time, the "burglar" only has to reboot the machine, break out of the autoexec, rewrite the autoexec to disable the TSR, and he's in. If you have the machine boot in without having the password in a file, then at least he's stuck for finding out the password, but he could write a routine to mimic the TSR. Locking the keyboard, as stated, is not all that effective. In short, if someone is skulking about your place of business trying to break into the supervisor account, there is NO way to stop him unless you put the machine in a secure place. Consider a house or a car. You can't keep someone out, can you? You make it hard to get in, you can force them to break the glass, thus alerting anyone nearby, but you can't actually keep them out. Same with a computer, unless you remove all the "doors" and "windows". David DelGreco ddg@intuit.com
masinter@parc.xerox.com (Larry Masinter) (12/12/90)
Are the novell protocols secure enough that someone couldn't just tap into your net and just watch for packets with the supervisor's password? What kind of risk do you want to protect against? -- Larry Masinter (masinter@parc.xerox.com) Xerox Palo Alto Research Center (PARC) 3333 Coyote Hill Road; Palo Alto, CA USA 94304 Fax: (415) 494-4333
bdelvecc@kinetics.com (Brian Del Vecchio) (12/29/90)
In article <MASINTER.90Dec11194227@origami.parc.xerox.com>, masinter@parc.xerox.com (Larry Masinter) writes: > Are the novell protocols secure enough that someone couldn't just tap > into your net and just watch for packets with the supervisor's > password? NetWare now encrypts all passwords on the wire, to avoid exactly this problem. The workstation asks the server for an encryption key, then encrypts the password and sends it in encrypted form across the wire. A capture of the packet containing the password would not be valid for a second login attempt from another workstation, since the login key is different each time. This encrypted password feature is available in file servers starting at 2.15 (maybe a little earlier, but definitely not 2.0), and in DOS workstation shells (net#.com) and utilities (login.exe, attach.exe, etc) on or around 3.0. I am a little unclear about which version of the software first had this feature. The default configuration for a 3.x server is to deny unencrypted logins. When this happens, you get this message on the console: "Station <n> attempted to use an unencrypted password call." It is possible to configure the 3.x server to allow unencrypted logins, but the wiser choice is to upgrade the utilities on all servers to match the 3.x server. At least, that's what the install manual recommends. [----------------------------------------------------------------------------] brian del vecchio; software engineer; novell, inc.; walnut creek, ca, usa; "But for what purpose was the earth formed?" asked Candide. "To drive us mad," replied Martin. - Voltaire, _Candide_ [---the opinions expressed are mine...the official Big Red Word may differ---]