Protecting Your Network Against Known Security Threats

Articles and Tips: article

01 Nov 1997

This article has been edited since it was originally published.

Explains how a proper security implementation can protect the network from various types of attacks, and how NetWare's security features can be implemented during a transition to a sucure system.

Introduction
A Two-Sided Issue
Understanding the Nature of Attacks
Protective Measures for NetWare Networks
Conclusion

Introduction

How do you protect shared information? Isolating electronic information is one means of protecting data that could cause either corporate or personal catastrophe if it were to fall into the wrong hands. Physical isolation can protect such sensitive information through the use of hard walls, safes, and locked doors. But what about the other types of information--the shareable, collaborative, and sensitive information intended for limited internal and external distribution? How real are the security threats to this information, and what is available to help you protect that information?

In truth, it may be some time before you can purchase off-the-shelf tools that will logically isolate electronic business information stored in "open" electronic networks. However, if you are looking for a networking system available today that gives you dependable security capabilities in a "closed" environment, you need look no further than NetWare.

If you have vitally sensitive information on a network, you must secure your system before it is penetrated. Otherwise, none of the available protection mechanisms will be effective, as it is highly probable that some of your vital information has already been compromised in some manner. Understanding the nature of attacks and how they originate can be useful when you need to impress upon superiors just how easily electronic information can be subverted. Knowing the courses of action that are available to an attacker is also beneficial to system planners, especially when instituting a security policy or other such relevant activities.

This AppNote discusses the basic classes of attacks on computer information. It describes several of the published attacks that might be used on NetWare-based systems in open, closed, or mixed environments. It then explains how Novell's NetWare (and the enhanced levels of security it provides) can protect your network against these known security threats.

A Two-Sided Issue

Any discussion of the classes of attacks implies a knowledge of the various attacks that are available to hackers; however, most people do not have this knowledge. Not knowing enough about attacks to provide adequate protection is actually a two-sided issue. On the one side, you are faced with the task of protecting information, data, or resources which you do not even realize are exposed; on the other side, your network almost assuredly already contains a security weakness which makes it vulnerable.

While this may seem like the classic no-win scenario, there are ways to reduce the risks on both sides of the issue. By narrowing down the potential attack threats through risk analysis and security policy definition, you can institute effective protections for the known threats to your system. Risk analysis will also help you determine the sensitivity of information and its value to the organization. By knowing what types of attacks exist, how they operate, and what the appropriate protective measures are, you can better determine what actions to take to implement greater security in your network environment.

Understanding the Nature of Attacks

Because new methods of attack are introduced so quickly, it is not practical for most network designers and administrators to try to keep up-to-date on every possible attack and hacker program that is out there. However, knowing the general types of attacks that are currently available to attackers can help you determine the level of protection you need to implement within your company.

Passive vs. Active Attacks

There are two main categories of attacks: passive and active. "Passive" attacks are those in which the attacker taps into the system and simply waits for some information of value to be transmitted. "Active" attacks are those in which the attacker may launch an active search for weaknesses in your network security. Information obtained from a passive attack may be used in an active attack to institute a more aggressive assault.

The Importance of Physical Protection

Before we look at specific types of attacks, we need to emphasize the number one requirement for any measure of network security: that is, physically protecting the servers. Simply put, allowing casual access to your server can put the server (if not your entire organization) out of business. Not having your server physically secured and locked up precludes any meaningful or persistent security measures elsewhere in the system. On the other hand, with physical security for the server in place, the following attacks cannot be mounted against a NetWare server:

Obtaining unauthorized supervisor access
Taking over with supervisor-level permissions
Leaving back doors
Cracking passwords past the server
Setting a new password
Disabling passwords
Defeating console logging functions
Setting console passwords to known values
Detecting hidden files on the server
Accessing server startup (NCF) files
Detecting audit status
Introducing Trojan horses
Loading unknown NLMs
Preventing server configuration from being changed
Preventing console security parameters from being changed

If you do not have physical access security and your network hasn't been attacked, you are only coasting on delusions of protection. When your network is attacked, you may never know for certain where the attack came from. This causes more problems than just the potential loss of the server or its data. For example, in a non-secure server, auditing information is patently unreliable and unusable for legal purposes, since the integrity of audit data is neither credible nor provable. Without physical security of the server, there cannot be a preponderance of evidence to associate subversive activities with a specific user's actions. Thus administrative changes, password maintenance, and other tasks cannot be considered reliably traceable, trackable, or useable as evidence, even out of court. The same is true for administrative actions performed at an unsecure workstation.

This is why the Novell recommends that the server be physically secured and protected from unauthorized access. You should maintain log files and manual entry logs to verify work done at the console. We also warn against running audit or other administrative utilities from unsecure workstations. These procedures eliminate both server- and workstation-based attacks by outside persons and by most unauthorized insiders.

