SECURITY

UNLESS THE COMPUTER YOU are trying to protect is in a locked room where access is controlled and no connections to this computer from outside the room exist, then your computer is at risk. Break-ins and security violations occur almost daily around the world. These violators are not just Internet vandals, they include the employee down the hall who steals computer time or services for his own personal or malicious use.

This article examines computer security in some detail. You learn what computer security is, how you can protect yourself, and what is available to help you perform these security tasks. Because Unix is the predominant operating system on the Internet, this article focuses on Unix. This does not mean, however, that other operating systems do not have their security problems. Regardless of the manufacturer of your hardware and operating system, you must have a thorough understanding of the risks in your situation.

EXAMINING SECURITY LEVELS

According to the computer security standards developed by the United States Department of Defense, the Trusted Computer Standards Evaluation Criteria—the Orange Book, several levels of security are used to protect the hardware, software, and stored information from attack. These levels all describe different types of physical security, user authentication, trustedness of the operating system software, and user applications. These standards also impose limits on what types of other systems can be connected to your system.

LEVEL D1

Level D1 is the lowest form of security available. This standard states that the entire system is untrusted. No protection is available for the hardware; the operating system is easily compromised; and there is no authentication \ regarding users and their rights to access information stored on the computer. This level of security typically refers to operating systems like MSDOS, MS-Windows, and the Apple Macintosh System 7.x. These operating systems do not distinguish between users and have no defined method of determining who is typing at the keyboard. These operating systems also do not have any controls regarding what information can be accessed on the hard drives in the computer.

LEVEL C1

Level C has two sublevels of security—C1 and C2. Level C1, or the Discretionary Security Protection system, describes the security available on a typical Unix system. Some level of protection exists for the hardware because it cannot be as easily compromised, although it is still possible. Users must identify themselves to the system through a user login name and password. This combination is used to determine what access rights to programs and information each user has.

These access rights are the file and directory permissions. These Discretionary Access Controls enable the owner of the file or directory, or the system administrator, to prevent certain people, or groups of people, from accessing those programs or information. However, the system administration account is not prevented from performing any activity. Consequently, an unscrupulous system administrator can easily compromise the security of the system without anyone’s knowledge.

In addition, many of the day-to-day system administration tasks only can be performed by the user login known as root. With the decentralization of computer systems today, it is not uncommon to enter an organization and find more than two or three people who know the root password. This itself is a problem because no way exists to distinguish between the changes Doug or Mary made to the system yesterday.

LEVEL C2

The second sub-level, C2, was meant to help address these issues. Along with the features of C1, level C2 includes additional security features that create a controlled-access environment. This environment has the capability to further restrict users from executing certain commands or accessing certain files based not only upon the permissions, but upon authorization levels. In addition, this level of security requires that the system be audited. This involves writing an audit record for each event that occurs on the system.

Auditing is used to keep records of all security-related events, such as those activities performed by the system administrator. Auditing requires additional authentication because without it, how can you be sure that the person who executes the command really is that person. The disadvantage to auditing is that it requires additional processor and disk subsystem resources.

With the use of additional authorizations, it is possible for users on a C2 system to have the authority to perform system management tasks without having the root password. This enables improved tracking of system administration-related tasks because the individual user performs the work and not the system administrator.

These additional authorizations are not to be confused with the SGID and SUID permissions that can be applied to a program. Rather, they are specific authorizations that allow a user to execute specific commands or access certain kernel tables. Users who do not have the proper authority to view the process table, for example, see only their processes when they execute the ps command.

LEVEL B1

B-level security contains three levels. The B1 level, or Labeled Security Protection, is the first level that supports multilevel security, such as secret and top secret. This level states that an object under mandatory access control cannot have its permissions changed by the owner of the file.
LEVEL B2

The B2 level, known as Structured Protection, requires that every object be labeled. Devices such as disks, tapes, or terminals might have a single or multiple level of security assigned to them. This is the first level that starts to address the problem of an object at a higher level of security communicating with another object at a lower level of security.

LEVEL B3

The B3, or Security Domains level, enforces the domain with the installation of hardware. For example, memory management hardware is used to protect the security domain from unauthorized access or modification from objects in different security domains. This level also requires that the user’s terminal be connected to the system through a trusted path.

LEVEL A

Level A, or the Verified Design level, is currently the highest level of security validated through the Orange Book. It includes a stringent design, control, and verification process. For this level of security to be achieved, all the components of the lower levels must be included; the design must be mathematically verified; and an analysis of covert channels and trusted distribution must be performed. Trusted distribution means that the hardware and software have been protected during shipment to prevent tampering with the security systems.

CANADIAN SECURITY

The Canadian government has undertaken its own design of trusted computing standards. These standards consist of two components: The Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) and the Common Criteria. The CTCPEC addresses both functionality and assurance of the product under development or evaluation. Functionality addresses the areas of confidentiality, integrity, availability, and accountability; and assurance focuses on the degree of confidence with which a product implements the organization’s security policy.

