
-------------------------------------------------------------------
SECURTY2.DOC -- 19980114 -- Email thread on NetWare Security Issues
-------------------------------------------------------------------

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




Date: Tue, 20 Aug 1996 21:49:50 -0700
From: Bill <billr@GOODNET.COM>
Subject: Re: Disabling the debugger

Password protecting the monitor console has no effect on the debugger. You
can, however, issue the "SECURE CONSOLE" command, which will not only
prevent the debugger from being used, but will also prevent NLM's being
loaded from anywhere other than SYS:SYSTEM. It also removes DOS, thus
preventing anyone from exiting out to DOS after issuing a DOWN command.

The only way to "un-secure" the console after doing this is to down the
server and reset or power off. Placing "SECURE CONSOLE" at the end of the
AUTOEXEC.NCF will go a long way in keeping people from screwing around
with your server.

I must stress that this is no substitute for physiical security of the box,
along with a well communicated policy of termination and prosecution for
violators.

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

Date: Thu, 22 Aug 1996 13:48:43 EST
From: hal katzen <hal.katzen@CORPMAIL.CORPNET.NYSE.COM>
Subject: <No subject given>

>I am a security officer and auditor,  i am  looking for good audit
>tools for novell v3.11.

You may want to consider Bindview or Audittrak also,

The following are for Netware, but much of the audit programs included
can be used generically to audit any LAN.  I have used the one for
Netware 3.x, and thought it was very helpful.  The chapters on
auditing include sections on - audit procedures and overview,
technlogy controls, operating system, system access, system
operations, backup and recovery, and more.

NetWare Security: Configuring and Auditing a Trusted Environment (3.x)
#164-000030-015  Novell Research, In USA - 800.377.4136  cost me
$15.00 (this was well worth the money)

Building and Auditing a Trusted Network Environment with Netware 4.x.
This one can currently be found on-line on Novells experimental
on-line press site.
http://occam.sjf.novell.com:8080/nw410.english/trustenu

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

Date: Wed, 2 Oct 1996 08:23:05 EST
From: Sam Martin <Sam_Martin@G1.COM>
Subject: NW Hack Attack and NCP packet signatures

Here is a post which I found interesting , ... not exactly the
footprints of a gigantic hound,... but still not entirely devoid of
interest, suspect there are others out there who might agree.

I preface it w/a discussion of NCP Packet Signatures.

What is an NCP Packet Signature:
A security enhancement to protect a client by preventing packet
forging.

How do I turn it on:
At the server console and autoexec.ncf
SET NCP PACKET SIGNATURE OPTION = <0,1,2,3>
At the workstation
net.cfg
dos requester
signature level=<0,1,2,3>

Options:
Number    Results

0         Client does not sign packets
1         Client signs packets only if server requests it (server
	  option is 2 or higher)
2         Client signs packets if server is capable of signing (server
	  option is 2 or higher)
3         Client signs packets and requires the server to sign packets

Signature levels for client and server combine to determine an
effective packet signature level. There is a performance hit for some
combinations.

Client   Server =
WS                0           1            2               3

 0                No sig      no sig       no sig         no login
 1                no sig      no sig       packet sig     packet sig
 2                no sig      packet sig   packet sig     packet sig
 3                no login    packet sig   packet sig     packet sig

(Hope this space delimited table makes it thru our mailer)


>>>FORWARDED MESSAGE
>From owner-bugtraq@NETSPACE.ORG Sat Sep 28 00:20:01 1996
Date: Sat, 28 Sep 1996 03:13:13 GMT
From: Greg Miller <gregmi@galileo.mis.net>
Subject: An attack against the NetWare login protocol.
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>

I have successfully implemented this attack against a 3.12 server, the
exploit is available on my web page in the Novell section.  A breif explanation
of the attack follows:


			An Explanation of NOCRYPT.EXE
				Greg Miller
			    September 26, 1996

The NetWare login protocol consists of three packet exchanges between
the server and the client.  First the client sends a request for a login key,
the server generates a random eight byte value and sends it to the client.
Then the client sends a request for for the user ID of the user loging in, the
server looks up the user ID in the bindery and sends it to the client.
Finally, the client computes X=hash(UID,password) and Y=hash(X,login key) and
sends the result to the server.  The server retrieves X'=hash(UID,password)
stored in the bindery and computes Y'=hash(X',login key).  If Y=Y', the client
is granted access as the user.  If both the client and server agree to use
packet signatures, both parties then compute Z=hash(X,c) (where c is some
constant value) which they will use as a shared secret for authentication.
The following chart gives a graphical representation of the protocol:

     CLIENT						SERVER

Request Login Key	----------------------------->

			<----------------------------- Login Key

Request User ID		----------------------------->

			<----------------------------- UID of client

   Compute						  Compute
 X=hash(UID,password)				   X'=hash(UID,password)

   Compute						  Compute
 Y=hash(X,login key)				   Y'=hash(X,login key)

Request Authentication	----------------------------->
If Y=Y', Access granted

Compute Z=hash(X,c)				    Compute Z=hash(X,c)

When a user Alice logs in, an attacker Bob can interrupt this protocol
sequence and gain access as Alice without knowing her password.  In order
for the procedure to work, Bob must be on a network where he can observe
the traffic between Alice and the server, and Bob must be able to respond
to Alice's requests faster than the server.

First Bob sends a request to the server to login, and the server sends
Bob a login key R".  Then Alice requests a login key from the server, Bob
sees the request and spoofs a reply as the server which sends Alice R" as
her login key.  The server receives Alice's request and sends her R as her
login key, when Alice receives R she will discard it as a duplicate.  Alice
requests her UID from the server, and the server responds with her UID.

Alice computes X=hash(UID,password) and Y=hash(X,R") and sends the result
to the server.  The server computes Y'=hash(X,R), since Y' is not equal to
Y, Alice is denied access.  Meanwhile, Bob saw Alice's Y submitted to the
server, he retrieves this value from the network and sends it to the server
for authentication as Alice.  The server computes Y"=hash(X,R"),
since Y = Y" Bob is granted access as Alice.  Bob requests not to sign
packets, if the server does not require all clients to sign packets, then
Bob is allowed to masqurade as Alice.

	Alice                           Bob                     Server

				Requests Login Key R" ->

						      <- Sends R" to Bob

Requests Login Key R	-------------------------------->

			<----   Sends R" to Alice
			<-------------------------------- Sends R to Alice
Receives R" first
Discards R as a duplicate

Requests UID for Alice	-------------------------------->

			<-------------------------------- Sends UID of Alice

Computes X=hash(UID,password)
Computes Y=hash(X,R")
Sends Y to the server	--------------------------------> Computes
								Y'=hash(X,R)
				Sees Y and retrieves it.     Y != Y',
							  access is denied

				Sends Y to authenticate -> Computes
							    Y"=hash(X,R")
							    Y"=Y, access is
								granted

				Refuses to sign packets    If all clients are
							   not REQUIRED to
							   sign packets,
							   access is granted.

There may be a second attacker, Joe, waiting for Alice to log in
without using packet signatures.  As a result, Joe can highjack Bob's
connection as Alice.

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

Date: Fri, 25 Oct 1996 09:35:08 -0400
From: Dick Cook <cookd@SERVEND.COM>
Subject: Re: Hiding REMOTE.NLM password in autoexec.ncf

>I vaguely remember reading somewhere about how to write your
>autoexec.ncf such that the RCONSOLE password is not visible.

You can encrypt the password in NW 4.1.  Using:

load REMOTE ENCRYPT password

this returns an encrypted password (long string of alpha-numerics) that
you would use in the .NCF file.

Eg:
   load REMOTE -e "new encrypted password"

There is a TID on this at Novell's website

http://support.novell.com/cgi-bin/search/tidfinder.cgi?1001567

I though that the docs said something about the encrypted password being
unique per machine (ie if you used "billgates" as your password on
different servers, each would return a different string of nonsense)

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

Date: Tue, 26 Nov 1996 16:34:17 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Rconsole

>Yes you can, and the encryption scheme used on the password sent over the
>wire is a simple substitution cipher, so if someone can capture your
>packet stream while you establish a RConsole session, it takes VERY little
>effort to work out the console password.  And the contents of the server
>console are sent back to the workstation uncompressed and unencrypted, so
>don't edit your autoexec.ncf (if that's where Rconsole is loaded from)
>over the wire, if you have the least suspicion that your cable can be
>tapped.
>
>Remote Encrypt would be a step in the right direction, if it would work
>with INetCfg, but until Novell or someone else comes out with a Rconsole
>version that's secure (and Novell Rconsole isn't) use it sparingly or not
>at all.
>
>It should be using the same password encryption scheme as login does, and
>the across the wire stuff should be compressed at least.  Novell's last
>comment I heard on the subject was "It's under advisement"
>
>So it should be.
-----------
	Adding two cents:
	1) I delete xconsole.nlm as a tragedy waiting to happen out of my
control.
	2) Fortunately ODI is designed to permit loading series (en passant)
encryption/decryption while handling packets. Not much has been done in
this area, but it is untrue that nothing has been done (English is
wonderful). Facts of life are encrypting packets in software is horribly
expensive and causes headaches from PC Magazine articles reviewing server
performance.
	Joe D.

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

Date: Tue, 10 Dec 1996 09:09:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Special access attributes of PUBLIC under 4.1

>I decided that I would like to keep the students out of the public
>directory, and give them a stupub directory with just the applications
>I wanted them to have access to.
>
>I have taken the Public object out of the trustee list for the SYS:\PUBLIC
>directory, students still have access.  I specifically took all access to
>the directory away from the group STUDENT, they still have access.  I used
>grant to take away access from the files within the folder, students still
>see them!  I even got bold and used an inherited rights filter for the
>group student on the Public folder but students still can see the files.
>
>So I give up.  Does anyone have any information on what is special about
>sys:\public and how to change it?
>
>What is the implication of ROOT and my O.OU being trustees?
--------
	I dunno. While I remove most .exe files from sys:public to keep
