Novell is now a part of Micro Focus

Chapter Two: Security Basics

Articles and Tips: article

01 Apr 1994


Security Basics

In the network computing industry, there are various examples of computer security - password protection, virus checkers and locked server consoles are a few such examples. While these components are important aspects of implemented security procedures, they are only methods and devices belonging to a much greater endeavor - that of establishing security in the overall network environment.

This chapter begins with a conceptual discussion on security issues in NetWare 4. This information details the components from which realistic security efforts must be derived, and provides a context for the reader to use while reading the various discussions on security and auditing within this report.

In this chapter, both theory and application for network security are presented in a manner which allows you to discover security weaknesses and find solutions immediately. If you have an interest in network security, or if you are exploring security features in NetWare 4, you will find the basic security information in this chapter helpful.

The Basis of Computer Security

The basis for network security comes from the simple concept of sharing. If it were not for sharing, simple isolation techniques alone would eliminate the need for any further levels of security. However, once internal and external sharing schemes are used with programs and data, implementing and maintaining security to protect the data and systems becomes a prerequisite.

Note: When implemented properly, security can be used to securely enable sharing as well as using it strictly for the purpose of disabling use or access.

In today's industry, computer networks are a crucial business asset - greater than the sum of both workstations and servers combined. Modern networks are made up of several components including servers, cables, workstations, services, and peripherals. With each component comes some new technology, procedure, or consideration.

Additionally, at every level of network implementation - from the workgroup to the global enterprise - we find new components and varying scalability, as well as a changing implementation paradigm as components, configurations, and administrators change.

To implement complete security, each component and user will require evaluation - and often action - by a network administrator before the network can be secure. A complete network evaluation is vital to understanding and implementing proper network security.

What is Security?

Security, defined in its simplest form, is "freedom from danger or risk of loss; safety." Thus network security can be considered as any effort made to protect a network from danger or risk of loss - making the network safe from intruders, errors, and other threats. While this is an over-simplification, it makes the point that network managers want to keep their data and resources safe.

Next, it is important to define what "trusted" means in the context of network security. The concept of "trusted" is different for different needs. For some networks, something as simple as implementing user passwords and an anti-virus program may suffice as enough to classify the network as being "trusted". However, for a Fortune 500 company running mission or business critical applications on a network, the concept of what constitutes a "trusted" network is markedly different. This advanced conception of "trusted" may require a complete network system with at least a C2 level of security (as defined in Chapter 1).

Depending on the network and the importance of the data, define the amount of protection your network requires. This determines the criteria for what a "trusted network environment" is for the network. The effort and resources spent on protection should directly correlate with the value of the protected items.

With this in mind, objective evaluation criteria can be applied as the basis of an effective security policy.

While too much protection for an inconsequential item exemplifies waste and inefficiency, it also points out the need to examine an object's value before exploring the dangers it may be subjected to.

Note: Security can increase the difficulty of system access and use by legitimate users. By decreasing the likelihood of unauthorized system access, the burden on authorized users may be increased. When planning for network security, consider the trade-offs involved between security and the possible increased difficulty for authorized users - not just the monetary benefits.

The question, "Is an item subject to attack?" always receives a "yes" answer. Thus, determining an item's value is likely to provide a better basis for security needs. Answers to such questions as "Is this item worth an attack?" and "Could someone inadvertently allow access?" provide more insight to the level of security necessary.

Note: The questions above beg for an answer on how items are valued. Certainly some valuation methods are more appropriate than others, and pertinent questions about how long one can actually do without a service must be examined.

Once perceived values and potential weaknesses have been defined, it is possible to discern the credible potential for an attack. The "incredible" attack is better left to fiction writers - few intruders will attempt an impractical assault without commensurate gain. However, the inadvertent mishap is another matter well worth examining (especially in the area of providing redundancy).

The successful implementation of a few practical security measures - such as file system security, regularly scheduled backups, strict login and password procedures, and so on - virtually eliminates the majority of practical assaults and inadvertent errors. Another important item to consider in this context is "Can you trust the people that have access to your network environment?"

Security Basics

Once the potential and credibility of an attack has been identified, it is time to employ a methodology to protect the network from possible attacks. Such a methodology would encompass the following points:

  • Understanding what protection is available

  • Identifying specific areas of possible attack

  • Identifying suitable countermeasures

  • Instituting (deploying) countermeasures

  • Monitoring changes in the system and countermeasures

