Novell is now a part of Micro Focus

Netware Security: Closing the Doors to Hackers

Articles and Tips: article

Mark Foust
Consultant
Novell Consulting, Atlanta
mailto:mfoust@novell.com

01 Jun 2000


Securing corporate information is one of the essential duties of every network administrator and consultant. Yet protecting network data is an increasingly difficult challenge. Almost every day we read about hackers exploiting some new security hole or unleashing some new virus on desktop operating systems, e-mail programs, office applications, network operating systems, or the Internet. It seems hacking is a passion for many people. Some are in it just out of curiosity or for the thrill of breaking in to "secure" sites. Others are driven by more sinister motives, actively seeking to steal or destroy valuable data.

While the threat of outside hackers is real, most organizations face a greater threat from within. In a 1999 study on computer crime, the FBI concluded that 55% of security breaches are internal, costing an average of $142,000 per incident. In addition to securing your data from intentional hackers, you must protect against the accidental deleter as well. I am continually amazed at how many customers simply grant everyone all rights to the file system, then yell and scream every time they have problems with users inadvertently deleting information from the server.

NetWare is well known for its extensive security features. However, as with most other operating systems, few of NetWare's security features are enabled by default when you install the OS. Many novice administrators--and even some veterans--are unaware of which options to enable to protect against various types of attacks. Since no organization can afford to lose valuable data, it is essential to know what security doors to close to the curiosity seeker, the computer hacker, and the accidental deleter.

To that end, this AppNote provides a compilation of information relating to NetWare security, gleaned not only from available documentation and other references, but also from visiting all of the known hacking sites on the Internet. It presents a number of recommendations to help you protect your network investment.

NetWare's Security Track Record

NetWare has a great security track record, especially in its more mature releases. If you search for NetWare hacks on the Internet, you will see mostly old NetWare 3.x hacks and utilities. In my research, I've found significantly fewer hacks available for NetWare than for other operating systems.

Security has always been a high priority in the NetWare operating system's feature set. NetWare 2.x and 3.x set the standard for access control with file system rights that can be set on directories and files. The arrival of Novell Directory Services (NDS) in NetWare 4.x introduced a whole new layer of security with strongerauthentication and NDS object/property rights. NetWare 5 offers additional security features to provide even greater control over who can access the network. (These new features are discussed later in this AppNote.)

Committing to a Security Policy

With its excellent security model, NetWare is a great foundation for building a secure network. But just having the best tools does not necessarily make you the best mechanic. You must learn about and use the tools that NetWare provides to make your implementation secure.

Even the strongest security features are ineffectual without a corporate-wide commitment to adhere to established security policies. I often see companies spending millions of dollars on security-related hardware and software, but no one from upper management will enforce a security policy. What good does it do to have a stringentpassword policy if users are seldom, if ever, reprimanded for posting their passwords on their monitors?

The sections in this AppNote provide a summary of security concepts, along with my recommendations for closing potential security holes in each area. Topics covered include:

  • Updated security in NetWare 5

  • Physical security

  • Virus protection

  • File system security

  • NDS security

  • Password management

  • Server security

  • Workstation security

  • Auditing

  • Miscellaneous security tips

Updated Security Features in NetWare 5

This section lists the new security features in NetWare 5. These enhancements are in addition to the Public Key Infrastructure Services (PKIS), the enhanced cryptography services (NICI), the integration of Secure Sockets Layer (SSL) 3.0 and LDAP v3 into NDS, and the Novell Modular Authentication Service (NMAS) which includes support forbiometrics, smart cards, and other secure authentication services.

More Granular Controls Within NDS

To better control who can perform specific administrative functions within the NDS environment, NetWare 5 offers two new features:

  • Inherited Rights checkbox within the NetWare Administrator (NWAdmin) utility to allow (default) or disallow (by unchecking the box) NDS permissions to flow down the OU.

  • A password management feature that provides a specific attribute within an OU allowing an Admin-assigned User object the ability to change user passwords, without granting full permissions to User object attributes.

    Note: You can do password management in mixed NetWare 4.x and 5.x environments, but your primary connection must be to a NetWare 5 server with a replica on it. Otherwise, the Change Password button may be grayed out.

Security Equivalence List

The new "Security Equal to Me" tab within NWAdmin lists all objects that are equivalent to a given object. This help the system administrator knows who is granted effective rights to any object within the NDS environment.

Screen Saver for Servers

In place of the Lock Console option in MONITOR.NLM in NetWare 4.x, NetWare 5 comes with a screen saver (SCRSAVER.NLM) with which you can require NDS authentication to obtain access to the server console. In addition, access to the server console can be limited based on the system administrator's access rights. This can be helpful inseparating duties between various types of system administrators, such as NDS administrators and backup operators.

You can either place the SCRSAVER command in the AUTOEXEC.NCF file or load it manually. When loading SCRSAVER as a console command, you can add any of the following options.


Option

Usage

ACTIVATE

Overrides the delay interval and activates the screen saver immediately. Also overrides both DISABLE and ENABLE modes. This means that if you enter ACTIVATE when the screen saver has been disabled, the DISABLE mode is changed to ENABLE so that the screen saver can appear.

AUTO CLEAR DELAY

Sets the number of seconds to wait before clearing the unlock dialog box. The range is 1 to 300, and the default is 60 (one minute).

DELAY

Sets the number of seconds to wait before activating the screen saver. The range is 1 to 7000 and the default is 600 (10 minutes).

DISABLE

Disables the screen saver, thereby preventing it from activating and saving the console display.

DISABLE AUTO CLEAR

Disables the automatic clearing of the unlock dialog box. When this command is executed, the unlock dialog box remains on the screen until it is cleared by user input.

DISABLE LOCK

Disables the console lock. When the locking feature is disabled, you can retrieve the console display without a username or password simply by pressing any key.