tiny fingers away from matches I otherwise leave the directory in a normal
state. It's much easier to upgrade and maintain that way. You seem to be
fixating on rights to specific items such as users and groups. I suggest
you step back and look at rights from the tree root on down, the inherited
stuff, particularly rights granted to the container object.
	Joe D.

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

Date: Mon, 30 Dec 1996 17:28:31 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Securing against hackers

	Those interested in network security, including how NW 3 and 4
approach the problem, and who aren't intimitated by some math symbols
on pages, might be interested in obtaining a copy of the book
	"Network Security, PRIVATE Communication in a PUBLIC World,"
by Kaufman, Perlman, and Speciner, Prentice Hall, 1995, ISBN 0-13-
061466-1, around US$45.
	Ms Perlman is also known to dabble in things like routing,
NLSP in particular, when working for Novell. This book gets rather
technical while pretending it's all just good fun. This is a "what
and reasons why" technical discussion of encryption and authentication
written for the non-specialist, but not about how to configure a server
(it's from Prentice Hall not Novell Press).
	Joe D.

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

Date: Fri, 3 Jan 1997 09:13:38 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Bind Question

>Anyway, I was looking at their autoexec.ncf files and noticed that they
>have 802.3 and ethernet_II being loaded.  At my last job, I brought up 40
>different servers using only ethernet_II for ipx and ip.  Had no problems.
>I know that the 802.3 is not needed because ethernet_II will handle ipx and
>ip.

<snip>

>load tcpip
	You forgot to explicitly load snmp with private passwords, and hence
	tcpip autoloaded it. Your system is open to inspection by the world.

<snip>

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

Date: Mon, 13 Jan 1997 09:43:53 GMT+10
From: TONY OAKLEY <oaklto@ASGARD.CLARE.TASED.EDU.AU>
Subject: Security on NW3.11

>>It's not easy for me to change 200 pc's net.cfg that have there
>>hard drive locked with pcLockout.
>
>I'd like to know more about this "PCLockOut". Does it write-protect
>the HDD?

Yes, check out http://www.widewest.com.au/aspa/html/soft025.htm
or email:pcplus@pcplus.com.au

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

Date: Sat, 8 Mar 1997 10:43:15 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@ecnet.net
Subject: Re: Internet fire blocks

>I know this is off the 4.1 subject a bit, but we are looking into
>setting up an ip firewall and web server DMZ zone type architecture.
>Has anybody heard about the PIX system?

No, but I've become more interested in this sort of product of late,
so I'd be interested in what information you  could provide.

Here are some alternate products.

Ukiah Software http://www.ukiahsoft.com has a NLM based firewall that
also does network address conversion and ip/ipx gateway functions.
It's not bad at all.

FTP Software has one also.  http://www.ftp.com

BSDI software has a Unix based system that can act as a firewall,
router, ip/ipx gateway, and act as a ftp server and www server, dns
host, and so on.

Microtest has a possible product also, depending on your needs.  Look
on their home page http://www.microtest.com/webetc

Also, Gauntlet has a free Linux version, with source code,
of it's firewall.

More information can be had from the comp.security.firewalls

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

Date: Mon, 17 Mar 1997 18:59:36 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Novell server as "firewall" using IPX

>At our University, we have set up the 2 separate networks, ie Admin
>and Academic and both partitioned off at the routers.
>
>What had happen with the TCP/IP network is that if the Academic users
>want to access the Admin network, they have to log into a Linux box
>and if the login is OK, then the Linux box would allow the user to
>access the Admin systems.
>
>We want to do the same thing using IPX.  Could a Novell server handle
>this, ie log into Novell server and if OK, then allow the access to
>the Admin network.
---------------
	I'm not clear on what you think you are defending against. Certainly
that Linux box is a security risk rather than enhancement, and what's worse
is passwords over regular telnet are plaintext on the wire.
	Novell has a far better scheme. Allow logins from only certain
users and if desired from only certain networks and/or stations. The traffic
on logins is encrypted both ways. Once logged in NetWare security is
effective in keeping people away from areas they ought not be in.  Unix
security of this kind is a joke.
	There is no precondition login via IPX such as you summarize. Each
server is independent of the other for that work. NDS is spread over the
top so a secure login permits access to and from only the places the manager
has allowed. That means NDS imposes the conditions at all times, not by
trusting one piece of the network. NDS is not aware of routing pathways,
so electrical connectivity must exist before NDS can deal with requests.
	I suggest the high level managers be clear about what they mean
by security and isolation, and dig into the manner by which it is ensured.
That should include your real routers as well.
	Joe D.

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

Date: Wed, 19 Mar 1997 10:26:58 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: One Time Password and NetWare

>Our university is looking at implementing an OTP (one time password)
>system for various servers/users. A search on the FAQ and on the Web has
>brought up very little with regard to Netware.
>
>I would appreciate any pointers/information on solutions in the Netware
>3.1x and 4.1x environments.
------------
	You are discussing an entirely different cryptographic methodology
than NetWare provides for authentication. NW does not have provision for
third party authentication procedures.

	Joe D.

---------

Date: Wed, 19 Mar 1997 17:29:44 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: One Time Password and Netware

>Our university is looking at implementing an OTP (one time password)
>system for various servers/users. A search on the FAQ and on the Web has
>brought up very little with regard to Netware.
>
>I would appreciate any pointers/information on solutions in the Netware
>3.1x and 4.1x environments.

OTP systems are useful if you're logging into the network using an
unencrypted username/password.

Since 3.1x and 4.x all use encrypted passwords you don't need a OTP system
for this.

---------

Date: Wed, 19 Mar 1997 13:32:41 -0700
From: Jason Green <srpbfs01.jgreen@STATE.UT.US>
Subject: One Time Password and Netware -Reply

There is a new firewall product from Ukiah Software called NetRoad Firewall
that runs on a NW 3.X or 4.x server that supports OTP using MD4 or MD5
authentication.  You can download an evaluation copy or find info at their
web site:

	www.ukiahsoft.com

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

Date: Tue, 25 Mar 1997 11:24:02 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Can Firewalls be set up??

>>You want to learn about TCP/IP firewalls, go to NEWS and investigate
>>the existing groups dealing with that topic, or consider hiring a
>>consultant. There is no "firewall" NLM for NW and NW isn't designed to
>>do that job. Firewalls are not a single object but rather a whole body
>>of software and management techniques, ranging from simple to very
>>elaborate.  As such they are outside the pervue of the list's topics.
>
>Thanks, Joe!  I'll investigate that option.
>
>But what about my other question... Is there a nice, neat way to filter
>people from using the internet in NW 3.12 (ex. SAP filtering ala NW 4.1x)?

Setting up a firewall is NOT for the faint of heart and people who have
little interest in picky details (as it's these which hackers exploit)

If people are interested in books on the topic, then I reccomend the
"Building Internet Firewalls" by Brent Chapman. This has some good
diagrams on protocols, their characteristics and how to block/filter/proxy
them

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

Date: Wed, 26 Mar 1997 09:09:06 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: NetWare: New Border Services Product Outlined (fwd)

I've just read the following announcement, which might be of interest to
NDS sites. I've not looked at the product and can't comment on it's
security / features, this is just a press-release

Richard Letts

>>>>>
---------- Forwarded message ----------

FOR IMMEDIATE RELEASE
March 25, 1997

Novell Extends Corporate Networks to the Internet, Outlines New Border
Services Product Novell's Border Services to Focus on Security,
Manageability and Performance and the *Border* Between the Intranet and
the Internet

OREM, Utah, -- March 25, 1997 -- Novell*, Inc. today announced key
network solutions for business intranets and the Internet. This year,
Novell will deliver a new *border services* product to enable
businesses to extend their private corporate networks across the public
Internet while retaining the security, manageability and performance of
their current network. Novell also outlined additional solutions to be
delivered over the next twelve months including Novell Distributed
Print Services* (NDPS*), Novell Replication Services* (NRS), Java
Application Environment for IntranetWare (JAE), and Moab, the next
major release of IntranetWare*.

*Novell is focused on delivering the products its customers need more
now than at any time in the company's history,* said Mike Hicks,
systems engineer for the City of Tucson, Arizona. *We're in the process
of upgrading each of the city's over 300 servers to IntranetWare and
have been very pleased with the results so far. We're also are
confident that Novell--with its planned release of border services and
other IntranetWare solutions--will continue to deliver the products
we'll need to stay competitive and to provide a high level of customer
service.*

*Novell is committed to delivering IntranetWare technology to customers
in the most timely and efficient manner possible,* said Coleman Barney,
vice president of the IntranetWare Product Group. *The solutions we are
outlining today reflect Novell's focus on intranets and the increased
need customers have to secure their data over the Internet.*

Border Services

Novell's new product, currently referred to as border services, will
provide customers with security, manageability and performance within
the intranet and at the border between the corporate network and the
Internet. The product includes firewall security, proxy/cache, circuit
gateways, Virtual Private Networking (VPN), routing and remote access
capabilities and a runtime version of IntranetWare as the server
operating system.

*Novell is squarely positioned in the Internet space by providing
customers with solutions like border services that offer security,
manageability and directory integration for connecting an intranet to
the Internet* said Lee Doyle, vice president, Worldwide LAN and Data
Communication, International Data Corporation. *Novell knows how to
deliver secure, high performance networking solutions and is uniquely
positioned to help customers meet the new challenges of leveraging
intranets and the Internet to help run their businesses.*

Novell's border services product, now being distributed in a Brainshare
special edition Early Access CD, delivers:
  improved security for information sharing across the Internet; access
  management and control for securing and managing user access; proxy
  serving for enhanced performance of data look up on the intranet and
  Internet; reduced cost of operation through single point of
  administration and leveraging Internet infrastructure.

Security: The new product delivers an NDS*-based security solution more
comprehensive than simple firewalls, enabling organizations to secure
the corporate network, to monitor and manage both inbound and outbound
access, and to leverage the information and power of the Internet.

VPN: VPN technology allows businesses to leverage the Internet backbone
for securely connecting with remote sites, customers and partners
through site-to-site encryption, eliminating the need for costly
dedicated lines.

Proxy: Novell's border services proxy provides acceleration technology
to offset performance disparities between the Internet and corporate
networks by intelligently caching Internet or intranet information
closer to the users who need it.

Novell Directory Service* (NDS) Integration: Novell's solutions offers
the unique ability to easily manage Internet access to the individual
user level through NDS - all from a single point of administration
across the enterprise. The integrated administration and comprehensive
approach to all aspects of the border space will reduce the overall
cost of managing corporate intranets and Internet connectivity.

<snip>

<<<<<

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

Date: Thu, 27 Mar 1997 12:23:45 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: screen lock

	Paraphrasing from pp 434-436 of the book "Network Security" by
Kaufman, Perlman, and Speciner, Prentice Hall, 1995, the password process
for NW 4 goes about like this. Alice is the innocent user in crypto-speak:

	Server holds in NDS
		Alice's username
		hash(salt, password) = X
		public RSA key
		encrypted private RSA key


	Alice sends to the workstation
		Alice, pwd      but not as one unit

		(below, time runs down the screen)

	Workstation             Server
	Sends Alice     Alice-->   Lookups up Alice in NDS to obtain
	as plaintext                    X = hash(password, salt)
					public RSA key
					encrypted private RSA key

				 Picks a random number R, sends R and salt
			 <--R,salt    to workstation as plaintext
	Gets plaintext
	password from Alice
	Computes
	X' = hash(password, salt)
	Y' = hash(X', R)
	Password memory is erased.
	X' memory is erased.

	Picks random number R2.
	Retrieves public key of
	NDS if not cached.
	Sends {Y', R2} encrypted with
	NDS public key.   {Y', R2}NDS-->

					Computes Y = hash(X, R)
					Verifies Y' = Y. This is the pwd check.
					Sends (private RSA key XOR R2)
					encrypted by Y (equals Y').
			     <--{encrypted private key XOR R2}Y

	Now have private key.
	Does not have password.         Does not have password.
	Does not have encrypted         Does not have encrypted password.
	password.
	Does not have hash of
	encrypted password.             Does have hash X of encrypted password.

	The plaintext password never leaves the workstation, is solicited
after the server's initial response, and is erased immediately after the Y'
encryption step. The encrypted password itself does not leave the workstation
in bare form; it is super-enciphered with the NDS public key on the wire (only
the server knows the matching decryption key, the NDS private key). Wire
snooping will not reveal items which can be "replayed" by an intruder.
	There's a little more to this to prevent nasty guys from slipping
in packets but the above scenario is the basic flow of information.

	One needs to be convinced that password handling programs do not
store items on disk files and that the memory areas involved are erased
immediately after use (and that's sticky if a program is aborted) and that
plaintext or encrypted passwords exist for only minimum time in memory, and
that includes DOS' typeahead buffer.
	Joe D.

---------

Date: Fri, 28 Mar 1997 07:34:22 -0500
From: Brian Dunworth <brian@VISTACHROME.COM>
Subject: Re: NOVELL Digest - 27 Mar 1997 - Special issue

>If a program like SETPASS can verify my password before it lets me
>change it, I would imagine that a screen saver or mail program could
>verify it too, the same way.

Right.

>To try to find out how, I ran SETPASS.

  [snip]

>It looks to me like there's a function to verify a password based on the
>public key (and, perhaps, a private key that is local?).  If SETPASS can
>do it, why can't anyone?

Anyone can.  In the Netware API, there is this call:

NWVerifyObjectPassword

Verifies the password of a bindery object on the specified NetWare server

NetWare Server:       2.2, 3.11, 3.12, 4.x
NetWare for UNIX Server:      3.11, 3.12, 4.02, 4.1
Platform:     DOS, Mac OS, NT, OS/2, UNIX, Win

Syntax

#include <nwbindry.h>
 or
#include <nwcalls.h>

NWCCODE N_API NWVerifyObjectPassword

(NWCONN_HANDLE   conn,
 pnstr8          objName,
 nuint16         objType,
 pnstr8          password);

Pascal Structure

#include <nwbindry.inc>

Function NWVerifyObjectPassword

(conn : NWCONN_HANDLE;
 objName : pnstr8;
 objType : nuint16;
 password : pnstr8
) : NWCCODE;

Parameters

conn

(IN) Specifies the NetWare server connection handle whose password is
     to be verified.

objName

(IN) Points to the name of the object whose password is to be verified.

objType

(IN) Specifies the type of object.

password

(IN) Points to the password to be verified.

Return Values
These are common return values; see "Return Values Section" in the Preface
for more information.

0x0000        SUCCESSFUL
0x89F0        WILD_CARD_NOT_ALLOWED
0x89FB        INVALID_PARAMETERS
0x89FC        NO_SUCH_OBJECT
0x89FF        NO_SUCH_OBJECT_OR_BAD_PASSWORD

Remarks
The requesting workstation does not have to be logged in to the NetWare
server to call NWVerifyObjectPassword.
If the server supports encrypted passwords, the password is encrypted. If
the server does not support encryption, password verification is attempted
without encryption.

objName  and objType  must uniquely identify the bindery object and cannot
contain wildcards.
A bindery object without a PASSWORD is different from a bindery object with
a PASSWORD having no value. A workstation is not allowed to log in to a
NetWare server as a bindery object that does not have a PASSWORD. However,
a workstation can log in without a password if the bindery object has been
given a PASSWORD containing no value.

---------

Date: Mon, 31 Mar 1997 12:37:22 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Screen Lock

I've hacked around a bit, and found something interesting.  I've got my
standard Windows 95 screen saver (Flying Through Space) asking me for my
Netware password.  I accomplished this amazing feat by tweaking the registry.

Here's a disclaimer:  Don't teak your registry!  You can render your machine
useless very easily!

I've found that there's a section in
HKEY_LOCAL_MACHINE\System\CurrentControlSet\control called PwdProvider.  It's
a repository for password handler related stuff.  There are several keys under
that, two of which are NWPASSWD and SCRSAVE.

Each of these keys has values that define a description of the password
provider, the path to a DLL of related password functions (ProviderPath), the
name of a DLL function that performs a "GetPasswordStatus" operation, and the
name of a DLL function that performs a "ChangePassword" operation.

(Disclaimer:  You would have to be an IDIOT to try the following!)

I found that if I change the SCRSAVE values to match those of the NWPASSWD
values, the screen savers that use the SCRSAVE password provider settings will
thereafter use the Netware functions to check the password.

I also ran a packet trace, and found that the client does NOT ask the server
to verify the Netware password!  So, the password is cached on the workstation
- yikes!

(I haven't tried chaning the Netware password while the screen is locked, or
trying to guess the password too many times...)

So, that answers two issues:  1) A screen saver can use the Netware password
in Windows 95; 2) It is done in a security-unfriendly (or unconscious) way.

Remember, manual registry changes are not advised by me, Microsoft, or anyone
sane.  Also, I will not provide more details than I described above, either
here or by direct e-mail.

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

Date: Tue, 8 Apr 1997 03:25:07 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: security

>I am running Netware 3.11 and think I might have a hacker giving
>themselves Supervisor rights.  Does anyone know of a way to list all
>users who have equivalence to a certain group or user without going
>through each one? ( I have several hundred users)

In SYS:SYSTEM there's a utility called SECURITY.EXE.
Execute: SECURITY > CHECK.TXT and make use of EDIT or something
to search for "SUPERVISOR" and "[S".
Then use SYSCON to straighten things out.

For hackerstools you may browse the Internet and query some
search-engines and learn how they did it.
Another thing. Current patches from Novell prevent any results from
most known user-friendly hacking tools (SEC*.* files???).

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

Date: Wed, 9 Apr 1997 15:43:49 -0400
From: Debbie Becker <dbecker@CLARK.NET>
Subject: Re: Netware 4.1 Security

>I am running 9 Novell 4.1 servers over a WAN with container
>administrators in each state. How can I check users security,
>i.e. who has supervisor access etc. at both the NDS and file levels.
>
>I am aware of a utility that came with Netware 3 called SECURITY.
>I don't have a copy of this and am not sure if it would be of any
>use if I did have it. I would assume it would only work within a
>bindery context and wouldn't know about NDS rights.
>
>I have used RIGHTS /S /T from the [root] context. Is this the only way?
>or is there a another?

I use RIGHTS VOLUMENAME: /T /S to get trustee assignments for all
directories/files on a volume. Usually port this off to a file for easier
evaluation.

For NDS rights, I CX to the [Root] of the tree and type:  NLIST * SHOW ACL

This will show you the Access Control List (a.k.a. Object Trustees List)
for all objects in the [Root] context ([Root], Country, Organization) with
trustees and all Object and Property rights granted shown.

I then run this for any object I want to check trustees for (i.e., NLIST
"ORGANIZATIONAL UNIT" SHOW ACL /S). Usually run it for Organizational Units
and Server objects. (Sometimes for volumes as well, since people seem to
feel that granting NDS rights to volume objects will somehow translate into
file system rights).

Last thing I do is to run    NLIST USER SHOW "SECURITY EQUAL TO" /S    for
a listing of all security equivalences (groups, org.roles, other users,
servers, etc.)

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

Date: Mon, 14 Apr 1997 21:03:59 -0400
From: Greg Small <gsmall@SYMPATICO.CA>
Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12

>"This user's SECURITY_EQUALS property has group <groupname> stored
>beyond the maximum of 32, so the group is not considered when
>determining Security Equivalences, Trustee Directory, and FIle
>rights. The group membership is ineffective and should be deleted."

There is a 3rd party utility called OVER32.ZIP which I have used to
determine who was near, at or over 32 entries in the table.

I believe this will also allow some kind of bindery change to make the
entries over 32 work as expected.

If you cannot find it EMAIL me at gsmall@spar.ca tomorrow and I'll ship it
off to you.

IMPORTANT NOTE -- FOR THOSE USING NW 4.1 and PROBABLY 4.11 -- the
equivalent problem shows up when either 57, 58 or 59 entries (I forget
exactly which) are reached.

I only used to see the OVER32 in 3.1 and now the "over5?" in 4.1 when I was
testing a lot of new apps and had all sorts of groups enabled.  The users
never reached this limitation -- that Novell obviosuly never expected ANYONE
to reach.

---------

Date: Tue, 15 Apr 1997 10:23:55 GMT
From: Roger Kresge <rkresge@WEB.IIS-CENTPA.COM>
Subject: Re: SECURITY_EQUALS Bindery Property & NW 3.12

>I recently upgraded from NW 3.11 to 3.12. The NW 3.11 server was
>called DLAN and the NW 3.12 server was called NEW-DLAN. The object
>was to move the user's personal files (in DLAN/USER:) and the
>workgroup files (in DLAN/GROUP:) to the analogous directory on the
>NEW-DLAN server. The further object was to have the user's mail IDs
>and passwords remain the same. All of this was accomplished with a
>combination of BINDFIX and JRB Utilities (netcopy).
>
>The problem arose on Monday morning when users began logging into the
>new server (which had been renamed from NEW-DLAN to DLAN; the former
>DLAN is now OLD-DLAN and will be kept around until we're sure we
>don't need anything from it). Some users could no longer get into
>applications and directories they had access to before the change.
>This smelled like a trustee rights issue. WHen I went into SYSCON to
>check out the users, I would receive the following message:
>
>"This user's SECURITY_EQUALS property has group <groupname> stored
>beyond the maximum of 32, so the group is not considered when
>determining Security Equivalences, Trustee Directory, and FIle
>rights. The group membership is ineffective and should be deleted."

I studied Novell's available technical documents that seem to match up with
this, and conclude that you may have had a hacker attack your network by
running a utility that increases a user's security equivalence.  Try
running BINDIFX *twice* from the 3.11 server, then take the *.OLD files to
your NW 3.12 server and BINDREST again.  FWIW, Novell didn't change the
binderies from NW 3.11 to 3.12, but they *did* change the APIs to close
some security holes; perhaps the JRB utilities tried to mess around with
the binderies on the NW 3.12 server.

If that doesn't fix it, run BINDFIX *again* on the NW 3.12 server, which
may fix the problem.  Oh, the problem manifests itself as a trustee issue,
but it appears to be a bindery issue.

>The problem here is that we never saw this message before in NW 3.11.
>It's also quite strange in that one user will be able to get to an
>application while the adjoining user will not. I believe this is
>because the bindery stored trustee rights in the order they're
>assigned so that the 33rd one, regardless of what it is, will not be
>available.
>
>Is there any way to get around this short of actually editing that
>property with a bindery editor? Would running BINDFIX help? Hinder?
>Make no difference?

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

Date: Wed, 16 Apr 1997 14:01:52 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Admin User Corrupted

>My NW4.11 server crashed during a Backup Exec backup. Upon rebooting
>the NDS system was out of whack, I ran DSREPAIR and all is fine
>*except* that user ADMIN is now an "Unknown" object (as opposed to
>being a user object), I cannot login as ADMIN, unfortunatly I did not
>grant another user supervisor equivelency so when I run netadmin.exe
>as a regular user I don't have the privilege of deleting and
>re-creating the Admin object.  I can login as SUPERVISOR in bindery mode,
>but I can't run netadmin.exe without NDS login.

There is no utility (as far as I understand) for adding Admin-like rights
to an object in a tree.  If there is one with rights to [Root], you need
to call Novell, and ask their expert hackers to add or fix the Admin
account, using their special magical tools.

For future reference, making an object security-eqivalent to Admin
wouldn't fix the problem, because if Admin goes away, the other account
becomes security-equivalent to no one!  You need another account with
rights to [Root], not just equivalence, to cover that base.

---------

Date: Wed, 16 Apr 1997 14:33:01 -0600
From: Steve Miller <smiller@FTJ.COM>
Subject: Re: Admin User Corrupted

>My NW4.11 server crashed during a Backup Exec backup. Upon rebooting
>the NDS system was out of whack, I ran DSREPAIR and all is fine
>*except* that user ADMIN is now an "Unknown" object (as opposed to
>being a user object), I cannot login as ADMIN, unfortunatly I did not
>grant another user supervisor equivelency so when I run netadmin.exe
>as a regular user I don't have the privilage of deleteing and
>re-creating the Admin object.  I can login as SUPERVISOR in bindery
>mode, but I can't run netadmin.exe without NDS login.

There is a third party utility called MakeSU to make a new Admin object
from the console.  This utility is licensed to your tree.  A demo and
more info at at:

	ftp://ftp.netcent.com/makesu.zip.

I have not tried this program, but I like the other utilities put out by
this company, DreamLAN Network Consulting. ˙They make a toolkit (called
NDS Toolkit) that includes this utility or you can buy it by itself.
The last I knew the entire toolkit only cost $500 to $600.  I think the
MakeSU utility by itself might only be $100, and the guy at DreamLAN can
probably mail it to you.  Thats how we got our DSLogin utility from them.

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

Date: Mon, 21 Apr 1997 14:27:41 +0100
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Compromise of a single NDS server

>Is it true that in Netware v.4.x, if a single server is compromised the
>whole NDS network could be compromised? To ellaborate:
>
>Say I get a rconsole password for a single 4.x server
>Can I create/access accounts on other servers in the tree (using commonly
>available hacking utilities like setpwd.nlm or burglar.nlm)

No, not the whole tree, but you would be able to modify the password for
any account that server held a RW/master Areplica for in the same way as
you can any account on a NW3.x server you have the passoerd for.

On our servers the rconsole passord bear not relationship to the ADMIN or
SUPERVISOR passwords, gaining rconsole access to the server leaves the
monitor lock-screen hurdle [we leave our console locked by default, even
in the machine room].

Security requires thought, not questions.

/please/ no knee-jerkreactions here. NT security is worse.

I don't doubt for a moment you're an IS Security Auditor -- your question
was simplistic; I know the kind since I'm getting atleast one dumb
questionaire a week from our Auditors on network security.

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

Date: Tue, 22 Apr 1997 10:31:22 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: ? Admin password

>Does anyone know how to recover an ADMIN password
>on a Novell 4.1 network; without reloading.

I'm assuming the problem is that you don't have an object with Supervisor
rights to [Root], right?  There are two things you can do:

1) Call Novell's technical support, and they can dial in to your network
   and create an object with rights to [Root].  $200, quality work.

2)  Have a look at

http://ourworld.compuserve.com/homepages/dreamlan/toolkit.htm.

"NDS Toolkit" is produced by DreamLAN Consulting Ltd.  (The president of
this company is Peter Kuo, author of one of my "must have" books,
"NDS Troubleshooting.")

There's a utility called MakeSU that creates a user object as described.
I tried the demo (after the last time someone asked this), and it really
does create an object with Supervisor rights to the [Root].  But, the
Demo assigns the object a password and doesn't tell you what it is,
so it's essentially non-functional.

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

Date: Fri, 9 May 1997 13:33:26 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NDS tree surgery

>I've got an annoying NDS problem that I've been researching with no
>success.  I taught a NetWare 4.x class and created a container where
>students could run amok with full rights.  Now I've got several
>containers with an IRF that blocks everything except Browse.  This
>makes cleanup "challenging" since there's no way to delete the
>containers or the objects therein.  I've checked and the accounts
>used to create the containers are locked out as well.
>
>If there's a next time, I'll bring up a disposable tree for students
>to frolick in.  For now, I just want to lop off a branch of my NDS tree.
----------
	Here's an object (sic) lesson for your students and staff: always
create a safe administrative account on each server so that you can always
get in and override anything others have done. Do not use "equivalent to."
	Here's another: never put play servers in the same NDS domain as
production equipment. And the corrollary is never trust a server which has
been tinkered with by less than expert hands: clean the drives and make
fresh installations.
	Joe D.

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

Date: Tue, 13 May 1997 08:42:27 +0100
From: Chris van Oorspronk <Chris.vanOorspronk@RHIJ.NL>
Subject: Re: rconsole

>Try setting this us in INETCFG. Under "Manage Configuration" select
>"Configure Remote Access to this Server". Enable Remote access, and
>set the password.  You are done!

Don't use this. This tool creates a file NETINFO.CFG in SYS:ETC.
Everyone who can reads this file can read the rconsole password.

Type this at the console:

  remote encrypt (you will now be ask for a password)

Then type your password (you will not see it) and press <enter>.
Then there will be created a file LDREMOTE.NCF. This file contains
your password (encrypted).

Put this command (ldremote) in your autoexec.ncf.

>I installed a Netware 4.11 server and am trying to get rconsole to
>load in the autoexec.ncf so that the server can be downed and
>restarted remotely.  I put "LOAD REMOTE PASSWORD" AND "LOAD RSPX" in
>the autoexec.ncf and when the server is downed and brought back up it
>still asks for the password before continuing to load and connect to
>our tree.  Is there something else that I am missing?  I have even
>made another NCF file and put a call from autoexec.ncf and it still
>asks for the password.  This is currently how we have our 3.12 servers
>set up.

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

Date: Tue, 3 Jun 1997 17:16:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Anonymous E-mail through Groupwise

>Has anybody noticed that the Groupwise mail server does not keep track
>of full headers? All one person needs to do is telnet to that server and
>then you can send anonymous email. Are there not logs to keep track of
>who telnets in and sends mail? There needs to be because if you route
>email through a groupwise server it is totally anonymous...
---------
	How do you propose to distinguish a remote email system from a
person telneting to TCP port 25 and typing by hand when they both say
the same thing (follow the rules)? It's all text mode stuff, what you
see is all there is. Faking mail this way is as old as email. It's also
how email programs work.
	Joe D.

---------

Date: Tue, 3 Jun 1997 22:02:28 -0400
From: Larry Hansford <hansford@ERINET.COM>
Subject: Re: Anonymous E-mail through Groupwise

>Has anybody noticed that the Groupwise mail server does not keep track
>of full headers? All one person needs to do is telnet to that server and
>then you can send anonymous email. Are there not logs to keep track of
>who telnets in and sends mail? There needs to be because if you route
>email through a groupwise server it is totally anonymous...

Groupwise isn't the only e-mail that allows that -- it is standard
way of doing business.  Read the news on the ISP's trying to get a
grip on people (not subscribers) using their e-mail system for
spamming.  I don't allow Telnetting into my mail servers --
Groupwise or Otherwise....

---------

Date: Wed, 4 Jun 1997 17:56:41 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: anonymous email

>>>Has anybody noticed that the Groupwise mail server does not keep track
>>>of full headers? All one person needs to do is telnet to that server
>>>and then you can send anonymous email. Are there not logs to keep track
>>>of who telnets in and sends mail? There needs to be because if you route
>>>email through a groupwise server it is totally anonymous...
>>---------
>>	How do you propose to distinguish a remote email system from a
>>person telneting to TCP port 25 and typing by hand when they both say
>>the same thing (follow the rules)? It's all text mode stuff, what you
>>see is all there is. Faking mail this way is as old as email. It's also
>>how email programs work.
>>	Joe D.
>
>You are obvioulsy confused. Of course you can telnet to port 25 of any
>isp and type in the headers manually but this does not make it totally
>anonymous. If you send mail to yourself using this method and look at
>the full headers you will see that it may say it is from
>yourmom@aol.com  when it is really from hrd@cc.usu.edu but it also logs
>where the call came from. In my case, sending mail through my isp's port
>25 can change the "from:" to anything I want it to but in the header it
>will read the IP number I had when I telneted in and where I came from,
>citrine.cyberstation.net for example. On the other hand if you telnet to
>port25 of mail.amnat.com and send mail to yourself you will see this:
-----------
	Yes, I know about the envelope, and how to launder connections
so the envelope is from another place. Stopping laundering is a bit
of a problem actually, on many systems (on yours too perhaps)?
	And if one looks carefully, a very large fraction of sites have
messed up DNS records such that the apparent IP name is not the one
supplied otherwise, ptr records and cnames being what they are. And
you are believing the remote DNS server, and so on. If I rejected such
connections to my machines ftp and web service would slow to a trickle.
	Needless to say, folks create convincing fake mailgrams all the
time, and often the envelope material is not seen or even visible.
	My points are: Email travels as plain text which anyone can
type, to port 25, and there is no way of discerning that the person
is using Telnet or whatever to create those bytes. Expecting a machine
to validate a remote email user just isn't in the cards at this time.
	Validation involves a shared secret or public/private keys,
PGP signatures being commonly used today, but done right and not as
merely a digital signature.
	Joe D.

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

Date: Mon, 9 Jun 1997 08:03:30 -0400
From: Dennis Large <wdlarg01@HOMER.LOUISVILLE.EDU>
Subject: Re: Additional Security for Netware 4.11

>Is anyone aware of a shareware or commercial software package
>which allows you to provided added security to netware directories.  I
>am looking for extra password protection, folder locking, etc. I am aware
>that NetWare is a very secure networking environment, but our H.R.
>dept. is paranoid.  Any help would be greatly appreciated.

Technically, no, at least none that I know of, but I'll offer some related
comments.

1) The shrinkwrapped netware package has been given a C2 security rating
which is quite an honor for NW, in my mind. One of the manuals deals
specifically with the security issues, and may be worth some reading time.
See where your operation is in reference to the optimum dreamworld
described, and make any changes you deem appropriate. Prepare appropriate
info from all this to share with HR.

2) Many applications have the ability to password individual documents,
databases, etc. Though this has no central control, you may want to give
this as an option, but claim absolutely no responsibility for forgotten
passwords in such a case.