Each of these items contributes to the protection of a network. Before you can develop or implement a useful security policy, you must know and understand what protection is available, and what that protection provides.

Security Policy

A network security policy should define not only what is to be protected, but also state what constitutes a loss. Once these two items are clearly defined, the people writing and implementing the security policy should have a good idea what they are trying to accomplish.

An example of a loss might be a user losing his password. In NetWare 4, end-users can forget (lose) their password. While the network system does not lose the password, the user cannot gain access to the network without the help of an administrator. In an enterprise network, this might entail end-users calling the network help desk to have their password cleared or reassigned to allow them network access. Something as simple as verifying who is calling for the new password, and making sure that the proper person is the only one receiving the new password is important. This is a situation where a specific network security policy should exist.

A basic security policy defines what is to be protected in the network system. This policy must also take into account the fact that not all information about a computer network actually exists or resides inside the computer system. For example, passwords exist both inside and outside the computer system.

Inside the computer, passwords are maintained at the server for reference during the login process. Outside the system, users might post their passwords on their keyboards, monitors, or paper. Security policy must cover all of these possibilities.

NetWare 4's RSA authentication process provides a level of security required by most internal identification and authentication policies, but cannot maintain passwords outside of NetWare (such as passwords posted on the user's keyboard).

Simply defining a loss of system integrity due to unauthorized access, system or data manipulation, or lack of availability can be quite time-consuming. Understanding what countermeasures are available and can be implemented takes even more time. To achieve a specified level of protection and trust, it is imperative that specific threats be identified and countered.

Identifying Threats

There are four general areas of data security concerned with potential threats:

  • Physical (including hardware)

  • Operating system-level

  • Communications

  • Procedural

Physical Security. Physical security is directed specifically in one of two directions: outside the computer, and through ISO's OSI model of the physical layer. Most physical security is concerned with keeping equipment locked up, proper passwords implemented and enforced, and keeping unauthorized people away from network resources. Essential elements of physical security are theft prevention, tampering avoidance, and containment of signals that can be monitored.

Even within subordinate areas like hardware security, there are differences between hardware containment to prevent physical theft and hardware containment to prevent tampering or inadvertent misuse. While the first can be addressed by physical security, the second is a matter of procedural security - assuming you allow someone workstation or remote access.

The other area of physical security has to do with the network frame type (such as 802.3, 802.5, and so on) as identified by the IEEE where one might try restricting specific network traffic (packets) from other parts of the network or by not allowing monitoring of other addresses on the network. This may require separate physical channels for communications. There are options for anyone establishing physical security at this level.

Like any data network or network operating system, NetWare 4 has one major area for attack: unauthorized access to the network. This is the primary area network administrators need to focus on, as it is extremely relevant to any discussion of security.

Assuming you have effective physical security, the next threat to system integrity is unauthorized access to the network itself. This threat can be depicted in two areas: those seeking access without knowing the network (from outside), and those seeking access to the network from the network (from inside). For a discussion of outside access, read the NetWare-specific "Security Threats" section of this chapter. This section offers a less rigid treatment describing the inside attack.

Both types of security attacks mentioned above pose a threat since the underlying motives are against any security policy. Attacks from someone outside might be attempted in order to siphon data from the authorized traffic of the network, or to gather information about the structure of the network itself - often in preparation for an insider attack.

For someone with access to the network hardware (inside access), there are three areas of possible network attack:

  • Hardware attack where someone attaches a device to the network to gather and siphon off data

  • Software attack where workstation modules - operating systems, TSRs, and application software - are modified to gather data from the system and save it for later retrieval or to deny data or network access

  • Masquerade attack where the perpetrator uses the identity of an authorized user to obtain access to the network

A masquerade attack is usually performed for the purpose of searching the network structure using someone else's identity, or using one's own identity to search an unsecured network structure or data.

Both of the methods for an inside attack require access to an operational workstation or network terminal. With operational hardware available, there are multiple options available to impose a security threat.

Insider attacks on networks are the most common, especially if workstations are not secured. An unsecured workstation can allow a software attack. Of the two types of software attacks which can be mounted, the most common is the dictionary attack. This is when a person looks for a way in to the network usually by randomly entering possible user names and then supplying possible passwords.

