Repositories

I l @ ve RuBoard

The identity and authentication information is usually stored together in an authentication data repository. This repository can be as simple an in a password file on each individual system, or it can be implemented as a service to enable enterprise administration.

Files

On UNIX systems, the default storage location for passwords is the /etc/passwd file. This file is required to be world readable so that there is universal access to user and group IDs. This file contains seven fields separated by colons. The fields are user name , encrypted password, numeric user ID, numeric group ID, GECOS, home directory, and start-up program.

• The user name is eight characters or less; the initial character must be a lower-case letter and cannot contain the characters # or @. These two special characters are used as the delete character and delete the entire line characters . This is the only editing that is allowed at the standard UNIX login prompt.

• The encrypted password is not actually an encryption of the password; it is the encryption of the value 0 using the password and the salt as the key. The field is 13 characters; the first 2 characters are the " salt," composed of 2 characters, which is appended to the password to make the key. This adds an additional 4096 possible encryptions for the same password. The salt adds a little spice to the algorithm. This field may be suffixed by a comma and two characters which are the password aging element. The first character denotes the maximum number of weeks for which a password is valid. The second character indicates the minimum number of weeks before the password can be changed. The character set used in the encrypted password field is composed of 64 characters representing the values from 0 to 63. In order, the characters are the period, the slash, 0 through 9, the upper-case letters, and the lower-case letters .

  No account should be allowed without passwords. A user without a password is easy to spot since the password field in the password file will be blank. This script will print out all the accounts without passwords.

   awk -F: 'length()<1 {print }' <  /etc/passwd 

• The third field is the user ID (UID) field. It is a 16-bit integer. It is this value, not the user's name, that is used to identify ownership and grant access to resources. A UID of 0 indicates superuser privileges. The UIDs of -1 and -2 are used by NFS . The UID of -1 is for an unauthenticated user and is referred to as nobody; the UID of -2 is used for the root user of another system who is accessing a file system for which he does not have root access.

• The fourth field is the group ID (GID) field; it is a 16-bit integer. Groups are used to group users together so they can share files among the individuals in the group without allowing everyone access.

• The fifth field is the GECOS field. This is a comment field that, by convention, contains a comma separated list of user's "real-life" name, location, office phone number, and home phone number. This field is used by the finger command, as well as a number of other commands that display a user's real name.

  GECOS information should never be included. Not having this information may be an inconvenience. You will have to manually convert a user's login name to his real name. However, the GECOS information is some of the most valuable information your system has to aid a hacker in password cracking. It gives the hacker more information about users that can lead to insight into guessing passwords. Some of the system management tools will request the user's name, telephone number, and organization information and fill in the GECOS field.

• The sixth field is the user's home directory, generally limited to no more that 64 characters.

• The seventh field is the user's start-up program. It is generally limited to 44 characters.

NIS

Network Information Service (NIS ) was developed by Sun Microsystems to provide a centralized repository for common system configuration files. These configuration files generally include the password file, group file, and many others. Since many of these contain sensitive information, access is limited to those clients that know the NIS domain name.

Security for NIS is based on only a single password: the NIS domain name. Any system with the NIS domain name can read any of the information in the NIS database since there is almost no authentication between clients and servers. The NIS domain name is generally easy to guess by using the same techniques as those used in guessing passwords. You must select a domain name that is difficult to guess. This is your only protection on all your NIS databases. Selecting a good password is not enough when the systems will tell you the password when it is requested .

If the system is running the NFS diskless boot daemon, a simple program can be written to access the boot server and receive the NIS domain name in the response; it can then be used to compromise the NIS system. The Remote Procedure Call (RPC) that requests the resources is illustrated below.

 callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI,           xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);  printf("%s has NIS Domain name:  %s\n", server, res.domain.name); 

Once a hacker knows your NIS domain name, he can access any of the information in the server's NIS maps by utilizing a simple RPC query, even when he is outside the subnet served by that server. The program ypx which has been posted on Usenet News does just that. It will transfer any NIS map from any host that is running the ypserv daemon.

NIS also requires that each file on each client computer have a special entry that tells the system to access the server for the information for that file. This entry starts with a plus sign. For example, a password file may look like the following:

 +::0:0::: 

In this case, all passwords are pulled from the NIS server. However, if this system does not bind to a NIS server because it cannot talk to the server, a hacker will be able to log in as "+" and have root privileges. A system may be unable to reach a server for any of a number of reasons, including a server failure, a network failure, or routing error.

It is imperative that the NIS client files be configured correctly. The above example should be:

 +:LOCKED:88:88::: 

Then if the system could not bind to its server, you would be unable to log in to the system as "+". Even if the password field is omitted, you would not be able to get superuser access. Because of the long-standing security problem with NIS, some vendors have implemented special rules pertaining to the NIS configuration. Check your vendor's documentation for specifics.

If a hacker can gain access to the yp master files by mounting the ypmaster directory or compromising the NIS master system, he can control all the systems that are in the NIS domain. Any changes to the NIS master will propagate to all the clients. The ypmaster directory is usually /var/yp or /usr/etc/yp . The subdirectory that contains the data is the same name as the domain name.

One feature on HP-UX specific to NIS security is the /var/yp/secureservers file. This file can be used by NIS clients to specify a list of valid IP addresses (i.e., NIS servers) for which the client can bind. This file helps to eliminate the threat of a client binding to unauthorized, rogue NIS servers.

NIS+

NIS+ manages the same information about usernames, passwords, groupnames, and hostnames, but does so with greater emphasis on security. The enhancement to security include greater control of access to data and both client and server authentication. NIS+ uses a combination of public and secret key cryptography to authenticate clients and servers. However, the key exchange implementation limits the effectiveness of the security implementation. All nodes within the domain must be running NIS+ (not NIS) or all security enhancements are disabled. It is also more complex to administer and this is where many security issues arise.

LDAP

LDAP (Lightweight Directory Access Protocol) is a proposed open standard for accessing global or local directory services over a network and/or the Internet. A directory, in this sense, is simply a data repository which associates an attribute to an identifier. Requests for an identifier return the attribute. It is typically used to associate names with phone numbers , e-mail addresses, and user credentials. LDAP directories are designed to support a high volume of queries, but the data stored in the directory do not change very often.

LDAP can be used as an authentication service via the pam_ldap module. LDAP is commonly used as a central authentication server so that users have a unified login that covers console logins, POP servers, IMAP servers, machines connected to the network using Samba, and even Windows NT/2000 machines. Using LDAP, all of these login situations can rely on the same user ID and password combination, greatly simplifying administration.

OpenLDAP is present in Red Hat 6 and newer releases and supports LDAP as an authentication method. HP-UX introduced LDAP as an authentication method at release 11 and provides Netscape LDAP server for intranet uses.

I l @ ve RuBoard