3) Enable auditing on the appropriate areas, and show them some samples
of information that you track and monitor. If you do not have specific
personnel handling security and auditing issues, perhaps it's time to
consider such.  You may want to supplement the native auditing features
with some 3rd party tools which do a much better/easier job of reporting
the data.(bindview, etc). Maybe they'd be willing to pay for some of it.

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

Date: Thu, 12 Jun 1997 17:30:53 GMT
From: Herb Axilrod <bgrove@ONRAMP.NET>
Subject: Re: Screen-saver Win95 - NW 4.11

>We are upgrading our workstations to run Windows 95.  To enforce
>security on workstations, we are looking for a product that
>can enforce screen-saver activation after a predefined period.
>
>Ideally it should not be possible for the users to de-select
>the screen-saver, it should follow the user and authenticate
>to NW i.e., use same password as NW.

Birch Grove Software offers such a screen saver product.  Key features:
* Unlocks with user's or the administrator's password.
* NDS aware.
* Distributable and configurable from Login script
* Option to prevent user from disabling.
* Displays bouncing bitmap or uses any *.scr display.
* 2nd level timeout logs users off of network.
* Available for Win 3.x, Win 95, or Win NT.
* US or German language versions.

Demos are available from http://www.bgrove.com/bgrove

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

Date: Mon, 16 Jun 1997 15:35:10 +0100
From: Richan Postmus <Richan.Postmus@RHIJ.NL>
Subject: Re: way to load remote without passwd on 3.1X?

