-------------------------------------------------------------------
SECURTY1.DOC -- 19960730 -- Email thread on NetWare Security Issues
-------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




On firewall's in general you should run to your favorite bookstore
and get: "Firewall's and Internet security: repelling the wily
hacker" from Cheswick & Bellovin, Addison & Wessley press.
The section with port-numbers to block in the back is very usefull
and can already be inplemented at a decent access list on a decent
router.

Henno Keers

------------------------------

Date: Tue, 26 Sep 1995 00:16:16 -0400
From: Joe Short <jshort@FUENTEZ.COM>
Subject: Finding Supervisor Users in Bindery

>I am looking for a utility which will give me a list of all users on a
>server who have supervisor rights. We recently had a problem with some
>goofy user backing up their hard drive to the apps volume and running
>it out of space. She should not have super access, and we arn't sure
>how she got it. Now I want to see who else may have these rights. With
>over 10,000 defined users looking up the rights one at a time isn't an
>option :-)

Try NetWare's SECURITY.EXE command (DOS executable). Not the most detailed
function, but an effective reporting tool. You can use the command by
itself for screen display, or redirect the output to a file.

Example:  Z:\SYSTEM\SECURITY  >  C:\NET\LOG\SECURITY.LOG

With 10,000 users, I strongly suggest you redirect to a file!
After entering the above command, the prompt will not let you know
that it is processing, and it could be quite a while before you see
results.  Just be patient and let it complete.

Joe Short

------------------------------

From: Garry J Scobie Ext 3360 <GSCOBIE@ml0.ucs.ed.ac.uk>
Date: Tue, 26 Sep 1995 12:25:45 +0000
Subject: Security hole ?

http://mft.ucs.ed.ac.uk/novell/techsup/servman.htm

------------------------------

Date: Tue, 26 Sep 1995 04:03:15 GMT
From: Eli Shapira <elis@EGSOFTWARE.COM>
Subject: Re: Crack: Released.

A similar program is available from e.g. Software, Inc.

Will scan for 150,000 words and different alogrithms searches (Dates,
NetWare names, Anagrams, etc...).

However, it is an NLM that works on your server and does not require a
download of the bindery (and therefore it is more secure).

SmartPass NLM is available for download from:

http://www.egsoftware.com

-----

Yes - SmartPass also uses NetWare names, Real Names (First and Last),
places around the globe, common used words, hackers dictionary.

SmartPass can automatically expire passwords that are found weak, notify
the user and notify the administrator.

ID DOES NOT REQUIRE YOU TO CLOSE THE BINDERY AND DOWNLOAD IT TO YOUR
WORKSTATION.

SmartPass runs in the background and has a built in Scheduler to start a
password scan on a specified time.

It will also automatically scan any new password set by the user or
administrator.

All of this can be done only through an NLM that runs securely on a
server.

SmartPass and other NLM products can be downloaded from:

http://www.egsoftware.com

SmartPass is available in two versions - one that displays the passwords
and one that does not display them but does display the user name that has
the weak password.

Eli Shapira

------------------------------

Date: Wed, 27 Sep 1995 12:15:57 +0100
From: "Mr. R. Coates" <roysan@LIVERPOOL.AC.UK>
Subject: Re: Crack: Released.

> A similar program is available from e.g. Software, Inc.
>
> Will scan for 150,000 words and different alogrithms searches (Dates,
> NetWare names, Anagrams, etc...).
>
> However, it is an NLM that works on your server and does not require a
> download of the bindery (and therefore it is more secure).

Crack also uses netware names, real-name info, and a few other tricks in
addition to the dictionary. Since it will run on a standalone PC it also
causes no network load. But the greatest difference, and one which is
important to many sysadmins (esp University/College ones) is that it is
free.  This is one of the main reasons ALL my software is freeware.

Incidentally, Crack 1.2 is now online and supports a /SECRET switch to
suppress the display of discovered passwords on the screen. As requested
by several users.

	ftp://ftp.mechnet.liv.ac.uk/novell/freeware/crack.zip

	http://www.mechnet.liv.ac.uk/~roy/freeware.html

A couple of people have suggested that I add a feature to disable accounts
whose passwords have been cracked.... your thoughts please to:

Roy Coates

------------------------------

Date: Mon, 16 Oct 1995 12:55:02 -0800
From: Stephen Herzog <herzogs@SDESIGN.COM>
Subject: Re: Passwords

>>> Does anybody know about some kind of program
>>> that can read a user's password from the Netware bindery?
>>> Is the bindery  secure?

>"Mr. R. Coates" <roysan@LIVERPOOL.AC.UK> wrote:
>>There is no way to read a users password from the bindery. It's quite
>>secure.

and lastly, <gmcneel@bindview.com> Gary McNeel, Jr.
	Director - Technical Marketing BindView Development Corporation
	made the following comments:

>This is not true!  Passwords in the Novell bindery can be read and
>captured, though it is not easy.

So, I felt the need to add my 2 cents worth.

No, you can not just open the bindery and see a user's password.

Yes, passwords can be obtained, however it is not something trivial.

* You must get a copy of the encrypted password from either the bindery,
  or capturing a login packet sequence.

* You then have to use a guess and check method of determining the password.
  ie, take the first word from your dictionary, encrypt it, check the
  result against the encrypted password, if it matches, the word you
  encrypted was the password.  If it doesn't match, get the next word
  from the dictionary and try again.


And then <gmcneel@bindview.com> Gary McNeel, Jr.  Continues...

>There are a few products on the
>market that can do this.  Some can give you list of passwords found
>not to be secure, such as SmartPass NLM, which keeps a list of
>passwords it has found by comparing user passwords against, at last
>report, a 150,000 word database(s).
>
>We felt that a security product should not give you a list of unsecure
>products, it opens another security hole in your network.  We
>developed Password Sentry NLM help people secure their sites against
>intrusion through the exploitation of weak passwords.  Password Sentry
>has 18 databases with over 1 million words.

Ok, lets argue on dictionary sizes.  First off, the bindery provides
you with the number of characters in the original password.  How nice.
If you pre-sort your dictionary by the length of the words, you can
avoid checking all but the words of the same length of the password.

I assume that a "set of 18 databases with 1 million words" is 18 files,
each with a set of words of a specific length.  Each password in the
bindery would be checked with aprox 60 thousand words then, correct?
It would be a waste of time to check all 1 million words, since you can
eliminate the ones that are the wrong length.

And what of large dictionaries.  Is bigger always better?  Yes and No.
If you were trying to break the supervisor password on a specific
file server, and you happen to know that they use a password checking
program such as Password Sentry, our Password Inspector, or SmartPass,
you could purchase a copy, extract the words from the dictionary, and
you now have a list of 1 million words you don't need to check.

So in short, a dictionary with 5 words is pretty useless... So is one
that contains every possible combination of letters and numbers for
each length of password.  (what should the user use for a password if
*all* the word-letter combinations are already in a dictionary.)  I
won't make any judgements as to what the best word count is for a
dictionary (the sysop should do that) but don't assume bigger is
always better.

If you want passwords that are harder to guess, increase your minimum
password length.   4 and 5 letter passwords can be broken by testing
every possible set of letters and words pretty quickly.   Explain
to your users why secure passwords are important, and ask/force them
to use long passwords with letters and numbers.

But be careful; long-hard-to-remember passwords tend to get written
down.  There is nothing worse than someone finding a business card
with your account name and password on the back.

------------------------------

Date: Thu, 16 Nov 1995 13:06:27 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Novell Hacking Protection?

>What programs, or patches can be run to prevent to use of the following
>programs or ideas?
>
>hack.exe - a program that i believe sends packets from a fake supervisor
>	    to do such things as gain supervisor access.

packet signing -- I insist everyone who uses supervisor has their station
set to level3 -- if they cannot login to an unsecure server, then they
know to fix it.

>view.exe - a program that allows anyone to see supervisor equals.

not too worried about this...

>sniffers..watching network packets, from the supervisor as he calls

Build your network using devices that scramble data, eg the 3com FMS-II
hubs have the ability ot operate in a secure mode.

>rconsole, with the use of rcon.exe anyone could decrypt, or see the
>rconsole password (that was a senario using sniffers.)

go back to the previous answer.

Yes, we really need to be quick on our feat in an academic environment,
commercial companies don't appear to suffer from the same problems (from
experience of doing security consultancy work)

Richard Letts

------------------------------

Date: Sun, 19 Nov 1995 08:34:04 +0000
From: Rob Mcgillen <rmcgillen@HOUSING.HOUSING.UOKNOR.EDU>
Subject: A good NLM to think about....

I am not one to give faint praise- usually no news is good news
around my shop..... but I wanted to share with this listserv the
excellent experience I have recently had with a Commercial Nlm....

Audittrak- from On Technologies.

I installed it this past Friday afternoon on a 250 user Novell 3.12
lan here at the Univ. of Oklahoma... this lan is used for a number of
tasks.... from payroll to lab software distribution.... and a number
of the workstations are "public" access- someone could(and have) wander
in with little to no supervision and monkey with things....( I inherited
this headache- and have been pulling out hairs at the numerous screwball
things that have been going on....)  Using the default nlms and logs
on Netware 3.12- I was not getting much of an idea of how certain
programs were executing, etc.

Anyway- I installed the NLM on Friday afternoon.... came in Yesterday
(Saturday)- and had a full log of access, logins, .exe alterations,
attempted logins, accesses to restricted documents, etc.  I sat down
and read thru the 12 hour -61 page log- and was amazed at what was
going on.... caught 6 different students in VERY wrong places.... all
kinds of .jpg's and .gif's that really should not be on a state
server, etc.  Also found a person trying to hack the supervisor
password...

The log was quite an interesting read... not only did it give me an
idea who were problem users, it also let me know about files that
were not working properly-resulting in some of the squirrelly program
executions I had witnessed.

Anyway, if you need a better idea of what is going on in your network
- and console logs are not cutting it- I recommend it.  As this isn't
an ad for On Technologies- you will have to look up their number
yourself or drop me some mail...

------------------------------