Protecting Against Known Attacks

Here is a short list of the types of attacks or vulnerabilities which apply to NetWare-based systems (and networks in general):

Viruses, worms, bombs, and Trojan Horses
Trap doors
Denial of service attacks
Snooping attacks
Spoofing attacks
Server console attacks
Password attacks
Login program attacks
Exploring and looking for administrative flaws
Exploiting bugs in the operating system

With the protection mechanisms available to you in a secure network operating system such as NetWare 4.11, you can protect authentication secrets (passwords) against all of these types of attacks.

Viruses, Worms, Bombs, and Trojan Horses. Network users can store viruses, worms, or bombs in files on the server. However, a non-administrative user cannot infect the server's Trusted Computing Base (TCB), because there is no way for a user to cause the server to run non-TCB code. Non-administrative users cannot plant a Trojan horse in the server's TCB code, but they may use the server file system for storage of Trojan Horses that are intended to run on client components.

Trap Doors. A trap door is a mechanism built in to a system by its designer or administrator to give that person subsequent unauthorized access to the system. This threat can be addressed by specifying the server's interfaces and testing that they all operate properly.

Denial of Service Attacks. This threat comes in many forms, ranging from physical destruction of a network resource to flooding the resource with so many requests that it is unable to service legitimate users. Physical protection of the server is key to preventing destruction of the hardware. To help protect against other denial of service attacks, the server provides audit mechanisms to track security-relevant operations and provides an accounting mechanism to charge users for use of network resources.

Snooping (Passive Wiretapping). Snooping is a passive attack that involves tapping into the network wire and listening for data that might be valuable. Tapping into the network cable is usually done to acquire information (such as passwords) that might be useful later in a more active attack, especially in an electronic commerce environment.

Even a secure network would be subject to these types of attacks if solid security procedures are not followed. Because network operating system vendors have no control over the physical media customers choose, they all disclaim the wire against snooping or tapping. Protections to prevent passive listening in secure configurations are thus obtained by using the prescribed hardware on the system.

In a secure configuration, the wire has some type of physical protection to ensure it is not tapped into. Thus, by physically inspecting the hardware for tampering, you can rule out any possibility of a snooping attack having taken place on your network.

Snooping attacks generally rely on the presence of a standard network adapter that uses promiscuous mode. Novell's security architecture calls for network adapters which cannot be put into promiscuous or "listening" mode, and which cannot be configured to a different node address.

Of course, there are other ways to get available data off the wire. Because of this, network analyzers and protocol "sniffers" of any kind are not casually allowed in an enhanced security configuration. If they are allowed, the data they collect is not to be taken into an unsecure environment.

Spoofing (Active Wiretapping). Spoofing involves deceiving someone or deceiving the system itself. This is usually done by tapping into the wire and injecting information in an attempt to intercept valuable data destined for a valid user or workstation. Whereas a snooping attacker can use the network adapter to listen in promiscuous mode, the spoofing attacker uses the network adapter (or some other part of the network) to inject data or command packets into the data stream. The hardware or program at the receiving point is "spoofed" into believing that the disingenuous data has come from an authentic source.

Most often the purpose of spoofing is to gain access control to the system by posing as a more privileged user. In another spoofing scenario, known as the "false address" attack, the intruder seeks to acquire a valid workstation address. This type of attack is a threat for every network.

Certain security configurations protect against spoofing by requiring that administrators set up station and time restrictions for every user on the system. Station restrictions allow users to log in only at certain workstation addresses, while time restrictions limit the hours during which users can log in to the network. By limiting the addresses to known hardware configurations, only specific users can access the network from known addresses. This prevents unauthorized persons from injecting packets from an outside address.

Server Console Attacks. Server console or remote console attacks are performed by gaining access to the console prompt of the server. Of the most prominent console attacks, access to the console debugger is the most highly productive for an attacker, as this allows code modification and file editing. Other console attacks that can be launched at the console prompt include:

Defeating console logging processes
Bypassing a console locked via the MONITOR utility
Permitting a remote console attack
Detecting audit "on" status
Removing NDS
Removing auditing features
Introducing unknown NLMs

Remove physical access and remote access to the server, and you remove the ability to pursue any of the above attacks! Even though you may have physical protections in place, this type of an attack can be mounted by an unchecked, unaudited administrator, or even by a maintenance person with a key if the SECURE CONSOLE command has not been issued at the server. Forbidding remote access through utilities such as RCONSOLE further prevents outside personnel from accessing the server console. Since you are not allowed to use RCONSOLE in the NetWare Enhanced Security environment, it is best not to have it installed at all.

Clearly, if your server data is sensitive enough that a normally trusted administrator needs to be protected from becoming the sole point of authority and access to the server, data, and audit information, then perhaps the addition of independent audit, or two-person access to the server room with additional paper controls, should be required as well.