>There is a command you can type at the console which encrypts
>the password you set on the server.  It then load the rconsole:
>
>load remote     20570982
>
>The 20570982 will be the encrypted password that Novell churns out, it
>then keeps another hidden file with your real password.

The commands are:
LOAD REMOTE (With unencrypted password)
REMOTE ENCRYPT

The system prompts for a password to encrypt. You
type the password and press <Enter>.  By default the commands are
written to LDREMOTE.NCF in the system directory. Add LDREMOTE to
your AUTOEXEC.NCF and ready you are.

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

Date: Sat, 26 Jul 1997 17:28:54 +1200
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Require Unique Passwords

>>We have this setting turned on as a system default. Does anybody know
>>how many old passwords Netware remembers? Surely it doesn't
>>remember every password for the life of the user ID.
>
>Last I heard, version 4.1 remembers 20 passwords.
>
>Debbie Becker

I thought the answer was still 8 so I ran a test. After 40 different
passwords (under NW 4.11) I still could not reuse the original. I then
tried reusing the 39th and it worked. Further testing shows that the
first 25 passwords had been retained, and I could freely change between
the 26th through 40th password. This indicates that Novell have
re-introduced the system where there is a time-delay (24 hours?) before
a password can be re-used. I would be interested to hear if these results
apply to 4.10 - I don't have access to a 4.10 server any more.

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