The Common Criteria is a collaborative effort to pool the investigations and research of the United States, Canada, France, Germany, and the United Kingdom. This document contains the requirements for the selection of appropriate IT security measures. There are seven levels of assurance within the Common Criteria: EAL-1 to EAL-7. These criteria are defined in the following sections.

LEVEL EAL-1

EAL-1 is the lowest level of assurance that is meaningful to the developer and the consumer. It defines the minimum level of assurance and is based on an analysis of the security functions of the product using the functional and interface designs, as presented by the developer, to understand the security behavior.

LEVEL EAL-2

EAL-2 is the highest level of assurance that can be granted without imposing on the developer of the product tasks additional to those required for EAL-1. An analysis of the functional and interface specifications is performed, along with a high-level design review of the subsystems of the product.

LEVEL EAL-3

EAL-3 describes a moderate level of independently assured security, meaning security validated by an outside source. This level permits maximum assurance from the design stage with few alterations to the testing process. Maximum assurance implies that the product has been designed with security in mind instead of security being implemented after design. The developer must provide evidence of testing including vulnerability analyses, which are then selectively verified. This is the first level to also include elements of configuration management evaluation.

LEVEL EAL-4

EAL-4 is the highest level of assurance that is feasible to retrofit an existing product line. An EAL-4-assured product is a methodically designed, tested, and reviewed product, which provides the consumer the highest level of security based on sound commercial software development practices. The use of these practices assist in eliminating the common software design problems that can plague a project.

Aside from the elements of Level EAL-3, EAL-4 also includes an independent search for vulnerabilities in the product.

LEVEL EAL-5

EAL-5 level is not easily achieved for existing products, as the product must be designed and built with the intention of achieving this rating. Here the developer must apply commercial software development practices as well as specialized security engineering techniques. This level is suited for those developers and users who require a high level of assurance through a rigorous development approach. At this level, the developer also must present the design specifications and how these specifications are implemented functionally in the product.

LEVEL EAL-6

Level EAL-6 consists of a semi-formal verified design and test component. This level includes all the elements of the Level EAL-5, with the requirement of a structured presentation of the implementation. Additionally, the product undergoes a high and low design review, and must ensure a high degree of resistance to attack. Level EAL-6 also assures that a structured development process, development controls, and configuration management controls are in place through the design cycle.

LEVEL EAL-7

Level EAL-7 is intended for only the highest level of security applications where high risks of security breaches justify the cost of development and, in turn, the price paid by the consumer. This level consists of a complete independent and formal design review, with a verified design and test stage. The developer must test every facet of the product, looking for obvious and non-obvious vulnerabilities, which are then completely verified by an independent source. This is an exhaustive process, and the evaluating agency must be involved from the conception of the idea to the completion of the product.

EXAMINING LOCAL SECURITY ISSUES

Aside from the security products or regulations developed outside your organization, you must work to resolve security issues that may be local or restricted to your organization or to a subgroup within your organization. These local security issues include security policies and password controls.

SECURITY POLICIES

Two major stances can be adopted when developing the policies that reflect security at your site. These major statements form the basis of all other security-related policies and regulate the procedures put into place to implement them. That which is not expressly permitted is prohibited, is the first approach to security. This means that your organization provides a distinct and documented set of services, and anything else is prohibited. For example, if you decide to allow anonymous FTP transfers to and from a particular machine, but deny telnet services, then documenting support for FTP and not telnet illustrates this approach.

The alternative train of thought is That which is not expressly prohibited is permitted. This means that unless you expressly indicate that a service is not available, then all services are available. For example, if you do not expressly say that telnet sessions to a given host are prohibited, then they must be permitted. (You can still prevent the service, however, by not allowing a connection to the TCP/IP port.)

Regardless of which train of thought you follow, the reason behind defining a security policy is to determine what action should be taken in the event that the security of an organization is compromised. The policy is also intended to describe what actions will be tolerated and what will not.

THE PASSWORD FILE

The first line of defense against unauthorized access to the system is the /etc/password file. Unfortunately, it is also often the weakest link! The password file consists of lines or records in which each line is split into seven fields with a colon, as illustrated in the following example:

chare:u7mHuh5R4UmVo:105:100:Chris Hare:/u/chare:/bin/ksh
username:encrypted password:UID:GID:comment:home directory:login shell