Date: Tue, 21 Nov 1995 03:44:06 GMT
From: Gerald Khoo Seng Wee <cceksw@LEONIS.NUS.SG>
Subject: Re: Novell Password Change

>There is a parameter for checking of the number of days where the
>password will expire. I think it is PASSWORD_EXPIRES (I don't have the
>manuals with me right now). I have added that in my system login
>script to inform my users when their password is going to expires within
>7 days.

Yes... just put the following lines in your login script:

	write "Your Password Expires in %PASSWORD_EXPIRES Days"

and it will show you the number of days before your password expires on
each login.

------------------------------

Date: Sat, 25 Nov 1995 09:24:16 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Logging hacking on Novell

>>>>I have a problem with somebody internal that is a litle to eager on the
>>>>Novell 3.12 network.  Does anybody know of a NLM that writes to a
>>>>log-file every login and logout with name, nettwork address, date
>>>>and time. Both successful and unseccessful logins ?
>>
>>Paudit only logs succesful logins, not the
>>unsuccesful. You could use the Intruder detection for the unsuccesful
>>ones (at least you'll know where they come from), but this will
>>severely disturb the 'hacked' user account. Especially the
>>supervisor's.
-------------
	You need to look around more thoroughly. See file SHOWEV.ZIP in
directory misc on netlab2.usu.edu. It will show much more than you may
wish. It is the original tool used to detect presence of hack program.
	Before asking repeated times for a utility, Please read the list's
FAQ and explore the sites listed therein. Failure to do so bothers everyone
on the list.
	Joe D.

------------------------------

Date: Wed, 29 Nov 1995 18:17:13 UTC+0100
From: Amador Hernandez <amador@ETSEIB.UPC.ES>
Subject: Re: Reducing net$acct.dat

>I need to reduce the size of the net$acct.dat file and move some of the
>oldest data to other files. How do I do that ? I would prefer if the new
>files with the oldest data would be readable for paudit or paudit2.

You can simple delete the NET$ACCT.DAT, and next time some user logs in,
a new one will be created (on NetWare 3.11).

I use it to see how many times a user logins in one month. I do PAUDIT
one a month, and with a simple C program I examine the lines generated
with PAUDIT > C:\PAUDIT.TXT, and see how many times a user had logged in.
Each month I delete the NET$ACCT.DAT, and a new one is created when the
next user logs in.

------------------------------

Date: Mon, 27 Nov 1995 16:50:40 PST
From: Rob Wiese <rtwiese@UCDMC.UCDAVIS.EDU>
Subject: Re: Logging hacking on Novell

>I have a problem with somebody internal that is a litle to eager on the
>Novell 3.12 network.
>
>Anybody know of a NLM that writes to a log-file every login and logout
>with name, network address, date/time, both successful & unsuccessful
>logins ?

I track this using a combination of w3secmon.nlm and conlog.nlm

Each unsuccessful login via invalid password is written to the console:

  <date> <time> <error #> Intruder lock-out on account jdoe <mac address>

Which is then written to sys:etc\console.log (may be redirectable).
sys:system\sys$log.err contains the same info, although the level of error
written may be changeable.  This info tells me who the target is, and what
machine(s) they are using.

w3secmon.nlm writes all changes to the bindery, including logins.  On a
monthly basis I grep this file for logins, then compare typical login mac
addresses.  If there is alot of activity during off hours, or logins from
a machine other than their normal machine, then I know I have a problem and
take appropriate action.  netmon.nlm (mentioned in another post) is similar
and would work.

Rob

------------------------------

ftp://ftp.coast.net/SimTel/msdos/security/awolv11.zip       74075 bytes

AWOL v1.1 is simply a password prompting program designed primarily for
a network user, who wishes to tmporarily leave their PC while remaining
logged on.  The user runs AWOL as a convienient method of securing
their account in their absence, saving them the bother of logging out,
searching for another PC on their return, and logging back in again.
AWOL consists of a graphics display with a message, as well as the
password prompt. FreeWare. Uploaded by the author: Val Hayes,
c2vhayes@compapp.dcu.ie, http://www.compapp.dcu.ie/~c2vhayes/val.html

Floyd Maxwell

------------------------------

Date: Sat, 2 Dec 1995 22:23:27 -0500
From: Faisal Imtiaz <faisal@COFS.COM>
Subject: Re: Firewalls

Well, let's look at this...

If you are only using IPX/SPX for on the Novell Server, i.e. TCP/IP
is not bound on the file server,then it will be impossible to get to
the file server...

However...
if any of your worksations decide to experiment with ftp or telnet
daemons, then someone from the outside can get access to the novell
file server through the WFW/WIN95/WIN nt client...( in this case
the client acts as a gateway !)

By the way ... I would worry about the NT machine a lot....with
the right settings on the client side (WFW or WIN95) users can very
easily MOUNT your shares !!!! (If you wish to know more about this
send me Email)...

------------------------------

Date: 12 Dec 95 09:12:06 EST
From: Deepak Bhatia <70404.1143@compuserve.com>
To: NW4 Mailing List <NETW4-L@bgu.edu>
Subject: Burglar brings Supervisor back to Life!!!!

Location of burglar is as folows:

	ftp://ftp.rhij.nl/cyco/burglar.nlm

Note: BURGLAR creates a tempory user that is incomplete. Log in under
this users name (and remove the account after use). BURGLAR was written
by Bart Mellink from Cyco.

Works with NetWare 4.x too

---------

BURGLAR would work for any version of Netware that supports a
CreateBinderyObject with READ|WRITE level status.

The control is to physically secure the server and limit rconsole access
and could also REMOVE DOS and SECURE CONSOLE at the server to limit the
damage.

Mervin Pearce

------------------------------

Date: Fri, 15 Dec 95 00:37 MET
From: arthur-b@ZeelandNet.nl (Arthur B.)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

>I am not a system admin so please bear with me.  I joined this list
>because I'm working in a public library where we just installed 90 pc's
>with Windows 3.11 and Novell 4.1, MS Office, etc.  They are available
>to the public and we are having security nightmares.
>Can we secure individual hard drives through Novell?  We have a security
>system called Fortres but there are lots of things it doesn't do.  Any
>suggestions you can provide are appreciated.

Aiaiaiaiaiaiai!

What you need is RPL boot-PROMS.  Consult your supplier for this.

Also, put a CMOS password on every PC.

Deactivate all floppy-diskdrives (option in most CMOS's).

Deactivate the LPT and COM ports as well.

Delete Windows 3.1 from the local harddisks and put it
in a directory on the fileserver (shared full fileserver install;
check the manuals for: setup /a). Restrict the rights to that.

Buy a good book about Windows 3.11.  It should contain text about
installing Windows on a network. Solutions to securing Windows 3.11
(preventing access to certain areas of Windows). Preventing access to
DOS, etc.

What you don't want in Windows is access to the configuration,
access to DOS, allowing starting of executables, deleting icons, etc.

In short, a book about Security (Novell and Windows specific).

Call MicroSoft and Novell, maybe can direct you to some
informations spots (ftp or so) about this.

I will not bother you with other options than RPLboot as these are
somewhat difficult to explain.

Just wondering...
What was the reason for buying 90 PC's and a network and not
hiring a system administrator?

Have you checked for virusses lately?

------------------------------

Date: Thu, 14 Dec 1995 19:42:58 -0600
From: pinc0059@centuryinter.net (Shawn Dunn)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

Mary

     I know what you are going through.  I am the Tech Coordinator for the
Sparta School district and we had a terrible time with security.  But this
is what I did.

First- take off Fortres it's nice but not useful.

Second- Make a window. Go to 'File' and the 'New' and selecting 'Program
Group'.  Call it Library for the description and Library for group name.
Move the icons that you want the patrons to use to the Library Group.

Third-Go out of windows and at the dos prompt change to the windows directory
and edit the Progman.ini file.  Under the groups section go through and put
a semi colon in front of each line except for the library group line.

For example:
	[Groups]
	;Group1=C:\WINDOWS\MAIN.GRP
	;Group2=C:\WINDOWS\ACCESSOR.GRP
	;Group3=C:\WINDOWS\NETWORK.GRP
	 Group4=C:\WINDOWS\LIBRARY.GRP

Next time in

	[restriction]
	NoClose=1
	NoExit=1

This will prevent people from exiting Windows.

Fourth Create a boot diskette.  If you have to make changes to windows,
you will have to boot from the diskette, edit the progman.ini, changing
the NoClose=1 to NoClose=0 and then NoExit=1 to NoExit=0.  Make your
changes and the edit progman.ini back.  The kids at school cannot make
any changes.

------------------------------

Date: Fri, 15 Dec 1995 17:53:27 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Supervisor Password 3.x

>> I have just been hired at our local High School which has a business lab
>that
>> was setup on a Novell Network sometime ago by a fly-by-night group that is
>> now out of business.  Apparently, in order to keep the business of the
>> school, they setup the password for the supervisor and kept it a secret.
>>  Now, I would like to take control of the supervisor responsibilities but
>> cannot because I don't know the password.  What can I do?
>
>     it is possible to change it with a disk editor.  I have the exact
>procedure at home (have to look for that one!,  its been a loooooong time!).
>
>     Alternatively,  it is possible to play some games with renaming the
>sys volume, mounting a "new" sys volume,  etc.

cue: no, no, no, no

get setpwd.zip from ftp.salford.ac.uk/network/nlms

put it on a floppy.

insert floppy into floppy drive on server

type:
load a:setpwd.nlm supervisor fat-freddys-cat

hey-presto the supervisor's password will be set to fat-freddys-cat

moral of this: if your fileservers are not locked away then they are
insecure!


------------------------------

Date: Sat, 16 Dec 1995 06:16:26 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

Andee and Shawn

Before implementing ANY of these solutions I would bring in a knowlegeable
expert to look at your system:

1. Depending on the system configuration, booting and running from the
server can overload the server. This problem is workable, but the entire
system configuration needs to be considered. Don't forget that while
Windows CAN be run from the network it was not originally designed for it;
the result is some VERY heavy server loads.

2. Unfortunately the suggested INI file alterations will not keep any but
the novices from messing with the system. Windows doesn't have anything
resembling security, hence the proliferation of third party solutions. I've
seen a number over the years, but none come to mind at the moment.

3. Much as I hate to admit it, RPL boot proms may be the way to go. The you
can lock down the system until a gnat can't get through. If your clients
don't need them you can disable the floppy drives, but of course that
depends on what the PCs are for. If they're needed, you can at least
implement a secure virus policy and limit infections to nearly none.

4. Follow the earlier advice regarding security education. Even if you have
someone else do the work, you need to know enough to know they know what
they're doing!

Not hiring an administrator for 90 workstations? Let me guess, either the
advice was that you wouldn't need one or someone decided to save some money
and YOU could do the work (along with your current job, of course). Gee,
I'm not cynical, really I'm not. It's just the usual reason.

------------------------------

Date: Sat, 16 Dec 1995 07:44:44 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

>For example:
>	[Groups]
>	;Group1=C:\WINDOWS\MAIN.GRP
>	;Group2=C:\WINDOWS\ACCESSOR.GRP
>	;Group3=C:\WINDOWS\NETWORK.GRP
>	Group4=C:\WINDOWS\LIBRARY.GRP
>
>Next time in
>
>	[restriction]
>	NoClose=1
>	NoExit=1
>
>This will prevent people from exiting Windows.
>
>Fourth Create a boot diskette.  If you have to make changes to windows, you
>will have to boot from the diskette, edit the progman.ini, changing the
>NoClose=1
>to NoClose=0 and then NoExit=1 to NoExit=0.  Make your changes and the edit
>progman.ini back.  The kids at school cannot make any changes.

This, while helpful and a start, will not keep the kids at school from
hacking the system. Possible ways in:

Choose Run from the file command, type edit or notepad and enter. They can
then edit the progman.ini to their heart's content.

You're probably using DOS 6 or higher; they can reboot, hit the F8 key and
step through config.sys and autoexec.bat once layer at a time, and stop
just before entry into windows.

THEY can bring a bootable disk from home and hack away.

My point here is that ANY system is breakable, but Windows has very little
in the way of security. Use it, but don't rely on it. In fact, as a
failsafe I typically place an image of the completed workstation on the
server; in the event of real problems it's pretty easy to copy destroy any
potential viruses, reformat local drives and reload EVERYTHING in a very
short time.

------------------------------

Date: Mon, 18 Dec 95 08:43:25 +0000
From: "Mervin Pearce" <pearcem@orion.sbic.co.za>
To: netw4-l@bgu.edu
Subject: Re: Burglar brings EVERYONE back to Life???

Most of the Network Operating Systems have 'security holes' (please read
the quotes).  It is up to the custodian of the Network to ensure that the
proper controls are placed.  For BURGLAR you have to ensure that the
console is physically secure as to minimise the risk of the NLM load at
console.  Additionally you may type at the console (or as part of the
AUTOEXEC.NCF or STARTUP.NCF) the following commands:

REMOVE DOS: This removes access from drive A: or B: on the server
	    No NLMs can be loaded from those devices

SECURE CONSOLE: This will ensure that NLMS can only be loaded from
		SERVER:/SYS


It can be secured properly...you just have to implement the proper
controls.

------------------------------

Date: Sun, 17 Dec 1995 23:33:35 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: Burglar brings EVERYONE back to Life???


>REMOVE DOS:	This removes access from drive A: or B: on the server
>		No NLMs can be loaded from those devices
>
>SECURE CONSOLE: This will ensure that NLMS can only be loaded from
>		 SERVER:/SYS
>
>It can be secured properly... You must just implement the proper
>controls.

It wasn't clear from your post, but the second command also effectively
performs the first. It also effectively prevents the use of a number of
server based products unless all the required NLMS are copied to the SYS
directory. Ultimately the choice between higher security and functionality
may have to be made, but it should be mentioned that someone who can access
the console or rconsole passwords may be able to get sufficient access to
copy burglar to the system directory, and then run it from there. Plug that
hole, too. BTW, the correct path above is:

	SERVER/SYS:SYSTEM

------------------------------

Date: Mon, 18 Dec 95 18:36 MET
From: arthur-b@ZeelandNet.nl (Arthur B.)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

>1. Depending on the system configuration, booting and running from the
>server can overload the server. This problem is workable, but the entire
>system configuration needs to be considered. Don't forget that while
>Windows CAN be run from the network it was not originally designed for it;
>the result is some VERY heavy server loads.

Is VERY true, but easy to install, easy to maintain, easier to secure.
IMHO, if you don't have the knowledge and security is your main issue I
would go for this one and worry about the 'fine-tuning' later.
And you can allways redirect the temporary files and the permanent swapfile
to the local harddisk (it helps some).

>2. Unfortunately the suggested INI file alterations will not keep any but
>the novices from messing with the system. Windows doesn't have anything
>resembling security, hence the proliferation of third party solutions. I've
>seen a number over the years, but none come to mind at the moment.

Those INI statements are more for making the managers stop worry about the
security-holes. It is not a problem for the novice hacker.

>3. Much as I hate to admit it, RPL boot proms may be the way to go. The you
>can lock down the system until a gnat can't get through. If your clients
>don't need them you can disable the floppy drives, but of course that
>depends on what the PCs are for. If they're needed, you can at least
>implement a secure virus policy and limit infections to nearly none.

IMHO it's the best way to go if you lack the knowledge to do otherwise.
And if security is your main issue I would *really* disable the floppy
drives, set CMOS passwords (you can use that to unlock the diskdrives if
needed) and disable the COM and LPT ports as well.
And make sure that exiting to DOS or executing a DOS programm is not
possible (even not in the application).
Also check if you can lock the CPU-cabinet (is this good English?).

>4. Follow the earlier advice regarding security education. Even if you have
>someone else do the work, you need to know enough to know they know what
>they're doing!

Yep!

>Not hiring an administrator for 90 workstations? Let me guess, either the
>advice was that you wouldn't need one or someone decided to save some money
>and YOU could do the work (along with your current job, of course). Gee,
>I'm not cynical, really I'm not. It's just the usual reason.

You've been there too?
And here I was thinking I was all alone... :)

------------------------------

Date: Mon, 18 Dec 1995 15:25:20 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: Audit and Control

>I am an Information Systems (IS) Auditor.  IS Auditors come and bother system
>administrators periodically to look at things like security and back-ups of
>the LANs and WANs you folks administer.  I have looked at a number 3.X LANs
>but have never audited a 4.x LAN.  (Though I've read about 4.x Security
>features).  I'd like any perspectives any of you might have about 4.x
>security when you are running Bindery emulation mode.  I'd also welcome any
>security and control perspectives from "your" (the System Admin) angle.

I'm not Systems Admin, but rather a Systems Engineer. 4.x has some
interesting things, but the biggest misunderstanding is that Bindery
emulation does much. ALL it does is advertise that a particular server is
"in" a container when accessing those objects in bindery mode, so they see
themselves associated with a particular server/volumes. From what I've seen
all the security features are intact, and cannot be circumvented with
bindery context enabled.

One of the best features is the ability to place the Rconsole load line and
password in a separate file - it's no longer possible to simply read the
autoexec.ncf file to obtain console access. Of course that's part of the
inetcfg utility, which makes administering network configruation much
easier, but the security improvement is an added bonus. The audit feature
is nice, too. There's more there than I could have ever guessed; I don't
use it, but then I haven't had to clamp security down that much yet. It's
possible to audit just about anything; audit config events, DS events, file
access, printing, etc. I could see a lot of potential uses for it beyond
just security auditing, but haven't had the time to explore.

What type of auditing do you do regarding backups? I've spent years trying
to educate users on backup proceedures, but the more automated things
become the less they seem to want to do manual verification on backups -
looking at reports, test restores, etc. Is there any uniform proceedure we
can point sysadmins at to emphasize the importance of auditing backup
proceedures?

------------------------------

Date: Mon, 18 Dec 1995 15:36:11 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

>>Not hiring an administrator for 90 workstations? Let me guess, either the
>>advice was that you wouldn't need one or someone decided to save some money
>>and YOU could do the work (along with your current job, of course). Gee,
>>I'm not cynical, really I'm not. It's just the usual reason.
>You've been there too?
>And here I was thinking I was all alone... :)

