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.

Kevin Novak is a Chicago-based consultant. Send him your comments on this article at knovak@neohapsis.com.