Password Attacks (Brute-force and Dictionary). Brute force password attacks are basic guessing attacks. A dictionary attack employs a predefined list of common combinations in an attempt to arrive at a complete username and password. With no security protections in place, anyone can sit down at a workstation and begin attempts to enter the correct username and password. If usernames can be obtained without much effort, or if an actual username is known, all that remains is for the intruder to try to guess the password. If the intruder can view the end-user's actions at entry time, the attack becomes that much easier.

While these attacks do not require physical access to the server, they can take place much more easily with physical access. However, do not assume that a brute force or dictionary attack is difficult or will take a long time just because the system attacker may not be able to get to the server. Neither may be the case.

These types of attacks become feasible if end-users or administrators do not follow the enhanced security procedures with regard to both passwords and physical protection.

Password guessing attempts can be easily detected if you include "SET Intruder Detection = ON" in the server's AUTOEXEC.NCF file. This also enables the server to provide a record of the time and location of repeated login attempts. Including station restrictions on workstations' addresses is another effective deterrent for password guessing attacks.

Still, the most effective means for preventing successful password attacks is by implementing a good procedure in creating and maintaining passwords. Users must be trained to protect their passwords when creating them by using non-obvious choices and lengths of eight characters or more.

To end-users, the importance of authentication secrets is identification; users are known to the computer by their user names and passwords. The maintenance of credible (even legally documented) authentication for access control (authorization) and reliable audit is often overlooked in commercial systems. Previously, only organizational users with access to non-commercial software or physically monitored rooms could obtain these levels of protection. However, NetWare 4.11 offers such security as part of its commercial, off-the-shelf network operating system.

In a "required password" environment where identification secrets may be complex, other attacks exist such as console-based attacks, where password disclosure can be collected. As previously noted, an unsupervised administrator can physically alter passwords at the console through the console debugger (although this is more of a problem in NetWare 3.x servers). In an enhanced security environment, each of these problems is attended to by preventing physical access to the servers.

Spoofing Login Programs to Collect Passwords. Spoofing often implies the misuse of a physical hardware address for some purpose other than what it is intended for. However, the login program spoofing attack is designed to acquire a user's identification secrets through some deceptive means, such as getting the user to reveal the secret when protection does not exist. In this attack, the objective is to obtain login IDs and passwords of end-users or administrators. While other types of spoofing attacks attempt to confuse the actual source with injected information, the spoofing login attack is not intended to confuse anything. Spoofing login is aimed strictly at gaining authentication secrets which can be used at another time. If any confusion exists, it is only that users think they have used the legitimate login program.

A spoof login attack requires some sophistication on the attacker's part, or existing knowledge of the end-user's system. Underlying a successful attack are overlooked access control flaws surrounding the actual login executable files (including hand-off programs from unevaluated desktop operating systems such as Windows 95), or the local hardware designed for login. Below is a list of what an attacker can do using the spoof login attack class:

Fooling users into thinking they have logged out when they really haven't
Storing login passwords
Replacing LOGIN.EXE with other code
Replacing other pre-login code

You can prevent these attacks through hardware control of the login sequence and by ensureing that no unknown programs can be run at boot-up time, prior to the user login.

Exploring and Looking for Administrative Flaws. Administrators do occasionally misinterpret or incorrectly assign rights. Users with too few rights usually complain, but users with too many rights might never complain. Attackers with too many rights most certainly will not complain, at least not right away.

By following certain procedures, you can eliminate the majority of flawed practices. While there are more than this AppNote can describe, some of the more obvious flaws are:

Not setting up or checking intruder detection
Allowing unauthorized access to audit files
Using RCONSOLE (at all, ever, anytime)
Not reviewing thoroughly all default trustee assignments
Not restricting access to server NCF files
Not knowing third-party software "holes"
Allowing unauthorized access to login scripts
Allowing the administrator unlimited initial access at setup time
Poor administration during setup, such as not using user templates
Allowing untrusted or unchecked access to the server

All of the attacks listed above need to be clarified with administrators, auditors, and security personnel. You must handle these attacks procedurally if you expect any level of enhanced protection to remain in place through the inevitable shuffling of personnel.

Some customers will have additional requirements that can jeopardize security. For example, requirements to extend beyond closed into open networks, or to distribute data to "other" users such as Internet users present on the network introduce new security considerations.

Exploiting Bugs in the Operating System. Operating systems, like every other software product, are likely to contain "bugs"--portions of code that do not execute quite as the designers intended. Most software vendors, including Novell, expend a great deal of time and effort to find and fix bugs both before and after a product ships. However, it seems new bugs are always cropping up despite the vendors' best efforts. Upgrades, updates, and validated patches from a known source are ways of keeping an operating system--and its security--current.