Date: Mon, 28 Jul 1997 16:05:16 +0100
From: Graeme Findlay <gfindlay@INVERESK.CO.UK>
Subject: Re: Password Change Date

>I am running NW 3.12, 250 users.  The server is patched up to date.
>Users must change their password every 120 days.  My problem is, the
>date field doesn't calculate right.  It should reset itself to be 120
>days from the date the account is setup (atleast that's what I was
>thinking should happen).  What am I missing here?  The date always goes
>back to January 1, 1985.

That is correct behaviour. The 120 days is from the date that the
password was last changed, not when the account was created. This
means that all new accounts default to asking for a password to be
setup by the user the first time they logon and then takes the 120
days from that point.

The Jan 1,1985 is basically a NULL date, so any date is later than
that as far as running Netware. So Netware looks at the date. If it
is earlier than (or the same as) today then the user is asked to
change the password when they login.

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

Date: Wed, 13 Aug 1997 18:19:47 +0200
From: Svetlin Petrov <admin@ECS.RU.ACAD.BG>
Subject: Re: Making Novell Password Security better

>I am looking for an add on package to my Novell 4.1x environment that
>will put tougher requirements on the types of password user's use.
>I am looking for something that has a dictionary of common words,
>etc...  so my users do not use passwords such as names or common
>words.  Does anyone know of such a product that works in a Novell
>Netware 4.1x environment???

Look here:

http://www.intrusion.com/

and here

http://www.egsoftware.com/

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

Date: Tue, 2 Sep 1997 16:59:15 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet frames -Reply