Yup! I've had so many clients do this it's kind of a joke - I finally the
credentals to take sales people to ask for giving away support under these
conditions.

>>1. Depending on the system configuration, booting and running from the
>>server can overload the server. This problem is workable, but the entire
>>system configuration needs to be considered. Don't forget that while
>>Windows CAN be run from the network it was not originally designed for it;
>>the result is some VERY heavy server loads.
>Is VERY true, but easy to install, easy to maintain, easier to secure.
>IMHO, if you don't have the knowledge and security is your main issue I
>would go for this one and worry about the 'fine-tuning' later.
>And you can allways redirect the temporary files and the permanent swapfile
>to the local harddisk (it helps some).

Agreed as to moving temp and swap files, but the maintenance simply becomes
delayed. I have a client as an excellent example - shared windows, it's
been that way for some time and so many problems they HAVE to reinstall -
but doing that in a planned fashion isn't easy. There's too many users to
do it all in a single weekend with available manpower, and still make sure
they retain full functionality. Installing locally at least compartmentizes
the problems, instead of bringing their entire operation down.

>>3. Much as I hate to admit it, RPL boot proms may be the way to go. The you
>>can lock down the system until a gnat can't get through. If your clients
>>don't need them you can disable the floppy drives, but of course that
>>depends on what the PCs are for. If they're needed, you can at least
>>implement a secure virus policy and limit infections to nearly none.
>IMHO it's the best way to go if you lack the knowledge to do otherwise.
>And if security is your main issue I would *really* disable the floppy
>drives, set CMOS passwords (you can use that to unlock the diskdrives if
>needed) and disable the COM and LPT ports as well.
>And make sure that exiting to DOS or executing a DOS programm is not
>possible (even not in the application).
>Also check if you can lock the CPU-cabinet (is this good English?).