Known flaws, especially those that are well advertised, increase both the risk of using a particular product and the ability of hackers to institute a future attack. Patching avoids legacy and well known flaws, and known flaws become better known as time goes on. Keeping up on the latest operating system upgrades is important to maintaining a trusted environment and diminishing the risks associated with software attacks through such known flaws.

Attacks Summary

The following table summarizes the known security threats for NetWare and how NetWare protects against them.

Type of Threat	Description	How NetWare 4.11 IsProtected
Viruses, worms, bombs, andTrojan Horses	Malicious programs that can causevarious types of damage or performundesired or unintended operations	Although such programs can be stored in theserver's file system, NetWare architecture provides no way for a non-administrative user to cause the server to run non-TCB code.
Trap doors	Mechanism built in to a system by itsdesigner or administrator to give thatperson subsequent unauthorizedaccess	Specifies the server's interfaces and testingthat they all operate properly.
Denial of service attacks	Comes in many forms, ranging fromphysical destruction of the resource toflooding the resource with so manyrequests that it is unable to servicelegitimate users	Physical destruction prevented throughphysicalprotection of the server. The server also provides audit mechanisms totrack security-relevant operations and providesan accounting mechanism to charge users foruse of network resources.
Snooping attacks(passive wiretapping)	Intruder taps into the network cablingand listens for valuable data,generally using network adapters inpromiscuous mode	Network media is required to be physically orcryptographically protected. Evaluated configuration requires use of onlyapproved network adapter hardware that doesnot use promiscuous mode.
Spoofing attacks(active wiretapping)	Intruder taps into the network cablingand injects packets, often in anattempt to impersonate an authorizedadministrative user	Network media is required to be physically orcryptographically protected. For additional protection, use Set NCPPacket Signatures = 3 on each server.
Server console access attacks	Intruder gains either physical orremote access to the server consoleand launches various attacks, often byentering the NetWare debugger.	Prevented through restricting physical accesstothe server, through key or guarded access toserver room. For added protection, institute reliable meansof monitoring activity at the server console(two-person policy, manual logs, and so on) Secure the console with SECURE CONSOLE. Remove RCONSOLE from the network.
Password attacks	Intruder employs either brute-force ordictionary attack in an attempt toguess usernames and passwords.	Protected by procedural security: enablingIntruder Detection and Lockout, implementingstation/time restrictions for users, and ensuringthat all users have non-obvious passwords atleast eight characters long.
Login program spoofing attacks	Intruder introduces code that eitherreplaces LOGIN.EXE or surreptitiouslygathers passwords at login time.	Hardware and software fortrusted workstations prevents compromise oflogin integrity.
Looking for administrative flaws	Intruder explores network in search offlaws that could be exploited in othertypes of attacks	NDS controls access to files and objects.
Exploiting bugs in the operatingsystem	Some well publicized bugs providemeans for intruders to launch attacks.

Protective Measures for NetWare Networks

There are numerous measures to provide some protection for network environments that can tolerate the inherent level of risk.

Securing NetWare Servers

System administrators should make sure their file servers are secure, both physically and in how the consoles may be accessed.

Restrict physical access to the file server.

It is extremely important to physically lock up your servers. There simply is no security without physical security. Physical security serves two functions: (1) it protects the equipment from theft and/or tampering, and (2) it protects against unauthorized access. Physical access to any server, regardless of the operating system, is the easiest method of circumventing all access restrictions. For instance, a nonsecured server is open for anyone to enter console commands, load and unload NLMs, or place the server into debug mode. With physical access to the server hardware, an intruder can remove the disk drives, install them on another NetWare server, and have full access to the data. Thus, physically securing the system not only protects the server hardware and the data on disk, but also reinforces all other security measures outlined in this AppNote.

You should also consider implementing an access policy that controls who may physically access the server. Ideally, all access to machine rooms should be logged and audited by an entry pass system. Another alternative is a key-controlled access policy. Since access to the file servers must be closely controlled, some method of physical server room key distribution should be implemented. Other alternatives include electronic access mechanisms which identify and time code all access to the server room.

Use MONITOR's Console Lock Feature. Activating the "Lock file server console" option in MONITOR.NLM prevents unauthorized persons from interfering with the server. You should also ensure that the console password is different from the Admin password.

Enable SECURE CONSOLE Feature on Server. The SECURE CONSOLE command performs several important security functions: in addition to the REMOVE DOS console command, it also prevents entry into the operating system debugger and freezes the file server search paths. An intruder with physical access to the server console could enter the debugger and be able to directly patch the running server code and possibly bypass security mechanisms.

One well publicized attack method allows a locked (via MONITOR.NLM) console keyboard to be unlocked. Securing the console ensures that additional NLMs may only be loaded from the existing NLM search path and also prevents loading of a hostile NLM from the server's floppy drive (REMOVE DOS does this also) or from any other location within the mounted volumes of the server.