It is not necessary that the actual encrypted password be placed in the encrypted password field. This field can contain other values. For example, to prevent someone from logging in using a specific account, that password can be changed to a non-matchable value, such as NOLOGIN. This field, however, typically contains an x or an asterisk (*), indicating that the password is stored either in the Trusted Computing Base (TCB.

The permissions on the password file are read-only, which means that no one can edit the file. Similarly, the shadow password file and the files in the TCB are generally also read-only. The password information in these files are updated by the password command. The permissions on the password command include the SUID (Set User ID) bit, which makes the user executing the program look like the owner of the program, or in this case, root. Because of the application of the SUID bit, the user can change the password even though he does not have the authority to edit the file.

THE SHADOW PASSWORD FILE

The versions of Unix that do not include the advanced security options from SecureWare can support the shadow password file. When you see the character x in the password field, then the user’s actual password is stored in the shadow password file, /etc/shadow. Unlike the /etc/ passwd file, the shadow password file must be readable only by root, as illustrated in the following example:

# ls -l /etc/shadow
-r-------- 1 root auth 861 Oct 24 11:46 /etc/shadow
#

SecureWare is a software company specializing in network security, secure Web servers, and privacy-enhanced mail. SecureWare wrote the code for SCO needed to bring the SCO Unix operating system to C2 compliancy. More information on SecureWare can be found at the URL http://www.secureware.com.

The format of the /etc/shadow file is identical to the /etc/passwd file in that it also has seven colon-delimited fields. However, the /etc/shadow file only contains the user name, encrypted password, and password aging information, as illustrated in the following example:

# cat /etc/shadow
root:DYQC9rXCioAuo:8887:0:0::
daemon:*::0:0::
mmdf:MZ74AeYMs4sn6:8842:0:0::
ftp:b80lug/92lMeY:8363::::
anyone::8418::::
chare:7xqmj9fj3bVw2:9009::::
pppdemo:4QYrWsJEHc8IA:9062::::
#

The /etc/shadow file is created by the command pwconv on both SCO and SVR4 systems. Only the superuser can create the shadow password file. On SCO systems, the information in the /etc/passwd and the protected password database are used to create the shadow password files. On SVR4 systems, the information from /etc/passwd is used. The primary advantage to using the shadow password file is that it puts the encrypted passwords in a file not accessible to normal users, thereby decreasing the chances that a vandal will be able to steal the encrypted password information.

THE DIALUP PASSWORD FILE

The issue of supporting dialup access directly on a Unix system is open to debate. Many people still do it, but it generally leads to problems. Allowing a vandal the opportunity to “hack” on the system might result in the system’s compromise. Many Unix systems offer anonymous UUCP access, which could result in the loss of the password file and would be detrimental to the organization.

An alternative to offering dialup access on a Unix system is to provide access through a terminal server that supports authentication. In this manner, the user must validate to the terminal server before being permitted network access. Because there is no password file to steal from the terminal server, the job of attacking the terminal server becomes more difficult.

In those situations where you must provide dialup access on the Unix server, you can take some steps to better protect yourself from unauthorized network access. The capability to install additional passwords on serial port lines is unfortunately not present in all versions of Unix. They have become most prominently found on SCO-based systems.

The dialup password protection for these serial lines is controlled through two files: /etc/ dialups and /etc/d_passwd. The /etc/dialups file contains a list of the serial ports protected by a dialup password. The file is illustrated in the following example:

# cat dialups
/dev/tty2A
#

The file /etc/d_passwd is used to identify the login shell that a given password is for. Unlike the regular password, which uses the user’s login name, the dialup password is tied to the login shell that a given user is using. This means that every user who uses the Bourne shell has the same dialup password. The following example illustrates the typical dialup password.

# cat /etc/d_passwd
/bin/sh::
/usr/lib/uucp/uucico::
#

Each line or record in the file consists of two colon-delimited fields. The first field identifies the shell that the given password is for, and the second field lists the password. In the preceding example, neither shell has a password. This means that the user will not be prompted for a password when he logs in.

The dialup password is added through the use of the -m option on the passwd command. This option informs passwd that the password being collected is for a specific shell in the dialup passwords file. The syntax for this form of the command is as follows:
passwd -m shell_name

The execution of this command is illustrated in the following example:

# passwd -m /bin/s:
Setting modem password for login shell: /bin/sh
Please enter new password:
Modem password: testing
Re-enter password: testing
#

In the preceding example, the system administrator is adding a dialup password to the /bin/sh shell. This means that any users who log in to the system and have the Bourne shell as their login shell will be prompted for the dialup password. The password they must enter is shown in the preceding example as the system administrator would have typed it. Like the normal passwd command, the actual password is not displayed as it is typed. It is shown here only for illustration purposes. Note that only the system administrator can change the dialup password for a shell.

The passwd command modifies the contents of the d_passwd file to include the new password, as illustrated in the following example:

# cat d_passwd
/bin/sh:ORa691.Na1jjQ:
/usr/lib/uucp/uucico::
#

As shown in the preceding example, the Bourne shell users now have to provide the additional password when logging in on the terminal ports specified in the file /etc/dialups. The following example illustrates the process that a user now experiences when he logs in with the dialup password:

gateway
gateway!login: chare
Password:
Dialup Password:
Last successful login for chare: Fri Oct 28 22:52:02 EDT 1994 on tty2a
Last unsuccessful login for chare: Tue Oct 18 16:27:56 EDT 1994 on ttyp1
SCO Unix System V/386 Release 3.2
Copyright (C) 1976-1989 UNIX System Laboratories, Inc.
Copyright (C) 1980-1989 Microsoft Corporation
Copyright (C) 1983-1992 The Santa Cruz Operation, Inc.
All Rights Reserved
gateway
TERM = (ansi)
#

As illustrated, the user goes through the normal login procedure until he enters the user name and password. After these are validated, the dialup password control file, /etc/dialups, is checked. When the terminal on which the user is connecting is located in the file and the login shell is the Bourne shell, the user is prompted to enter the dialup password. If the dialup password is entered correctly, the user is granted access to the system, as illustrated in the preceding example. If the dialup password is incorrect, however, the login is aborted, and the user is forced to start over again. This is illustrated in the following example:

gateway
gateway!login: chare
Password:
Dialup Password:
Login incorrect
Wait for login retry: .
login: chare
Password:
Dialup Password:
Last successful login for chare: Fri Oct 28 23:28:28 EDT 1994 on tty2a
1 unsuccessful login for chare: Fri Oct 28 23:30:55 EDT 1994 on tty2a
SCO Unix System V/386 Release 3.2
Copyright (C) 1976-1989 UNIX System Laboratories, Inc.
Copyright (C) 1980-1989 Microsoft Corporation
Copyright (C) 1983-1992 The Santa Cruz Operation, Inc.
All Rights Reserved
gateway
TERM = (ansi)
$

THE GROUP FILE

The /etc/group file is used to control access to files not owned by the user. Recall how permissions work: If the user is not the owner of the file, then the group(s) to which the user belongs is checked to see if the user is a member of the group that owns the file. The group membership list is stored in /etc/group. The format of the file is shown in the following:
tech:*:103:andrewg,patc,chare,erict,lorrainel,lens
group name:password:GID:userlist

Table 1 explains each of the fields contained in the /etc/group file.

The password for the group file is not used, and no easy mechanisms are available to install a password in the file. If a user attempts to switch to a group that they are not a member of, then they are greeted by a prompt to enter a password, as illustrated in the following example:
$ newgrp tech
newgrp: Password
newgrp: Sorry
$ grep tech /etc/group
tech:*:103:andrewg,patc
$
If the user who executed this command had been a member of the group tech, then the newgrp command would have been successful. Many current versions of Unix, however, enable a user to be a member of more than one group at a time, thereby reducing or eliminating the need for the newgrp command. It is important to consider that Berkeley Unix further protects the root account with the wheel group. Only the users who are also members of the wheel group can use the su command to become root.

PASSWORD AGING AND CONTROL

Many versions of Unix provide for password aging. This mechanism controls when users can change their passwords by inserting a value into the password file after the encrypted password. This value defines the minimum period of time that must pass before users can change their passwords, and the maximum period of time that can elapse before the password expires. This explanation becomes clearer by thinking of a timeline, as shown in figure 1
 

FIGURE 1 Password aging and lifetime.

The password aging control information is stored along with the encrypted password, as a series of printable characters. The controls are included after the password, preceded by a comma. Typically a number of characters after the comma represents the following information:

•    The maximum number of weeks the password is valid
•    The minimum number of weeks that must elapse before the user can change his or her password again
•    When the password was most recently changed

VANDALS AND PASSWORDS

The term hacker did not always have such a negative connotation. Rather, it was a term denoting someone who was persistent, who tried to break things and figure out how they worked. As a result of this reputation, and because most of the people doing hacking were computer science wizards, the term hacker developed a negative connotation. However, for the purpose of this discussion, and because I know “good” hackers, the bad guys are referred to as vandals.

A vandal wants to get access to your system for one reason or another. Some of those reasons can include the following:

•    Just for the fun of it
•    To look around
•    To steal computer resources like CPU time
•    To steal trade secrets or other proprietary information

Note that not every attempt to access your system is intended to do harm. However, in most cases they should be treated that way. Regardless of the reasons behind the attack, the piece of information most wanted by a vandal is the /etc/passwd file. When the vandal has a list of valid user account names, it is trivial to create a program to simply guess passwords. However, many modern login programs include a time delay between login prompts that gets longer with each unsuccessful attempt. They also might include program code to disable the access port should too many unsuccessful attempts be recorded.

The primary source of protection is to use /etc/shadow or the Protected Password Databasem because these files and directories require root access to view them. This makes it harder for the vandal to obtain encrypted password information. However, recall that the password information in /etc/passwd is encrypted. How can the vandal even hope to gain access when he cannot decrypt the passwords as they are stored?
UNDERSTANDING HOW VANDALS BREAK PASSWORDS

It is correct to say that after the password is encrypted it cannot be decrypted. But this doesn’t mean that the password is still safe. A password cracker is a program used by a vandal that attempts to “guess” the passwords in the /etc/passwd file by comparing them to words in a dictionary. The success of the cracker program is dependent upon the CPU resources, the quality of the dictionary, and the fact that the user has a copy of /etc/passwd. Password crackers are fairly easy to write. A simple, although less-effective one, can be written in approximately 60 lines of C code or 40 lines of PERL code. That’s it. In attempting to provide for better passwords on your system, a system administrator may well give consideration to writing one. Be warned, however, that you might be inviting disaster. If the program is efficient enough, or detects some deficiencies in the passwords on your system, you may have further defeated the security of your machine! An efficient cracker program may be stolen and subsequently used to gain access to other machines. Other ways to better protect the system are available using the logical security tools.

Furthermore, because of the possibility that your cracking program could be stolen, other legal issues could be involved should damage be a direct result of the use of the program. This issue is not to be taken lightly; it is a serious example of how successful these types of programs can be.

For example, a system administrator once had the unfortunate circumstance of not knowing the root password of a machine and no distribution media to reinstall. In this case, he was a friendly vandal in that he owned the machine. He retrieved the /etc/passwd file through anonymous UUCP (Unix to Unix Copy). (So much for security.) After he had the file, he sent it to a contact who tried his password cracking program on it. With no success, he sent it to another machine where a supercomputer chewed on the file for about 18 hours before finally cracking the root password. The ironic part about it was that the password was the name of the company he was working for at the time! Sometimes the simple practice is so effective.

Over the last few years, several password cracking, or guessing, programs have been posted to the Internet. This does not mean that you should run out to get one. In fact, it may be the one program you do not want to have on your system. The authors of these programs clearly state in their documentation that they assume no responsibility for the use of these programs, yet they claim that the programs are highly efficient. It is highly recommended that you have copies of any password cracking programs on a tightly secured machine and make use of them regularly. However, make sure that the company’s security policy allows you, the system administrator, to use the files, and at the same time prohibits everyone else from doing so. A number of password cracking tools are available; they are listed in Appendix B, “Sources of Information.” The moral of the story is to treat programs that try to guess passwords as dangerous and not worth the potential problems that they could be used to overcome.

SECURITY AND THE TRUSTED COMPUTING BASE

The Trusted Computing Base (TCB) is part of the security system for C2-rated Unix systems. It adds a significant level of complexity to the operation of the system and to the administration of it. This system works by moving bits of the /etc/passwd file to other places, as well as adding additional information into the original information. The files that make up the databases for the trusted computing base are scattered in several different directory hierarchies. It is not a good idea to edit these files, however, because serious damage can result to your system.

On a system that uses the TCB, an asterisk is placed in the password field of /etc/passwd. This is because the actual user password is stored along with other user information in the Trusted Computing Base. Using the TCB doesn’t change the operation of the system so much as how Unix provides the same services using TCB. On some versions of Unix, such as SCO Unix, even if you are not using C2 security, the Trusted Computing Base is still being used to provide the security services.

The trusted computing base is comprised of a collection of software including the Unix kernel and the utilities that maintain the trusted computing base. These utilities include authck for verifying and correcting problems in the password database and integrity for verifying the accuracy of the system files. The trusted computing base implements the security policy on the system. This policy is a set of operating rules that governs the interaction between subjects such as processes, and objects such as files, devices, and interprocess communication objects.

Accountability for an action is defined only if the action can be traced back to a single person. On traditional Unix systems in which more than one person knows the root password, it is difficult, if not impossible, for the action to be traced to any single person. The pseudo-accounts like cron and lp run anonymously—their action can only be traced after the change of system information. This is corrected on a trusted Unix system because each account is associated with a real user, each action is audited, and every action is associated to a specific user.

Little Identification and Authentication (I&A) is performed on the traditional Unix system. On traditional Unix, the user logs in by providing a login name and password combination, which is validated by a search in the /etc/passwd file. If the login name and password are correct, then the user is allowed access to the system. In a trusted system, some additional rules are used to improve upon the standard I&A techniques. For example, new procedures for changing and generating passwords have been established, providing better protection for parts of the password database to prevent prying eyes from accessing it.



Traditional Unix systems keep a limited amount of information regarding system activity, and in some cases, only when they have been configured to do so. In trusted Unix, auditing is a major element to ensure that the actions taken are associated with a specific user. The audit system writes a series of records for each action to generate an audit trail of the events that have occurred on a system. This trail consists of every action between a subject and an object that is either successful or unsuccessful in regards to object access, changes made to subject or object, and system characteristics. Consequently, the audit system provides the audit administrator with an extensive history of system actions. This helps the administrator determine what happened, who did it, and when it occurred.

UNDERSTANDING NETWORK EQUIVALENCY

The two primary types of network equivalency are trusted host access and trusted user access. Throughout this discussion, keep in mind that many network administrators prefer to use these facilities to deliver services throughout their organizations without understanding how they operate and what impact these facilities have on host and network security.

HOST EQUIVALENCY

Host equivalency, or trusted access, enables the users of a system to access their accounts on remote systems without having to use their login names and passwords. Through the use of the /etc/hosts.equiv file, the system administrator can list all the trusted systems. If no user names are identified for the machine entry, then all the users are trusted. Similarly, if the system administrator does not specify a particular machine for all users, each individual user can use the.rhosts file in their home directory to list machines to which they want trusted access.

Each entry in the hosts.equiv file is trusted. This means that users on the specified machine can access their equivalent accounts on the local machine without a password. This is not applicable for root because this would be a major security problem. For root, and for the user who wants to provide access to systems not included in the system-wide list, use of the .rhosts file in the user’s home directory is required. Consider the following sample /etc/hosts.equiv file:

# cat /etc/hosts.equiv
macintosh.mydomain.com
delicious.mydomain.com
#

In the preceding example, the entries enable any user on these machines to log into the local system using the same account name without using a password. However, as the following example shows, it is possible to list account names in this file.

# cat /etc/hosts.equiv
macintosh.mydomain.com andrewg
delicious.mydomain.com
#

As the preceding example illustrates, the user andrewg on that system can log in using any account name other than root on the local system. Consequently, this creates the potential for problems because andrewg’s account may be compromised, and then a vandal can access the local system from that machine. As a result, use of account names in the /etc/hosts.equiv and .rhosts files is discouraged.

The security issues regarding host equivalency include root equivalency and file permissions.m It is very dangerous to allow root equivalency between systems. Although root equivalency makes the administration tasks easier to complete, it also makes vandalization of the network easier. If security is compromised on one node that has root equivalency with other nodes, it takes the vandal seconds to determine this and access the other machines. Consequently, it is the author’s recommendation not to allow root equivalency in your network environment.

Another problem is the permissions on the network access files /etc/hosts.equiv and .rhosts. The /etc/hosts.equiv file must only be writable by root, although other users can read the file. The .rhosts file must only be writable by the owner of the file. Having the file world writable— and even world readable—can create problems such as enabling users to edit the fileand add in other systems.

Some implementations of the Berkeley r-commands that use the .rhosts and /etc/host.equiv files check the permissions on them and refuse to use them if the permissions are set inappropriately.However, it wouldn’t take too much effort to write a shell program to look for inappropriately authorized .rhosts files.

USER EQUIVALENCY

Trusted user access is much easier to configure but can be very difficult if it is being installed after a list of users has already been configured. User equivalence is a simple concept that is quite different from trusted host access. Trusted host access is not required for user equivalence to work. For NFS (Network File System) use, user equivalence becomes mandatory to prevent access problems.

User equivalence is configured by giving each user on your network, not just the machine, a unique user name and numerical UID (User ID). This means that on each machine, the user has an account with the same UID. If you do not want to allow a user to access a specific machine, then you do not have to provide an account. Another way to explain this is to say that all the /.etc/passwd and /etc/group files on the machines in the network will be the same. As you will see, not using user equivalence in your networks can put your file systems and data at risk by allowing unauthorized access to them. Consider the following user list:

Username UID
chare 003
janicec 1009
terrih 1009
andrewg 1004
The users in the preceding list each have a unique user name, but their UID numbers are not unique. In figure 2, you see that janicec has her account on macintosh.mydomain.com, and terrih has her account on delicious.mydomain.com.

FIGURE 2 A user equivalence example.

The file system on which terrih has her account is part of an exported file system to the users working on macintosh.mydomain.com. When janicec accesses the files in terrih’s directory and lists them, the ls -l command lists janicec as the owner of the files because the UID numbers are the same. This means that janicec can erase or modify the information in those files as if she were the rightful owner. In this case, it does not matter that the user names are different. The key with NFS and user equivalence is the UID.

Another type of problem can occur when user equivalence is not properly configured. Consider the following user list:
•  Username Home System

•  efudd (Elmer) delicious

•  efudd (Elizabeth) macintosh

In the preceding list, two users named efudd exist. The user efudd on the system named delicious is Elmer Fudd, whereas Elizabeth Fudd uses the account name efudd on the system known as macintosh. In an effort to make things easier, the system administrator on delicious has configured trusted host access, or host equivalency, for all the other systems in the network. One day Elizabeth uses the rlogin command to access macintosh and finds that she can log in without having to provide a password.

She can see all the files that belong to Elmer, and she has access to all of them. That is because as far as macintosh is concerned, Elizabeth is really Elmer. In this situation, the user name is the determining factor—not the UID. As you can see, both types of network equivalency, although creating a more productive and user-friendly environment, can actually create a list of security problems that are difficult to track down and correct.

DEFINING USERS AND GROUPS

As you saw in the preceding discussion on network equivalency, placing some forethought into how you will handle the addition of users in your network is essential to your defense. The comment that your /etc/passwd and /etc/group files will be the same across all the systems is an accurate one. However, a strategy for assigning UID numbers and ensuring their uniqueness is more the issue.

This can be done in many ways. You can assign them in sequential order, allocate number blocks to departments or categories of users, or allocate number blocks to offices. Regardless of the method, it is critical that it be the standard for adding users.

UNDERSTANDING PERMISSIONS

The permissions that Unix uses on each file determine how access to the files and directories is controlled. Many situations can be prevented through the correct application of this simple, yet powerful mechanism. The next section reviews how permissions are handled in the Unix environment.

A REVIEW OF STANDARD PERMISSIONS

The permissions applied to a file are based upon the UID and GID (Group ID) stamped on the file and the UID or GID of the user trying to access the file. The three sets of permissions are as follows:

•    Those applicable to the owner of the file
•    The users who have the same GID as that on the file
•    All other users

ROOT AND NFS

When you think about root, you think of uncontrolled access to the files, directories, programs, and devices on a system. However, when root attempts to access files on a remote system through NFS, the root user has little or no permission. This is due to the security features built into NFS. This security feature looks for a UID value of zero. When it finds that value, it knows that this is root, and it remaps the UID value to 65534, or -2. This means that over NFS, root falls into the other category of user. The advantage here is that if you have no root equivalency between your network machines and one becomes compromised, it becomes harder for the vandal to propagate through your filesystems.

EXPLORING DATA ENCRYPTION METHODS

The opportunity to encrypt information to provide a higher level of security for your system and its data is of interest to users and system administrators everywhere. However, even encrypted data can be at risk without the proper monitoring and training for the users who want to use these facilities.

HOW PASSWORDS ARE ENCRYPTED

At one time, the passwords were stored in a plain text format, and only the administrator and system software had access to the file. However, numerous problems occurred when the password file /etc/passwd was being edited. Most editors create a temporary file, which is the file actually edited. At this point, the file would be world readable, giving away the passwords for all the accounts.

As a result, a method of encrypting the passwords using a one-way encryption algorithm was developed. The encrypted values were then stored instead of the clear text. However, the security of the system is only as good as the encryption method chosen. When a user logs in to a Unix system, the getty program prompts the user for his user name and then executes the login program. The login program prompts for the password but does not decrypt it. In fact, the login program encrypts the password and then compares the newly encrypted value to the one stored in /etc/passwd. If they match, then the user supplied the correct one.

The Unix encryption method for password encryption is accessed through a kernel mechanism named crypt(3). Because of United States Federal licensing issues, the crypt routines might not be available on your machine. The issue is that while the needed routines to encrypt information are available, those programs that decrypt information are not available outside the United States.

The actual password value stored in /etc/passwd is the result of using the user’s password to encrypt a 64-bit block of zeroes using the crypt(3) call. The clear text is the user’s password, which is the key to the encryption operation. The text being encrypted is 64 bits of zeroes, and the resulting cipher text is the encrypted password. This crypt(3) algorithm is based upon the Data Encryption Standard (DES) developed by the National Institute of Standards and Technology or NIST.

In normal operation according to the DES standard, a 56-bit key, such as eight 7-bit characters, is used to encrypt the original text, which is commonly called clear text. This clear text is typically 64 bits in length. The resulting cipher text cannot easily be decrypted without knowledge of the original key. The Unix crypt(3) call uses a modified version of this method by stating that the clear text is encrypted in a block of zeroes. The process is complicated by taking the resulting cipher text and encrypting it again with the user’s password as the key. This process in performed 25 times! When complete, the resulting 64 bits are split into 11 printable characters and then aved in the password file.

Despite the fact that the source for crypt can be obtained from many vendors, although the commercial distribution of this is limited outside the United States (you can find public versions of the code on the Internet), no known method is available to translate the cipher text or encrypted value back to its original clear text. Robert Morris, Sr. and Ken Thompson, who originally implemented the Unix crypt(3) technology, were afraid that with the advent of hardware DES chips, the security of the Unix system could be easily bypassed. By using a “grain of salt,” they managed to bypass this threat.

It is possible for multiple users on the same machine to use the same password, and no one, including the system manager, would be the wiser. When a user runs the /bin/passwd program to establish a new password, the /bin/passwd program picks a salt based upon the time of day. This salt is used to modify the user’s password. The problem comes later in encrypting the password the next time the user logs in. It is possible, but unlikely, that the user will log in and the salt will be the same. For things to work correctly, Unix stores the salt in /etc/passwd as well. It, in fact, makes up the first two characters of the encrypted password.

The following is a sample encrypted value. 2eLNss48eJ/GY In the preceding example, the initial two characters—2e—are the salt for this password. When the user logs in to the system, the login program collects the salt from the stored password and uses it to encrypt the password provided by the user. If the newly encrypted password and the stored password match, then the password entered by the user is correct, and the user is logged in to the system. If the values do not match, then the user is greeted by a Login incorrect message, and the user must try to login again.

ENCRYPTING FILES

As you have seen, the encryption of passwords using a mechanism that is not easily decrypted provides a relatively secure method of preventing unauthorized users from having access to the system. But how can users prevent unauthorized access to their files? This can be accomplished through the use of the command crypt(1). This is a relatively unsecured method of encryption, however. Interestingly enough, some Unix commands support the direct manipulation of these encrypted files without having to decrypt them first. Encrypting files using the crypt command is relatively simple. If no arguments are provided on the command line, crypt prompts for the key, reads the data to encrypt from standard input, and prints the encrypted information on standard output. Ideally however, the information to use is provided on the command line, as illustrated in the following example:

crypt key cipher The preceding command reads from the file clear, encrypts the test using the password key, and saves the resulting encrypted text in the file cipher. Encrypted files can be viewed or decrypted by using a similar command line, as shown in the following:
crypt key clear
crypt key < cipher | pr | lp
632-8.04 89 11/11/96, 5:07 PM

In the first command of the preceding example, the encrypted text in cipher is decrypted using key and saved in the file called clear. The second command-line example uses crypt to decrypt the text and sends the resulting clear text to pr for formatting and then to lp to be printed. The files generated by crypt can be edited by ed or vi, provided the version of ed or vi you have on your system supports editing encrypted files.

EXAMINING KERBEROS AUTHENTICATION

The Kerberos Authentication system was developed by the Massachusetts Institute of Technology’s Project Athena. Since that time, Kerberos has been adopted by other organizations for their own purposes. Many third-party application developers include support for the Kerberos Authentication system in their products.

UNDERSTANDING KERBEROS

Kerberos is an authentication system. Simply put, it is a system that validates a principal’s identity. A principal can be either a user or a service. In either case, the principal is defined by the following three components:
•    Primary name
•    Instance
•    Realm
In Kerberos terminology, this is called a three-tuple and is illustrated by the following example: The primaryname, in the case of a genuine person, is the login identifier. The instance is either null or contains particular information regarding the user. For a service, the primaryname is the name of the service, and the machine name is used as the instance, as in rlogin.mymachine.

In either case, the realm is used to distinguish between different authentication domains. By using the realm, it is possible to have a different Kerberos server for each small unit within an organization instead of a single large one. The latter situation would be a prime target for vandals because it would have to be universally trusted throughout the organization. Consequently, it is not the best configuration choice.

Kerberos principals obtain tickets for services from a special server known as a ticket-granting server. Each ticket consists of assorted information identifying the principal that is encrypted in the private key for that service. Because only Kerberos and the service know the private key, it is considered to be authentic. The ticket granted by the ticket-granting server contains a new private session key that is known to the client as well. This key is often used to encrypt the transactions that occur during the session. The major advantage to the Kerberos approach is that each ticket has a specific lifetime. After the lifetime is reached, a new ticket must be applied for and issued from the ticket-granting server.

DISADVANTAGES OF KERBEROS

As mentioned earlier, the Kerberos system was originally developed at MIT during the development of Project Athena. The disadvantage here is that the configuration of the environment at MIT is unlike any other organization. Simply speaking, Kerberos is designed to authenticate the end user—the human being sitting at the keyboard—to some number of servers. Kerberos is not a peer-to-peer system, nor was it meant for one computer system’s daemons to contact another computer.

Several major issues concern the Kerberos authentication system. First and foremost, the majority of computer systems do not have a secure area in which to save the keys. Because a plain text key must be stored in the initial dialog to obtain a ticket-granting ticket, there must be a secure place to save this information. In the event that this plain text key is obtained by an unauthorized user, the Kerberos authentication server in that realm can be easily compromised.

The next problem is how Kerberos handles keys on multiuser computers. In this case, the cached keys can be obtained by other users logged into the system. In a single-user workstation environment, only the current user has access to system resources, so there is little or no need to enable remote access to the workstation. However, if the workstation supports multiple users, then it is possible for another user on the system to obtain the keys. Other weaknesses also exist in the Kerberos protocol, but these are difficult to discuss without a thorough understanding of how the protocol works and is implemented.

UNDERSTANDING IP SPOOFING

IP Spoofing is a potentially dangerous threat to any network connected to the Internet. On a network, a host allows other “trusted” hosts to communicate with it without requiring authentication. This is accomplished by setting up the .rhost and other files. Any communications coming from sources other than those defined as trusted must provide authentication before they are allowed to establish communication links. With IP Spoofing, a host not connected to the network connects and makes it look as if they are one of the trusted hosts on the network.

This is accomplished by changing their IP number to one of those on the network. In essence, the intruding host impersonates a local system’s IP address and fools other hosts into not prompting for authentication. Security measures to avoid being hit by IP Spoofing include avoiding any IP address based authentication. Require passwords every way you can, and implement encryption based authentication. Many firewalls are also capable of checking the IP source address against the physical location of origin and ascertaining whether or not the data is coming from a real host.