|
|
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.
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:ETC\SERVICES. 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:ETC\SERVICES 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:
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:
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 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:
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 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.
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.
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.
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 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 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/.
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 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 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 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 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 is identical to IPXCntrl in purpose, but not nearly so well designed. It is a simple utility, though, and works well.
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 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.
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.
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.
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 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.
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.
The following sections describe a few utilities that are of some help in either securing your server or managing your network.
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 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 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 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 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.
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.
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.
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.
The following is a list of NetWare-related Usenet newsgroups:
© Copyright, Macmillan Computer Publishing. All rights reserved.