Note: Neither the SECURE CONSOLE nor the REMOVE DOS method of protection applies if you allow RCONSOLE connection capabilities, since you can load and unload NLMs through the RCONSOLE utility itself.

Disable All Remote Console Capabilities. RCONSOLE has a known weak password mechanism: an intruder with access to packet capture tools might be able to trap the REMOTE password, decode the password, and gain access to the console. It is good practice not to use it under any circumstances unless you recognize it as a security vulnerability and can tolerate the inherent risks.

Use CONLOG to log all Output to the Server Console Screen. The NetWare operating system displays a lot of useful information on the server console screen. However, this information typically scrolls off the screen and is lost unless you use the CONLOG.NLM utility to capture console messages and write them to a log file. Currently this is the only way to audit console usage. CONLOG.NLM comes with NetWare 4.1 and later versions, and the utility can be downloaded for NetWare 3 from Novell's web site at http://support.novell.com by performing a search on the CONLOG.EXE file.

The utility must be unloaded in order to close the log file and make it available to read. To do this, simply place LOAD CONLOG <Enter< at the beginning of the AUTOEXEC.NCF file and UNLOAD CONLOG <Enter< at the end of the last .NCF file loaded (usually the AUTOEXEC.NCF file).

Ensure that NetWare Disks Cannot Be Accessed from DOS. Normally, if a NetWare server is brought down to DOS, DOS-based programs can access the NetWare disks. One way to protect against this is to use an IDE disk to boot DOS, but use SCSI disks for the NetWare partitions. Make sure the BIOS chip is removed (not just disabled by the configuration utility) from the SCSI controller, and that DOS does not have access to SCSI drivers for the card. This prevents direct editing of the NetWare volumes from DOS.

Remove DOS from the Server. Because the underlying DOS file system is normally accessible to the file server and because NLMs are not subject to the security access restrictions (NDS and file system) that apply to workstations, any person with access to the file server could load a hostile NLM on the server from the server's floppy drive. Hostile NLMs can be written to do almost anything the writer desires. For example, NLMs have existed for some time that directly change a user's password (typically targeted at ADMIN and the bindery services SUPERVISOR).

Removing DOS by typing the "REMOVE DOS" command at the console prevents an unauthorized person from loading a hostile NLM from the file server's floppy drive.

Note: In order to make the REMOVE DOS command effective, you must also prevent the loading of the REMOTE.NLM from the server console or through the AUTOEXEC.NCF file (or any other .NCF file for that matter).

Consider Additional Console Security. Several third-party products have been introduced to enhance console security. One such product is SecureConsole for NetWare, from Protocom Development Systems. Among other features, SecureConsole provides console access restrictions by bindery/NDS user ID and password, automatic console locking, the ability to restrict console commands by users/groups, and the auditing of login attempts and commands executed by users. More information is available at http://www.serversystems.com/secure.htm.

Require Passwords for Print Servers. When using Novell PSERVER.NLM print servers, assigning passwords to each print server guards against a print server "spoof" where a program, run from a workstation, acts like a print server and gets access to all print jobs in the queue. Since the default print security allows the print server to assume the rights of the print job submitter as it services the job, a print server spoof could scan the waiting print jobs, select a job submitted by a high system privilege user, and exercise that user's rights for any other purpose.

You can avoid this security problem by applying the following SET parameter:

SET Allow Change to Client Rights=off (default=on)

Requiring a password for a print server effectively requires the print server to perform a login check similar to a user.

Ensure That All Servers Are Correctly Patched. Novell releases patches for its operating systems to fix known and potential problems, as well as to improve performance. Potential security vulnerabilities are also addressed by some of these patches. It is strongly recommended that you keep up-to-date on the latest patches found at http://www.novell.com.

Securing the Network

The following server settings will help secure the network as a whole. (These settings are all included in the SECURE.NCF file for the NetWare Enhanced Security server.)

Enable NCP Packet Signatures. Packet signatures protect from connection hijacking (such as is done by various hacker programs--which, by the way, cannot be loaded if you follow the physical security procedures outlined above). Setting this option to 3 forces the use of packet signatures at all times:

SET NCP Packet Signature Option = 3

Ensure that you have the latest client software for your workstation platform in order to properly support packet signatures. Note that NetWare 3.11 requires the special security patch (which includes packet burst) to use NCP packet signatures.

Do Not Allow Unencrypted Passwords. The default server setting for unencrypted passwords, which should be kept, is:

SET Allow Unencrypted Passwords = OFF

Very old client software sent user passwords over the network in plain text, which could be viewed by packet sniffers. This setting ensures that a user with such software is unable to log in (the login request will be rejected), and will enable you to locate and upgrade outdated client software. Very few sites still use such old client software.

Rejecting Bad NCP Packets. To reject NCP packets with bad components or lengths, use the following settings:

Set Reject NCP Packets with Bad Lengths = ON Set Reject NCP Packets with Bad Components = ON