Locking the server's a great idea. Should have suggested it myself.
However, some of your other suggestions may not be usable depending on the
environment. Don't forget the network is there to service customers, and if
they must bring work in from the outside then they have to have floppies;
but you're right that an unsupported novice admin doesn't have the knowlege
to do ANY of this by themselves. OTOH, if they can disable floppies it's an
easy way to achieve some control.

------------------------------

Date: Tue, 19 Dec 1995 12:00:10 -0500
From: pinc0059@centuryinter.net (Shawn Dunn)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

Randy

RPL boot proms are not they way to go especially for institututions like
libraries and schools that do not funds available like businesses.

The changes I suggested to the PROGMAN.INI works.  I have this on 90
computers throughout the Sparta school district and no kids have broken
through.  By taking away the main group you remove file manager, so kids
cannot go to file manager to run a program.  Also the RESTRICTION section of
PROGMAN.INI file will keep people from going FILE, RUN and then running an
application.  Try this, you will see there is no FILE in the Program
manager.  Also by removing the acessories group you can keep kids or users
from getting to NOTEPAD and editing the config.sys, autoexec.bat, win.ini or
the

True kids can F8 at the start to step through the config.sys or
autoexec.bat.  They can even F5 and bypass the config.sys and autoexec.bat
files.  But I have added a line in the config.sys "SWITCHES=/F/N".  This
keeps the F5 key or the F8 from bypassing the config.sys.  But I realize an
expert like yourself would have known about this.

Kids can also bring in bootable diskettes and boot from the A: drive.  But
that is only if you allow the computer to boot from the a: drive.  The PS/2s
and the 486 machines that I work on allow the CMOS or the configuration to
be changed so that the computer will first boot from c: and the a: or only
boot from c: or only from a:.  There is nothing to prevent the kids from
trying to change the configuration of the computer but they are enough
defenses to slow them.

As far as being a knowledgeable expert, I have 10 years of PC experience, 5
years of network experience.  I have built computers and networks from
scratch.  Currently I am managing 9 school networks along with a RS/6000
network. If I am not a system administrator then I do not know what one is.
I am doing this on very limited monies and a lot of frustrations.  If you
would like to volunteer your time, I can always use a helping hand.

Before you condemn any idea first, try it and see if it works.  I have
worked with to many knowegeable experts that get stuck in a rut and want
spend, spend, spend.
Sometimes you have to work with what you and sometimes you have to listen.

------------------------------

Date: Tue, 19 Dec 1995 11:43:50 -0800
From: rgrein@halcyon.com (Randy Grein)
To: netw4-l@bgu.edu
Subject: Re: pc security through Novell 4.1

Shawn

There's ways around your recommendations, but disabling the floppies and
password protecting CMOS will satisfy most requirements provided floppy
access is not required. Not all clones have this capability, but it is
getting more common. If floppy access is required, your suggestion simply
won't work and neither will boot proms. Still, I'd never trust kids to not
break into something, and never use restricted access for more than a front
line defense against viruses.

>As far as being a knowledgeable expert, I have 10 years of PC experience, 5
>years of network experience.  I have built computers and networks from
>scratch.  Currently I am managing 9 school networks along with a RS/6000
>network. If I am not a system administrator then I do not know what one is.
>I am doing this on very limited monies and a lot of frustrations.  If you
>would like to volunteer your time, I can always use a helping hand.

Sorry, but I make my living as a systems engineer, and doubt the boss would
let me take time off to fly in and help!

>Before you condemn any idea first, try it and see if it works.  I have
>worked with to many knowegeable experts that get stuck in a rut and want
>spend, spend, spend.
>Sometimes you have to work with what you and sometimes you have to listen.

>Shawn
>
>P.S.  I apoligize for being on soapbox but I was trying to offer an
>inexpensive solution that can be proven to work.


No sweat, Shawn! I do disagree with your solution as a total package, but
it is a good start. You might go back and read my posts, however. the Boot
Prom was not my preferred solution; in general I prefer an active defense
against viruses and other attacks. As far as "spend, spend, spend" I'll
assume that the intended tone didn't translate. I have seen the type of
problem solvers you're referring to; right now ATT and Novell are trying to
sell people on outsourced network management via ATT NetWare connect
services. Not a bad solution if you've got big bucks, but not for most
networks until the price comes WAY down. However, don't forget that there
are many more end users out there that cry for cheap, easy and free
solutions to complex problems. If the solution exists and works great, but
that's usually not the case. The trick is balancing the cost with
functionality.

------------------------------

Date: Thu, 28 Dec 1995 12:05:46 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Security Issue.

>I have had a number of problems with PC security here at Grand Rapids
>Public Library.  It appears that a member of our staff on 2nd or 3rd
>shift has been attempting to gain access to our PCs that are logged into
>the network.  Why are they logged into the network at night when most of
>us are gone?  Valid question, some of us do batch electronic execution at
>night.  Also, my stations/PC needs to be attached to the file server in
>order to do remote daily backups.  I currently have Windows for
>Workgroups and Norton Utilities installed in place of the program
>manager.  I am using the screen saver within Windows for Workgroups to
>require a password before allowing the user to gain access to WFW and
>thus the network.  I am also locking my PC at night which has seemed to
>help, they have not gained access to date.  However, this is a very
>serious issue since my workstation is logged in as Supervisor in order to
>do the required daily backups.  My question is, is there a software
>package that will run under WFW which will tell us when an unauthorized
>break-in was attempted? <snip>
----------
	You should talk to Microsoft about WFW. They will tell you PC clients
have no security whatsoever, and they would be correct. So don't do priv'd
things as you are. Instead acquire a server based backup program and let
it do the work with its own scheduler running in the server. I use Arcada's
BackupExec and it does this job just fine.
	Secondly, any time physical access is granted to the server (yes, I
know you were discussing clients) then your server can be subverted by many
means (few leave traces); it's not a NW security problem but rather a physical
attack. Lockup your server. Don't expose passwords for server operations.
	Joe D.

---------

Date: Thu, 28 Dec 1995 15:21:12 EST
From: Vic Drecchio <73041.1314@COMPUSERVE.COM>
Subject: Re: Security Issue.

To answer your question in one word, NO.

However, it seems like you are taking good measures to lock up
your PC.  Use the keyboard lock, CMOS password, Screen Saver
password.  Afterdark for Windows has good screen savers and
password protections for the network.  If someone tries to
reboot Windows while the screen saver is active, the next time
Windows is executed, the user cannot login w/o providing the
correct password.  The best and almost-fullproof security
protection is --as someone else said, too-- to LOCK UP YOUR
SYSTEM in an office.  But, if that is not possible, doing the
things I mentioned above will help out very much.

---------

Date: Thu, 28 Dec 1995 22:02:04 GMT+0001
From: "Szekeres Bela, Jr." <SZEKERESSU@EVT.BME.HU>
Subject: Locking up a PC with Windows screen saver

There were articles about securing a PC with screen saver passwords.

This is a good step, but keep in mind, once somebody can get access
to the control.ini file on your PC, he/she can easily decrypt your
password (less than 200 lines in C). In the night, he can disassemble
your PC and remove any power-on password. DO NOT USE THE SAME PASSWORD
for Netware. Windows does not use a one-way encryption as one could
expect.

Also, if you do not want to backup the bindery, log in as a user, who
has S rights in the root dir of every volume, but who is not
Supervisor equivalent.

Szekeres Bela, Jr.

------------------------------

Date: Sun, 31 Dec 1995 06:53:03 GMT
From: Ed Kwasniewski <ylwm0106@CYBERSTORE.CA>
Subject: How to disable DOS shells?

Thanks people . . . your ideas (here and in EMail) were
right on and I've been able to use them to shut down
the DOS shells in both programs.

The programs needed slightly different approaches, but
both use the COMSPEC environment variable.  For those
interested:

- Turbo PASCAL's shell shuts down very nicely if
  COMSPEC is removed.  In the applications menu I've
  entered:

    @echo off
    set tempspec=%comspec%
    set comspec=
    turbo
    set comspec=%tempspec%
    set tempspec=

  Thanks to James Berry for this nice piece of
  re-direction!

- Microsoft Works needed a bit more slight of hand
  (and ideas from a few people) to do the same
  thing:

  First, in the applications menu I've entered:

    c:\dos\command /e:1024 /c works.bat

  WORKS.BAT is a small file in the WORKS
  subdirectory that looks like:

    @echo off
    set comspec=c:\works\dummy.exe
    works

  And finally DUMMY.EXE is a small compiled TP file
  that does nothing but clear the screen.

This of course won't stop anyone who 'really' wants to
get into DOS but it should be adequate for now.  Again,
thanks everyone!!

------------------------------

Date: Mon, 1 Jan 1996 23:20:00 MET
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Admin/Supervisor

>The netware 4.10 manual advises that one gives the administration
>privileges to a supervisory account and restrict the default admin
>account.

And a panic-account I hope -- an account at root-level in the NDS-tree
which has the same rights to the root-object (not the volumes) as admin
has (but is *NOT* security-equivalent to admin)

Novell probably means that you shouldn't use admin for your daily
maintaining. They suggest to use another account for that and use
admin as little as possible.

And 'administration' is/are the people who maintain the entire network.
Like: network-administrator.

>Can someone tell me what would be involved to give this access to a
>different account.  I'm very concerned about restricting the admin
>account before I'm sure that the access has been properly transferred.
>I'd hate to be locked out of certain privileges that I never knew
>existed.

Sorry, but are you a network-administrator or the boss of one?

Copy user admin to the root object. Give it another name.
You're not restricted then but copied.

Make sure the new user account has Supervisory rights on the root-object.
If you have Supervisory rights on the root-object you have all the rights.

Also, make sure only the people that really know what there doing have
all the rights. Managers and so on should have *at most* Read Scan rights
in the NDS-objects at root level.
Reason for this is simple. Only people how really know what they are doing
should have modification rights in crucial parts of the network.
People who are the bosses of those people may look but not touch. OK?

