We'll look at how to lock down a NetWare environment. It should be noted that we'll cover only Novell NetWare 5.x; other Novell products, such as BorderManager and GroupWise, pose security implications of their own and should be looked at with similar scrutiny before implementation.

NDS File and Object Security

Since every implementation of NDS is going to be different, administrators must have a firm grasp of the rules that apply to all NDS objects. With all these guidelines understood, and a few other rules of thumb, a NetWare administrator should be able to keep NDS secure--at least from an object perspective. Below are some suggestions to follow when securing the objects in an NDS tree.

The Admin object, by default, is given carte blanche trustee access to all objects in the NDS tree and thus will always be a target for attack. Taking special precautions to secure this user is of the utmost importance. Because all environments must be approached differently, here are a couple of basic concepts:

• Rename the Admin object using the standard naming conventions and place it in a typical user container.

• Give administrators the trustee rights necessary to complete their job--and nothing more.

• Use the newly renamed admin account only if absolutely necessary.

• Create another object named Admin, lock it out and audit it. Then check the audit logs regularly. This might sound obvious, but you'd be amazed at how infrequently it's actually done.

Coupled with the default attributes granted Public, to the root object--and the utility CX--a would-be attacker can view attributes about your tree structure, which could then be used as a stepping stone to obtaining even greater access. The effectiveness of this utility can be limited, however, by restricting read access from Public at the root level. You should take caution when making major rights changes, as certain applications may require this access.

Physical Security

An important aspect of physical security includes keeping all network systems in secure locations. Also, do not showcase your NOC (Network Operating Center) behind clear glass walls. Attackers feed on information, and if they're given enough of it, a breach is only a matter of time. And make sure both power and air-conditioning systems are redundant, as a loss of either can result in a denial of service to users.

Console Security

When not in use, server consoles should be locked. The utility Scrsaver.nlm, introduced with NetWare 5.0, provides a new method to lock the server console. This utility gives administrators more flexibility for controlling when a console locks and, unlike older versions of Console Lock, uses NDS for its security--what a concept! To unlock the console, you must supply an NDS user name and password. Scrsaver then verifies that the user object has write rights to the ACL (access control list) attribute of that particular server and, if so, unlocks the console. Specific instructions on its use can be found at Novell's Web site by referencing TID (Technical Information Document) No. 2941164.

Remote Control

While any network administrator can list several reasons why remote control of a server is necessary, the method by which this is accomplished must always be seriously considered. Novell NetWare 5.x maintains the legacy application Rconsole but also introduces a Java-based utility for remotely administrating servers--RconsolJ. The applications continue to share the same faults, however: They operate over nonencrypted connections.

The security implications of these software packages are extremely severe, because console access can mean all the difference to an attacker. A wide array of tools is publicly available both to create accounts with supervisory access and to change current accounts to have supervisory access. Almost all require console access, however.

Rconsole and RconsoleJ pose significant risk for two reasons:

• For remote-console modules to execute on start-up, passwords must be entered into a text file. While Novell offers a means of encrypting these passwords, administrators often enter them in clear text, leaving a perfect target for attackers. Care should be taken to always encrypt remote-console passwords. This may not provide the best security, but it beats the alternative.

• Rconsole and RconsolJ connections are insecure, and much is transferred as clear text. An attacker capturing packets over the network can gain knowledge otherwise unobtainable.

  If remote control is necessary, two options are available:

  1. Investigate and implement remote-control software that communicates over a secure connection (see "Software for Securing NetWare").

  2. Use Novell NetWare's built-in applications, but only under the following conditions:

  • Do not use hubs. Rather, use properly configured switches for network connections. This helps to prevent packet sniffing.

  • Protect the remote password and change it regularly.

  • Make sure the console is relocked after use.

  • Encrypt the password and never use the unencrypted version again.

  • Don't call the remote session from a file on the local DOS partition. A simple reboot provides an attacker with the file.

To limit an attacker's effectiveness if console access is achieved, you can use the Secure Console command. When executed, Secure Console enhances security by preventing any modules not locating in SYS:/SYSTEM or C:\NWSERVER from loading. It also prevents keyboard entry into the system debugger and denies server date and time changes.

Bindery Context

For years, there have been applications publicly available for compromising Novell's bindery. These tools have the capacity of spoofing and sniffing a bindery connection. They can let an attacker falsify a network connection to the server and make the server think requests are coming from an administrator's workstation. With these tools, attackers can also change standard user privileges to those of a network supervisor or retrieve all the passwords on the network.

Often, applications or services will require bindery context to be enabled, thereby leaving no alternatives. Short of replacing those applications or services with NDS-compliant applications, attacks can be prevented by enabling those measures mentioned in the "NCP Security" section below. If bindery context is not necessary, those contexts should be removed.