These options can protect against badly formed packets possibly sent by malicious utilities. Sites still running older versions of the NetWare utilities should exercise caution as these settings may cause the utilities to fail.

Securing Novell Directory Services Information

Generally, Novell Directory Services (NDS) is quite secure. However, it is worth checking the version periodically to make sure your servers are running the current DS software.

Ensure You Are Using the Latest Version of NDS (DS.NLM). Updated NDS software (DS.NLM) is released from time to time for different versions of the NetWare operating system, providing increased performance and bug fixes. In particular, older versions of DS.NLM (pre-IntranetWare) did not check the integrity of some synchronization packets, which could result in inconsistent trees when packets were corrupted in transit over the network. You can obtain NDS updates from Novell at http://support.novell.com.

Remove [Public]'s Browse Rights to the Tree. On a network using Novell Directory Services where external users have access to the network (such as a university), you may want to remove the Browse rights that [Public] has to the [Root] of the tree. This will prevent unauthenticated users from easily guessing the names of other users (and administrators); however, it will require additional work to enable user-friendly logins.

Administrator Account Recommendations. Provide your system administrator with the capabilities and security equivalencies of the ADMIN user object and then delete the user ADMIN. Since the ADMIN account is a known high privilege account, it is the most likely target for an unauthorized entry. One way to frustrate unauthorized access attempts through the ADMIN account is to delete the account after another user is assigned those rights directly. Another option would be to leave the ADMIN account in place but remove any rights beyond those that a regular user would possess. A potential intruder could then hack away at an account which, if penetrated, would yield no special access. You can also set the intruder detect for the Organization container (which wouldn't normally have any other users) at a very tight level to further slow the attempts.

Security equivalence should not be used as a means of granting administrative rights. Security equivalence was the method used in NetWare 3.x to grant supervisor level rights; however, it is inadvisable to use this for NetWare 4 since any administrator who acquired rights via security equivalence would lose those rights if the ADMIN user were deleted. Instead, assign the Supervisor object right for the [Root] object to the system administrator. NDS rights should be assigned directly to the system administrators or to an Organizational Role for [Root] administration.

Check Access Control List Rights in NDS for All Users Other Than ADMIN. The flexibility of NDS rights assignment creates several possible points of attack. Objects appearing on the Access Control List (ACL) of any object have been granted explicit rights to that object. The ACLs of the following objects should be checked on a regular basis to see if someone has been assigned rights in addition to default rights:

[Root]
Every container
Groups
Organizational Roles
File Servers
Any user with explicit rights to other objects

There should be no unexpected entries as trustees of these objects. Simplicity and consistency of NDS rights administration will enable faster and easier reviews. The use of Organizational Role objects as trustees is suggested. Any non-Organizational Role object on a trustee list should be investigated thoroughly.

Check for Security Equivalences. Check for possible security holes created by security equivalences. The following NLIST commands will list any potentially dangerous security equivalences:

NLIST username where "equivalent to me" exists



     show "equivalent to me" /r /s



NLIST servername where "equivalent to me" exists



     show "equivalent to me" /r /s



NLIST groupname where "equivalent to me" exists



     show "equivalent to me", "member" /r /s



NLIST "organizational role" where "equivalent to me" exists



     show "equivalent to me", "occupant" /r /s

NetWare 3-experienced administrators tend to fall back on the NetWare 3 paradigm of using security equivalences instead of using the NetWare 4 method of direct rights assignment. Regular use of these commands can identify administrators in need of further training, as well as spot possible security holes.

Redirecting the output of these commands to a file might be necessary. To do this, simply add a Greater Than sign (>) followed by the filename at the end of the NLIST command.

You should ensure that there are no occurrences of objects with security equivalences to users or servers. An upgraded NetWare 3 server will automatically create security equivalences to the server object for all "supervisor equivalent" NetWare 3 users, and security equivalence to the server object results in complete file system rights on that server. Remove these and apply the correct rights via direct assignment.

The lists for group objects ("equivalent to me" and "member") should contain exactly the same names. NetWare assigns group rights by automatically making group members security equivalent to the group. Any differences between these two lists would indicate a problem in the rights assignment. A user that is on the "equivalent to me" list but not the "member" list might indicate an attempt to bypass security via a "hidden" security assignment. The NetWare Administrator will successfully search for these objects but doesn't currently have the capability to display the actual values of "equivalent to me". Investigate these carefully and eliminate any differences.

The Organizational Role object uses the same security mechanism (automatic security equivalence) as the group object. The same suggestion applies: "equivalent to me" and "occupant" should be exactly the same. The Organizational Role object is a more likely target for this type of attack because it is more commonly used for high-level NDS and file system administrative assignments. Investigate these carefully and eliminate any differences.

Managing the Server's File System

There are numerous ways to manage the server's file system files and directories in a more secure manner.

Learn and Understand File System Directory and File Attributes. Novell software provide file system security through file rights, what the user can do in a given directory, and through file attributes, what can be done to the files (such as read only). By understanding how these work, the files can be protected from accidental and malicious intrusions.

Always Install Network Application Software to Specification. Every manufacturer provides detailed specifications for their application software. These may include items like RAM requirements, hard disk space required, video resolution, and so on. Carefully following these guidelines will assure the software performs adequately.

Install Software in its Own Directory. Software should be installed in its own directory for the sake of easier maintenance of individual programs. Normally these applications will be installed in stable volumes. Application files should be flagged as READ ONLY. This will prevent the file from being accidentally erased or removed.

Verify Sizes for Installed Executables with the Manufacturer . Check files periodically to ensure they have not changed size. By verifying file size, the administrator can determine initial disk space requirements. Additionally, by knowing the original file size, the administrator can determine if any viruses have been introduced to the file.

Install an Anti-virus Package for the Network. Use one that can be set to autoload in the login script. A comprehensive anti-virus program should include an NLM to scan the files on the server and workstation components to protect against the common perimeter point of introduction.

Securing User Accounts

The main risk to user accounts is that an intruder will either guess the passwords or find them by some brute force method. It should be recognized that intruders may not necessarily come from outside your organization; they might even have a valid and active user account on the network.

Use Intruder Detection and Lockout. This feature should be enabled at the container level in NDS, or as part of the Supervisor Options in SYSCON in NetWare 3 networks. Without intruder detection and lockout, it is difficult to detect and stop brute-force password guessing attacks.

Intruder detection settings limit the number of incorrect passwords a user or potential intruder can try with a given configurable time period. Too many incorrect attempts indicates that a user has either forgotten the password, can't type or is, in fact, an intruder. The option then exists to lock that account for a specified period of time. Intruder detection is set at the container level.

Purposeful attempts at the ADMIN or other high-level administrative account could be used to deliberately deny access to system administrators. The "enable login" console command resets the bindery services SUPERVISOR account which can then reset any user's account within the bindery context via SYSCON. Another alternative is to maintain an administrative account with rights to manage the other administrative accounts in a container without intruder detection.

Set Login Time Restrictions. Another way to control user access is to limit the time of day when users can be logged in to the network. Refusing logins after reasonable business hours ensures that employees can only access the network at certain times and prevents late-hours tampering.

Limit the Number of Concurrent Connections. The more times a user is logged in to the network, the harder it is to determine if that user was really the person who logged in. Limiting the number of concurrent connections to two or even one makes tracking users' network access easier and provides an additional level of security by reducing the number of logged in but unattended workstations. Administrator accounts, in particular, should have limited concurrent connections. If an administrator should receive a denied login due to a current connections limit she would immediately know that her account had been compromised, or that another login had been inadvertently left active.

Give Every User a Password. Forcing users to use a password provides a minimum level of protection against unauthorized network access. Choose a password for ADMIN that is not common or easily discernable by anyone. Require your end-users to do the same with their own passwords.

Common or easily discernable passwords can be broken quickly and with little effort. Using phrases, non-alphanumeric characters, and non-dictionary words will make breaking a password that much harder for intruders. You can strengthen your password policy by increasing the length or diversity of types of characters in the password. Here are some general guidelines for good password management:

Passwords must contain characters from at least three of the following four categories:
- English uppercase letters (A, B, C, ..., Z)
- English lowercase letters (a, b, c, ..., z)
- Arabic numerals (0, 1, 2, ..., 9)
- Non-alphanumeric characters such as punctuation or symbols (!@#$%^&*()_+&&;)
Passwords must not contain the user's e-mail name, parts of the user's full name, or other familiar names of family, friends, acquaintances, and so on.
Passwords should not be a "common" word.
Passwords should be easy to remember yet complex. For example, Ilve2:)@TSSet (a representation of "I love to smile at the sunset").

Require Periodic Passwords Changes and Unique Passwords. When old (favorite) passwords are allowed to stay in use indefinitely, the chance of a compromised password increases over time. Most users won't change their passwords unless they are forced to, which can create security problems: the older a password is, the more likely that it has been compromised. Changing passwords on a regular basis ensures that even if an unauthorized user did obtain network access using a compromised password, that password will only be valid for a given time before the real user changes it.

Do Not Allow Re-use of Passwords. Reusing passwords can cause a great deal of trouble: if an unauthorized user knows that a person reuses passwords, he or she can simply cycle through a list of known passwords until the unsuspecting user reuses a password on the list and inadvertently grants access to the unauthorized user. Use the account restriction to "require unique passwords". The system tracks the last eight passwords used for more the 24 hours.

Require Specific Password Length. Users tend to use short, easy-to-remember (but easy-to-guess) passwords, unless passwords are required to be of a certain length. Eight characters is considered the minimum for secure environments.

Don't Use Cross-System Passwords. The NetWare login process protects the password by using a highly secure cryptographic mechanism. But if the same password is used for different applications on multiple systems, a secure user password could be discovered because a less secure system uses the same password. You can limit system exposure from accidental password compromise by maintaining different passwords for different accounts or applications (for example, user account, administrative account, e-mail system, console lock, remote console, host systems, and so on).

However, there is a risk that users will resort to recording passwords on paper if the number of needed passwords gets too large. Also, NetWare provides no mechanism for assuring the uniqueness or too many cross-application/cross-system passwords, so this security measure needs to be implemented by system policy and user education.

Regularly Run a Password Checking Program. NetWare does not have hooks for password-screening programs (sometimes called fascist password programs), so users cannot be prevented from choosing passwords that are easily guessed (such as their first names, last names, or other commonly-used weak passwords). However, a commercial password-checking program called SmartPass is available from e.g. Software, Inc. Details are available at their web site: http://www.egsoftware.com.

Ensure Workstations Are Turned Off When Not in Use. Train users to log out and turn off their workstations during lunch breaks and at the end of the working day. This practice is good general security hygiene; it ensures that nothing is left in memory for subsequent users of the computer to find. It also prevents a specific attack in which logging out is disabled on a compromised workstation, leaving it logged in and vulnerable to unauthorized use.

Disable or Delete Unused Accounts or Accounts of Terminated Employees. Leaving old or unused accounts active creates a major security hole: at best, former employees can still gain access to information and applications on the company network; at worst, disgruntled employees could cause serious damage by introducing viruses or stealing or destroying vital information. In addition, unused or rarely used accounts that aren't disabled or frequently monitored provide a perfect opportunity for unauthorized people to access the network for long periods of time before being discovered.

If You Must Use RCONSOLE on the Network

Use NetWare's Remote Console (RCONSOLE) utility only if absolutely necessary. The traffic sent between workstation and server is not encrypted. This allows eavesdroppers to see every screen you view during a remote session (which may include AUTOEXEC.NCF loading REMOTE.NLM with its password) and to catch keystrokes you make (which can also include passwords). Remote console access to the file server can be just as damaging as allowing direct physical access to the file server. If someone obtained access to the AUTOEXEC.NCF file, they would be able to access the file server console.

If you must use RCONSOLE, follow these steps to set it up as securely as possible:

Make sure you have a newer version of RCONSOLE (see below).
Unload RSPX.NLM and RS232.NLM if they are loaded.
Unload REMOTE.NLM if it is loaded.
Type the following command at the server console to load the service with no password:

LOAD REMOTE -NP
Enter REMOTE ENCRYPTat the server console.
Type the password when prompted.
Press Y to save the Load command to SYS:SYSTEM\LDREMOTE.NCF.
Unload REMOTE.NLM.
Type the following commands at the server console:

SYS:SYSTEM\LDREMOTE.NCF LOAD RSPX
Add these commands to the server's AUTOEXEC.NCF file.

This setup ensures that if you edit AUTOEXEC.NCF with RCONSOLE, no one can capture the encrypted password from the screen image to crack it off-line.

Avoid Older Versions of RCONSOLE. Older versions of RCONSOLE sent the password across the network in an easily-decoded manner. This is true of the RCONSOLE, REMOTE and RSPX modules that come with NetWare 3.11 or earlier. Always use the newer versions of RCONSOLE, REMOTE and RSPX that come with NetWare 3.12, NetWare 4.x and IntranetWare.

The newer versions of RCONSOLE attach to RSPX.NLM using a challenge-response method similar to the NetWare 3 Keyed Login protocol. This does not send the password across the network. Newer versions also prevent RCONSOLE connections from being hijacked by using packet signatures. It appears unlikely that an intruder can perform a protocol rollback attack to cause the unsuspecting RCONSOLE client to send the password across the wire in the old format.

Make Sure RSPX Packet Signatures Are Enabled. This is the default on versions of RSPX which support packet signatures. You can check that they are enabled by typing RSPX <Enter< at the server console screen when RSPX.NLM is loaded. You should see the following:

RSPX Packet Signatures:

          All packets must contain signatures.



     RSPX Connection Information:

          (lines here for all current RCONSOLE connections)



     Type 'RSPX HELP' for a list of RSPX commands.

RSPX packet signatures are different from NCP packet signatures. RSPX signatures only apply to the RSPX information sent in SPX packets during a remote console session with the server. NCP packet signatures only apply to the NCP requests sent in IPX packets to the NetWare server.

Conclusion

This AppNote has outlined ways to protect your network from various types of known attacks. In NetWare 4.11, many of these protections are automatic due to the Enhanced Security architecture and its procedural security requirements. New versions of NetWare include even more advanced security features--all integrated with NDS to give administrators control over the entire security infrastructure of their network.

* 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.