>>I use just Ethernet_II on my networks, because I run both IPX
>>and IP.
>>
>>But I've seen a server (I was told to look at it), where was
>>bound Eth_802.2 AND Eth_802.3 on one NIC. The LAN I talk
>>about is realy small, about 10 stations, just a bussines LAN for
>>some accounting aplication.
>>
>>When I look at monitor.nlm/LAN, I saw that all the communication
>>is done twice - both interfaces have the same Send_packet_number,
>>Receive_packet_number and so on. The clients have also used
>>all the frames.
>>
>>I would like to know, if I'm right that all the communication
>>goes twice, or if its just some trick and the configuration
>>described above has some use (all the client's NICs are some
>>3c5x9, so they can use all the frames).
>>
>>I would also like to hear your opinion about using frame
>>types -  if there's some reason not to use Eth_II frame type
>>(when all the NIC's can use it)
>
>>I'll say it in case JD is taking some time off:
>>Go to ftp://netlab2.usu.edu/sys/anonftp/misc/ and read ethernet.txt
>>amongstothers.
>
>I just wanted to elaborate a little more.  Yes, most likely the 802.3 is there
>for legacy purposes, at one time they may have been running the older
>packet drivers or something.
>The stats you see are not per protocol, rather per NIC.  The packets in
>and packets out are counted for that particular NIC, I can't think of a place
>to find out how much traffic each individual frame type uses.
>George Taylor
---------
	Time off? How does one spell that?
	Here's another aspect to keep in mind when looking for useless traffic.
If your IPX traffic traverses an FDDI link then it is quite possible for the
FDDI to Ethernet converter box to be puzzled about recreating the proper
Ethernet frame (FDDI does not preserve them, normally). I had just that
situation this weekend, where the converter was instructed to send a copy of
each three times (three different frames). That made the RIP/SAP bursts
gigantic. The cure was to tell the converter please use Ethernet_II.

	And on the useless traffic topic but a change of protocols, to IP.
Many of you know that Ping (ICMP/IP) can be used to create denial of service
attacks. The idea is to send a Ping Request with a destination IP address of
255.255.255.255, and often with a MAC address of broadcast (all 1's). Then
all stations hearing it are tempted to do a Ping Reply (to 255.255.255.255
or whereever).
	The attack can be manifold. The simple step is the source IP address
is local, and the idea is to get many machines generating a Ping Reply
surge. The nastier one is to put a foreign IP address in the Request packets
such that the foreign address gets all the replies (and your WAN link
saturates).
	One would think that in this day and age machines would discard
Ping requests which involve an IP broadcast address. Ha! Not only do many
machines reply, but (take careful note) most HP Jetdirect boards do too
if not configured properly, and many managed hubs do also. The HP JD boards
in unconfigured state do an ARP for the destination IP rather than a formal
Ping Response. Hubs can do either too, for the same reason.
	The sneaky bad guys find a way of slipping such Ping Request packets
onto the wiring. They should not be conveyed by the full Internet because
broadcast addresses should be filtered out, but then...
	The defense is to chat with your router people to filter out such
packets. Don't let in IP traffic with broadcast addresses (for either src
or destination) and don't send them outside either. This does not stop the
local wackos from generating the probes, but we can, with much work, track
down the originating machinery. What applies for in/outside the site applies
equally to each side of routed links within the site. A handy rule of thumb
is to reject packets whose source IP address is not appropriate to that
wire (subnet masks considered).
	Joe D.

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

Date: Sat, 13 Sep 1997 19:55:00 -0700
From: Hansang Bae <hbae@PRIMENET.COM>
Subject: Re: TFTPD Server

>>Is there any way to make an IntraNetware server a TFTP Server?
>
>FTP Services for IW, the 4th CD in the set has a TFTP server component.
>After install, look at sys:etc/inetd.cfg, and see that the corresponding
>line is commented out by default. Remove the semicolon, and go! You
>don't have any other management options to play with.

Keep in mind that tftp (trivial ftp) can be a BIG security hole.  As no
passwords or usernames are required.  It's typically used to download
bootstrap code or new firmwares.  So make sure you know what you are
doing before implementing tftpd.

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

Date: Thu, 18 Sep 1997 21:24:17 -0400
From: Dave Wineman <dw@AVCI.NET>
Subject: Client 32 Security Hole

Does anyone know of a way to plug a Client 32 security hole upon startup
with policies in place and forced login before access to the computer
for the following scenario:

I found another security/program glitch with win95/Client32. You know
that if your at the Novell Client32 logon screen and press CTRL+ESC you
get the task manager. And that you can enter a program to run. If you
enter CONTROL and press enter it DOESN'T bring up the control panel like
you would think, it skips the logon (leaves the logon box there) and
takes you into windows. It appears that you get the local start menu
(including MS-DOS Prompt, Explorer, Etc). Try it and see if it does the
same with the old win95. This is at HB with the Win95B machines

Any ideas on how to force the login without bypassing to windows
(not connected to the network?)?

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

Date: Fri, 19 Sep 1997 06:32:10 -0400
From: Desmond Irvine <dirvine@YORKU.CA>
Subject: Re: Client 32 Security Hole

>Does anyone know of a way to plug a Client 32 security hole upon
>startup with policies in place and forced login before access to the
>computer for the following scenario:
>
>I found another security/program glitch with win95/Client32. You know
>that if your at the Novell Client32 logon screen and press CTRL+ESC you
>get the task manager. And that you can enter a program to run. If you
>enter CONTROL and press enter it DOESN'T bring up the control panel like
>you would think, it skips the logon (leaves the logon box there) and
>takes you into windows. It appears that you get the local start menu
>(including MS-DOS Prompt, Explorer, Etc). Try it and see if it does the
>same with the old win95. This is at HB with the Win95B machines

Delete or rename TASKMAN.EXE and the CTRL+ESC trick will no longer work.

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

Date: Thu, 13 Nov 1997 12:10:00 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: How do the workstation login, attach ?

>I wonder if anybody knows how does a workstation connect (login, attach)
>to a server NetWare 4.1, I mean what kind of packets are sent between the
>file server and the workstation or if there is a place where I can see this
>information.
-----------
	Use a wire monitor. Novell's Lanalyzer for Windows is a good tool
for NetWare work.
	Also you may wish to dig deeply into the security exchanges, and
this is summarised conveniently in the book "Network Security, PRIVATE
Communication in a PUBLIC world" by Kaufman, Perlman, and Speciner,
Prentice Hall publisher.
	Joe D.

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

Date: Thu, 27 Nov 1997 20:19:53 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Rights to Applications NOT to Users

>The problem I am facing is when the worker accesses DOS they also have
>access to the files allowing then to copy, delete, or change the status
>of the file.
>
>I NEED A PROGRAM THAT GIVE ACCESS TO APPLICATION, NOT FOR A USER OR
>GROUP !!!
-----------
	Let's stop and think for a moment. A user can't give him/herself
more rights than he/she already has. To give them would be a fundamental
security flaw. NW does not know how a user makes requests on a server,
though some TSRs try to make guesses by trapping DOS. The app is running
on the user's machine, not in the server, and thus the app is essentially
the user. Consequently the app is merely one of many ways the same requests
can be made on the server by that user.
	The solution is to have an agent running on the server which has
necessary rights and can be commanded by the user through a second matching
agent to assign them. Naturally, the weakness is how the commands are
validated, and a second is knowing when to rescind them. A third is
restricting the command set to particular operating conditions and sequences.
And a final weakness is knowing the user agent is not being mimiced. And
so on along the twisty pathway of security.
	In the database world the pair of agents is often called a frontend
and backend program, and the user is not allowed to see the data as such.
	Joe D.

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

Date: Tue, 9 Dec 1997 08:53:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: TCPIP messages

>>Any news about a patch to the recent LAND Attack on INW4.11, it
>>will cause 100% CPU usage.
>
>Yes i saw that too but what i allso saw that the utiization wil dropped a
>while and the server can still be accessed while being under attack.
>I tried the same on an NT server that was unreachable for about 60 seconds...
>
>Joe D. said
>>Best to talk with your IP router
>>people now and get the attack blocked as it enters the site. SYN is TCP
>>start of data stream, and the SYN attack is to continually open such
>>connections and never responsd to the local side's complment to the open.
>>Thus the target system crashes from overallocation of buffer resources.
>>Port 25 is SMTP mail. This is an old adolescent game. Block at your site's
>>router. Thank Novell for their software trying to survive the attack
>>automatically. Joe D.
>
>but as one of my novell servers acts as an incoming mail server and the
>other one as a web server it seems to mee that blocking means cutting me out
>on the rest of the world, or am i wrong joe ?
--------
	Let's face reality on the net. There are many bad guys and stupid
people on the Internet who can and do perform disruptive things to any
machine they can reach. It will not get better, it is getting worse.
The normal first line of defense is the router separating the site from
the world. Whoever is in charge of it needs to be familiar with ways of
blocking the bad guys while letting normal work proceed, as much as is
possible. This is TCP/IP material rather than local IPX.
	In addition, individual machines on site should be protected and
configured to not be inviting targets or security holes. This is a system
manager's responsibility, working with the router people.
	The normal strong defense is constructing a firewall system. This is
complicated, costly, and not a single unit that is plugged in and magically
provides protection. People have to configure the system. There are NEWS
discussions groups on firewalls, books on such matters, and so on. In depth
knowledge of TCP/IP is a requirement to intelligent defense.
	Joe D.

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

Date: Wed, 17 Dec 1997 11:03:40 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Teardrop  TCP/IP attack

>I just searched Novell's Knowledge Base for Teardrop and there seems to
>be no information about it
>
>Some implementations of the TCP/IP IP fragmentation re-assembly code
>do not properly handle overlapping IP fragments. Teardrop is a widely
>available attack tool that exploits this vulnerability.
-------
	It is a malicious attack. Let's see why.
	TCP or UDP or ICMP generates a request to send to IP and an IP
decides the request must go out in fragments. Or, equivalently, a large
IP datagram arrives at a router and needs to be fragmented to fit a smaller
outgoing pipe. These fragments are contiguous, not overlapping.
	Suppose the datagram implies a response and the response never
appears. The high levels can initial a retransmission. The retransmission
creates a new IP datagram, one with a different IP ident in its header.
The pieces can be fragmented differently that before. These fragments are
considered a completely independent datagram than the first case, because
the IP ident field is different; no overlap is possible.
	Networks rarely make copies of datagrams in transit. Thus the same
datagram is extremely unlikely to arrive by two different paths, each
fragmented differently.
	Now you can see that overlapping fragments mean the same IP datagram
must be copied and fragmented differently. This implies bad guys are trying
to destroy machines. There are many ways of violating common sense operating
conditions to create trouble and we will never be free of such opportunities
for mayhem.
	For the standard IP frag reassembly algorithm see RFC815.TXT. It is
kind and does not explicitly defend against the crazy people inciting riot.
	If you catch any of your people with destruction tools you may wish
to contact your legal people right away. In addition, in cases of serious
attack from outside put up a good firewall.
	Joe D.

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

Date: Sun, 21 Dec 1997 10:34:06 -0500
From: Steve Kurz <skurz@NORFOLK.INFI.NET>
Subject: Re: RCONSOLE

>I have two servers, a 4.11 and a 3.12.  The AUTOECEX.NCF loads
>REMOTE.NLM with the password, and I use that same password to lock the
>server with MONITOR.NLM.  Yes it is different from the supervisors
>password.

Remote = Password "A"
Monitor = Password "B"
Supervisor = Password "C"

>Client 32 v2.2 is on the clients.
>
>When I attempt to access the servers using RCONSOLE via DOS, I must
>enter two different passwords (So far so good).  One to access the
>sever, and another to unlock the server as locked with the MONITOR.NLM.
>The problem is that they are two different passwords and I believe the
>two passwords should be the same.  Is this correct?  I have downed the
>server and brought it back up with the same results.

Rconsole = Password "A"
Monitor = Passwords "B" or "C"

No matter what password you use to lock the console, the supervisor's
password always works.  I usually use a sweep of my finger over the
keyboard to lock the console and the supervisor's password to umlock it.

---------

Date: Tue, 23 Dec 1997 09:12:36 +0200
From: Patrick Medhurst <pmedhurs@CTCC.GOV.ZA>
Subject: Re: RCONSOLE

>It's been my observation that the Admin password will not unlock the 4.1
>Console unless it is the original password from when the server was
>installed.  If user Admin has had a password change - the new one will not
>unlock the console.  The original server setup password is assigned to the
>user Supervisor and cannot be changed in this regard.
>CraigE...

It can be changed if you change that server's bindery emulated Supervisor
user.  You need a bindery context set on the server to do that, however.

As a matter of interest, in Moab (NetWare 5) the lock feature has been
removed from MONITOR.NLM.  There is a separate SCRSAVE.NLM which does the
snake and locks the console.  The console is unlocked by authenticating to
NDS as Admin (or equivalent).  This will solve the confusion that has been
caused by the MONITOR lock password, but will bring a worse problem (in my
opinion) in that how will you unlock the console if the replica on the
server does not contain an Admin user, and the server is currently unable
to synchronise with a replica that does (because of a WAN link down, etc.)?
I am sure we will figure out the best way around this, but who needs the
headache?

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

Date: Tue, 6 Jan 1998 11:45:35 -0600
From: Marius Swart <mps@knersus.nanoteq.co.za>
Subject: New: Firewall-l - Computer network security & Technology

FIREWALL-L on LISTSERV@LISTSERV.NANOTEQ.COM

FIREWALL-L is a mailing list for discussions on computer network
firewalls, network security and related technology, concepts and
techniques.

To subscribe, send a message to listserv@listserv.nanoteq.com
containing a single line in the body of the message:

SUBSCRIBE firewall-l Yourname Yoursurname

Owner: owner-firewall-l@listserv.nanoteq.com

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

Date: Tue, 6 Jan 1998 10:40:38 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Office 97 running on a server?

>Joe has a point of course.
>
>In my personal view, and after enough time using this software called
>office, I can't think of any reason not to install disks in WS's other
>than a monetary one. These programs are getting too large and too
>cumbersome for diskless WS's......whethere they work on them or not.
>
>And there is no problem installing disks and no diskettes.
---------
	Ok, let me add the context in which I have to work.
	It is a student open lab, a very public arena with thousands of
users going through it daily, seven days per week. I have requirements
that each user gets a clean machine upon every boot, with no leftovers
from the previous user, and the machine configuration is the same every
time, and the time to get the machine ready for them is about a minute or
less.
	Real life shows that there is no way of keeping a local hard disk
intact in this environment. Not with DOS nor Win3.1/95 nor with NT. Remaking
a hard disks takes at least 20 minutes using the best of today's tools, and
that is 20 times too long for a public place.
	The solution is diskless booting, with a local floppy drive for
carry-aways. Each station is given an individual scratch area on the server,
shown to users as drive D:, which is cleaned absolutely during login (takes
a few seconds at worst). Collectively the drive D:'s share an 800MB volume,
but a user cannot see another user's drive D: no matter what they try.
	As you can see, this public arena is very different from dealing
with one-person-per-machine desktop situations.

	On MS Office 97 slowness. There are two principle slow items: the
interactive spelling checker in Word (so turn off that option) and searching
vast ClipArt collections. Of the two the first is the most noticable. In
my environment we don't have a bandwidth problem, using 100Mbps Ethernet
by design, nor a swap file problem (using 32MB clients, by design, with
swap on the server in a per-station scratch area). Bloated programs have
become a fact of life and we arrange the net to accomodate most of them.
	Joe D.

---------

Date: Thu, 8 Jan 1998 09:31:02 -0500
From: Bob Dopher <rcd@EE.UMR.EDU>
Subject: Re: Office 97 running on a server

>>>	It is a student open lab, a very public arena with thousands of
>>>users going through it daily, seven days per week. I have requirements
>>>that each user gets a clean machine upon every boot, with no leftovers
>>>from the previous user, and the machine configuration is the same every
>>>time, and the time to get the machine ready for them is about a minute or
>>>less.
>>>	Real life shows that there is no way of keeping a local hard disk
>>>intact in this environment. Not with DOS nor Win3.1/95 nor with NT. Remaking
>>>a hard disks takes at least 20 minutes using the best of today's tools, and
>>>that is 20 times too long for a public place.
>>
>>Have you tried PC-Rdist?
>>
>>It works great at in a lab of 190 computers on campus. All the
>>machines have Windows 95 and Office 97 installed locally, along with
>>other software. The typical log off and rebuild process takes no more
>>than a minute, with severe cases taking longer. It cleans the drive
>>throughly right down to the bookmarks in Netscape.
>>
>>Kris S.
>--------
>	Down to bookmarks in Netscape is a looooong way from cleaning a disk,
>Kris. As mentioned, I've looked at these tools (including Ghost). One must
>start with a repartition operation. Now measure the time to rebuild.
>	Joe D.

I've been following this thread for the past couple of days & just
thought I'd throw in my 2 cents worth. We run about 50 public win95
machines from the local hard disks very successfully, without having to
reconfigure back to the basic setup each time. We use a combination
hardware/software locking system to prevent user reconfiguration of the
local harddrive so that a reboot always brings the machine back to its
original configuration. From our point of view this has a couple of
advantages:

1. The initial boot of the machine is local, thereby reducing the network
traffic ( or more properly, the load on the server). When one gets an
instructor telling 30 students " now push the reset button" that
becomes important as far as the boot time is concerned.

2. Swap space is kept off of the file server; an important consideration
to us as we observed considerable thrashing of the file server when swap
space was allocated for the user on the file server itself.

We still run our applications, such as Office 97, from the file server;
and this neither overloads the server at any given time nor does it
consume any significant bandwidth beyond normal bursts.

We do make use of Ghost, but it's only needed when we build a new image
for our machines. Other than that the machines run for extended periods
with no reconfiguration necessary.

---------

Date: Fri, 9 Jan 1998 10:00:43 -0500
From: Jim Pretty <jpretty@CITY.LONDON.ON.CA>
Subject: Re: Office 97 running on a server?

>	"Real life shows that there is no way of keeping a local hard
>disk intact in this environment. Not with DOS nor Win3.1/95 nor with NT.
>	Joe D.

I definitely agree with the Win3.1 part and agree that it is a real bear
under Win95, although there are some 3rd party utilities which make it a
lot easier, but am confused about why you don't think it is possible (even
relativly easy) to keep a disk intact under NT.