Is somewhat like a bodyguard that has to protect Mister X. For that reason
he gets a gun from Mister X, but Mister X thinks it's smart to keep the
bullets himself, because *he* feels safer that way. Of course, Mister X
is now buried and the bodyguard too perhaps.

------------------------------

Date: Mon, 1 Jan 96 17:33 MET
From: arthur-b@ZeelandNet.nl (Arthur B.)
To: netw4-l@bgu.edu
Subject: Re: Re [??]: pc security - Passwords

>>And I changed the password for supervisor.
>
>Reminds me of my 3.12 Admin course. The instructor said, "Change and write
>down the supervisor password twice and stick each in an envelope. Place one
>in an inconspicuous place, and take the other home.  Then, under no
>conditions should you reveal the password."

I wouldn't write down the password anywhere.
This way you don't risk getting it stolen or whatever.
Besides, there are enough ways to break in and gain supervisor access if
the password is forgotten.

And about the 'reveal' part.
The guy didn't reveal it. He typed it in as he should have done.
What he didn't check for was the present of a small TSR that copied
every typed-in character to RAM. After he left the user only needed to
'read' a certain part of the RAM.
I know there is a security patch for this (hooks up some IRQ's)
but it didn't work for this little TSR.

>My supervisor balked at that one.  I guess he was afraid *I'd* be the one
>to become disgruntled and thrash the password...  Both he, and I have a
>copy of it in our desks...

An issue of trust?

And about your supervisor, as long as he has access to the fileserver he
can always get in and get supervisor control back. So why worry?

And about the deskcopy, put them at home.
If you ever need it I'm sure the boss will allow you to drive home and
get it.

About password security:
 1. The password should be at least 6 characters
 2. The characters should be at two sides of the keyboard in such a way
    that you can type the password without moving your hands (only the
    fingers).
 3. Some of the characters typed in should be under the hand.
    (eg. typing a 'w' and then a 'd', 's' or 'f').
    Try seeing that happen with your eyes.
 4. The characters should be typed in from one side of the keyboard to
    the other side, but not allways.
    (eg. 'wdlaoa') left-left-right-left-right-left
 5. The password shouldn't be a speakable word.
    This way, if someone is watching your fingers the chances are they
    will convert what they saw into something they can say
    (it's the way the brain works)
 6. Practise the password. Make sure you can type it in less then 3 seconds.
 7. Make sure that the password is typeable on every keyboard layout that
    you come across. So no special characters that require such a handling
    on this keyboard and another handling on another keyboard. This way
    your typing is always up to speed, even with a strange keyboard.
 8. Make the password a part of you, but for 1 month only, then change it.
 9. Make several accounts. A daily account with low rights, a troubleshoot
    ing account with a few more rights and the supervisor account.
    All should have different passwords of course.
10. Bend towards the screen while typing in the password.
    Put your elbows out.

Bringing this into practice makes it possible to be videotaped from two
sides and still have a secret password. Personal experience!

And don't forget to check for Intruders daily.

All in all I have about 5 or 6 passwords that will give you complete
access to the entire network (console keyboard password, CMOS fileserver
password, CMOS supervisor station password, supervisor password,
admin password, NLM applications password, CMOS workstations password,
pserver password, panic account password [=reserved for admin])

True, there should be 9 different passwords and I only change some of
them each month. But then again I like to live a life :)

------------------------------

Date: Thu, 4 Jan 1996 19:45:32 GMT+0001
From: "Szekeres Bela, Jr." <SZEKERES@EVT.BME.HU>
Subject: Re: Directory Entries

>I have been scanning my disks with VOLINFO and note that several disks with
>about equal numbers of files (arround 10K) have vastly different numbers of
>directory entries ranging from under 20K to over 80K.  What causes that?  Does
>the larger number of entries slow down use? slow down mounting? If so, how can
>I reduce the number of entries.

Directory entries are being created 'as it seems appropriate'. They
are never deleted. They are being allocated on a page basis
(4kB=16 entry), one page is for one directory a minimum, but obviously
can be more. This means, that if you have more directories on one
volume, and less on a different one, you will not have the same
number of dir entries. As I mentioned, they are NEVER deleted. If you
had many dirs or files, they will be there waiting to be reused.
(Deleted files take a dir entry if they can be recovered.)

Some experience shows (this may not be totally correct), that dir
entries are being created on the server, if it thinks you may run out
of them shortly. So, if you create a lot of dirs in a short time (by
a program), it may think the avail entries will be enough for a few
seconds only, and will create more. Create 1000 dirs in 5 seconds, and
it may allocate 2 or 3 times more, than necessary.

A funny boy played with such a program on our server and we had 60MB
allocated for dir entries. These could be recovered with the
well-known backup-reinstall-restore  sequence. Note: dirs do not
take any space from the quota, if he has C right somewhere (in the
MAIL dir, for example), he can play this game.

You can limit the percentage they can take up on a volume, (Set
Maximum Percent of Volume Used by Directory), but be aware:
Netware 3.11 (and maybe others) have a patch, which makes the things
work as they should. Otherwise, you can have twice the limit
allocated for Dirs (they forget the second copy of the dirs).
By default, this setting is around 13 percent, which is probably
more, than necessary. If you decide to change this setting, you may
also want to change the Maximum Pecent of Space Allowed for Extended
Attributes. Nobody played with this so far, but we can never know.

------------------------------

Date: Fri, 12 Jan 1996 18:26:08 GMT
From: Teo Kirkinen <kirkinen@CC.HELSINKI.FI>
Subject: Re: monitor password (reply)

>>Is it true that if you use the admin's password on the monitor screen
>>that you will be locked out of the server.  If so what should you do.
>
>The answer is 'maybe'.
>This will happen only if the supervisor's account gets locked somehow.
>Such as when someone tries to login to supervisor and uses the
>wrong password and Intruder Detection is turned on.  That can lock
>the supervisor account. If that happens, it happens at the console
>monitor password as well.

Yes, but intruder detection lockout for SUPERVISOR can be easily
cleared by ENABLE LOGIN on the server console.

Because the Elberd wrote about admin instead of supervisor, I would
guess that he is running Netware 4. There the problem may be that
admin's original password (from the time the server is installed)
is used as the password of the bindery-emulated supervisor. After
the installation it is not syncronized with admin's password. So
if admin's password is changed, the new one will not unlock monitor.
But the original still will.

------------------------------

Date: Mon, 22 Jan 96 00:21 MET
From: arthur-b@ZeelandNet.nl (Arthur B.)
To: netw4-l@bgu.edu
Subject: Re: Looking for ideas?

<snip>
>>Well, how about routerconfiguration?
>>Connecting to UNIX, VAX/VMS, other mainframes?
>>Software issues like Post/Mail system, Network Management, etc.?
>>Remote login security, installation and configuration?
>>How to hack a Netware network?
>>Make a rescueplan (rescuediskette's, backup and *restore*)
>>How to test a network?
>>Virusprotection?
>>You know, everything!
>
>Now you're talking my language, Arthur! I especially like the security and
>rescue plan ideas - security is becoming a real issue for me. Thanks for
>the tips; I'll see what I can do. If you have any more ideas, shooth them
>over!
>
Security? Rescue?
 1. Making rescue diskettes
    a. for the fileserver
    b. for user workstations
    c. for supervisor/operator workstations
    d. for hardware without floppy-discs (routers, modems, etc.)
    e. what files to put on
    f. restoring your backup-programm
    g. rescue tools and how to use them
    h. emergency checklist (what to do next)
 2. Backup and restore
    a. what should the backup programm do (checklist)
    b. how to protect your backups from
       1. disasters
       2. theft
       3. reading the medium by unwanted persons
 3. Configuration
    a. Protecting the configuration (-files)
       1. DOS environments
       2. Windows environments
       3. Netware enivronments
       4. UNIX environments
       5. VAX/VMS environments
       6. AS/400 environments
       7. others (routers, printers, modems)
    b. Checklist for 'hardcopies to make'
 4. Hacking/Break-ins/Inside jobs
    a. Preventing access to hardware
       1. fileservers
       2. distribution of keys
       3. how to deal with (remote) support companies
       4. password protocol
    b. People
       1. dividing workload, responsebility and security among people
       2. how to prevent people selling data to the competition
	  i.  encryption/decryption
	  ii. benefits of creating wrong data
	  iii.deviding the work amongst several departments
	  iv. riscs (supervisors, managers, temporary workers)
    c. Hacking
       1. testing security
       2. potential hazards
	  i.  hardware (modems, ISDN, connections to other networks)
	  ii. sofware (deamon dialers, trojans, hacktools)
	  iii.people (supervisors, supportcompanies, organized crime)
       3. monitoring

Anyway, this list could go on and on and is far from complete.
And still we are only looking at one or two subjects of the
"Bible for system administrators - Netware edition"-book which
still isn't on the market. But then it would be a very big book.
If only my manager would know of the things a modern system
administrator needs to know of...

If you need more info/detail or views on other subjects you know
how to find me.

------------------------------

Date: Wed, 24 Jan 1996 20:00:34 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: public login dilemma in University lab!

>We are public university operating a 3.12 lab.  Also, we have Banyan ENS
>running over Netware to provide simultaneous login across all servers.
>Currently, we are using a public login.  Since we have several thousand
>users coming through the lab each semester, we'd prefer not to have to deal
>with the creation and admin of thousands of user accounts.  But, security
>requires that we track individual usage.
>
>Is there a way of holding individual users accountable for actions, short of
>creating several thousand new user accounts?  Perhaps a batch file launched
>from public user login script that queries the user for identification
>(although name and SS# are not secure enough) and compares it to a database
>of enrolled students...if no match, login fails...if match, record user info
>and station to a log?  Of course, this would be a rather crude method.  I'm
>hoping there are other university administrators who have dealt with similar
>issues that can suggest a better solution.  If not, is there a down and
>dirty way of creating batch accounts for enrolled students (rather than
>doing it by hand, one at a time)?
--------
	As I reread your message above I was left in progressively greater
doubt about what you want to track and why.
	Let's take a situation similar to mine: all students are NetWare
user GUEST with no password. They have access to provided programs but
no server storage capabilities. How is that different from your situation?
Well, you want individual logins, but beyond that what? Local storage?
And what of local storage and "accountability?" (No telling how stuff
got there, if pressed in a court of law).
	My situation permits no Email sent from public PCs. Email goes
out from the main campus DEC Alpha cluster where individual logins are
enforced. That, however, does not stop the occassional complete fabrication
of email.
	My next question is what might people mean by "security?" Very
slippery term, that. If you mean tracing back whom did what then I'd
say forget it since lan servers don't normally bother with that detail
and disk drives fill in mere days from really intrusive tracking. Could
you mean stealing copyrighted software? If so there are ways under NW
to reduce such cases (the Execute-Only X flag on selected files).
	There is perhaps another meaning you intend: distinguishing legit
students from interlopers. In campus facilities we require presentation
of a valid Univ picture id and we swipe the card in a reader upon entry
to computing facilities. Works well, cheap too. Reader talks to an Alpha
which holds the list of who is who and reports back to the reader as OK
or not within a second of the swipe.
	What's my user population? Campus has 20K, my part of it has 4K
plus all the folks from anywhere choosing to visit my area. In going on
8 years of public computer lab experience with NetWare I've hardly had a
problem with security as mentioned above.
	Joe D.

------------------------------

Date: Thu, 25 Jan 1996 10:14:56 MET-0100
From: Ole "Maestro" Aasmoe <oga@MEDFYSIK.AAU.DK>
Subject: (Fwd) Re:  tracking login attempts

>We've had a rash of "Station <connection number> attempted to use an
>unencrypted password call" messages occurring on our campus fileservers.
>I'd like to find out what/where the source is. Is there any utility that
>will log net and node numbers for attachment/login request?

Take a look at JRB utilities. There's a program to log all attempted
logins with MAC adresses etc. You'll find the utilities on Netwire.

------------------------------

Date: Fri, 2 Feb 1996 19:36:05 GMT
From: Eric Rossing <erossing@SIRUS.COM>
Subject: Re: Mission Critical Application & Fault Tolerance

>WRONG! If you use the built in security features of Access correctly you
>can protect everything from unauthorized meddling/snooping. To do this
>you need to create a new System.MDA file create an empty database, then
>import your existing database, set up your own admin account and set the
>security features you want on each object (the books give more detail).
>If done right its pretty good.

Not exactly...

The CopyObject security hole allows any user(no matter how
underpriveledged) that can access the database to get to your code.
The code is NOT protected against a determined attack(which would
probably take all of 10-15 minutes by a knowledgable Access hacker).

------------------------------

Date: Thu, 8 Feb 1996 21:51:37 -0500
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Supervisor can't login on 4.1 server

>We are having a problem unlocking the system console
>in Monitor.nlm after a 4.1 server re-install. The supervisor
>cannot login using bindery emulation and the server returns
>error 893b with either attach or login.

Are you sure that you have the correct SUPERVISOR password? It's the same
as the ADMIN password that was defined in the installation. If you change
ADMIN's password afterwards, the SUPERVISOR password will *not* change as
well, but will remain the original...(a good reason to document this
somewhere during the install!)

------------------------------

Date: Thu, 15 Feb 1996 11:21:03 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: NetWare security discussion

	Ok, let's see if we can be constructive and informative, without
teaching the wacko's anything at all.
	I divide the problem into
	a) breaking in across the wire
	b) breaking in from the console, stealing disk drives, etc
	c) fooling system managers into using compromised clients

	Breaking in across the wire is dealt with by two mechanisms today.