ENABLE

Enables the screen saver. When enabled, the screen saver displays after the keyboard has been inactive for the number of seconds specified in the DELAY option.

ENABLE AUTO CLEAR

Enables automatic clearing of the unlock dialog box after the number of seconds of keyboard inactivity specified in the AUTO CLEAR DELAY option.

ENABLE LOCK

Enables the console locking feature. When enabled, the screen saver requires the username and password before restoring the console display. The User object must have appropriate rights.

HELP

Displays information about command options and their use.

NO PASSWORD

Allows you to unlock the console without requiring a password. This option is provided mainly as a way to unlock the console in the event that NDS becomes unavailable. You must set this option when you load SCRSAVER. Otherwise, the console cannot be unlocked when NDS is unavailable. (This option is not recommended foruse in secure environments.)

STATUS

Displays the current status of screen saver features and command options.

If you load SCRSAVER with no parameters, it defaults the following settings:

  • AUTO CLEAR DELAY=60

  • DELAY=600

  • ENABLE

  • ENABLE AUTO CLEAR

  • ENABLE LOCK

Netscape Enterprise Server Security Features

The NetWare-optimized Web server that comes with NetWare 5 also has new security features. These include:

  • The ability to restrict access to information stored on the server via NDS authentication.

  • The ability to encrypt communications between the server and a Web client.

  • The ability to allow access to documents, directories, and applications based on specific user name/password pairs, groups (collections of users), IP addresses, host names, or domain names.

  • Support for client authentication to restrict access based on client certificates.

  • The incorporation of Secure Socket Layer (SSL) 3.0.

  • Centralized management due to the integration of NDS and LDAP directories.

Recommendation for NetWare OS

My first recommendation for existing NetWare 3.x and 4.x customers is to upgrade to NetWare 5.x and take advantage of these enhanced security features.

Physical Security

Every security policy should start with protecting the server hardware from unauthorized access. That means physically locking away your servers in a secure room. No server is safe when a hacker has direct access to its console. If someone has access to a server, they have free reign to load NLMs from a diskette, switch the server into debug mode, remove NDS from the server, shut down the server, or even remove the server's hard drives.

The screen saver in NetWare 5 (described above) provides some measure of protection since it requires NDS authentication. But according to some hacker sites, there are still possible holes. The best policy is to strictly limit physical access to servers. If someone has physical access to the server, all security bets are off.

I have seen many customer sites in which users have rogue servers sitting under their desks. This is not a problem if these servers are used solely for testing purposes. However, such servers should exist in a different tree and on a separate network from the production environment.

Virus Protection