Granted the way rights work under NT are quite different if you are used
to the Novell paradigm, but one should be able to lock down an NT
workstation very tight.

---------

Date: Fri, 9 Jan 1998 09:47:06 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Office 97 running on a server?

	Because
	a) writable space must exist locally to run the login script
	b) anyone with a floppy disk can become administrator via common
hacker tools on the net. No intelligence needed.
	c) anyone with a floppy disk can consume a hard drive. No
intelligence needed.
	Joe D.

---------

Date: Fri, 9 Jan 1998 10:37:20 +0000
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Office 97 running on a server?

>>>	"Real life shows that there is no way of keeping a local hard
>>>disk intact in this environment. Not with DOS, Win3.1/95 nor NT."
>>
>>I definitely agree with the Win3.1 part and agree that it is a real bear
>>under Win95, although there are some 3rd party utilities which make it a
>>lot easier, but am confused about why you don't think it is possible
>>(even relativly easy) to keep a disk intact under NT.
>>
>>Granted the way rights work under NT are quite different if you are used
>>to the Novell paradigm, but one should be able to lock down an NT
>>workstation very tight.
>--------------
>	No, because
>	a) writable space must exist locally to run the login script
>	b) anyone with a floppy disk can become administrator via common
>hacker tools on the net. No intelligence needed.
>	c) anyone with a floppy disk can consume a hard drive. No intelligence
>needed.
>	Joe D.

	d) A Linux boot disk will grant the user full access to the NTFS
partitions.

---------

Date: Mon, 12 Jan 1998 09:58:14 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Office 97 running on a server?

>>	No, because
>>	a) writable space must exist locally to run the login script
>OK, but can not a small part be left so that the login script be run?
>>	b) anyone with a floppy disk can become administrator via common
>>hacker tools on the net. No intelligence needed.
>Do they not need some idea of the administrator password?
>>	c) anyone with a floppy disk can consume a hard drive. No
>>intelligence needed.
>
>Can you elaborate on this one.
>
>We are in the process of upgrading to NT (from Win31) at the moment
>and trying to glean as much 'additional' information as possible.
---------
	You are at a Univ. I suggest asking the scruffiest students you can
find to come in and "play" with your machinery. Within about 20 minutes they
will have reduced it to rubble, in the CS sense. That's too bad because the
last time I visited Sheffield it was a nice Univ.
	Try FDISK, or get any Linux user to arrive with a boot floppy to
take out NTFS material. Try boot sector viruses, partition table viruses.
Try Norton's Utilities.
	There are tools circulating on the net which let anyone with them
on a floppy to become Administrator. Clearly, they don't need to know the
password. Your system is now toast. MS has commented upon these tools, and
at last reading there is no defense.
	There are no space quotas on NT, so any opening means all available
disk space.
	It's part of the job to know about such things, alas. I too find it
repellant and a waste of energy, but it is necessary. Please read NT groups
in NEWS for more information.
	Joe D.

---------

Date: Mon, 12 Jan 1998 11:52:39 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Office 97 running on a server?

>>	There are tools circulating on the net which let anyone with them
>>on a floppy to become Administrator. Clearly, they don't need to know
>>the password. Your system is now toast. MS has commented upon these tools,
>>and at last reading there is no defense.
>>	Joe D.
>
>But what if the stations cannot boot up from a floppy via the CMOS
>setup, and users are denied the right to run or copy anything from a
>floppy?
---------
	A fair question: basically no floppy. That means users have
difficulty taking data to or from the machine, unless one provides remote
data access across the network. In my situation (public access labs) users
carry their data on floppies and there is no public remote access data
storage. One may also imagine individual usernames and private storage
associated with them, but I can't support that nice concept.
	I think the break-in tools (become Administrator) work even without
a floppy, and thus remote data access permits them to be run. But I am not
expert in the fine points of those tools. Removing the floppy drive and
remote data access tends to create a totally inward looking system, and
that's not worth much in a University.
	Joe D.

---------

Date: Mon, 12 Jan 1998 14:30:30 -0800
From: Michael Kessler <mkessler@CERES.SFSU.EDU>
Subject: Re: Office 97 running on a server?