For NW 3.11 only, load the SEC*.EXE patches now many years old. NW 3.12 and
NW 4 include this material interally. Then turn on packet signing, on both
server and client; that's denoted by a "security level" like this for NW 3.12:

file server name EDU-USU-NETLAB2
ipx internal net 817b012c
set allow unencrypted passwords=on
set reply to get nearest server=on
set maximum directory cache buffers=270
set minimum directory cache buffers=250
set maximum outstanding NCP searches=1000
set maximum packet receive buffers=250
set timezone=MST7MDT
load clib /L1 tz=MST7MDT /pb
	  ^^^-------------------- the packet signing security level

And on the client side (VLM material):
Netware dos requester
	PB buffers=1
	PBurst read window 6
	PBurst write window 6
	checksum=on             ; speedup high quality links
	true commit=off         ; off=let server buffer writes
	lip start size= 1500    ; long packets across routers
	bind reconnect=on
	network printers=1      ; shrinks print.vlm, won't load it
	average name length=24  ; shrinks connection table
	load low conn=ON
	load low ipxncp=ON
	load low fifo=on        ; part of fifo.vlm, speeds accesses
	load low netx=on        ; part of netx.vlm, speeds accesses
	load low redir=on       ; part of redir.vlm, speeds accesses
	read only compatibility=on
	first network drive=n
	signature level=0       ; 0=don't load security.vlm
	^^^^^^^^^^^^^^^^^--------------- packet signing security level

	Now, on part b), the usual rule applies that physical access
means pretty much all access, so lockup the server. While locking, ensure
the rconsole password is not seen by humans; it's in autoexec.ncf. Ditto
for the SNMP passwords. Do lock the console keyboard. Disconnect the
floppy drive in the server.
	There is a trojan horse attack possible here, and folks need to
be aware of it. Never load an NLM whose parentage is in doubt. That means
never accept kind offers of helpful NLMs sent via the mail or obtained from
sites not legally bound to Novell. The official mirror sites are so bound.
Ftp.novell.com & related minions, Novell controlled parts of Compuserve,
and the official mirrors are safe sites; others are not.
	On part c) By now most system managers know that priv'd access
should occur from clean clients. Basically, never execute from any user
floppy until it's been thoroughly screened for viruses, and you have a
look at your machine for trouble afterward. Logging in all day as supervisor
is not a swift idea, and I almost never employ username supervisor. Peer
to peer networking is an excellent way of contracting many network ills,
so don't let that happen to your management PC.
	That's my opening bid to the constructive part of the discussion.
There's more that can be done within the server to keep perfectly respectable
users from seeing what they ought not, and I place that topic under the
heading of normal server management rather than security. Rights management
under NDS is something requiring careful study, however.
	Joe D.

------------------------------

Date: Thu, 15 Feb 1996 20:07:24 UT
From: Dave Kearns <DKearns@MSN.COM>
Subject: Re: NetWare security discussion

>	Ok, let's see if we can be constructive and informative, without
>teaching the wacko's anything at all.
>	I divide the problem into
>	 a) breaking in across the wire
>	 b) breaking in from the console, stealing disk drives, etc
>	 c) fooling system managers into using compromised clients
>
<SNIP>
>	That's my opening bid to the constructive part of the discussion.
>There's more that can be done within the server to keep perfectly respectable
>users from seeing what they ought not, and I place that topic under the
>heading of normal server management rather than security. Rights management
>under NDS is something requiring careful study, however.
>	Joe D.

Other considerations should be:

Do not grant rights to any user for SYS:SYSTEM.

Directories containing executable files should be flagged R F

Executable files (including .DLL, .DRV and other Windows files) should be
flagged RO

Users should have R, M and E rights only in their personal directories.

------------------------------

Date: Thu, 15 Feb 1996 17:11:56 -0600
From: Todd W Herring <THERRING@SPEANET.IUPUI.EDU>
Subject: NetWare security discussion -Reply

Under part A I'd add:  Keep wiring closets physically secure to prevent
hackers with laptops from doing any damage, and to prevent someone
from literally cutting connectivity.  If you have the resources, run SNMP
software on intelligent hubs to monitor activity -- it could reveal if
someone is up to something.

For part B:  Use SECURE CONSOLE and move any NLMs you really need
to SYS:SYSTEM.  That's an obvious one, though.

For part C:  Virus check *everything* before you put it on the system, no
matter where it came from.

Part D (Common sense lessons for users):  Warn all users to *never*
give their passwords to anyone, even you or your staff.  Warn them to
never write down their password on paper and keep it near their desk.
Also, stay away from third party software which can display a user's
current password -- why would ever need to know that?!  Just give
them a new one if they forget it!

------------------------------

Date: Thu, 15 Feb 1996 17:33:38 -0500
From: Al Payne <apayne@PLEIADES.COM>
Subject: Netware Security discussion

>...turn on packet signing, on both server and client; that's denoted by a
>"security level" like this for NW 3.12:
>
>load clib /L1 tz=MST7MDT /pb
>	   ^^^-------------------- the packet signing security level

This can alternately be set with
set NCP Packet Signature Level Option = 2

>And on the client side (VLM material):
>Netware dos requester
>	 signature level=0       ; 0=don't load security.vlm
>	 ^^^^^^^^^^^^^^^^^---------- packet signing security level

This would need to be set to a minimum of 1, I prefer to set both the
servers and the workstations to use level 2 instead of relying on the other
end to initiate the signing.

------------------------------

Date: Thu, 15 Feb 1996 22:34:03 -0500
From: Joe Thompson <JST604@aol.com>
To: netw4-l@bgu.edu
Subject: Re: FireWall Software

>The BEST firewall I've ever heard of is to run IPX only on your servers,
>and IPX and IP on the clients that need internet access, then disable
>drive and print sharing on your win95 and WFW clients. Firewalling that
>can't be cracked, although it's not appropriate if you're using most
>flavors of unix.

That is a good solution, but...what if you have 1000+ users and, like most
large nets, have UNIX boxes for SQL and large legacy apps?  And of course
your bosses demand that the Novell server run FTPSERV so that the UNIX
programmers can get to data entered from the users?

Here's a little twist (well not so little but the same theory of using
protocol blocking) that we hashed out.

Have one router from the internal corporate network to a "bastion" or buffer
network, then have another router from the bastion network to the Internet.
On the first router route IPX only on the second router route IP only.

You can then place a CUBIX or other PCs in the bastion network running
REACHOUT/PC ANYWHERE/CARBON COPY etc in host only mode and connceting via
IPX.  Remove the client side of the software from these remote control
boxes.  You can load TCP/IP on them so that your people can download,
surf etc.

