Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
  
18
Novell
Whenever I am at a client's office, invariably the conversation turns toward operating
systems. We bat around various flavors of UNIX, discuss Windows NT, and then suddenly,
Novell emerges. From there, it is all downhill. We go from Novell to DOS 3.x,
and finally, to CP/M. Most people today speak of Novell in the "I remember when"
mode. Think about that for a moment. I will wager that the last time someone talked
with you about Novell, that dreaded term "legacy network" was mentioned
more than once.
This is a mystery to me, largely because Novell had made innovations relevant
to the Internet "way back" in 1991. Even at that time, the Novell NetWare
platform supported TCP/IP and was Internet ready. Today, Novell is still very much
in the running. Web servers and other baseline Internet applications continue to
be written for the Novell platform. And, interestingly, Novell may measure out to
be as secure as any of its counterparts.
Background
NetWare has been with us a long time. The first version of NetWare was released
in 1983. To put that in perspective, consider this: MS-DOS had just emerged. Computer
enthusiasts were dreaming about the luxury of a 286 with 640KB RAM. It was less than
15 years ago, and when you think of it in these terms, it doesn't seem so far away.
However, measure that 14 years against the backdrop of the computer industry (which
has now exploded).
Since that time, NetWare has undergone some major changes. And, although it is
not really secure in its out-of-the-box state, NetWare has some substantial security
features. Control of what services run on what port is just as incisive in Novell
as it is in UNIX. The system is, in fact, nearly identical. For those of you who
are considering stringing your Novell network to the Net (which is now a popular
practice), I suggest getting some background in TCP/IP. Many excellent Ethernet administrators
familiar with IPX are less confident about their TCP/IP knowledge. This is where
standards really shine through and assist the administrator. TCP/IP is negotiated
in a similar fashion on almost every platform.
In NetWare, the file that governs your service is SYS:ETCSERVICES. This
file contains a list of services that you will be running from out of your intranet
to the Internet at large. It is the equivalent of the /etc/services file
in UNIX. It is from this file that you pick and choose your services, which may include
TFTP, FTP, and Telnet. In this respect, a Novell network running TCP/IP could be
scanned in the same fashion as a UNIX box. The SYS:ETCSERVICES file is
one to watch closely. Misconfigurations there can lead to security problems.
The discretionary access controls in NetWare are also formidable. In fact, Novell's
control of the system is quite granular. It extends, for instance, to time-based
restrictions. A user's access can be restricted to certain hours of the day and certain
days of the week. Users' passwords are subjected to aging and there are at least
rudimentary controls to reject passwords that are either too short or those that
have been used before.
Control over directories and files is good. For example, the following controls
can be placed on directories:
- Delete inhibit--Files or directories marked with this attribute cannot be deleted
by system users.
- Hidden--Files or directories marked with this attribute cannot be seen. (That
is, if a user is snooping through a directory, he will not discover a directory or
file so marked.) Also, any object marked with this attribute cannot be deleted or
copied.
- Purge--This attribute causes a file to be purged, or obliterated from existence
upon deletion. In other words, when the supervisor deletes files marked with this
attribute (or files within a directory marked with this attribute), the files cannot
be restored.
The control that NetWare offers over files is even more finely structured. In
addition to being able to apply any of these attributes to files, a Novell NetWare
system administrator can also apply the following:
- Read only--This restricts users from altering the files.
- Execute only--Marks a file as execute-only, meaning that it cannot be copied,
backed up, or otherwise "taken away."
- Copy inhibit--Prevents Macintosh users from copying files.
These controls are impressive in an operating system. A comparative analysis of
Novell 3.x, for example, and Microsoft Windows for Workgroups is instructive.
Windows for Workgroups was an excellent platform on which to establish a network.
However, its security capabilities were practically nonexistent. In contrast, Novell
NetWare had advanced controls on all elements of the system.
Here is an interesting bit of trivia: Using the Novell NetWare operating system,
you can actually restrict the physical location at which a user can log in. That
is, you can specify that John can only log in from his own station. If he proceeds
to another computer, even just 6 feet away, he will be unable to log in. In order
for you to do this, however, you must specify that all users are restricted in the
same manner.
NOTE: NetWare also has provisions for
a hierarchy of trust. That is, you can assign managers to each section of the LAN
and assign a group of people to each manager. Thus, NetWare can be used to quickly
and efficiently map out relationships of trust and authority that closely (if not
precisely) parallel the actual levels of trust and responsibility between those within
your organization.
The Novell NetWare network environment offers fine security. (It is not perfect,
but demonstrates advanced security techniques, even going back to Novell NetWare
3.x.) Novell NetWare 4.x is a very strong platform and has become popular
as a WWW server platform.
The flip side of this is that we have not yet seen Novell handle the void. In
closed network situations, Novell has proven to be an excellent networking platform.
The levels of security it provides will foil all but the most studious cracker or
hacker. Novell is just now getting a taste of the real outside world. It may not
be long before we see Novell security advisories floating around the Internet. Later
in this chapter, you will get a chance to see at least one flaw found only two months
prior to this writing. It is a hole that could allow a remote exploit. You'll also
learn about other exploits as we briefly look at the security of Novell.
One point I should explain here is why Novell holes have not surfaced in the same
way that UNIX holes have. The Novell NetWare environment is vastly different from
the UNIX environment. NetWare is used primarily in business settings. Many accounting
firms, law firms, and medical practices use NetWare as a networked platform. DOS-based
programs run well in NetWare, so you can use it for record keeping, accounting, and
billing.
NetWare also provides an attractive enough interface, and it is surprisingly lightweight
considering the wonderful networking job that it does. However, NetWare users and
UNIX users are disparate. NetWare users characteristically access DOS-based programs
through the shell. The shell provides a suitable menu interface. You simply move
the arrow down the list of choices and fire. It is a point-and-shoot type of environment
from that standpoint. Thus, although there are undoubtedly thousands of developers
that may work their craft on a Novell NetWare network, the majority of NetWare users
never really come into contact with the operating system level. To them, the underlying
framework is largely invisible.
In contrast, UNIX users regularly have contact with dozens (if not hundreds) of
commands at the operating system level. Because UNIX is a developer's platform (with
that development deeply rooted in the C programming language), UNIX users are more
intimately familiar with the nature of their operating system, its flaws, and its
virtues. On this account, hard-core analysis of the UNIX operating system is constantly
under way. This process is not only undertaken by developers for UNIX vendors, but
also by the people who rely on this strange operating system each day. As the general
knowledge of an operating system increases, so does the specific knowledge regarding
its holes.
Such in-depth analysis in NetWare is confined primarily to the developers who
created it. Their source code is proprietary and therefore, the computing community
has no reliable way of knowing what flaws, if any, exist in the NetWare operating
system. True, there may be fragmented efforts here and there to attack the binaries
of that operating system, perhaps searching for buffer overflows or other, lower-level,
problems.
The future will tell us all about NetWare, though, because it has now survived
that one giant step to the Internet. NetWare users now want their networks strung
to the Net. And, as I said at the beginning of this chapter, Novell had provisions
for strong TCP/IP support five years ago.
Throughout this chapter, I will take a look at NetWare security. Again, the purpose
of this book is not to cover one operating system extensively, but rather, to prepare
the user for general Internet security. By the time you reach the last quarter of
this book, I will be making references to all the operating systems covered up until
that point, often not only in the same chapter, but in the same paragraph. I have
tried to design this book so that by the time you reach that point, you will be well
prepared.
In short order, then, let's have a look at this old but revolutionary operating
system.
NetWare Security in General
NetWare has always been a platform that is attacked from within. That is, those
on the internal network are usually the enemy. A wide variety of attacks are available
if you are within close physical proximity of a NetWare server. Here are a few:
- Down the machine, access the disk, and alter the bindery. When this machine reboots,
the operating system will examine the bindery. It will determine that a valid one
does not exist. Based on this information, it will reconstruct a new default bindery.
When it does, all previous password protection will no longer exist.
- Load one of several network loadable modules (NLMs) that can (at least on 3.x
and before) change, disable, or otherwise bypass the supervisor password.
- Attack the Rconsole password on earlier distributions of Novell. Reportedly,
the algorithm used for the encryption of that password was poorly conceived. It is
weak and passwords so encrypted can be cracked quite easily.
Default Passwords
There is never a replacement for good system administration. Do you remember the
SGI exploit I examined at the beginning of this book? The Webforce line of computers
had a default login for the line printer. This login ID did not require a password.
This is referred to as a passwordless account. Almost every network operating
system has at least one account that already exists that does not require a password.
NOTE: When installing Slackware versions
of Linux, for example, the process completes by you booting to a login prompt. The
first time you log in, you log in as root without a password. It is left to the user
to assign a password to the root account. Not all UNIX-based platforms work this
way. For example, when you're installing SunOS by hand, one of the last options it
requests is what the root password will be. Similarly, Red Hat Linux registers a
password before the first boot load. This policy is probably a wise idea.
In NetWare, the supervisor account is passwordless on a fresh installation and
remains so until the supervisor assigns a password. (In other words, the operating
system never forces a password.) Moreover, there is a GUEST account created
at time of installation. If you do not feel that you will need this account, go into
SYSCON and delete it immediately. However, if you envision using this account
to provide guest access, assign a password to it immediately.
Spoofing
Spoofing is the act of using one machine to impersonate another by forging the
other's "identity" or address. It is not a baseline skill with crackers.
Either they know how to do it or they don't. The technique is talked about often
because of its uniqueness. It is a method of breaking into a remote host without
providing so much as a user ID or a password. For that reason, spoofing has developed
a mystique on the Internet (despite the fact that spoofing was known about at Bell
Labs more than 12 years ago).
There are different forms of spoofing. Typically, when we think of spoofing, we
have in our minds the notion of IP spoofing across the Internet. Certainly, this
is the most popular kind of spoofing among crackers because of the press coverage
that followed Kevin Mitnik's arrest. How-ever, there are different types of spoofing.
Here, I am referring to hardware address spoofing.
In Chapter 28, "Spoofing Attacks," I address IP spoofing attacks. However,
it will suffice here to write that in 1985, at Bell Labs, it was determined that
spoofing was a viable procedure. A paper was posted to the Net on this subject. It
was four pages or so, describing how such an attack might someday be implemented.
Spoofing in the NetWare environment is not impossible; it is just difficult. Most
crackers advise that you can change the hardware address in the NET.CFG
file. However, it might not be as easy as this.
NOTE: The NET.CFG file contains
parameters that are loaded on boot and connection to the network. This file includes
many options to alter the configuration by hand (which is mighty useful because conventional
configurations sometimes fail to "come out right"). To supplement this,
changes may be made directly to the interface using this file. Options include number
of buffers, what protocols are to be bound to the card, port number, MDA values,
and, of course, the node address.
The node address is generally hard-coded into the Ethernet card itself. If you
have such a card lying around the office, take a look at it; the address is generally
posted directly on the face of the card (a little sticker or perhaps even letters
burned into the board itself). Some cards have jumpers that allow you to alternate
the IRQ and ROM address settings. Some boards also allow you to alter the node address
of the card via software. That is where the spoofing comes into the picture.
The popular way to spoof is by altering the address in the NODE field
in the NET.CFG file. In this scenario, you assign the node an address belonging
to another workstation. However, severe problems could result from this if you were
to initiate a session using the identical hardware address of a workstation also
logged on. This could potentially crash the system, hang the machine, or cause other
trouble on the wire.
If this technique is to be truly effective, the cracker must devise a way to temporarily
"kill" or anesthetize the machine from which he is claiming to originate.
This may not be a problem, depending on the circumstances. Perhaps the other machine
has been turned off for the night. If so, the cracker has a wide open field for experimentation.
NOTE: In order for this type of attack
to work, many variables must be just right. For example, if there are any
network interfaces between the attacker and the target, this may not work. Say the
packets have to cross a hub and there is some hardwire scheme that manifests the
path between the target and the machine the cracker is claiming to originate from.
Under this scenario, the spoofing attack will fail miserably.
This refers only to hardware address spoofing in an Ethernet setting. However,
some Novell NetWare networks are running TCP/IP on the inside. TCP/IP spoofing from
inside a Novell NetWare network is a different matter and much will depend on how
much information the cracker can glean about the network.
Sniffers and Novell
In Chapter 12, "Sniffers," I examined sniffers as one important method
of attack against an Ethernet network. Sniffers are primarily valuable in surreptitiously
capturing login IDs and passwords on a network.
Fortunately, in most instances, such an attack will not be effective against a
Novell NetWare network. Following version 2.0a, passwords passed during the login
process were encrypted. Therefore, a sniffer attack would be largely a waste of time.
NOTE: An attacker could technically capture
encrypted passwords and transport these elsewhere, perhaps to his home or office.
There, he could eventually crack these using a brute-force password utility. However,
there are other more immediate avenues to try. Running a sniffer could be a complicated
process on a NetWare network. Many workstations are liable to be diskless clients,
leaving the cracker no place to hide his bounty. (And realistically, just how much
sniffed traffic can fit on a floppy that already has boot and network loading files
on it?)
Any attempt to capture passwords on a Novell NetWare network would probably be
via a keystroke capture utility. There are only a limited number of these and they
all have to be at least on the same interface or machine as the target. Thus, securing
each workstation for key capture utilities is a fairly straightforward process.
Obviously, keystroke capture utilities won't be found on diskless clients (unless
loaded onto the floppy), so your field of investigation is narrow. The time your
search will consume is increased only by the hard drive size and directory structure
depth of the workstation you are examining. You can assume that the utility is probably
a hidden file, probably named something different from what it was originally named.
(In other words, you will not be looking for files such as Gobbler or Sniffer.
Crackers and hackers may write programs with dramatic, pulp-fiction names,
but when they go to deploy those tools, more innocuous names are in order.)
There are several ways you can search. One is by checksum/size. Another is to
use a utility such as grep. Most of these cracking utilities contain within
the code some string of unique text. (Frequently, crackers put a slogan, a nickname,
or a comment within the code.) Using grep, awk, or other utilities
with powerful regular expression search capabilities, you can attempt to identify
such files, which may be masquerading as normal system files or documents.
NOTE: Crackers suggest that keystroke
capture utilities be placed somewhere in the path. This allows the utility to be
remote, but still capture the needed data. Thus, if you were searching for such a
utility, you would start with all directories declared in the path statement. This
statement may be oddly formed, too, depending on whether the machine is a diskless
workstation. If it is not a diskless workstation, take a look at the autoexec.bat.
It is true that sniffers are almost pointless (too much effort and too great a
risk) with respect to Novell NetWare passwords in versions higher than 2.0a. However,
if your network houses older file servers, the default password encryption scheme
must be disabled, according to Novell NetWare Version 3.11 Installation Guide
(Novell, Inc.).
This poses quite a different situation. Passwords on those interfaces will be
moved across the network in clear text. This is a fact well known to crackers. Under
such circumstances, a cracker would benefit greatly from utilizing a packet sniffer.
If you are currently in such a situation, I suggest you attempt to transplant that
information elsewhere and upgrade the OS or to disconnect that file server from any
portion of a network already reasonably believed to be safe from sniffing attacks.
Cracking Tools
The following sections describe tools. Some were written by individuals who wanted
to better network security. Others were written by crackers. All of them share one
thing in common: They can be used to crack a Novell site.
Getit
Reportedly written by students at George Washington High School in Denver, Colorado,
Getit is designed to capture passwords on a Novell network. The program was written
in assembly language and is therefore quite small. This tool is triggered by any
instance of the LOGIN.EXE application used in Novell to authenticate and
begin a login session on a workstation. Technically, because of the way Getit works,
it can be marginally qualified as a sniffer. It works directly at the operating system
level, intercepting (and triggering on) calls to Interrupt 21h. It's probably the
most well known NetWare hacking tool ever created.
Burglar
Burglar is a somewhat dubious utility. It can only be used where an individual
has physical access to the NetWare file server. It is an NLM, or a loadable module.
Most of Novell NetWare's programs executed at the server are loadable modules. (This
includes everything from the system monitor to simple applications such as editors.)
The utility is usually stored on a floppy disk. The attacker sometimes has to reboot
the server. Providing that the attacker can reach the Novell server prompt (without
encountering any password-protected programs along the way), the utility is then
loaded into memory. This results in the establishment of an account with supervisor
privileges. However, the utility's impact on the Novell networking community has
probably been negligible. Rarely are file servers available for public tampering.
Spooflog
Spooflog is a program, written in C by Greg Miller, that can spoof a workstation
into believing that it is communicating with the server. This is a fairly advanced
exploit. It should be observed here that Miller is not a cracker. He provides these
programs over the Internet for research into general network security and he has
no affiliation with any radical or fringe group. He is simply a talented programmer
with a very keen sense of NetWare.
Cross Reference: Spooflog is available
(along with the source code) at http://www.users.mis.net/~gregmi/.
Setpass
Another loadable module, Setpass is designed to give the user supervisor status.
This module also requires physical access to the machine. Basically, it is a variation
of Burglar. It works (reportedly) on Novell NetWare 3.x to 4.x.
NWPCRACK
NWPCRACK is a brute-force password cracker for cracking passwords on the Novell
platform. This utility is best used from a remote location, working on passwords
over long periods of time. As the author points out, there is a period of delay between
password attempts and thus, brute forcing could take some time. This utility would
probably work best if the cracker were attacking a network that he knew something
about. (For example, if he knew something about the people who use the machine.)
Short of that, I believe that a brute-force cracking tool for an environment like
NetWare is probably impractical. Nevertheless, some crackers swear by it.
IPXCntrl
IPXCntrl is a sophisticated utility, written by Jay Hackney, that allows remote
control of any compromised machine. For lack of a better description, the package
comes with a client and a server, although these are not a client and server in the
traditional sense. These are called the master and the minion, respectively. The
master drives the minion over remote lines. In other words, this software persuades
the network that keystrokes are coming from minion when they are actually coming
from master. It runs as a TSR (terminate and stay resident) program.
Crack
Crack is a password cracker for the Novell NetWare platform. This password cracker
is wordlist based (much like its UNIX-based namesake). It's a comprehensive tool
that does not require NetWare to be on the local disk in order to operate effectively.
It's a good tool for testing your passwords.
Cross Reference: Crack is available at
http://www.mechnet.liv.ac.uk/~roy/freeware/crack.html.
Snoop
Snoop is quite something. It gathers information about processes and the shell.
It's an excellent tool for collecting information about each individual workstation
and for watching the shell.
Cross Reference: Snoop is available at
http://www.shareware.com/code/engine/File?archive=novell-netwire&file=napi%2fcltsdk1e%2fsnoop%2eexe&size=102625
.
LA
LA is identical to IPXCntrl in purpose, but not nearly so well designed. It is
a simple utility, though, and works well.
Chknull
Chknull, by an unknown author, checks for null passwords and is to be used primarily
as a tool to strengthen security by alerting the supervisor to possible problems
stemming from such null passwords. However, like all these utilities, this is dangerous
in the hands of a cracker.
Novelbfh.exe
Novelbfh.exe is a brute-force password cracker for login. It keeps guessing combinations
of letters until it finally cracks the password.
The problem with these utilities, of course, is that they take an enormous amount
of time. Moreover, if the supervisor has enabled intruder detection, an intruder
detection lockout (IDL) will occur. IDL works by setting a "threshold,"
which is the number of times that a user can forward incorrect login attempts. Added
to this value is the Bad Login Count Retention Time. This time period (which defaults
to 30 minutes) is the block of time during which bad login attempts are applied to
the IDL scheme. So if an incorrect login is received at 1:00 p.m., monitoring of
subsequent logins on that account (relative to IDL) will continue to look for additional
bad logins until 1:30 p.m. To compound this, the supervisor can also specify the
length of time that the account will remain locked out. This value defaults to 15
minutes. IDL is therefore a very viable way of preventing brute-force attacks. If
these options are enabled, a brute-force cracker is worthless against the Novell
NetWare platform.
TIP: If you are new to security and have
been handed a Novell NetWare network, you will want to enable IDL if it hasn't already
been. Also, you should check-- at least twice a week--the audit log generated from
that process. (The events are logged to a file.) You can access that log (which is
really the equivalent of /var/adm/messages and syslog in UNIX)
by changing the directory to SYS:SYSTEM and entering the command PAUDIT.
Denial of Service
As I have pointed out at several stages in this book, the denial-of-service attack
is not much of an issue. The average denial-of-service attack typically disables
one network service. In the worst case, such an attack may force a reboot or freeze
a server. These actions remain more an embarrassment to the programmers who coded
the affected application than they do a critical security issue for the target. Nevertheless,
such activity can be irritating.
One reported way to cause a denial-of-service attack on NetWare (3.x and
possibly 4.x) is to capture a network printer and attempt to print an absurdly
large file. This overflows the SYS volume and causes the machine to crash.
Naturally, this would require not only physical access to an internal machine, but
also an account there. However, in large organizations, it is entirely possible that
malicious individuals may exist--individuals who may be secretly working for a competitor
or just plain crackers who love to see a system go down. This is a relatively low-priority
attack, as the machine can easily be rebooted and the problem solved.
FTP Vulnerability to Denial-of-Service Attacks
Certain versions of NetWare's FTP server are vulnerable to a denial-of-service
attack. (This has been confirmed by Internet security systems and Novell, as well.
Novell has issued a patch.) Apparently, when a brute-force attack is mounted against
the anonymous FTP server, this activity causes an overflow and a memory leak. This
leak ultimately consumes the remaining memory and the machine will freeze, failing
to respond further.
A brute-force attack in this case is a program that automates the process of trying
hundreds (or sometimes thousands) of passwords on a given server.
Login Protocol of NetWare 3.12 Flawed
In October 1996, Greg Miller posted an advisory and an accompanying paper to the
Net demonstrating a successful attack against the login procedure in Novell 3.12.
The procedure involved an interruption of the login process in real-time.
Cross Reference: A complete explanation
of Miller's process is available at http://geek-girl.com/bugtraq/1996_3/0530.html.
The attack technique is a form of spoofing and is dependent on many things. (In
other words, this is neither an easily implemented nor widely known technique.) The
following are the limitations on the attack:
- The attacker must be able to view, monitor, or somehow anticipate the login attempts
of legitimate users.
- The targeted server must allow unsigned packets.
The process works as follows: The attacker sends a request for a login key. The
server promptly responds with this key. The attacker then waits for a legitimate
user to issue a similar request. When such a request occurs, and before the server
can respond to the legitimate user, the attacker sends his login key to the legitimate
user. The legitimate user's machine takes the bogus key as authentic and therefore
ignores any further keys. (Thus, the legitimate user's remaining authentication will
be based on an invalid key.) What remains is for the attacker to watch the rest of
the exchange between the legitimate user and the server. The legitimate user's machine
calculates a value based on a user ID sent from the server. It is this value that
the attacker wants. The attacker can now log in as the legitimate user. (And of course,
the legitimate user is now denied access.) It is an extraordinary hole. Duplication
of this procedure in the void would be extremely difficult but not impossible. I
think that at a minimum, the attacker would have to be familiar with the targeted
server and the habits of those who routinely use it. Nevertheless, it is a hole and
one that does allow a remote individual to gain access.
These types of exploits for NetWare are rare.
Login Script Vulnerability
Under Novell 2.x and 3.x, if the supervisor fails to define a login
script, a potential hole exists because crackers can place a login script into the
supervisor's mail directory. It is unclear exactly what level of compromise this
might lead to. Certainly, the supervisor's password can be captured. Furthermore,
the number of parameters available to the author of a login script are many. In practice,
it seems absurd that a supervisor would fail to create a login script, but I have
seen some use the default. These are usually first-time administrators. This problem
has been remedied in later versions of the software.
One thing that you will readily notice about the Novell NetWare platform is that
most of the methods used to crack it require some local, physical access. In all
other respects, Novell NetWare is a strong platform, primarily because of its advanced
access controls.
However, my earlier point is still relevant. NetWare has not yet run the gauntlet.
As more NetWare servers are erected on the Net, we may see a shift.
Utilities
The following sections describe a few utilities that are of some help in either
securing your server or managing your network.
WSetPass 1.55
WSetPass 1.55 was designed by Nick Payne for system administrators to manage user
passwords over multiple servers. It works for NetWare 2, 3, and 4.x passwords
and runs on Windows 3.1x, Windows 95, and Windows NT 4.0. It allows you to
mix and match servers and sync the password update across all servers in the network.
Cross Reference: WSetPass 1.55 is available
at http://ourworld.compuserve.com/homepages/nick_payne/wsetpass.zip.
WnSyscon 0.95
WnSyscon 0.95 is SYSCON for Windows, really. It allows you to administer your
Novell NetWare Server from a Windows platform. You can perform all the same basic
operations that you would if you were at the file server console. The author of WnSyscon
0.95 is unknown.
Cross Reference: WnSyscon 0.95 is available
at ftp://ftp.novell.com/pub/nwc-online/
utilities/wnscn095.zip.
BindView EMS
BindView EMS is a powerful network management and security tool. This tool can
effectively analyze your network for security holes and identify problem areas, disk
usage, user rights, and even user rights inheritance. You can also examine the state
of objects, including all attributes on files. This is a substantial package for
network management and it is a commercial product.
Cross Reference: BindView EMS is available
at http://www.bindview.com:80/products/nosadmin3.html.
SecureConsole
SecureConsole is a security product from Australia that adds significant enhancements
to your security. It is designed to protect the file console and adds greater access
control and some deep auditing.
Cross Reference: SecureConsole is available
at http://www.serversystems.com/secure.htm.
GETEQUIV.EXE
GETEQUIV.EXE is a security-related application that analyzes privilege equivalencies
between users on the Net. (Wouldn't you be surprised to find that someone has supervisor
equivalency?) It's a solid tool and one that quickly sums up security levels.
Cross Reference: GETEQUIV.EXE is available
at http://mft.ucs.ed.ac.uk/novell/techsup/freedos.htm.
Summary
Although few people speak of Novell in the present tense, Novell has in fact made
innovations that are relevant to the Internet. Indeed, Novell is still in the running,
and Web servers and other Internet applications continue to be written for the Novell
platform.
Resources
Here you will find resources related to Novell NetWare security. Some are books,
some are articles, some are Web sites, and some are newsgroups. You will find that
in the past two years, many more sources have cropped up. This is especially so now
that NetWare sports its own Web server package, which has strong security. It stands
in a similar light to the Webstar server, primarily because UNIX is where most of
the security research has been done by crackers.
Publications
Following is a list of publications on NetWare security. You will notice that
the majority are older. Newer treatments tend to focus on safely integrating NetWare
networks into other systems. (As I mentioned, many legacy networks are now being
migrated to the Internet, especially those with databases.) This is by no means an
exhaustive list, but it will certainly help the new system administrator get started.
Books
NetWare Security. William Steen. New Riders Publishing. 1996.
Novell's Guide to Integrating NetWare and TCP/IP. Drew Heywood. Novell
Press/IDG Books Worldwide. 1996.
NetWare Unleashed (Second Edition). Rick Sant'Angelo. Sams Publishing.
1995.
A Guide to NetWare for UNIX. Cathy Gunn. Prentice Hall. 1995.
NetWare LAN Management ToolKit. Rick Segal. Sams Publishing. 1992.
The Complete Guide to NetWare 4.1. James E. Gaskin. Sybex Publications.
1995.
Building Intranets on NT, NetWare, Solaris: An Administrator's Guide. Tom
Rasmussen and Morgan Stern. Sybex. 1997.
The NetWare to Internet Connection. Morgan Stern. Sybex. 1996.
NetWare to Internet Gateways. James E. Gaskin. Prentice Hall Computer Books.
1996.
Novell's Guide to NetWare LAN Analysis. Dan E. Hakes and Laura Chappell.
Sybex. 1994.
Novell's Four Principles of NDS. Jeff Hughes. IDG Books Worldwide. 1996.
NetWare Web Development. Peter Kuo. Sams Publishing. 1996.
Magazines and Journals
The NetWare Connection.
Inside NetWare.
Institute of Management and Administration.
Usenet Newsgroups
The following is a list of NetWare-related Usenet newsgroups:
© Copyright, Macmillan Computer Publishing. All
rights reserved.
| 