>Removing the floppy drive and remote data access tends to create a
>totally inward looking system, and that's not worth much in a University.
>	Joe D.

Users can save their data on floppies, but can't run any executables from
the floppies. The station boots off the C: drive, and we use FoolProof to
define how the station may be used.

---------

Date: Tue, 13 Jan 1998 07:58:47 +0200
From: Mike Glassman - Admin <admin@IAA.GOV.IL>
Subject: Re: Office 97 running on a server?

>>	There are tools circulating on the net which let anyone with
>them on a floppy to become Administrator. Clearly, they don't need
>>to know the password. Your system is now toast. MS has commented
>>upon these tools, and at last reading there is no defense.
>	Joe D.
>
>But what if the stations cannot boot up from a floppy via the CMOS
>setup, and users are denied the right to run or copy anything from a
>floppy?

On the issue of security hacks, we all know that someone who is
determined to bring a system to it's knees can and will no matter how
many options we disable in our end users Pc's, and no matter how many
sniffers and other such we have running.

There is only one way to abolish this sort of issue from an
organization, and that is to make sure that if anyone is caught
attempting this sort of thing, whether as "fun" or any other, is simply
to punish. And I mean punish in large capitol letters - and make sure it
gets published.

Obviously this is easier in an organization like mine, and much harder
in schools and such, but the option to do so is available everywhere. In
my org, the rules have been published and are re-published once a year
at least, stating that any such atempts will be severely dealt with. In
the short time I have been here, I have been instrumental in catching 2
such "fun" hackers....both no longer work here, and I doubt if either of
them will ever work in any similar place again, not to forget the very
large sums of money they are paying for damages that they may have
caused.

There are some things that one simply has to be firm with. On security
issues, I have no mercy, I'm the devil incarnate. And I couldn't care
less if it was a kid or an adult. I have no doubts there will be many
replies as to the inability to punish children at schools.....but then,
if you have no way of causing people not to "want" to hack your system,
you'll get hit one way or another.

---------

Date: Tue, 13 Jan 1998 00:49:34 -0700
From: The Abundant One <sfinney@CCIT.ARIZONA.EDU>
Subject: Re: Office97 on Server

Like Joe says, its pretty easy to beat NT security.  For anyone who isn't
in the know, there are at least 3 different hacks freely avalible on the
net that will allow a person to bypass NT security.

Method #1 is to use a Linux boot disk and simply mount the NTFS drive as
a Linux volume.  Method #2 is to boot to DOS from a floppy and use
something like NTFS4DOS to gain access to the NTFS partion.   Method #3
is to install a new copy of NT into a different directory, and
boot that version of NT and you have full access to the NTFS partition.

Method #1 and #2 require a *bootable* floppy so going into the bios and
changing the boot order from C->A rather then A->C and then password
protecting the bios can do a pretty good job of protecting you from this
one.

Method #3 doesn't require a floppy, you could place the install files on
a FTP server then FTP them to the machine you want to hack, or even boot
from the CD (if you have bootable CD drives)

There is also a program called getadmin that gives you admin privs on a
NT box, but the hole this program exploits I think was dealt with in SP3
so I don't think its much of a concern anymore, but if you have an
unpatched box you are open to that hack as well.

---------

Date: Tue, 13 Jan 1998 17:19:46 +0200
From: Cris <cris@UTTGM.RO>
Subject: Re: Office97 on Server

>Method #1 is to use a Linux boot disk and simply mount the NTFS drive
>as a Linux volume.  Method #2 is to boot to DOS from a floppy and use
>a something like NTFS4DOS to gain access to the NTFS partion.   Method
>#3 is to install a new copy of NT into a different directory, and
>boot that version of NT and you have full access to the NTFS partition.
>
>Method #1 and #2 require a *bootable* floppy so going into the bios and
>changing the boot order from C->A rather then A->C and then password
>protecting the bios can do a pretty good job of protecting you from this
>one.

With debug.exe (DOS) is very easy to "crash" CMOS in only two line ;)

---------

Date: Thu, 15 Jan 1998 10:41:35 GMT0BST
From: Liz Jarman <L.Jarman@SHU.AC.UK>
Subject: Re: Office 97 running on a server?

>On the issue of security hacks, we all know that someone who is
>determined to bring a system to it's knees can and will no matter how
>many options we disable in our end users Pc's, and no matter how many
>sniffers and other such we have running.

And they do.

>Obviously this is easier in an organization like mine, and much harder
>in schools and such, but the option to do so is available everywhere. In
>my org, the rules have been published and are re-published once a year
>at least, stating that any such atempts will be severely dealt with. In
>the short time I have been here, I have been instrumental in catching 2
>such "fun" hackers....both no longer work here, and I doubt if either of
>them will ever work in any symilar place again, not to forget the very
>large sums of money they are paying for damages that they may have
>caused.

Like Joe we have 'Open Access' rooms. This means that the rooms are
meant for student use, but we have an open building policy that
allows members of the public to use the campus (we have a couple of
cafes that we enourage the public to use). We have a very large adult
student population and can never know whether the user is a proper
student or not. The PCs are only for educational use, but without
going round and checking each user which is time consuming we find
that occasionally a non student will use the PCs. Our Internet access
is controlled by login codes so we don't provide free inetnet access
to every Tom, Dick or Harry.

>There are some things that one simply has to be firm with. On security
>issues, I have no mercy, I'm the devil incarnate. And I couldn't care
>less if it was a kid or an adult. I have no doubts there will be many
>replies as to the inability to punish children at schools.....but then,
>if you have no way of causing people not to "want" to hack your system,
>you'll get hit one way or another.

Students mean cash, even in the UK were education was seen to be
free. If a student is found causing damage the redress isn't
immediate as there are various stages to go through.

We are aware that there is a problem and have to work on the basis
that we can recover a machine quick enough to not cause a problem for
the true users.

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

Date: Tue, 13 Jan 1998 22:20:13 -600
From: Steven Thompson <steve@MASTER.ASERVE.NET>
Subject: Re: MAC address tracking

>I have a MAC address of a machine that tripped the intruder lockout
>for my 'Admin' account.  Is there anything out there that can alert
>me when that address connects to the network or something that can
>list by MAC address.  I'm just looking for a way to know when that
>machine is connected so I can see the user ID and track that person
>down.

Try this...

IF "%P_STATION" ="Put-The MAC-Address-Here" THEN
#COMMAND /C SEND "Intruder Alert!! - Check the console" server/user
END

Check the syntax for SEND for your version, NDS and bindery are a
little different. Make sure the user you send the alert to is *you*
<smile>  Then just rconsole in and look for the address

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

Date: Wed, 14 Jan 1998 11:07:51 -0800
From: Jeff Groetsema <jgroetsema@UNIX1.CC.UOP.EDU>
Subject: Re: Office97 on Server

I have seen sites with many, many more NT hacks.  And on the issue of the
getadmin hack, there are already updates to get around the service packs.

At a generic OS hack site, there was information on many hacks to an NT
system and only two for NetWare (add on stuff - FTP and Perl).

So what does this tell you?

---------

Date: Wed, 14 Jan 1998 12:39:20 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Office97 on Server...Again

>Floppy disks are important, but so is providing a small chunk of
>network hard drive space for students.
>
>Why not purchase an additional hard drive (if you're low on space),
>and extra RAM since the prices have been crashing down for quite some
>time now?
>
>With NetWare (version 3.x, 4.x, and later) you can restrict the
>amount of disk space available to a particular subdirectory (which
>applies to all its subdirectories automatically).  When you do this,
>the amount of free disk space reported from this directory will be
>different than the root directory.
>
>For example, if you had 1000 students, all you would need to do is
>add 2 GBs of disk space and restrict each student's directory (not
>the user account) to 2 MBs each.  If the student fills it up, too
>bad, they'll just have to resort to floppy disks or clean up their
>files.
---------
	I'm afraid that this introduces larger issues. They start with
personal logins and the maintenance associated therewith. Then 2MB is
small and will be pressured to be much larger. 2MB won't hold even a
Windows swap file.
	I put all stations on volume USER: and share the space amongst
all without quotas. Each station's scratch directory there is independent
of that of the other stations. Each scratch directory is cleaned
absolutely upon machine boot, and I provide a count-down menu choice
to save files there or not (default is not save) to accomodate rebooting
after a crash. Volume User: has 800MB capacity and thus each user has
much elasticity but all share the capacity. Sharing makes far better use
of common resources, with the known danger of a hog consuming all.
	Takeaway/permanent storage is via floppy disks.
	Joe D.

---------

Date: Wed, 14 Jan 1998 11:47:46 +0000
From: Randy Richardson <randy@INTER-CORPORATE.COM>
Subject: Re: Office97 on Server...Again

[Above message snipped]

This solution definitely reduces the user whining, and simplifies
the administrator's job.  In most situations, I think this would work
very well.  When you get a network hog, that's where you add a
directory space "throttle."

2 MBs is enough in an elementary school setting, and even for many
high schools.  I keep forgetting that you run Windows from the
network, and have to deal with large swap files.

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

Date: Wed, 14 Jan 1998 16:33:00 -0400
From: "BURTT, PETER (AEL)" <PBURTT@GOV.NB.CA>
Subject: security info

> -Second prob is with my latest job task.
>My boss wants me to get all the security bugs that Novell servers have
>(all sorts of). And all the resources i've seen are not very useful for
>me, cause they contain hacking binaries, and what i need is a short
>describtion on what, how and solution.  Is there a good Info on the
>net or has anybody done this before?

A good place to start is the Simple Nomad Novell hack site,
http://www.fastlane.net/~thegnome/faqs/netware/index.html

This isn't your typical hack site, the information is well organized and
explains exactly what conditions you need to have in order to break in
using such and such a tactic. Of course that gives the admin a nice,
well
organized list of conditions that had better not be possible on his LAN.

In general though, off the top of my head...

1) Secure physical access to the server

2) Keep client and server software up to date. Well known security holes
   are usually (often??? sometimes???) patched.

3) Don't load RCONSOLE.

There are lots of things to worry about, but those 3 things will foil
most attacks.

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