Use the routers to filter SAPS from the bastion net.
You can then  place web servers, FTP servers, email gateways etc on this
bastion net.

This way you have a smaller net to monitor.

NOTE: As with any outside access, careful planning and testing should be
employed to insure security and functionality.

One last thing, don't fool yourself into thinking you have an "uncrackable"
solution.  Most Websurfers download files, especially zipped EXE's.  Think
a little bit and it will come to you.  Hackers feed off of ignorant users
and it's not that hard to write a one liner append to an autoexec.bat file.

Oh and remember hackers don't initially look for data, they look for
PASSWORDs.

------------------------------

Date: Fri, 16 Feb 1996 09:30:22 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NetWare security discussion

>>NW 4 include this material interally. Then turn on packet signing, on both
>>server and client; that's denoted by a "security level" like this for NW 3.12:
>
>When I turn on packet signing, I notice a -huge- performance
>degradation, something on the order of a 100% increase in access
>time.  I would like to enhance security, but the cost is too high at
>this point.  Am I implementing it incorrectly, or is that just the
>cost of packet signing?
-------
	Throughput reduction is indeed the cost of packet signing. I don't
recall halving throughput here, but then each system is slightly different.
Some careful organization of who does and does not sign can help lots. Clearly
supervisor and equivalent ought to be signed up to the whazoo if there is
any doubt about bad guys snooping that wire. Clients vote on signing if
the server is set to permit negotiation.
	Joe D.

------------------------------

Date: Fri, 16 Feb 1996 17:40:47 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: NetWare security discussion

Joe Doupnik wrote...
>	Throughput reduction is indeed the cost of packet signing. I don't
>recall halving throughput here, but then each system is slightly different.
>Some careful organization of who does and does not sign can help lots. Clearly
>supervisor and equivalent ought to be signed up to the whazoo if there is
>any doubt about bad guys snooping that wire. Clients vote on signing if
>the server is set to permit negotiation.

I was just going to post something similar....
Here we have one server which has all of the admin utilities on that
Supervisor/Admin is logged in on. it has the level set at 3 --
basically it won't talk to your client unless signing is configured at
level 1-3.

Everyone who logs in as supervisor here should have it set at 3 in
their net.cfg too. The performance hit is marginal (10%) but then we
are talking about SECURITY here. Sure it's faster for me to when I
leave the carpark if I had left my car-doors unlocked, but is this
little delay worth the possible loss?