The other type of software attack involves more sophisticated methods. Software known as a trojan horse is loaded on the workstation and allowed to gather information about the users at login time. These programs can be very small and deceptively like other programs used in the workstation, sometimes even having the same filename.

The usual options available for an inside attacker are:

  • Operating system-level attacks (including bugs)

  • Trojan horses

  • Viruses

Operating System-Level Security In networks, the application software uses operating system calls to function. For example, applications regularly ask the operating system to locate, store, and retrieve files. Most applications relegate these matters to the operating system to achieve a level of consistency in the manner by which programs and data are shared.

In a network operating system, one expects to find a shared-resource system where information is shared between users. NetWare 4 is designed around the controlled sharing of information utilizing user-specified access controls in a highly efficient capabilities-based system architecture. The architecture provides for capability changes to be immediately enforced between the server and the client.

In the NetWare 4 operating system, users have direct access to objects in the system (for example, the ability to see the directory structure, read data, or execute programs). The user's access to objects in the system is derived from the NetWare Directory Services (NDS) access specifications. In addition to NDS access specifications, file objects are covered by file access specifications. Finally, the network operating system provides security by utilizing memory access management, isolation, and both unrestricted and controlled sharing methods.

While it is true that network programmers can circumvent this architecture by writing and distributing system-level programs that violate the security mechanisms, this misuse can be precluded by not allowing unauthorized individuals to install software on the network. Another method of preventing this architecture circumvention is to make a list of "approved" software (software that has been tested to not violate the network's security mechanisms), and only allow software from this approved list to be installed on the network system.

Note: This concern over possible security breaches caused by system-level programs is one of the reasons Novell sponsors programs to evaluate and certify NLMs, and provide other subordinate system level programs.

There is always the potential for discovering an architectural flaw in the network or client operating system. You may hear of application software which "exploits" bugs in the operating systems. This includes client operating systems which are weak in the implementation of security functions. Bugs in recently released client operating systems are not uncommon, and can be a barrier to service, as well as leading to the possible loss of data integrity.

Even if the server operating system performs well with regard to message integrity and user authentication, there is another problem which can allow someone to tamper with your network. This problem is based on user-defined access controls (DAC) and insecure workstation operating systems, and is commonly known as the trojan horse.

The reason the trojan horse works is because workstation operating systems are largely unmanaged and easily assailable. The main source of prevention for the trojan horse attack is to assign correct and accurate access rights for users. This is the responsibility of the network administrator, and should not be left up to the individual user.

For example, if the file rights for the LOGIN.EXE routine in the LOGIN directory were changed to [RWF], an end-user could change that LOGIN.EXE with a different LOGIN.EXECperhaps one that records users' names and passwords. The network is especially vulnerable in an environment where workstations are shared by more than one user.

Communications Security. Communications is another area of security concern. This concern consists primarily of the following two types of attack:

  • Tapping

  • Spoofing

Tapping an open telephone line in a data communications system is similar to a hardware attack except that it can be done externally, and requires no knowledge of the computer system being monitored - only of telecommunications. Wire tapping provides a high risk for attack on any system which uses telephone or wire communications. While satellite communications provide varying degrees of isolation on outbound communications, they can have problems similar to tapping on incoming signals.

Spoofing is pretending to be a server or peer. It requires detailed knowledge of the system, and may be part of an insider attack. There are multiple kinds of "spoofs" that can be employed. A program can be put in place to replace the login program and gather usernames and passwords (this could be an access control breach or an attack by a disgruntled employee). Another spoof can be implemented between servers, where one server identifies itself to another server for routing and communications. If the first server begins using the spoofing server, all information routed through it can be captured.

In each case, a software component is used to spoof other servers, clients, or users into believing that the software is a valid component of the communications process. Like the client trojan horse, the spoofing software can gather information without the end-users or servers knowing - unless the spoofing software is poorly written or contains bugs.

In a poorly architected situation, a spoof might exist in a server component, router, or bridge without ever being detected. Almost any form of reverse authentication - from client to server - will eliminate a spoof at the server.

Procedural Security. The final aspect of data security threats exists in the area of procedural security. Procedural security is a broad topic and requires as much detailed examination as software review. Procedural security takes its name from a concern for procedures - mounting the wrong media, booting the wrong software, or doing anything else out of the norm.

For procedural security to be effective, you must have a well-defined and workable security policy implemented. Besides defining the proper security measures that need to be implemented, you must provide implementation methods that can be achieved with a reasonable amount of effort. You must also provide plans for security implementation for each and every network function that takes place in your environment (such as creating users, adding new resources, providing resource access, and so on).

Implementing a successful security policy requires that you provide adequate controls for assuring that your security policy is being implemented and enforced. This takes some effort, but the payback will be worthwhile.

While not a topic specific to NetWare 4, compromises in procedural security must be of major concern for a network administrator. The following example may help you better understand what a procedural security threat is.

Imagine that a new user is going to be assigned to the company's database application, and this is the first time any user below the level of supervisor has been assigned to this application. If supervisors are allowed access privileges, which others are not, a review of the new user's access privileges is in order. If the security policy requires a review of a user's access privileges in this circumstance, then a failure to review these privileges for this user can be considered a procedural security compromise.

Procedural security threats can encompass any of the ways we do things wrong. Hence the sheer size of the topic grows with every additional operation we perform. When defining basic procedural network security, consider the following:

  • How software is installed

  • How the system is administered

  • How user rights and privileges are administered

  • How the system is restored

At the network level, procedural security requires a lot of research on the part of a security analyst. This research includes - but is not necessarily limited to - uncovering procedural flaws documented in previous systems, comparing levels of trust for different versions of operating systems, and evaluating methods of protection. Thus procedural security is a vital part of an effective overall security implementation.

From the discussions above, it is evident there are many interactions between the areas of security attacks. They are not independent, nor are they isolated. In fact, anyone desiring to penetrate a computer system would likely use as many possible attacks as they had resources to muster. Thus, in viewing these areas of threat, it is important to keep in mind that for every "plausible" threat, a countermeasure is needed.

Developing Countermeasures

A countermeasure is any process or device instituted to counter a security threat. Countermeasures protect some component in the network. For instance, network countermeasures could include methods of authentication for programs or cryptographic systems utilized for communicating and storing information. Additional countermeasures could include the development of audit trails within specific programs, developing threat detection mechanisms in the operating system, and developing internal consistency checks. Countermeasures can extend all the way from non-technical to esoterically complex technical methods. Countermeasures are your means for protecting your network.

There are four areas for implementing countermeasure methods:

  • Physical

  • Software

  • Personnel

  • Procedural

To develop and deploy a new or built-in countermeasure, a network administrator must have a clear idea of what the countermeasure actually protects, how it protects, and whether the degree of protection is adequate to enforce the security policy. NetWare 4 currently provides several types of protection for the network. Knowing where this protection exists and understanding the degree of trust attributed to the protection is necessary for implementing a successful security policy.

The key to instituting a countermeasure is identifying what protection is considered secure or "trusted," and why or how it is trusted. In NetWare 4, the following areas should be considered for protection even before client applications are installed on the network:

  • LOGIN directory and executables - the process of being connected to NetWare

  • NetWare Directory Services - what network information users are allowed to see, or find out about

  • File and Print Services - what programs users can execute, and what resources and data they can access

The areas listed above should not be modifiable or accessible by every user. Unauthorized access can be overcome by using a combination of the Mandatory Access Controls (MAC) to control how the system data is accessed and the Discretionary Access Controls (DAC) to control what users are allowed to see and modify.

NetWare 4 provides an authenticated login to assure the identity of an end-user and to stop any unauthorized user. However, you should avoid automatically accepting the workstation as being secure simply on the basis of the network authentication process. Recognizing the limitations of workstation hardware, software, and operating systems is essential to developing effective countermeasures. Understanding that workstations are one of two primary sites for unauthorized access, and taking steps to limit the chances for this access is imperative.

Considering the threats to data security mentioned in the last section, we saw two basic types of network intrusion: those seeking access without knowing the network (from outside), and those seeking access into the network from a position on the network (from inside). By far the latter is more common.

For most attacks to be successful, workstation access is a necessity. Workstation-based attacks can come from any attached workstation. All three of the network attacks listed above require physical access to the workstation hardware. Thus, the simplest countermeasure is to deny workstation access to those who are not authorized users, and lock up workstations when not in use. This provides a relatively effective countermeasure, similar to NetWare 4's ability to limit where a user can login from. Additionally, remote workstation access can be limited by installing and implementing the dial-back feature of NetWare Connect (or other add-on products). Enabling NetWare's audit function provides the ability to detect modem intruder attempts.

There are several devices available which can be inserted into the floppy disk drive and effectively lock the front cover of the computer to the floppy drive. These mechanisms prevent the workstation from being opened or booted from diskette, and are quite effective countermeasures (especially for workstations that can't be locked up in a secure area). These devices prevent the introduction of viruses and trojan horses by unauthorized users.

Additionally, workstation tampering (getting into the workstation) can be deterred by instituting a workstation security program consisting of locking workstation cabinets and periodically monitoring the workstation to assure that component devices have not been tampered with.

It is important to remember that attacks on a network are not limited to unauthorized workstation users. The network may also be at risk - especially where users may inadvertently introduce viruses or install improper software at the workstation. Even network supervisors have been known to put incorrect versions of software on the network. This brings about the potential for a "denial of service" attack.

In any case, the trusted operation of a workstation is based upon the integrity of data files and executables. If the data or executables become corrupt, access can be denied. The most straightforward method to implement an effective countermeasure here is to use diskless workstations with password protection and physically secure printers.

For any environment where diskless workstations are not a viable option, security devices which control disk access, use of peripherals, and system booting may be more appropriate.

Even this is not an entire workstation solution. There are other potential modes of access and attacks. This only highlights how susceptible workstation hardware and software is to security attacks.

Note: Workstation security can be a difficult area to prevent security breaches. There are numerous methods of subverting the local operating system to gain unauthorized access to the network. These shortcomings are one reason that Novell is participating in the C2 security evaluation with the National Computer Security Center (NCSC) as well as E2 certification in the European Community.

One of the most important factors to consider for workstation attacks is the user. If the user is trustworthy and implements the workstation security features outlined in an organization's security policies, the risk of unauthorized use is greatly reduced. Trust - both of the user and the security implementation - is imperative.

When security exposures are identified and suitable countermeasures have been defined and developed, they must be implemented within the computer security system. This requires completion of the three following procedures:

  • Design of necessary procedures

  • Effective training of personnel

  • Providing adequate security documentation

Of these three points, training is the most important. Existing procedures are worthless if your personnel are not properly trained in executing those procedures.

The final procedure - and the one with the greatest significance - is monitoring countermeasures for effectiveness. No matter how you define security, monitoring what people do, and how the system is used is as significant as all other countermeasures combined. Through the years, this has been proven, and has diversified the security function by adding an entire an additional step to security monitoring - auditing. While the rest of this chapter is devoted to security functions, it is important to note that more than half of this report is devoted to auditing.

A systems audit can be invaluable to the system's security analyst. It provides checks and balances, evaluation for existing countermeasures, the potential for discovering new security threats, and the opportunity to develop new countermeasures. This provides the security analyst or network administrator the opportunity to receive input from an independent group that is not a normal part of the security group. The security administrator should work closely with the system auditors and inform them about new or additional functions.

In addition to receiving input from auditors, the security administrator should continue to define and respond to suspicious events and real-time alarms, keep and analyze records, and provide active testing and evaluation of new software. In a trusted network, there is no such thing as installing out of the box software without security evaluations of access parameters, access controls, and system interaction.

Conclusions About Security Basics

The implementation of security principles leads to a concept of what a "trusted" environment actually is. For many systems, a simple password and anti-virus program may suffice for a "trusted" system (by policy). In other systems, the concept of "trusted" may have more far-reaching consequences as can be seen in the concepts set forth by the NCSC regarding security evaluations. In any case, the trust imputed to a system is delivered by some form of assurance that security features cannot be disabled or circumvented, and that they work effectively against real threats.

NetWare-Specific Security Threats and Countermeasures

The remainder of this chapter addresses various security threats and countermeasures as they apply specifically to the NetWare computing environment. Some of these countermeasures involve steps that can be taken to ensure physical security within the organization.

Securing the Server

Despite Novell's best efforts to persuade network administrators to keep their NetWare servers in a locked room, there are still sites where servers are as accessible as a common workstation. Indeed, at some sites it may be difficult to locate and identify all network servers. While it is not uncommon for servers to be placed in an unused office or under a programmer's desk, this practice can be dangerous.

Key Distribution

Once the server is placed in a locked room, the next item to consider is key distribution - access to the locked server room should be closely guarded. To clearly define access control to your server room, consider the following questions:

  • Who will have keys to the room?

  • Should master keys issued to cleaning, maintenance, electrical, telephone, and security personnel also open the door to your valuable and sensitive data? If any of the afore mentioned personnel are temporary help - such as contractors or employees of an outside service organization - do you trust them with physical access to your network?

Some network administrators choose to lock out everyone else and go so far as cleaning the server room themselves. The same goes for any needed repairs, where the administrator will physically watch any needed repairs being made.

Some sites use card readers or biometric devices that send alarms, locations, times, and personnel identification to a security system where access is monitored and logged.

Once the server has been physically secured, additional security features of NetWare may be implemented at the console such as:

  • Type "REMOVE DOS" to prevent loading of NetWare Loadable Modules (NLMs) from floppy disks.

  • Type "SECURE CONSOLE" to restrict the loading of NLMs from anywhere other than from the SYS:\SYSTEM directory and to disable keyboard entry to the built-in debugger.

  • Lock the file server console from within the MONITOR NLM.

  • Disable all remote console capabilities or assign RCONSOLE a unique password. XCONSOLE uses telnet and could easily compromise the console password since telnet traffic travels as clear-text over the wire. Make sure the console password is different than the ADMIN password, and never store that password in the AUTOEXEC.NCF file on the server.

Note: Besides the potential loss of backup tapes, hard drives, or the entire server to theft, physically unsecured servers are vulnerable to NLM attacks.

NLM Attacks

There are several NLM attacks in circulation with names such as Burglar, Password, Security, and so on, that let you change the ADMIN password without knowing the old password. These NLMs call the SetBinderyObjectPassword function (available in both NetWare 3 and 4) which is clearly documented in the NetWare server application programming interface (API). Since NLMs are extensions of the operating system, they are allowed to make system calls. It is the network administrator's job to know what NLMs are being loaded and what they do.

Login Process Security

There are several things that can cause security problems or breaches during the login process. This is often considered the weakest link in a computer security system. Let's look at the most common attacks or threats that can take place during the network login process.

Trojan Horse. A quite destructive login program is known as a trojan horse. A trojan horse program gives the appearance of something worthwhile happening, while it is actually compromising your security. An example of a trojan horse that attacks during the login process is a program that masquerades as the real login program while keeping a hidden log of user passwords as they are entered from the keyboard.

Network Analyzer. Another thing that can be used to breach security during the login process is the network analyzer. A network analyzer can produce a list of clear-text passwords by watching for login packets. However, this kind of passive wire tapping attack is easily defeated by simply using encrypted passwords.

Dictionary Attacks. Dictionary attacks operate as the name implies - a program can try passing every word in the dictionary as a possible password to the login program. The dictionary can contain the entire English language, foreign languages, or be a custom dictionary composed of user's names, places, favorite things, slang, and so on. Dictionary attacks are easily defeated by choosing passwords not found in any dictionary (such as using passwords with mixed letters and numbers or symbols) and enabling intruder detection. Password management and security awareness training are effective preventative measures.

Brute Force Attacks. A brute force attack occurs when someone tries to exhaust all possible passwords by trying them one by one (for instance, A, AA, AAA, and so on). This kind of attack is best countered by enforcing a large password length and enabling intruder detection.

Intruder detection notifies the system administrator whenever an account is locked (due to invalid password attempts) and should always be enabled. Either the person logging in knows his username and password or he doesn't. Two or three bad login attempts should be the maximum allowed. Configure the server to remember the bad login attempts for at least one hour and lock the account for two hours or more. Increase these time limits as necessary to allow ample time for an investigation.

A strong password management policy is critical to the security of the whole system. Since the login process involves the human element, the security depends on how the passwords are managed. Passwords must be required for all accounts. They should have a minimum length of eight characters. The system should be set to require forced password changes every 30-45 days and must be unique (these requirements can be set by the network administrator in NetWare 4). Grace logins should be limited to two or three. These limits are guidelines and should be adjusted to conform with your organization's security policy.

Several books and software products address password management in detail. The Department of Defense Password Management Guideline (CSC-STD-002-85) and Password Coach by Baseline Software are two examples. Consider using these tools (or similar ones) as part of your employee security awareness training.

Encryption/Algorithm Attacks. Another attack on the login process is exploiting encryption algorithm weaknesses. NetWare versions 2.15c and 3.10a or earlier that implemented password encryption had such a weakness. If a log key (a pseudo-random number issued by the server as a challenge) was a palindrome (for example, 1122334444332211), the output of the NetWare encryption algorithm would be all zeroes.

An illegally modified and distributed copy of ATTACH.EXE v2.00 called KNOCK.EXE exploited this weakness (although the hacker had no idea why it worked). KNOCK.EXE repetitively attempted to attach to the server without specifying a password. Amazingly, once every 10,000 attempts or so, the user would be logged in with no password required. This event happened only when the log key was a palindrome. Novell fixed this problem in versions 2.2 and 3.11 and later by making sure the server would not issue weak log keys. Patches were also widely released on NetWire as the files SEC286.ZIP and SEC386.ZIP. This is not a threat in NetWare 4.

Forged Packet Attacks. A greater threat to all networks (not just NetWare) is that of forged packets. The HACK.EXE program that came from the Netherlands demonstrated that a NetWare Core Protocol (NCP) request packet could be injected into a privileged session to grant rights to the intruder. Novell introduced NCP packet digital signatures using the RSA MD4 message digest algorithm as the first step of security enhancements to counter this kind of attack. The second step encrypts the NCP packets.

Print Server Attacks. Another important, but often overlooked area of security involves print server attacks. A print server processes jobs with the security level of whoever submitted the job. If a rogue print server were set up on the network, all it would have to do is wait for a job from user ADMIN, then perform whatever unauthorized functions it wants to while operating at the supervisory level!

To effectively counter this kind of attack, make sure all legitimate print servers use passwords (preferably not in clear-text). The number of concurrent connections must be limited for print server accounts. Physical station address and time restrictions will help. Also consider physical security (such as locating print servers in locked rooms with servers) when setting up your network security.

Login Script Attacks. A personal (or user) login script attack can easily take place when a privileged user account does not have a personal login script. If another user copies a login script into the mail directory of the privileged user, whenever the privileged user logs in, the personal login script (created by the other user) now performs some unauthorized system function without the privileged user's knowledge.

This attack can be countered by doing the following:

  • Create personal login scripts for all users (an empty login script is better than no login script)

  • Make sure all users exit from the system login script

  • Remove write and create rights (or better yet, remove all rights) for the MAIL directory from the [Public] trustee.

For more information on login scripts, see the NetWare 4 documentation.

Managing Administrative Accounts

Administrative accounts should be limited to a maximum of two or three trusted network administrators. There should be more than one administrator in case of an emergency. The administrative functions should be performed as an Admin-equivalent user that has a name that isn't obvious. (Admin, SUPERVISOR, and ROOT are obvious to nearly everyone.)

Managing User Accounts

Properly managing user accounts is an important part of network security. For starters, users should only be granted rights to those network areas they absolutely need access to.

User Account Passwords. The system users must be well educated on the importance of passwords and their use. It is virtually impossible for an administrator to analyze every user's password to ensure that passwords provide a form of deterrence from unauthorized users. In your security policy and training, set specific password guidelines and train your users in their purpose and proper implementation.

For example, you might want to require the following criteria be met for every user's password:

  • Each password must be a minimum of 8-characters (more than eight is better).

  • Each password must be unique, and not easily discernable by others who know the user (no family names, pet names, nicknames, slang, and so on).

  • Each password must include at least one non-alphanumeric character in the string.

  • Passwords are not to be recorded or stored anywhere (such as in a day planner, on the workstation, under the keyboard, and soon).

While these seem like easily implemented, common-sense requirements, a surprising number of networks have users "asking" for a security attack. Make it a point to educate your users in proper password usage. Proper education is the first step in preventing password theft from being an easy way to penetrate your network and modify or steal your data.

User Account and Password Defaults. The default settings for a new user account are assigned using the USER_TEMPLATE User object. If a User object named USER_TEMPLATE exists, then all users created subsequently will acquire the property values of the USER_TEMPLATE object as defaults. The USER_TEMPLATE object only applies to new users created in the same container. Each container (Organization or Organizational Unit) may have its own USER_TEMPLATE object.

The initial default is to not require a password for a new user. Once a password is required, several related options are available (the defaults are shown in parenthesis). These include minimum length (5), whether the password must be changed and how often this change is required (90 days), whether the password must be unique (no), whether the user can change the password (yes), how many times a user can log in using an expired password (grace logins), and the number of incorrect login attempts allowed (7). We recommend that these parameters be modifed to fit your specific security requirements.

Security Equivalences. A user can be set as "Security Equivalent" to any other object in the Directory tree. The security equivalent assignment is intended for use in temporarily assigning NDS or file system rights. Long term rights assignments should be made explicitly.

Every object is security equivalent to all containers that are part of its complete name. This is why every object automatically acquires any rights assigned to a superior container. Since these rights are acquired through security equivalence and not through inheritance, they are not subject to inherited rights filters.

The operating system uses the "Security Equivalent" property of the User object to track several automatic rights assignments. When a user is added to the membership list of a Group object or the occupant list of an Organizational Role object, the Group or Organizational Role is listed in that user's security equivalence.

Other Security Suggestions

There are a few other security suggestions you can follow in order to provide better security for your network. These suggestions are:

  • Limit concurrent connections to one per user account.

  • Set up LOGIN time and station restrictions.

  • Do not allow clear-text passwords in the login process. (SET ALLOW UNENCRYPTED PASSWORDS = OFF)

  • Immediately disable or delete user accounts of terminated employees or other inactive users.

  • Perform virus scanning as frequently as backups.

  • Keep current with the released versions of the NetWare OS and client software.

  • Use the SECURITY utility periodically to discover potential problems and take appropriate action.

Remote server administration (from a workstation on the network or from a PC using a modem) can provide greater server security, as the server keyboard and monitor can be removed and the server locked in a secure location. The following administrative activities can be performed using a remote console:

  • Scanning directories and editing text files in both NetWare and DOS partitions on a server.

  • Transferring files to a server.

  • Bringing down or rebooting the server.

  • Installing or upgrading NetWare on a remote server.

Password Encryption

NetWare contains a feature that controls the use of encrypted passwords. The "Allow Unencrypted Passwords" command can be used to encrypt passwords and enhances password integrity by helping to ensure that passwords are not intercepted and used by unauthorized individuals. The default value for this command is OFF. When this parameter is set to OFF, all passwords are encrypted. When this parameter is set to ON, unencrypted passwords are allowed, but not required.

The following are the recommended settings:

  • If any NetWare servers are running NetWare 3.1x on an internetwork, use OFF.

  • If NetWare servers on the internetwork are running versions of NetWare below NetWare 3.0 and you leave the default to OFF, some users may have problems logging in.

  • If the internetwork has NetWare servers running NetWare 2.12 and above, the NetWare 3.1x utilities can be copied to these NetWare servers and this parameter can be set to OFF. If the NetWare 3.1x utilities are not copied to the NetWare 2.x servers, set this parameter to ON.

Secure Console

The SECURE CONSOLE utility allows authorized operators to use the console while preventing the following from occurring:

  • NLMs being loaded from any directory other than SYS:SYSTEM. This keeps anyone from loading an invasive NLM from a server's floppy disk drive.

  • Keyboard entry into the operating system debugger. This restricts the ability to directly access data on the server.

  • Anyone other than the console operator changing the date and time. Some security and accounting features depend on date and time for their enforcement.

Another feature available for securing the server console is the "Lock Server Console" option in the MONITOR utility. When used, keyboard entry to the server console is prevented until the Admin password is entered.

Intruder Detection

The NetWare 4 operating system provides various options that (when activated) help to detect incorrect login attempts and lock out the User object attempting access. This intruder detection/lockout feature can be set to detect an unauthorized user trying to gain access. This feature is administered at the Organization (O) and Organizational Unit (OU) levels.

Controllable settings for intruder detection include the number of incorrect passwords attempted for a user, the time interval over which the attempts may occur, whether the account will be locked after detection, and the time interval that the account will remain locked. The attacker must use a valid username or the attempt is ignored by the operating system.

Logging Out of Unattended Workstations

Another easy to implement countermeasure is that of training your users to log out whenever they leave their computers. If you prefer an alternative to having users always log out, provide a secure utility that automatically locks the computer whenever it detects a defined period of inactivity. (Several good locking utilities that are easily configurable and network ready are available from third-party vendors).

* 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