Securing Your NetWare Environment
October 16, 2000
By Kevin Novak
As the average network administrator sleeps, nightmares of hardware failures and server abends compete for time against sweet dreams of what some technicians call nirvana, and others call a pipe dream--finding a network operating system that they can call secure.
Over the years, Novell's NetWare has acquired the reputation of being one of the most secure operating systems on the market. While other vendors release network operating systems that begin insecure and require a magician to lock down, Novell has always held the viewpoint that an operating system should begin secure, with resource rights granted only on a need-by-need basis. Is NetWare that nirvana we're all dreaming of? Novell would have you think so, but there is a lot more to securing NetWare than many would imagine.
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:
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.
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.
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.
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:
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.
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.
|PAGE: 1 I 2 I 3 I NEXT PAGE|