[for those who don't know Salford is in a city; as we say "If it isn't
bolted down and alarmed then it's been stolen by the time you've read
this notice"]

------------------------------

Date: Fri, 16 Feb 1996 11:29:18 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NetWare Security

>Pursuant to the thread here, and discussions on some of the USENET
>groups, I've disabled FTP service on our NW311 box by the simple
>expedient of renaming ftpserver.nlm. Others have suggested 3rd party
>solutions a la Hellsoft, but what does Hellsoft know that Novell
>doesn't? What is the security issue w/FTPSERVER? What other problems
>do I need to know about TCPIP servers and clients?

	It's not what Hellsoft knows, but rather what you do. The
docs on Novell's FTP server do explain how to setup an environment,
in particular who is blocked from ftp access (sys:etc\ftpusers). It's
expected that system managers become familiar with such guidance and
apply it carefully to their site.
	I run ftpserv.nlm, have done so for many years, and half the free
world has used it while accessing netlab2.usu.edu. Part of the other half
has stuck pins in it trying to circumvent blocks, and have failed so far.
I see lots of probes to my other systems. Anyone offering Internet services
gets similar treatment. Hint: take that Xterminal rconsole facility, if you
have it, and delete file xconsole.nlm; talk about an open invitation.
Hint #2: put passwords on your snmp module, and keep those passwords private.
	See NEWS for security groups. Visit a decent bookstore and acquire
the O'Reilly & Assoc Unix security books (Unix).
	Guiding philosophy: deny everything, only afterward grant access
on a need-to-know basis. NW makes this easy to accomplish.

>On a tangent perhaps, my 2cents w/r to the perils of  informing the
>wackos by open discussion  here, is that it's likely that alt.2600.*
>newsgroups have long ago let the cat out of the bag on most of the
>security issues many admin types are just confronting. I believe that

	Once again. I won't condone educating these candidates. That
means we don't discuss ways and means of subverting here. I have tried
to explain the couple of steps needed to ensure security from exterior
attack, leaving open the vast subject of rational system management
of legit users working with any server. It's fine to list the steps
needed to ensure security, and I've done so. It's not fine to say let's
talk all about tricks A, B, C just because someone else has done so at a
NW users group meeting three months ago in New Guinea. See any CERT
announcement for the same philosophy; there's yet another flap on BIND
4.9.3 going on at this moment.
	If any of the readers have been involved with government security
they may recall the rules which say one may not discuss certain matters
even though partial or full details have been published openly and widely.
To talk implies confirmation, and big trouble for the talker.
	NetWare is rather secure as delivered, and can be tweaked for
greater security by the methods we have discussed this week on the list.
It's not perfect, openings will be found by the people who wish to destroy,
tell Novell privately if you have doubts about something in this area.
	Joe D.

------------------------------

Date: Mon, 4 Mar 1996 15:05:56 -0500
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Help

>We've just had a little problem here on our high school's LAN.  The
>system  has been breached by some unknown students.  This is what we
>found:
>
>Someone was logging on regularly as GUEST.  We assume that they had
>the key sequence to shell out to DOS.  From there the administrative
>ADMIN login's password was erased.  They might have access to higher
>levels of access due some of the teachers at the school.  The students
>then logged in as ADMIN.  There was a secure password on the ADMIN
>login before.  Somehow they erased it totally.  They then went in and
>created a new administrative account for themselves.
>
>How could they have done this?  Is there a command they could've used
>to erase this password?  Is there something else they could've done.
>Somebody please help.  Our records our very vulnerable to these
>intruders until we find out what has happened.

The security you can use will depend on the version of NetWare you're
using. If you're using 3.x, run the SECURITY program and port the results
to a text file so that you can see what problems you might have.

In 4.x, it's more complicated. The easiest way I've found to get info on
paper is to use the NLIST command as follows:

    NLIST ORGANIZATION SHOW ACL /R /S >SYS:SYSTEM\O.TXT
    NLIST "ORGANIZATIONAL UNIT" SHOW ACL /R /S >SYS:SYSTEM\OU.TXT
    NLIST GROUP SHOW ACL /R /S >SYS:SYSTEM\GROUP.TXT
    NLIST "ORGANIZATIONAL ROLE" SHOW ACL /R /S >SYS:SYSTEM\OR.TXT
    NLIST SERVER SHOW ACL /R /S >SYS:SYSTEM\SERVER.TXT

And so on. This will give you a listing (from the [Root] and covering all
sub-contexts) of each Organization object, each OU, etc. For each one it
will list all trustees of that object and the rights they have to the
object. (An example is below)

Contents of O.TXT file:
Current context: [Root]
Organization: INTERMEDIA
	Object Trustees (ACL):
		Subject: INTERMEDIA
		Property: Login Script
		Property Rights: [ R   ]
	Object Trustees (ACL):
		Subject: SubAdmin.INTERMEDIA
		Property:  [Object Rights]
		Entry Rights: [BCDR ]
	Object Trustees (ACL):
		Subject: SubAdmin.INTERMEDIA
		Property:  [All Properties Rights]
		Property Rights: [CR   ]
	Object Trustees (ACL):
		Subject: [Root]
		Property: Printer Control
		Property Rights: [ R   ]

One Organization object was found in this context.

One Organization object was found.
==================================

Do this for all object classes you're concerned with. The only one you'll
have to examine manually is [Root]. Check it out in NWAdmin or NETADMIN and
write down the info.

These should allow you to see where excessive NDS rights have been assigned.

File system rights are another story....

------------------------------

Date: Fri, 8 Mar 1996 09:36:27 WET
From: Dik van Oeveren <oeverend@esd2.esd.nl>
To: netw4-l@bgu.edu
Subject: Re: Admin Login Problem

>The original Admin password is still needed on our 4.1 server to unlock
>the console;  the new Admin password will not unlock the console, even
>though it works to login the Admin.  The server has been down, I've run
>VRepair and DSRepair.  Any ideas (the old Admin password is too obvious,
>and I really don't want it to be used anymore, for anything).
>Tom Milliner, CPA      TomMilliner@Delphi.Com    (214) 438-6932

You can go into the debugger if you have forgotten the console 
password.

This is the sequence (case sensitive !!!!!!!!):

Press: LeftShift-RightShift-Alt-Esc   at the same time

g VerifyPassword <ENTER>
<ENTER>
g [desp]
eax=0
g

This works on Netware 3.x and Netware 4.x servers.

------------------------------

Date: Thu, 14 Mar 1996 22:14:55 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Security: Policy for passwords on new accounts

>Can anyone offer some input on a policy for passwords for a newly created
>user accounts from a security point of view.
>
>Do not want to leave a security loophole by not assigning passwords to new
>accounts.

We create accounts with random (gibberish) passwords that have already
expired, so the user has to change thier password when they login for the
first time. The password is printed on the front of a piece of paper which
has their regulations on it for them to read.

This is done using scripts emitted by a Paradox database which controls
the user-registration process.

------------------------------

From: "Chris Tilbury" <C.J.Tilbury@estate.warwick.ac.uk>
Date: Thu, 21 Mar 1996 13:25:39 GMT
Subject: Re: Setting the path in login scripts

>>>Sometimes when I or my users log in, the DOS path is magically altered to
>>>have z:.;y:.; put on the front of the path.  Sometimes, it doesn't happen.
>>>Can anyone tell me why?
>>
>>Joe Doupnik <JRD@CC.USU.EDU> replied:
>>       Red Manual time. We went over this a week or two ago, but here is
>>a cryptic short form.
>>       1. Always have both system and user login scripts, no matter how
>>short. Reason: login.exe has a default which will absolutely eat the PATH
>>from the left, for reasons never explained and it has never been fixed.
>
>  As a reminder, it is not necessary to have both system & user login
>scripts... as a matter of fact, in a large network environment the use of user
>login scripts becomes an administrative burden. We have not run user login
>scripts since installation in 1988 and have not had problems.

Depends.

Joe's right if you don't EXIT from the system login script.

If there is no personal login script in the users mail directory, and you
don't "EXIT" from the system login script, then the LOGIN.EXE program will
run a "default" script which, as joe mentions, conveniently eat's the PATH
from the left inwards. Nice.

If you do "EXIT" from the system login script, then this default doesn't get
executed and the above doesn't happen.

Anyway, it's worth noting that it is a *very* bad idea not to create at least
an tiny login script in each users mail directory.

Why?

Because EVERYONE has at least the [C] right to every subdirectory in the
SYS:\MAIL tree (this is how software such as Pegasus Mail delivers mail to
each user). Hence, if you don't have a file called LOGIN in your mail
directory, anyone on the server can create an arbitrary login script in your
there. Should, for some reason, the EXIT command be removed from the
system login script, you could find yourself (or your users) running
potentially damaging scripts.

------------------------------

Date:	Fri, 31 May 1996 17:12:41 -0600
From:	NWNEWS@novell.com (NetWare News)
Subject: NetWareNews: Reality Check--C2 Security

Topic:	When Looking at C2 Security for a Microsoft
	Windows NT Network, Look No Further Than Windows NT's
	Own Messages

Current C2 Status of Microsoft Windows NT Server
The National Computer Security Center (NCSC) is the single
authoritative voice on the subject of C2 certification. The Red
Book  C2 certification process (network environment) does not
actually begin until an Evaluation Agreement (EA) has been
signed by the vendor and the appropriate government
organization and sent to the NCSC. Novell's EA was sent to the
NCSC in August 1995 and NetWare is expected to be C2 Red
Book compliant for its next version Green River, which will be
released in the fall of 1996. As of May 9, 1996, no public letter of
agreement has been posted by the NCSC indicating that NT
certification for C2 Red Book (complete trusted network) has
started or is in process. 

Below is a screen shot of Microsoft Windows NT 3.51 with a C2
Configuration Manager message (C2 Configuration Manager
can be found on the Windows NT Resource Kit).
Microsoft's status is therefore the same today as it was in July of
1995 as per the NCSC announcement: "A network configuration
of the Windows NT platform is currently pending evaluation
agreement." 

Although some reports from Redmond may imply otherwise,
Windows NT has gained C2 certification as a standalone
workstation or server only. One only needs to observe Windows
NT's own messages to discover that Windows NT is not secure
for networking. 

"Of course, we fail to see the benefits of NT Server when it's not
connected to a network." LAN Times, May 13, 1996 p. 70

------------------------------

Date: Fri, 21 Jun 1996 11:02:40 +0200
From: Patrick Medhurst <pmedhurs@CTCC.GOV.ZA>
Subject: Re: SUPERVISOR user in novell 4.10

Drop into the server debugger (Hold both shift keys, control and ESC)

Enter:  (case sensitive)
   c VerifyPassword<enter>
   b8<enter> 00<enter> 00<enter> 00<enter> 00<enter> c3<enter> .<enter>
   g<enter>

You better do this quickly or else the server will drop connections.
Practice with a test server first!

This will allow you to type any pasword to unlock the console.

In Netware 3.1x, doing the same trick will disable password checking
altogether.

------------------------------

Date: Fri, 21 Jun 1996 21:01:06 -0500
From: Darwin Collins <dcollins@fastlane.net>
To: netw4-l@bgu.edu
Subject: Re: De-centralized password administration

>I would like to be able to set up our help desk personnel with
>the authority to reset passwords ONLY without giving them
>supervisor-equivalent accounts.

Download n4pa12.zip from:
	http://www.fastlane.net/homepages/dcollins
Site contains NDS utilities + links to support & utility pages.

------------------------------

Date: Thu, 11 Jul 1996 06:48:08 -0600
From: "Mike Avery" <mavery@pernet.net>
To: netw4-l@bgu.edu
Subject: Re: Security HOLE

>Scott Etienne, C.N.E. wrote:
>>I hope I am not reporting something that is already painfully obvious,
>>but maybe it will serve as a good reminder.  I discovered that you can
>>login as USER_TEMPLATE.  On our network, we have never disabled login
>>from these accounts, or set any passwords, so that and of course, it
>>has all of the security rights you would never want an intruder to have.
>
>If I understand it correctly, you can maintain only one
>User_template per container; naming conventions make it that way.
>The user template is used as a basic template for creating users.

I just took a quick look at NWADMIN, and USER_TEMPLATE is just
another user.  I was... surprised.  But it shouldn't be any big
surprise that users can log in.  <g>

The question that comes to mind is how to close the hole.  If the
account for USER_TEMPLATE is disabled, that would suggest that newly
created accounts would acquire that property too, and you'd have to
activate each new account - something else to forget and go wrong.
Or, one could slap a password on the account, and that password
should not be aquired by new accounts.

------------------------------

Date: Fri, 12 Jul 1996 17:51:04 +0000
From: "Tim Stewart" <timmy@primenet.com>
To: netw4-l@bgu.edu
Subject: Re: Security HOLE

>>Yes I understand one USER_Template per contaner.  I am a Novell
>>Autherized Releller.  I sell and support Networks throughout southern
>>Kansas.  My client Base is about 30 local area networks and growing.
>>Almost half are nw4.1.  Now do you see my concern?
>
>If this hole isn't plugged, Green River will be lots of fun, with
>multiple user templates possible!

How about something like this while Novell covers their tracks:

At the beginning of the container login script, place the following line...

IF  %LOGIN_NAME = "USER_TEMPLATE" THEN BEGIN
   Write "Umm...Excuse me...what the hell do you think you're doing??"
   Write "Don't you understand you can be fired for this??"
   DOS SET ADDRESS=%P_STATION
   exit "Z:\PUBLIC\INTRUDER.BAT"
END

Contents of 'INTRUDER.BAT'

@Echo USER TEMPLATE LOGIN ATTEMP FROM STATION %ADDRESS >>
Z:\PUBLIC\INTRUDER\INTRUDER.TXT
LOGOUT

Give USER_TEMPLATE write and create  access to SYS:PUBLIC\INTRUDER, then flag the
directory hidden so nobody knows it's there.

Just an idea.....I'm sure the syntax needs work, but I think it would
work...at least you would have a record of which machines this was
being attempted at.

---------

Date: Fri, 12 Jul 1996 23:14:55 -0500
From: Darwin Collins <dcollins@fastlane.net>
To: netw4-l@bgu.edu
Subject: Re: Security HOLE -Reply

>OK, I might have stumbled on to somthing.  If I create the user_template
>buy hilighting the context the go to the OPTIONS pull down menu and pick
>create USER_TEMPATE I cannot login as USER_TEMPATE.
>
>BUT
>
>If I hilight the context, click the right mouse button, select create,
>the user and call the user "USER_Template" then I can login as
>user_template.
>
>AND
>
>I believe this will still work like a normal user_template except for
>the login factor.
>
>Infact I think I remember when I was in NW admin class I was tought that
>I could create the USER_TEMPLATE either way.

I think, you have found it!  I never realized that folks would
try to create user_templates this way.

Basically, if you create a 'real' USER_TEMPLATE, (using menu item
'Create User Template') then, the user object does not have the
attribute 'Public Key'.   The absense of this attribute is why,
you can not 'change password' in the 'Password Restrictions' page in
NWADMIN.

Also, the absense of this key, is also why you can not login, since, the
object does not have a 'Public Key' to be used by LOGIN.EXE.

But, by using SETPASS, you can give the 'User_Template' a password.
Once, set then, the object is a 'User' object, which means that you can
login into the network using the account.

By creating a user object with the name 'USER_TEMPLATE', is 'sufficient'
for Uimport and others, but, since, you have created the object using
the same steps as creating a 'normal' user, the new object does have
the 'Public Key' attribute in it.  Which means that folks can use
it to login.

So, basically, it wasn't a 'security' bug.  Except that some instructors
didn't realize that there is a difference.
The name didn't protect the object from being used to login.  It was the
lack of the attribute 'Public Key'.

------------------------------

Date: Tue, 30 Jul 1996 22:50:17 -0400
From: Slak! <jaysona@MICRO.ORG>
Subject: Re: Lost Suppervisor Password

>Is there anyone Hear or experience on using <BURGLAR.NLM>
>a kind of module that could help many of us wich has forgot
>Netware supervisor Password, couse maybe one-person had-been
>creating or installing several deference server for several company
>since the time past he/she forgot the password that he created

You don't even need to use an NLM to reset the password, you can use the
NetWare debugger for this.  Just type the commands listed below, and you
will be able to login as Supervisor, set the password, and go about you
business.

Go To The Console Not RConsole Do The Following..

Hold At The Same Time :
			 Left Shift.
			 Right Shift.
			 Alt.
			 Esc.

This Should Take You To A '#' Prompt Which Is The Novell Debugger. No
Server Acitivty Will Be Processed While Doing This. Then Type -

	'c VerifyPassword' Enter
	'B8' Enter
	'0'  Enter
	'0'  Enter
	'0'  Enter
	'0'  Enter
	'C3' Enter

	Take Note Of The Characters Being Replaced, You Will Need
	These To Re-Enable Password Verification.

	Then Type A Full Stop '.' Enter To Get Back To The # Prompt.

After This Type 'G' Enter This Will Take You Back To The Server Prompt.
Now You Can Log In As Any User Without Asking For A Password.

To Reenable Passwords You Will Have To Load The Debugger, And Enter The
Following:

	'c VerifyPassword' Enter
	'##' Enter
	'##' Enter
	'##' Enter
	'##' Enter
	'##' Enter
	'##' Enter

	The '##' Is What You Should Have Written Down Before Entering The
	'B8' '0' '0' '0' '0' 'C3'.  Then Type '.' Enter, And 'G' To Start
	The Server Back Up Again.

------------------------------