Destructive, rapidly-spreading computer viruses have been in the news a lot lately. I have therefore compiled the following recommendations for configuring anti-virus software for network environments.

  • Configure the virus software to immediately send virus notification(s) to the network administrator in addition to the user.

  • Enable the virus expiration warnings to alert you when signatures are outdated.

  • Set the server's virus scanning software to scan both incoming and outgoing files.

  • Include all file types when scanning (.EXE, .DLL, .ZIP, and so on).

  • Consider using a software package that allows files to be quarantined. This prevents users from accessing the infected files and perpetuating the virus.

  • If possible, do not give users the option to cancel the virus check or virus repair.

  • Use Novell's ZENworks for Desktops to mass-distribute virus signature updates. With ZENworks, you can "push" these updates to all workstations without user intervention.

  • Update your write-protected emergency boot diskette whenever new signature files are received.

  • Scan all incoming and outgoing e-mail and attachments.

  • Discourage users from downloading non-work-related e-mail attachments.

  • Configure your e-mail servers to filter and eliminate unsolicited junk e-mail that could contain a virus or malicious code.

  • Encourage users to install an anti-virus software package on their home computers. Computer Associates, one of the top anti-virus software developers, offers their InoculateIT product free to home users. (Visit http://antivirus.cai.comfor more information.)

Virus Signature Updates

It is critical that you keep your virus signatures up-to-date on servers as well as workstations. Here are some anti-virus software vendors that offer NetWare- compatible products (not intended to be an exhaustive list):

File System Security

The NetWare file system has a granular security model that allows you to protect certain directories or files from prying eyes or from accidental deletion. This security is managed through NetWare's FILER, NWAdmin, and ConsoleOne utilities.

In my dealings with customers, I find that file system security is often misunderstood or overlooked completely. For example, one of my clients insisted that the CIO be granted Supervisor rights to the entire file system simply because he was the CIO. Well, the CIO was working late one evening and needed to delete some files. Somehow he managed to delete everything on SYS volume. Fortunately, we were able to restore the data thanks to NetWare's SALVAGE utility (which is now part of FILER). But any time you give someone the unrestrained ability to delete files, you are flirting with disaster.

Another client kept paging me because the server was displaying licensing error messages and users were not able to log in. In diagnosing the problem, I looked at the server from an end-user point of view and realized that the users had too many rights to the SYS volume. When I told the client that I suspected someone was deleting the license files, they replied, "Impossible! Our users are not smart enough to do that." (How many times have you heard that?) I created an Inherited Rights Filter (IRF) in the appropriate directories to block the Erase right from being inherited. Amazingly, the license/login problems went away.

File System Trustee Rights

File system security for directories and files is implemented by assigning combinations of access rights to users (thereafter known as "trustees").


Trustee Right

Description

Supervisor (S)

Allows a user to do anything allowed by all the other access rights

Read (R)

Allows a user to view the contents of the directory or execute a file

Write (W)

Allows a user to view and modify the contents of a file

Create (C)

Allows a user to create new files (or salvage files that have been deleted)

Erase (E)

Allows a user to delete a directory, or to delete or overwrite a file

Modify (M)

Allows a user to rename a file/directory or change its attributes

File Scan (F)

Allows a user to view the contents of a directory without being able to view the contents of any of the files within it

Access Control (A)

Allows a user to change trustee assignments and IRFs, and to grant access rights to other users

Note: Users rarely need Access Control rights to any directory other than their home directory, as this is similar to giving them Supervisor rights. Exceptions might include junior administrators or department heads who need to create shared network directories.

Default File System Rights

By default, NetWare users receive the following file system rights:

  • All users have RWCEMFA (all possible rights except Supervisor) to their own home directories, which are created along with the NDS User objects.

  • Users in the same container as the SYS Volume object receive RF (Read and File Scan) rights to volume SYS so they can log in.

    Note: When you install or upgrade a server, the Admin account you use is given NDS Supervisor rights to the NDS Server object, which in turn grants file system Supervisor rights to all files on that server. This is the only time that NDS and file system rights overlap.

Inheritance and the IRF

File system rights "flow down" or are inherited in lower levels of the directory structure. In other words, a user with maximum rights to his or her home directory will automatically have maximum rights to all subdirectories created beneath that directory. Similarly, if you grant a user specific rights to a certain directory, that user will have those same rights in all subdirectories-- unless you take steps to change or block inheritance, as explained next.

Although seldom used, NetWare's Inherited Rights Filter (IRF) allows you to fine tune your security to prevent unwanted inheritance of trustee rights. Setting an IRF is one way to keep rights from flowing down the directory structure. The IRF will filter out the rights you specify and prevent them from being inherited in lower directories. The one exception is the Supervisor right, which can never be blocked by an IRF.

Note: Be careful when using IRFs, as NetWare doesn't provide a reporting mechanism to show what IRFs have been set. Without a third-party utility to show IRFs, you must keep track of all IRFs you and any previous Admins have used throughout the tree.

The more common method for changing inheritance is to explicitly assign different rights for a particular file or directory, which overrides the default inheritance within the file system. Of course, the new rights you assign at that level will flow down to lower directories until filtered out or explicitly changed again.

Recommendations for Trustee Rights Security

In most organizations, users have no business accessing NetWare utility directories other than SYS:PUBLIC (which they have R and F rights to by default).

An easy way to test your current file system security is to log in as a user with default rights and then browse the network. Check for possible security risks by answering these questions:

  • Can you see the SYS:SYSTEM directory or the SYS:ETC directory?

  • Can you see the directories from which administrative utilities such as NWAdmin and NDS Manager are run?

  • Can you browse the entire NDS tree?

If you find that users have more rights than they need, check their trustee assignments and make necessary changes. A file access security policy should be based on minimums. The following table lists the minimum required rights to perform specific tasks..


Task

Minimum Rights Required

Open and read a file

Read

See a filename

File Scan

Search a directory for files

File Scan

Open and write to an existing file

Write, Create, Erase, Modify

Execute a .EXE file

Read, File Scan

Create and write to a file (but not view it)

Create

Copy files from a directory

Read, File Scan

Copy files to a directory

Write, Create, File Scan

Make a new directory

Create

Delete a file

Erase

Salvage deleted fiels

Read, File Scan on the files; Create on the directory

Change directory or file attributes

Modify

Rename a file or directorry

Modify

Change the IRF

Access Control

Change trustee assignments

Access Control

Modify a directory's disk space assignment for users

Access Control

In a typical secure site, users are allowed only Read and File Scan rights in directories where they are needed.

Other recommendations relating to trustee rights are as follows:

  • Don't give users rights in the root directory of any volume (remember inheritance).

  • Place users' home directories on a volume other than SYS. I have seen NDS crash because users with home directories on SYS backed up their entire hard drive or a very large database to their home directory.

  • If you only have the SYS volume on your servers, restrict the amount of disk space users can take up. To do this on a per-volume basis in NWAdmin, select the Volume object and use the User Space Limits option. The amount of volume space is calculated based on the "owner" property placed on files as they are created on the volume for the first time. You can change the ownership of files if necessary to redistribute space on the volume.

  • You can also place size limitations on a per-directory basis in NWAdmin by selecting a directory and using the Objects | Details | Facts options. This limitation applies to files and subdirectories beneath the directory.

File and Directory Attributes

Individual files and directories can benefit from NetWare's attribute security. Unlike trustee rights, which apply only to the assigned users, attributes apply to all users and override any granted or inherited rights. For example, flaging an .EXE file with the execute only (X) attribute would prohibit anyone from copying the file, backing it up, or renaming it.

The following table lists the available directory attributes in NetWare..


Attribute

Description

Di (Delete Inhibit)

Prevents users from deleting the directory

Dc (Don't Compress)

Files in the directory will not be compressed (if NetWare's file compression feature is activated)

Dm (Don't Migrate)

Files in the directory will not migrate to an offline storage device; used with the data migration option on the volume properties

H (Hidden)

Hides the directory (such as SYS:\_NETWARE)

Ic (Immediate Compress)

Every file in the directory will be compressed immediately after being closed (versus waiting the default time of 14 days after the directory was last accessed)

N (Normal)

Default attribute - allows Read and Write to files, but not Shareable

P (Purge)

Flags a directory to be purged as soon as it is deleted, rendering it unrecoverable

Ri (Rename Inhibit)

Prevents users from renaming the directory

Sy (System)

Used to flag a system directory such as SYS:_NETWARE

NetWare's file attributes are listed below.


Abbreviation (Attribute)

Description

A (Archive Needed)

Automatically assigned to files that have been changed since the last backup

C (Can't Compress)

Disallows compression for the file (if NetWare's file compression feature is activated)

Co (Compressed)

Status flag set automatically by NetWare to indicate that a file is compressed.

Ci (Copy Inhibit)

Prevents Apple Macintosh users from copying the file

Di (Delete Inhibit)

Prevents the file from being deleted (overrides the Erase trustee right)

Dc (Don't Compress)

Prevents the file from being compressed (used to override NetWare' default "days untouched before compression" setting)

Dm (Don't Migrate)

Prevents the file from being migrated to an offline storage device

Ds (Don't Suballocate)

Prevents the file from being suballocated (I can't think of a valid reason to ever use this)

H (Hidden)

Hides the file

I (Index)

Accelerates access by indexing files larger than 64 FAT entries (set automatically)

Ic (Immediate Compress)

Sets the file to be compressed as soon as it is closed

M (Migrate)

Status flag set automatically by NetWare to indicate that a file is ready to be migrated

N (Normal)

Default attribute for all new files - allows Read and Write, but not Shareable

P (Purge Immediately)

Sets the file to be purged immediately upon deletion, rendering it unrecoverable

Ro (Read Only)

Prevents users from writing to, renaming, or deleting the file (NetWare automatically checks and unchecks the Di and Ri attributes when the Ro attribute is set or cleared)

Rw (Read Write)

Allows the file to be read and written to (all files are created with this attribute)

Ri (Rename Inhibit)

Prevents the file from being modified or renamed

Sh (Shareable)

Allows more than one user to access the file at the same time; most often used with Ro

Sy (System)

Hides the file from DIR (file still shows up with NDIR or FILER); normally used with OS system files

T (Transactional)

Allows a file to be tracked and protected by Novell's Transaction Tracking System (TTS); useful for database files

X (Execute Only)

Prevents a file from being backed up, copied or modified; use for .EXE files, but make backups first--once this value is set, it is irreversible

Different versions of NetWare allow for different attributes. Some of the attributes listed above may not apply to your version of NetWare.

Recommendations for Attribute Security

Attribute security is seldom used,but here are a few guidelines for those who see the need.

  • Use file and directory attributes to add additional security benefits where needed.

  • Network applications do not provide file- or directory-level security. You must implement it specifically.

NDS Security

NDS is one of the most important pieces of NetWare security. NDS is an object-oriented database in which each object can be assigned multiple attributes. For instance, a User object has a Full Name, Phone Number, Fax Number, Password, and so on, all of which are attributes or properties of the User object. NDS security includes both object and property rights, which are permissions placed on objects and their properties.

Access to the network and its resources is based on rights assigned to NDS objects. Some rights are granted explicitly, while others are inherited. For instance, when a User object is created, it automatically inherits the Read right to the login script property of the Organizational Unit (OU) in which the object resides. Since this property right is assigned in NDS by default, it is considered inherited.

User object security comes into play during an attempt to log in to the network. NDS first verifies that the supplied name is a valid User object in the given context. If so, NDS checks for account restrictions. If there are none, the password supplied by the user is "hashed" (mathematically encrypted) against an RSA public key. This key applies an algorithm to the password and calculates a mathematical value, which is what is transmitted over the wire. In this way, the user's actual password never leaves the workstation.

When the encrypted mathematical value arrives at the preferred server, it is checked against an encrypted version of the password that is stored in NDS. NDS uses the same public key algorithm to decrypt the password and compare the result against the value stored in NDS. If they match, the user is authenticated and permitted to access the network.

It is possible to attach to a server without authenticating to it. Hackers have taken advantage of this to collect information without ever having to log in. Once an attachment is made to a server, a hacker can use Novell utilities such as NLIST and CX , as well as shareware tools such as bindery, bindin, finger, userdump and userinfo, to collect information that may be useful in a later attack.

NDS Object and Property Rights

The NDS object rights are listed in the following table.


Right (Abbreviation)

Description

Supervisor (S)

Allows everything granted by all the other rights. Granting this right implies granting the same Supervisor right to all NDS properties. (Unlike the S right in the file system, the NDS Supervisor object right can be blocked through an IRF.)

Browse (B)

Allows trustees of the object to search the tree in NWAdmin and through NLIST and CX commands

Create (C)

Allows an object trustee to create objects in and below the container (available only on container objects)

Delete (D)

Permits the removal of objects from the NDS tree

Rename (R)

Grants the object the ability to change the object's name

Inheritable (I)

(NetWare 5 only) Assigned object rights are inherited by default in NDS. Removing this right on a container object will restrict inheritance and force the administrator to explicitly grant objects rights to the container.

The NDS property rights are listed in the following table


Right (Abbreviation)

Description

Supervisor (S)

Allows everything granted by all the other rights

Read (R)

Provides the ability to see or read the properties of an object

Compare (C)

Works in tandem with the Read right; used to query any property, returning a true or false response

Write (W)

Allows you to modify, add, change, and delete property values; automatically includes the Add/Remove Self right. (Granting this right to the ACL property of any object effectively gives Supervisor access.)

Add/Remove Self (A)

Allows an object trustee to add or remove itself as a value of the object property

Default NDS Rights

The NDS rights that are granted by default are listed below. Keep in mind that rights granted to the [Public] object are passed to everything connected to the network. (A connection is made to a server before NDS authentication. It is this connection that, by default, allows browsing the NDS tree.)

  • [Public] receives the R right to the messaging server

  • Admin receives the S and I right to [Root]

  • Users inherit the rights of their containers, which are R property right to the login script and R right to the print job configuration (in non-NDPS environments)

  • Users are granted the R right to the [Root] properties of Network address and group membership, R to the default server property of [Public], R and W to the user's own login script property and print job configuration property, and R to all of the user's property rights.

  • The S right to the Server object is given to any user who installs a server into the NDS tree.

  • A Server object receives the S object right to itself, thereby permitting the server to modify parameters of its own object.

Recommendations for NDS Security

My suggestions for implementing NDS security are listed below.

  • Disable users who haven't logged in for several months. Bear in mind that some remote users may not connect to the network for an extended period of time. If they don't call about not being able to access the network, delete them.

  • Use a very long password (at least 18 characters) for Admin and secure it in a safe.

  • Use a null character (Alt+255) somewhere in the Admin password. This way, even if hackers do manage to see the Admin password, they would see a blank space where the null character exists.

  • Limit the number of people who know the Admin password to four or less.

  • Instead of letting people log in as Admin, grant their User object security equivalence to Admin. This allows you to audit administrative actions based on individual User objects, rather than a single Admin object that many people may have used.

  • Strictly limit the number of people who have security equivalence to Admin. If administrators need Admin rights, grant them security equivalence only as long as they are needed, and take the security equivalence away as soon as possible. Send yourself an e-mail message as a reminder to take it away.

  • Keep the Admin object in a container that contains no other users.

  • Once you have set another account security equivalent to Admin, rename the Admin account to thwart hackers who are trying to log in as Admin.

  • Administrators should have two accounts: one that provides the security equivalence needed to perform various administrative duties, and a generic end-user account for their other work. This may be an inconvenience, but it will help alleviate potential accidents.

  • Implement a policy to manage user passwords (refer to the "Password Management" section of this AppNote for suggestions).

  • Enable intruder detection in every OU. This feature is turned off by default. To enable it, right click on the OU in NWAdmin and select Details | Intrusion Detection | Detect Intruders. Be careful when enabling intruder detection on the O container. The Admin object exists there by default and it is possible for the Admin account to the locked out if someone attempts to guess the Admin password.

  • Set up connection limits for users. One connection is sufficient for everyone other than Admin. (If you are using ZENworks, you will need two connections per user.)

  • Use the expiration date property for contractors or temps to restrict their access to the contracted time limit. (Some organizations use this feature for each User object created as a lazy man's way of removing inactive user accounts. For example, they set a one-year expiration date for each user, and then extend the time period only for those users who are still active on the network when the year is up. This would not work well in large networks.)

  • The time restriction options in NDS add an additional layer of security, although I rarely see them being used. If you do, think through the ramifications of restricting users based on time of day. You don't want the payroll department calling you for access at 11:30 p.m. because they are making a late check run.

  • Network address restrictions is another feature I rarely see used, but it can be useful if you have an older application that must log in to the server on a dedicated workstation. Since the automated login name and password often give more rights than a normal user, configure the login name to only use the dedicated workstation's MAC or IP address. (Other address restriction options are available; refer to the NetWare documentation for details.)

  • Use an IRF if necessary to prohibit global access to NDS objects and properties. For OUs, groups, or individual users, grant explicit rights to an NDS object by trustee assignments. This will replace any previous inherited rights.

  • When possible, use OUs as "groups" for assigning rights to network resources. Since User objects are security equivalent to the OU that they are in, any rights you assign to an OU spill over to every user within the OU.

  • Remove the Inheritable attribute on each OU that you want to be supported separately by other administrators (available in NetWare 5 only).

The following table is useful when granting a subset of NDS rights to help desk or junior administrators for specific NDS functions. The options are grouped according to their respective tabs in the NWAdmin utility.


Function

Required Rights

Login Restrictions Tab

Account disabled = Account Disabled

R, W, I

Account has expiration date = Account Has Expiration Date

R, W, I

Expiration date and time = Account Has Expiration Date

R, W, I

Limit concurrent connections = Maximum Connections

R, W, I

Maximum connections = Maximum Connections

R, W, I

Last login = Login Time

R, I

Password Restrictions Tab

Allow user to change password = Allow User to Change Password

R, W, I

Require a password = Require Unique Password

R, W, I

Minimum password length = Minimum Password Length

R, W, I

Force Periodic password changes = Days Between Forced Changes

R, W, I

Days between forced changes = Days Between Forced Changes

R, W, I

Date password expires = Date Password Expires

R, W, I

Require unique passwords = Require Unique Passwords

R, W, I

Limit grace logins = Grace Logins Allowed

R, W, I

Grace logins allowed = Grace Logins Allowed

R, W, I

Remaining grace logins = Remaining Grace Logins

R, W, I

Change Password - Password Management

R, W, I

Intruder Lockout Tab

Account locked

S object right

Incorrect login count

S object right

Account reset time

R, I

Last intruder address

R, I

A number of third-party programs are available that can audit NDS. See the "Auditing NetWare Security" section for more information.

Password Management

Your goal in password management is to eliminate a hacker's ability to gain access to the network by guessing or intercepting passwords. Hackers use a number of methods to obtain password access.

  • If they have physical access to the server, hackers can load a rogue NLM that creates an Admin-equivalent User object, which they can then use to log in.

  • They can run a password deciphering program on Windows workstations to decode the workstation password, which is usually synched to the NDS password. (See "Workstation Security" later in this AppNote for ways to prevent this hack.)

  • They can mount a brute force or dictionary attack to discover a User object's password.

  • They can run a utility to identify which users don't have passwords.

In a brute force attack, every possible combination of letters and numbers is tried until the correct password is discovered. In dictionary attacks, a predetermined list of the most popular passwords is used. Both hacks can be prevented by enabling Novell's intruder detection feature.

One freeware utility that is often used by hackers to identify user accounts with no passwords is called CHKNULL. This simple DOS command line utility checks all User objects to see which have "null" (no) passwords, without triggering any failed login attempts in intruder detection.

Of course, you can use to this utility, found at http://www.nmrc.org, to audit password compliance and close any no-password security holes you may find (see Figure 1).

Figure 1: Output from the CHKNULL utility showing that user MFOUST has no password.

CHKNULL has several parameters which you can use to extend its functionality:

Usage: chknull [-p] [-n] [-v] [wordlist]

-p = check username as password

-n = don't check null password

-v = verbose output

also can check specified words on the command line as passwords

A similar function can be performed by using Novell's NLIST command, as shown in Figure 2.

Figure 2: You can check for users without passwords using the NLIST command.

Recommendations for Password Security

The main defense against password hacks is enabling Novell's intruder detection to lock out users that supply incorrect passwords in a predetermined number of attempts. As a user exceeds the intruder detection limit, NetWare logs the event. The server beeps and displays a time- stamped message showing the account name that is now locked and the node's MAC address. A locked account can be reset by anyone with Supervisor object rights to the user.

Note: Server-generated error messages are displayed on the system console and logged to the \SYSTEM\SYS$LOG.ERR file, which can be read with a text editor.

To turn on intruder detection in an OU, select the OU in NWAdmin. Right-click on the OU and select Details | Intruder Detection. Click the Detect Intruders box and the Lock account after detection box, as shown in Figure 3.

Figure 3: To enable Intruder Detection in an OU, check the boxes as shown (neither box is checked by default).

The default values for these two options are also shown in Figure 2. Note that the default number of incorrect login attempts allowed is 7. I recommend changing that to 3.

Other password security recommendations include the following:

  • When creating user accounts, administrators do not need to specify a password. Similarly, users are not required to have a password by default. Make and use a User_Template object to require specific password properties.

  • Require users to have passwords with a minimum length.

  • Require users to have unique passwords. NetWare remembers the last eight passwords each user has had.

  • Keep the number of grace logins set at three.

Single Sign-On

Independent surveys have identified password resetting as one of the top reasons for help desk calls. One way to decrease the likelihood of users forgetting their passwords is to reduce the number of passwords they are required to memorize.

Novell's Single Sign-on solution allows a single enterprise-wide login to NDS to applications that would normally require separate passwords. Password-enabled application authentications are redirected via APIs and stored in encrypted form in NDS. For more information, visit http://www.novell.com/products/sso/.

Auditing Password Security

BindView (http://www.bindview.com) enables auditing and enforcement of user passwords policies on an enterprise level. BindView will provide reports of password attributes, such as length, number of days until change, and so on, along with the ability to change attributes system-wide.

Kane Security Analyst (http://www.intrusion.com) and BlueLance LT Auditor (http://www.blue lance.com) are two other third-party programs you can use to help audit password security. Various shareware and freeware utilities are also available to assist you with your auditing needs.

Securing Your Servers

To enable the Novell-provided security model for NetWare servers, a secure site should implement the following measures.

  • Upgrade bindery-based (NetWare 3.x) servers to NetWare 5. There are many NetWare 3.x hacks that can only be prevented by moving from bindery to NDS authentication.

  • Upgrade workstation client software and print servers to enable NDS logins.

  • Remove bindery contexts as soon as possible after upgrading to NDS. Many hacks are based on bindery access to the server.

  • In NetWare 5, use Novell's new SCRSAVER.NLM to password-protect access to the server console.

  • Keep all servers up-to-date with the latest software patches and field updates. One of the purposes for these patches is to fix known security holes. Updates can be downloaded from http://support.novell.com.

    Note: Don't be wary of Novell's field updates. Despite the name, these field updates are not beta versions of patches. They are roughly equivalent to Microsoft's HotFixes. Novell eventually bundles field updates into a service pack.

  • Don't use RCONSOLE for remote access to the server console. If you must use RCONSOLE, encrypt the password and set the server and workstation to use packet signature option 3. To encrypt the password, use the REMOTE ENCRYPT command as shown below and answer "yes" to the prompt:

: REMOTE ENCRYPT

Enter a password to encrypt > NOVELL

To use this password use the command:

Load REMOTE -E 2475030255179199A911D6

Would you like this command written to SYS:SYSTEM\LDREMOTE.NCF? (y/n)

>

  • A working hack against the hashed RCONSOLE password has been published at http://www.nmrc.org. To obtain the password, a hacker must have either a protocol analyzer trace of unencrypted client/server communication at a time when someone is using RCONSOLE, or access to the SYS:SYSTEM directory. For stronger remote console security, try Protocom's SecureRemote for NetWare (http://www.server systems.com/scremote/Welcome.html) or NetWare 5.x's new IP-based RCONJ utility.

  • Turn off or disable any unnecessary remote access services running on your network, such as FTP, anonymous passwords, and so on.

  • Use authentication (preferably NDS) to restrict Internet access by User object, Internet sites, time of day, and so on. Novell's BorderManager product can perform this function.

  • To reduce the chance of break-ins from the Internet, consider using a proxy server. Another option is Network Address Translation (NAT), a technique invisible to end-users which maps IP addresses from one group to another. Network Address Port Translation (NAPT) is a method by which both network IP addresses and their TCP/UDP ports are translated into a single "real" network address and its TCP/UDP ports. Jointly, these provide a mechanism to connect your private addresses to a single "real" IP address. Novell, Cisco, and other vendors sell NAT solutions.

  • For the most security-critical users on your network (especially Admin), consider using packet signature option 3 (the highest level).

    Note: This setting does encrypt the signature with an MD4 hash, purely in order to prevent the hijacking of the connection.

  • You set this at the server by entering "SET NCP Packet Signature Option=3" at the console prompt. At the workstation, enable it by right-clicking on the red N in the System Tray and selecting Novell Client Properties | Advanced Settings | Signature Level | 3.

Note: The protection afforded by NCP packet signatures comes at the cost of performance, as the encryption and decryption algorithms used for packet signing are fairly CPU- intensive. At one of my customer sites, they enabled packet signing on every client workstation for about 150 users. The server consistently ran at about 50% utilization just from the workload of packet signing.

  • LDAP (Lightweight Directory Access Protocol) version 1 uses clear-text passwords. Upgrade any applications that use LDAP v1 to LDAP v3. This version is supported by later versions of NDS 7 and all NDS 8 versions, including eDirecotry.

  • NetWare 5 supports telnet remote access to the server (configurable through the INETCFG utility). Since telnet uses clear-text passwords that any protocol analyzer can read, do not enable this feature in secure environments.

  • For ultra-secure environments, implement stronger methods of authentication such as biometrics or tokens. Biometrics involve the use of some unique personal identifier such as a fingerprint or retinal scan to provide authentication. A token is something you possess, such as a smart card. Both of these authentication methods are supported by NetWare 5. Visit http://www.novell.com/security for additional information.

Security for Web Servers

Connecting your network to the Internet is inherently risky. Here are some suggestions to increase security for your Web servers:

  • Install a firewall between your network and the Internet. Novell's BorderManager product has firewall capabilities. Visit http://www.novell.com/bordermanager/for details.

  • Another feature of BorderManager is known as reverse proxy. This allows you to cache your Web server's content on a separate box. Place a "pinhole" in the firewall which only the cache server can use to get content. That way, hackers can only hack cache.

  • Log all Web and DNS activity with BorderManager or your firewall software.

Workstation Security

Third-party hacking utilities can decipher passwords stored on workstations. These utilities undermine workstation security by allowing the hacker to read Microsoft-encrypted .pwl files. Snadboys' Revelation (http://www.snadboy.com) is an example of such as product.

The following security measures are recommended to protect workstations:

  • If possible, use Windows NT Workstation or Windows 2000 instead of Windows 95/98 or Windows 3.x.

  • Train users to lock their workstations via a password-enabled screensaver when they leave their work area. If users complain about having to remember yet another password, several NDS-enabled password screensavers are available at http://www.ethosoft.comor http://www.netwarefiles.com/scrsaver.htm.

  • Password-enabled screensavers on Windows 95/98 are not foolproof, because the workstation can simply be rebooted to bypass the screensaver.

  • If two or more users share the same workstation, train them to reboot or turn the machine off when they are finished, instead of simply logging out.

  • Dynamic Host Configuration Protocol (DHCP) can be a security hole, as it may be possible for someone to plug in a laptop to one of your Ethernet data jacks and obtain an IP address. This would give the intruder at least Internet access. An IP address also grants a user access to any one of a number of IP hacking tools. Unless you manually associate IP addresses to MAC addresses, almost any user can plug in and obtain an IP addresses.

  • Requiring users to authenticate for Internet access enables you to more selectively grant access and log the Internet activity of users. Most Internet authentication is accomplished either through a separate password or via permission on an IP address. BorderManager provides access via policies that are placed on NDS user, group, and container objects. Other firewall solutions may require password access to the Internet, but again, the user is faced with remembering another password.

Auditing NetWare Security

Administrative time devoted to searching audit logs and auditing your system for possible problems is time well spent.

Audit Logs

You should regularly view the following server log files for important system information (these files may be viewed from the server console or from a text editor).


Log File

Contents

SYS$LOG.ERR

Found in the \SYSTEM directory, this file contains file server errors and general status information.

CONSOLE.LOG

Found in the \ETC directory, this file maintains a copy of all console screen activity. It is started by the CONSOLE.NLM that is automatically loaded in NetWare 5 AUTOEXEC.NCF file. The file size limit is set to 100KB by default, but you can change this if necessary.

VOL$LOG.ERR

Automatically created and stored at the root of each volume, this file contains little of interest for security except the mounting and dismounting of volumes and VREPAIR operations.

ABEND.LOG

Found in the SYSTEM directory, this file keeps a record of server Abends. Sometimes hackers just want to Abend your server. NetWare 4.x and 5.x offer automated Abend recovery. You can also use third-party tools such as the AlexanderLAN Server Protection Kit to notify the administrator of Abend messages and other alerts.Visit http://support.novell.com/alexanderlan/ for more information.

Auditing Programs

Novell's main auditing tool is the AUDITCON utility. However, many find it cumbersome and somewhat difficult to use.

If you use NDS eDirectory on platforms other than NetWare (such as NT, Windows 2000, Solaris, or Linux), you do not have the essential ability to audit via AUDITCON as Novell has not yet included this capability in the NDS versions ported to other platforms. You will have to buy a third-party NDS auditing utility, so be sure to budget for this in your NDS purchase.

Note: According to Novell, the auditing ability will be incorporated into the other platform versions of NDS eDirectory soon.

Many Novell and third-party utilities are available that are far more efficient and much easier to use than AUDITCON.

  • Novell ManageWise (http://www.novell.com/products/managewise) is a comparatively inexpensive network management product that can audit NDS events such as partition operations, as well as hundreds of other potential problems. On the down side, it has a 16-bit console interface that some find cumbersome to use.

  • BorderManager (http://www.novell.com/products/bordermanager) is a network access management suite that is closely integrated with NDS, allowing you to enforce and monitor access consistently from a central location. BorderManager can help you enforce network security by monitoring event logs on a regular basis. These logs are used to check for anomalies in server traffic such as port scans, spoofed Routing Information Protocol (RIP) packets, DNS requests, ICMP redirects, or any inconsistent routing activity. You can also configure BorderManager Alert to notify you by e-mail when certain security-related conditions or events occur, such as packet flooding, abnormal packet sizes, and the unloading or loading of modules on the server.

  • BindView (http://www.bindview.com) is a great product with many features that are useful in auditing security-related aspects of your network. The only drawbacks are its dependency on Novell's AUDITCON and its relatively high cost. If you cannot afford the license for BindView, download a trial copy and test it on your network.

  • Security Analyst (http://www.intrusion.com) is a network security assessment tool that provides a fast, thorough security analysis for NetWare and Windows NT. It compares your network security configuration with industry best practices or your own organizational security policy to help you see your network's areas of vulnerability and take corrective action. The reports can be customized and compiled into an attractive audit presentation for your management team.

  • BlueLance LT Auditor+ (http://www.bluelance.com) is a powerful security auditing tool that has been successfully used by companies worldwide to monitor their networks and secure their assets from internal intrusion.

Miscellaneous Security Tips

To successfully guard against hacker attacks, you have to think like a hacker. Remember, hackers are usually trying to get Admin security equivalence. They also want to hide their tracks. Therefore, it is your job to make that as difficult as possible. Keep informed of hacks by visiting hacker Web sites to collect information and countermeasures.

Accounts Used by Applications

Be aware that certain applications must log in to the network using common login names and passwords. Examples of such login accounts include:

  • BACKUP

  • MAIL

  • POST

  • FAXUSER

  • PRINTER

  • LASER

  • HPLASER

Backup programs often require Admin equivalence, which is a security hole. Use network address restrictions for the backup node, if possible. Also, make sure your User_Template object has a password required. If not, it is possible for a hacker to clone a User object with the template.

Hidden OUs

To gain Admin privileges, the hacker needs access to the server, either through physical access to the server console or by authenticating with a stolen password. A common way for hackers to hide their tracks after successfully gaining Admin security equivalence is to create an OU with a single User object in it. The hacker gives that User object explicit trustee rights to the User object and the new OU, and then takes away browsing rights to the OU from the rest of the tree by removing the [Public] object's Browse right.

You can use a freeware utility called HOBJLOC.NLM to find these hidden OUs. HOBJLOC.NLM is available for download on Novell's Web site or at http://www.netwarefiles.com. To start the utility, load the NLM and enter the Admin password. Figure 4 shows an example of the output from this utility.

Figure 4: The Hidden Object Locator found that the Admin object has neither Browse nor Supervisor rights to HACKERSOU.

The "invisible" user will also show up in the MONITOR utility's list of service connections. However, using the Connections option in MONITOR is useful only in small networks with few users. On large networks with hundreds of connections, it is difficult to sift through the list and find a hidden user.

The Pandora Hack

The Pandora hack is probably the most infamous of NetWare hacks. Pandora is actually a set of hack utilities designed to obtain security equivalence to Admin. The Pandora home page is located at http://www.nmrc.org/pandora/index.html.

Defense against Pandora includes the following measures:

  • Since Pandora will not work with passwords over 16 characters long, make your Admin passwords 17 characters or longer.

  • Require users to have passwords that are at least 8 characters long and hard to guess (a combination of letters and numbers is most effective).

  • Since some of the utilities require access to the SYS:SYSTEM directory to hack against NDS backup files, restrict access to this directory from everyone except Admins.

  • Pandora also requires access to the same Ethernet segment as Admin. Keep the administrative workstation on its own segmented, switched subnet.

  • Ensure that Admin and equivalent userss are using packet signature option 3 at their workstations.

Preventing Tree Browsing

The ability to browse the network via Network Neighborhood is a security hole. On secure networks, valid users do not need this ability. Browsing allows users access to resources outside the administrator's reach. True, file and directory rights are still active, but any mistakes or oversights in assigning rights can leave your network vulnerable.

By default, anyone can browse the entire NDS tree. You do not even need to be logged in to see the entire tree with the CX utility. Entering the command "CX /R /A /T" displays the tree structure starting at the root. In NetWare 4.x, the SYS:LOGIN directory contains both the CX and NLIST utility. In NetWare 5.x, the NLIST utility was moved into the SYS:PUBLIC directory to be used only by authenticated users.

By default, the hidden [Public] object has Browse rights to the entire NDS tree. You should regularly check the NDS trustees of this object. You may delete the [Public] object or remove its default Browse assignment, but carefully consider the ramifications before doing so. In most cases, users' default Browse rights to their own container is sufficient to grant them access to resources within the container. However, many organizations place resources (most often printers) outside of the user's container. In this case, users would need Browse rights in the tree to locate print queues and other resources outside their home container. This usually comes from the [Public] object's Browse right to the tree. Also, contextless login is useless if users cannot search the NDS tree.

You can give the rights [Public] has to the [ROOT] object, which will preserve the rights needed by authenticated users through inheritance. However, you should test any such measures in a lab environment first. You don't need hundreds of users calling the help desk first thing Monday morning because they can't log in due to an inadvertent error on your part.

Another area where users traditionally need browsing ability is in mapping drives. By default, this function relies on the ability to find servers via the Service Location Protocol (SLP). In most cases, however, drive mappings are set up in login scripts designed by the administrator to create the users' work environment. NetWare 5 supports the ability to map to resources using IP addresses or DNS names within login scripts. If you have DNS implemented for all of your NetWare servers, SLP browsing support is unnecessary.

Using ZENworks

ZENworks for Desktops (http://www.novell.com/products/zenworks) uses NDS authentication for desktop application support. If you need to strictly control what end-users can do from their workstations, you can replace the Windows Explorer.exe shell with the NAL.exe shell.

ZENworks also allows you to associate applications with users or workstations based on predetermined policies. The licensing option assists you in enforcing adherence to application licenses. For example, if you purchased 250 user licenses for Corel's WordPerfect, you can monitor and limit user access to 250.

Scrutinizing Third-Party Products

Carefully scrutinize all third-party products before you implement them on your network. Be sure to ask vendors about their security models and their product holes. For example, Oblix, a directory white/yellow pages product for NDS, requires a middleware server that passes clear-text passwords over the wire.

Conclusion

Security on a network is not something to be taken lightly. In today's interconnected world, it is essential that you take steps to protect your valuable data from all points of attack, both external and internal. Hopefully this AppNote has given you some ideas for devising a strong security policy to meet your organization's needs.

Note: This AppNote is adapted from the security chapter of a book entitled NetWare in a Nutshell, currently being written by the author for O'Reilly and Associates. For more information, visit http://www.oreilly.com.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates