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:
- 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.
Replica Sufficiency
One of the most attractive aspects of using NDS is the ability to partition--and make redundant--the root database and its counterparts. To accomplish the highest degree of redundancy, Novell recommends having at least three replicas of any given partition of NDS, but you're not limited to using NetWare for these copies. With Novell's eDirectory, your replicas can exist even on other platforms (for more information, see "The Cross-Platform Challenge").
DS Version
Directory Services for NetWare is represented by the ds.nlm module and several supporting modules. Because of major differences in each version, adherence to a common standard becomes a must. Because Directory Services is the most critical component to NetWare, many administrators are hesitant to upgrade these modules. Failure to do so can result in other problems, including those encountered when you try to incorporate multiple versions of NetWare into the same tree (see TID No. 10015538 on Novell's Web site). We can't stress enough, however, that you must perform extensive testing on new modules prior to implementation, as there have been instances where Directory Services contained hazardous bugs and been removed from the Web site just days after the general release.
NCP Security
Novell NetWare Core Protocol (NCP) is a proprietary protocol NetWare uses to communicate with clients. Under certain conditions, NCP packets can be falsified, given adequate knowledge of other parties on the network. Several tools to aid in this process are in the public domain. The most common and extensive of these tools is Pandora (see www.nmrc.org), which is a utility developed exclusively for exploiting Novell NetWare servers.
NCP exploits can be prevented with the following settings:
- Reject NCP packets with bad lengths.
- Reject NCP packets with bad components.
- Set NCP packet signature to Level 3 on the client and server.
One of the most significant aspects of a complete security policy is auditing. Novell's AuditCon tool can monitor all aspects of activity in NetWare--from file systems to NDS--and should be used. Several functions that must be audited include supervisor authentication, NDS container changes, login script changes and user-policy compliance.
In addition to the tools provided by Novell, some third-party vendors provide utilities for auditing NetWare, both from an IDS (intrusion-detection system) point of view and from a policy-compliance point of view (see "Software for Securing NetWare").
User-Policy Compliance
You must take user policy into consideration during the planning phase of a NetWare implementation. Below is a common list of components that must be considered carefully when designing a company's user policy. Remember that balance is a necessity--too strict a policy will lead to noncompliance, while too lenient a policy will lead to security breaches.
- One means by which an attack can be thwarted is by limiting the number sessions that can be active under an individual account. By preventing an account from being logged in multiple times, attacks during business hours can be hampered, at least while the valid user is logged in. It should be noted that some versions of Directory Services had trouble releasing connections after logout, leaving two options: Add additional concurrent connections or deal with constant phone calls. Later revisions of Directory Services have fixed this issue, and it doesn't appear to be a problem with NetWare 5.x and Directory Services 8.
- By limiting the times when particular accounts can be accessed, you can limit attacks on those accounts during the hours specified. Typically, this would be during normal working hours.
- Intruder detection incorporates multiple aspects of security that must be considered, including incorrect login count and account reset time. Incorrect login count defines the number of times authentication can be attempted on a given account before that account is locked out. After this, the account must be reset automatically or by an administrator. This value should be set very low. Account reset time defines how long an account will remain locked before it is automatically reset. Under most circumstances, you should require the account reset time to be set very high, forcing administrative intervention and validation.
- User templates allow administrators to build user accounts based on corporate policy and, provided they are used, aid in the adherence to such a policy. Typically, in the absence of user templates, human error prevails and key settings are often omitted--especially where time is constrained. Use organizational roles and user templates as they are intended within NDS to enforce client compliancy.
- Station restrictions let administrators restrict account authentication to a particular network device. This prevents invalid attempts for authentication from workstations not belonging to the user in question. This method does require additional workload and maintenance for administration, but it provides for a very high degree of security. This is a great feature in locations where user stations are static; in mobile environments, however, it becomes much more difficult to maintain.
- Account expirations allow administrators to set time limits on user accounts. This setting is especially useful for temporary accounts. In the absence of constant maintenance, a temporary account will expire at a predefined time.
- One of the most commonly used, and least glamorous, methods of entry an attacker will use is simply guessing passwords. Shorter passwords are more vulnerable to this type of attack. Typically, you should set minimum password lengths of five to six characters. Other alternatives to using passwords can also be investigated (see "Authentication at Its Finest").
- The setting to force password changes determines how many days must elapse before a password change is enforced. At that time, a user has a number of login attempts--determined by the grace-logins feature--to comply before an account lockout. Upon an account lockout, reinstatement can be obtained only through administrative intervention. Typically, 60 days to 90 days is recommended for this feature.
- The grace-logins setting defines how many times a user can log into the system once a password change has been initiated. If too high, this setting poses a security risk in that it undermines the force password change. Therefore, keep this value low.
- Require unique password forces a user to have different passwords upon a forced password change. Password history is kept for the previous eight changes. This is the default setting and should be kept that way.
During the installation of Novell's Web services, Novell has allowed several sample scripts and application handlers to be placed onto the SYS volume. These scripts, coupled with application handlers such as NetBasic, PERL and Sewse, could pose a security risk should an exploit ever be discovered. Care should be taken to remove these scripts and either move or remove the application handlers so they don't become a problem in the future.
It is generally not recommended that FTP be used in a corporate environment. However, if FTP must be used, keep FTP data on a separate volume of its own. Do not keep it on SYS.
A Word on C2-Level Security
The requirements for A-, B-, C- and D-level secure products are outlined in the Trusted Computer System Evaluation Criteria (TCSEC), published by the National Computer Security Center (NCSC). This publication is often referred to as the Orange Book and is part of the National Security Agency's security rainbow series. The security policy in C2 is known as Discretionary Access Control (DAC). A system is not certified C2 unless it is at a set state reviewed and approved by the NSA. C2-level policy adherence, however, does provide those with the need for a very high degree of security a good guideline to follow.
Not only has Novell declined to apply for C2 review of NetWare 5.x, but it hasn't even constructed a document detailing how to make NetWare 5.x C2 compliant. Are we to conclude that there is no longer a public demand for security at this level? Or maybe Novell just did not think it could pass. You be the judge.
Novell Certificate Authority
NetWare 5.0 not only introduced the ability to use dual-key cryptography for secure communications between clients and servers, but gave NetWare administrators the ability to house their own NDS-integrated CA (certificate authority). Novell Certificate Server 2.0 supports S/MIME (Secure MIME) e-mail for Microsoft Outlook 98/2000, Novell GroupWise 5.5 (enhancement pack required) and Netscape Messenger. Browsers supported include Microsoft Internet Explorer 4.x and 5.x, and Netscape Navigator 4.x.
Do Your Homework
You should keep up to date with current patches, releases, exploits, bugs and security discussions. Regularly check a variety of sources to stay on top of current issues; a few useful Web sites are:
1) archives.neohapsis.com/
2) www.nmrc.org
3) www.securityfocus.org
4) www.packetstorm.securify.com
5) support.novell.com/
Following the Pack
The most prevalent reason operating systems are so difficult to secure is the fact that they attempt to provide too much. Web, DNS, DHCP, firewalling, file and print sharing, and software distribution provide a lot of alternatives, but they always increase the difficulty in maintaining security. Until recently, securing Novell NetWare has been a (relatively) simple matter of knowing the rules. However, in an attempt to keep up with a growing trend of multipurpose operating systems, Novell has begun an ominous journey down the same path.
Time will tell whether Novell has done its homework and learned from others' mistakes pertaining to Web server implementations and the like. Until then, we will continue to keep our file and print services on separate servers from other Novell application offerings.
A discussion about Novell NetWare security would be incomplete without mentioning NMAS (Novell Modular Authentication Services). There are two reasons why a company would want to implement this technology: Passwords aren't strong enough and alternatives are required, or management wants to restrict access to certain data based on "sequence" and "clearance" levels.
The sequence defines what method or methods of authentication must be satisfied before authentication is granted. Many sequences are available: Biometric, token, X.509, password and smart cards are but a few. Novell coins the collective of these sequences as "something we are," "something we have" and "something we know." Within the parameters of a sequence, users can then decide upon a given clearance. A user's clearance determines what authentication will be
granted him or her to individual NSS volumes, based on predefined policies. While currently only NSS (Novell Storage Services) volumes can be restricted with NMAS, more granularity is expected in the future, giving the same type of graded security to all NDS objects.
We tested one biometric device, one token-based device, an X.509 key and a simple NDS password. Identix sent us a demo of its MT Digit fingerprint reader, and Vasco Data Security sent us a demo of the Digipass 300 challenge-response token device. Both of these devices proved formidable for securing authentication. Novell provides other methods of authentication with the NMAS product, of which we tested an X.509 certificate with our private key being accessed from disk and a simple NDS password. Individually and in combinations, authentication was quick and painless.
For a list of Novell partners coding for the NMAS product, see www.novell.com/products/nmas/partners/.