About Network Security

The more available access is across a network, the more advantageous it is for the networked machines. However, free access and sharing of data and resources create security problems.

This chapter discusses network security, including ways to protect your network against unauthorized use, how to control access, and how distributed applications implement security on the network.

Protecting the Network With Firewall Machines

You can set up a firewall machine to protect the resources in your network from outside access.

A firewall machine is a secure host that acts as a barrier between your internal network and outside networks.

The firewall has two functions. It acts as a gateway which passes data between the networks, and it acts as a barrier which blocks the free passage of data to and from the network. The firewall requires a user on the internal network to log in to the firewall machine to access hosts on remote networks. Similarly, a user on an outside network must log in to the firewall machine before being granted access to a host on the internal network.

In addition, all electronic mail sent from the internal network is sent to the firewall machine for transfer to a host on an external network. The firewall machine receives all incoming electronic mail, and distributes it to the hosts on the internal network.

---

Caution - A firewall prevents unauthorized users from accessing hosts on your network. You must maintain strict and rigidly enforced security on the firewall, but since the other hosts on the network are protected, security on those systems can be more relaxed. However, an intruder who can break into your firewall machine can then gain access to all the other hosts on the internal network.

---

A firewall machine should not have any trusted hosts. (A trusted host is one from which a user can log in without being required to type in a password.) It should not share any of its file systems, or mount any file systems from other servers.

The Automated Security Enhancement Tool (ASET) can be used to make a machine into a firewall, and to enforce high security on a firewall machine. Chapter 5, "Monitoring and Controlling Security Using ASET," describes the ASET utility.

Packet Smashing

Most local-area networks transmit data between computers in blocks called packets. Through a procedure called packet smashing, unauthorized users can harm or destroy data. Packet smashing involves capturing packets before they reach their destination, injecting arbitrary data into the contents, then sending the packets back on their original course. On a local-area network, packet smashing is impossible because packets reach all machines, including the server, at the same time. Packet smashing is possible on a gateway, however, so make sure all gateways on the network are protected.

The most dangerous attacks are those that affect the integrity of the data. Such attacks involve changing the contents of the packets or impersonating a user. Attacks that involve eavesdropping--recording conversations and replaying them later without impersonating a user--do not compromise data integrity. These attacks do affect privacy, however. You can protect the privacy of sensitive information by encrypting data that goes over the network.

Remote Logins

The telnet and rlogin programs enable users to log in to a remote machine over the network, and use the resources of the remote machine. The rlogin programs include rsh and rcp, which enable you to create a remote shell, and copy files to and from a remote machine.

telnet security problems arise because the packets sent across the network are broadcast to every computer physically connected to the Ethernet cable. Although a machine should be programmed to listen only to the packets addressed to that machine, a computer can be programmed to listen to and record all the packets sent across the network. It is possible to intercept the part of the login message that contains a user's name and password. Since the password is sent in ASCII text, an intruder can use that information to assume the identity and permissions of that user.

The rlogin program automatically sends the user's name at the start of the transmission. If the remote login request is coming from a trusted host or a trusted user, the receiving machine allows the user to log in without requiring a password.

Trusted Hosts and Users

The administrator of a local system on the network can designate one or more remote hosts as "trusted" by listing them in the system file /etc/hosts.equiv. A user can then log in to and access the resources of a host on the network without being required to enter a password. In the same way, an administrator can designate trusted users on the .rhosts file.

The /etc/hosts.equiv File The /etc/hosts.equiv file contains a list of trusted hosts, one per line. If a user attempts to log in remotely (using rlogin) or to remotely execute a command (using rsh) from one of the hosts listed in this file, and if that user has an account on the local system with the same login name, the system allows the user to log in without a password.

A typical hosts.equiv file has the following structure:

host1 host2 user_a +@group1 -@group2

When a simple entry for a host is made in hosts.equiv, such as the entry above for host1, it means that the host is trusted, and so is any user at that machine.

If the user name is also mentioned, as in the second entry in the example, then the host is trusted only if the mentioned user is attempting access.

A group name preceded by a plus sign (+) means that all the machines in that netgroup are considered trusted.

A group name preceded by a minus sign (-) means that none of the machines in that netgroup are considered trusted.

---

Caution - The /etc/hosts/.equiv file presents a security risk. If you maintain a /etc/hosts.equiv file on your system, you should include only trusted hosts in your network. The file should not include any host that belongs to a different network, or any machines that are in public areas. (For example, do not include a host that is located in a terminal room.)

---

---

Caution - A single line of + in the hosts.equiv file indicates that every known host is trusted.

---

This can create a serious security problem. Either replace the /etc/hosts.equiv file with a correctly configured one, or remove the file altogether.

The .rhosts File The .rhosts file is the user equivalent of the /etc/hosts.equiv file. It contains a list of host-user combinations, rather than hosts in general. If a host-user combination is listed in this file, that user is granted permission to log in remotely from that host without having to supply a password.

Users can create .rhosts files in their home directories. Using the .rhosts file is another way to allow trusted access between their own accounts on different systems without using the hosts.equiv file.

---

Caution - Unfortunately, the .rhosts file presents a major security problem. While the hosts.equiv file is under the system administrator's control and can be managed effectively, any user may create an .rhosts file granting access to whomever the user chooses without the system administrator's knowledge.

---

The only secure way to manage .rhosts files is to completely disallow them. As system administrator, you can check the system often for violations of this policy. One possible exception to this policy is for the root account--you may need to have a .rhosts file to perform network backups and other remote services.

NFS Distributed Computing File System

The NFS system enables several hosts to share files over the network. Under the NFS system, a server holds the data and resources for several clients. The clients have access to the file systems that the server exports to the clients. Users logged in to the client machine can access the file systems by mounting them from the server. To the user on the client machine, it appears as if the files were local to the client. One of the most common uses of the NFS system is to allow systems to be installed in offices, while keeping all user files in a central location. Some features of the NFS system, such as the nosuid mount option, can be used to prohibit the opening of devices as well as file systems by unauthorized users.

The NFS system uses Secure RPC to authenticate users who make requests over the network. The authentication mechanism, AUTH_DES, use DES encryption to ensure authorized access.

Secure RPC

Secure RPC is a method of authentication that authenticates the host making a request, and the user. Secure RPC uses either DES or Kerberos authentication.

DES Encryption

The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt a secret key. If two credential users (or principals) know the same DES key, they can communicate in private, using the key to encipher and decipher text. DES is relatively fast encryption mechanism. A DES chip makes the encryption even faster; but if the chip is not present, a software implementation is substituted.

The risk of using just the DES key is that, with enough time, an intruder can collect enough cipher-text messages encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS change the keys frequently.

The client and the server each has its own private key which they use together with the public key to devise a common key. They use the common key to communicate with each other, using an agreed-upon encryption/decryption function (such as DES).

DES Authentication

The DES method of authenticating a user that is very difficult for an intruder to crack. DES uses encryption and decryption functions that involve two keys, a public key and a private key (sometimes called a secret key).

Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Make sure you synchronize the time on the client and the server.

The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.

The system administrator is responsible for setting up NIS or NIS+ tables and generating a public key and a private key for each user. The private key is stored encrypted with the user's password. This makes the private key known only to the user.

The NFS Administration Guide manual describes how to set up and administer Secure NFS. Setting up the NIS+ tables and entering names in the cred table are discussed in Name Services Administration Guide. Turn to "Implementation of Secure RPC" on page 69 for an outline of the steps involved in RPC authentication.

Kerberos

Kerberos is an authentication system that was developed at the Massachusetts Institute of Technology. Kerberos uses DES encryption to authenticate a user when logging in to the system.

Kerberos works by authenticating the user's login password. A user enters the kinit command, which acquires a ticket that is valid for the time of the session (or eight hours, the default session time) from the Kerberos authentication server. When the user logs out, the ticket can be destroyed (using the kdestroy command).

The Kerberos software is available from MIT project Athena, and is not part of the SunOS software. SunOS software provides:

• Routines used by the client to create, acquire, and verify tickets
• An authentication option to Secure RPC
• A client-side daemon, kerbd(1M)

"Implementation of Kerberos Authentication" on page 71 gives an overview of how the Kerberos authentication procedure works.

---

Note - Solaris provides the ability to connect to the Kerberos functionality. It does not provide the Kerberos package. However, you can ftp Kerberos 4 source from athena-dist.mit.edu using anonymous as a username and your email address as a password. The source is located in pub/kerberos.

---

Alternative to Secure RPC

If you do not want to run Secure RPC, a possible substitute is the Solaris "privileged port" mechanism. A privileged port is built up by the root with a port number of less than 1024. After a client system has authenticated the client's credential, it builds a connection to the server via the privileged port. The server then verifies the client credential by examining the connection's port number.

Non-Solaris clients however may not be able to communicate via the privileged port. If they cannot, you will see error messages such as these:

"Weak Authentication
 NFS request from unprivileged port"

For information on how to turn on the privileged port mechanism, see NFS Administration Guide.

Access Control

A network file server can control which files are available for sharing. It can also control which clients have access to the files, and what type of access is permitted to those clients. In general, the file server can grant read/write or read-only access either to all clients or to specific clients. Access control is specified when resources are made available with the share command.

A server can use the /etc/dfs/dfstab file to list the file systems it makes available to clients on the network.

The /etc/dfs/dfstab File

The commands in the dfstab file are run by rc scripts when the system enters multiuser mode. You can put a share command into this file that limits the access of a client to a particular file system. This is an example of an /etc/dfs/dfstab file.

# place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype][ -o options][-d "<text>"] <pathname> <resource> # .e.g, # share -F rfs -d "/var/news" /var/news NEWS share -F nfs -o ro /usr/share/man

Restricting Root Access

In general, a superuser is not allowed root access to file systems shared across the network. Unless the server specifically grants superuser privileges, a user who is logged in as root on a client cannot gain root access to files that are remotely mounted on the client. The NFS system implements this by changing the user ID of the requester to the user ID of the user name, nobody; this is generally 60001. The access rights of user nobody are the same as those given to the public (or a user without credentials) for a particular file. For example, if the public has only execute permission for a file, then user nobody can only execute that file.

An NFS server can grant superuser privileges on a shared file system on a per-host basis, using the root=hostname option to the share command.

Administration Tool

Administration Tool (accessed with the admintool command) enables a user to perform system administration tasks across the network. For example, an administrator can use the applications in this tool to add a new system to the network, add and set up a printer, or set up a new user account.

Administration Tool uses the underlying support of the distributed administrative framework, which enables a user to execute processes on remote systems.

---

Caution - It is important to control access to Administration Tool, since anyone with the right access can use Administration Tool to change the configuration of the systems on the network. It is also important to be sure that the network security is set up in a logical and consistent manner so that access is available to users who require it and unavailable to users who should not have it.

---

Administration Tool is designed to work in a distributed system. In a distributed system, some parts of the application run on the user's system and some parts run on a remote system, which could be a system server or another user's system. It is even possible for these two systems to be the same, as for example, if a user is logged on to the server. The Administration Tool application determines what modifications are taking place and which system is being modified.

Distributed Administration Framework Security

The security mechanism used by Administration Tool is the same underlying mechanism supported by the distributed administration framework.

Security is administered in three stages: authentication, authorization, and setting user and group identities.

Authentication Authentication means that the security mechanism verifies the identity of the user making the request. When executing a request, the admind daemon must authenticate the client identity to the server.

Authorization Authorization means that the security mechanism checks if the authenticated user has permission to execute the Administration Tool function on the server. Once the client identity is verified, admind uses this identity to perform authorization checks.

An additional level of authorization is used by NIS+ to allow or deny access to the NIS+ tables. You may have permission to use Administration Tool, but you also need to have create, delete, or modify permission to change an NIS+ database. See Name Services Administration Guide for a description of NIS+ security.

User and group identities are used for authorization checking as follows:

• Root identity - The root identity is allowed root privileges only on the local system (to access and update data on local files and databases). On the server, the security mechanism changes the UID of all requests that originate as root from a remote client to the user nobody. If the server is the local system (in other words, if the user has logged in as root on the server), the user will be allowed to perform Administration Tool functions on the server under the root identity.
• User ID - An ordinary user can only retrieve information, but cannot use Administration Tool to perform any tasks that modify administration data.
• User ID who is a member of sysadmin group (GID=14) - Administration Tool permissions are granted to users who are members of the sysadmin group (GID=14). This means that a user performing a task that modifies administration data on a system--using Administration Tool to add a new user account, for example--must be a member of the sysadmin group on the system where the task is being executed.

How Administration Tool Sets User and Group Identities

The security mechanisms are responsible for making sure that the user and group identities are set correctly for the task that needs to be executed. If the security mechanism has authenticated the client making the request, and has verified that the client has the authority to perform the administrative task, Administration Tool will set the UIDs and GIDs so that the client can perform the task. In some cases the root identity is set in order to perform the task; at other times, the client's identity is set.

Security Levels

Administration Tool uses the distributed administration framework daemon (admind) to carry out the security tasks. The admind daemon process executes the request on the server on behalf of the client process.

Each request contains a set of credentials with a user ID (UID) and a set of group IDs (GIDs) to which the UID belongs. The server uses these credentials to perform identity and permission checks. Three levels of authentication security are available:

• Level 0 (AUTH_NONE) - No identity checking is done. All user IDs are set to the nobody identity. This level is used mostly for testing.
• Level 1 (AUTH_SYS) - The server accepts the original user and group identities directly from the client system and uses them as the identities for the authorization checks. The server does not check that the UID of the client represents the same user on the server system. It is assumed the administrator has made the user IDs and group IDs consistent on all systems in the network. Checks are made to see if the client has permission to execute the request.
• Level 2 (AUTH_DES) - Credentials are validated using DES authentication, and the server checks that the client has permission to execute the request. The user and group identities are obtained from databases on the server system by mapping the user's DES network identity (the DES entry in the NIS+ Cred table, for example) to a local UID and set of GIDs. The database used depends on which name service is selected on the server system. This level provides the most secure environment for performing administrative tasks and requires that a publickey entry exists for all server systems where the admind daemon is running, and for all users accessing the tools.

Administration Tool Security uses the Level 1 authentication (AUTH_SYS) as the default. You can tighten security to require Level 2 security checks by editing the /etc/inetd.conf file on each system, and adding the -S 2 option to the admind entry. Make sure that the servers on the domain are set up to use DES security.

You do not need to maintain the same level of security on all systems in the network. You can run some systems, such as file servers requiring strict security, at security Level 2, while running other systems, such as systems, at

the default Level 1 security. The distributed administration framework automatically determines the right authentication mechanism to use for accessing each system based on its security level.

See "How to Set Up NIS+ Security for a User or a Client" on page 58, and "How to Set Up an NIS+ Client to Use DES Security" on page 61. See also the description of how to set security for NIS+ in Name Services Administration Guide.

Name Service Information

Administration Tool admind uses information held by the name service. The three sources of information are:

• Files in the /etc directory such as passwd, group, and shadow, referred to by the keyword files
• The NIS name service referred to by the keyword nis
• The NIS+ name service referred to by the keyword nisplus

On each system, the /etc/nsswitch.conf file lists administrative databases, followed by a list of one or more name services that will be searched for information. If more than one name service is listed, they are searched in the order given. For example, the following entry

group:      files nisplus

indicates that the admind looks first in the local /etc/group file for an entry. If the entry exists, it uses the information in this entry. If it doesn't exist, the NIS+ group table is searched.

In the case of Administration Tool, the /etc/group file is searched for an entry for sysadmin group (GID=14). If the entry exists, it uses the information listed there, and does not check the NIS+ group table. If you want to set up your system to use network-wide information, remove the sysadmin group from the local system.

The example below is a /etc/nsswitch.conf file that lists files and nisplus as the two name services to search.

# # /etc/nsswitch.conf: # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nisplus group: files nisplus # consult /etc "files" only if nisplus is down. hosts: nisplus [NOTFOUND=return] files services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files bootparams nisplus [NOTFOUND=return] files : publickey: nisplus netgroup: nisplus automount: files nisplus aliases: files nisplus

The following entry indicates that the /etc files should be searched only if the NIS+ network name service cannot be reached:

hosts:         nisplus [NOTFOUND=return] files

If the NIS+ databases are available, and if the entry is not found, then the /etc files are not searched.

This entry lists only one name service for public and private key information:

publickey:      nisplus

---

Note - When running under Level 2 security, the admind uses the public/private key information. Make sure that the entry for publickey is followed by either nis or nisplus (depending on which name service you are using), and remove the files designation.

---

Creating a Security Policy for Administration Tool

You can use the security mechanisms discussed in this section to create a security policy for using Administration Tool in the network. This security policy should be consistent with the policy chosen for the name service being used.

Determine How Much Trust Is Needed If your network is secure and you do not need to use elaborate authentication security, you can use the Administration Tool applications using the default Level 1 security.

If you need to enforce a higher level of security, you can set the security level of admind to Level 2.

For Level 1 security, the client system uses the client's ID and GID as established when the user logged in (or when an su command was issued). The distributed administration framework passes the client's UID and GID identities to the admind daemon on the server system, which accepts these identities without checking that they define the same user on the server system. You must align the passwd and group files on each system in the network to ensure users have the same identities on all systems. This is done most easily when using a name service like NIS+.

For Level 2 security, the client system maps the user's identity as established when the user logged in to a globally unique network identity, the netid. The distributed administration framework uses Secure RPC's DES authentication mechanism to do this mapping, and to pass the netid identity to the admind daemon on the server system within an encrypted credential. The admind daemon uses the DES authentication mechanism to decrypt the credential and map the netid identity to a UID and list of GIDs which represent the same user on the server system. The databases used on each system are determined

by which name service is being used on that system. Because of the way the maps are established and the public keys generated, Level 2 security is primarily used with NIS+ name services.

Determine Which Name Service Will Be Used The name services determine where the security methods get information about user and group identities. The name services are designated in the /etc/nsswitch.conf file (see "Name Service Information" on page 53).

Decide Which Users Have Access to Administration Tool Decide which users will use Administration Tool to perform administrative functions over the network. List these users as members of the sysadmin group accessed by the server system, as defined in the /etc/nsswitch.conf configuration file. The sysadmin group must be accessible from each system in the network upon which administration data will be updated by Administration Tool. The sysadmin group can be established locally on each system or can be used globally within a name service domain, depending upon the policy established by the administrator. By default, the Solaris system software creates the sysadmin group with a group ID of 14. Adding users to this group automatically gives them access to Administration Tool.

Determine Global and Local Policies The global policy affects all hosts in the network. For example, if you add users to the sysadmin group NIS or NIS+ group files, members of this group can perform administrative tasks on all systems that list the network name service as the primary source of information. The name services are listed in the /etc/nsswitch.conf file.

For example, a domain may have an NIS+ server that administers a domain using the NIS+ name service. The NIS+ group table contains an entry for the sysadmin group listing allison, beverly, and charles as members of this group. These three administrators have permissions on all systems in the network that list nisplus as the name service.

A user can choose to establish a local policy that is different from the global policy by adding users to the sysadmin entry to the local /etc/group file. The members of this group will have permission to use Administration Tool applications on the user's local system.

For example, to allow access only to beverly and david:

sysadmin:14:beverly,david

Set Up Permissions for NIS+ Databases You need the proper permissions when using Administration Tool to modify or update the NIS+ databases. In addition to the permissions required by Administration Tool, the NIS+ security mechanisms impose their own set of access permissions. The NIS+ security mechanisms are described in Name Services Administration Guide.

Set Up Initial Security By default, Solaris system software assigns the group ID 14 to the sysadmin group. Add users to this group to give them access to Administration Tool applications.

Use Database Manager tool to add users to the sysadmin group in the NIS+ group table. The appropriate global policy will allow members of this group to perform administration tasks on all systems in the NIS+ domain.

See Administration Application Reference Manual for information on using the Administration Tool applications.

ttyhstmgr Security

ttyhstmgr is a tool that allows an administrator to add or remove a host information when they do not have access to a window system without using Administration Tool. It uses the same security mechanisms as Administration Tool. That is, only members of sysadmin group (GID=14) have permission to manage the associations between servers and clients on a network with ttyhstmgr.

Instructions for Administering Network Security

A system administrator can implement policies that help secure the network. The level of security required will differ with each site. This section provides instructions for some tasks associated with network security.

· How to Search for and Remove .rhosts Files

As system administrator, you may want to search for and remove .rhosts files on a system, as they can pose a security risk.

1. Type find /directory -name .rhosts -print and press Return. The find command starts at the designated directory and searches for any file named .rhosts. If it finds any, it prints the path name on the screen.

2. Type rm /directory/username/.rhosts and press Return. The most secure option is to remove these files.

Example of Finding and Removing .rhosts Files

The following example searches for .rhost files starting from the /usr/users directory, printing any files it finds on the screen.

# find /export/home -name .rhosts -print /export/home/jjones/.rhosts # rm /export/home/jjones/.rhosts #

· How to Set Up NIS+ Security for a User or a Client

For detailed description of NIS+ security, see Name Services Administration Guide.

To set up secure NIS+ for root on a client: 1. As root, edit the /etc/nsswitch.conf file and add the following line: publickey: nisplus

2. Type nisinit -cH hostname and press Return. hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client machine.

3. Add the client to the cred table. Type the following commands:

nisaddcred local
nisaddcred des

4. To verify the setup, type keylogin and press Return. If you are prompted for a password, the procedure has succeeded.

Example of Setting Up an NIS+ Client With DES Security

The following example uses the host pluto to set up earth as an NIS+ client. You can ignore the warnings. The keylogin command is accepted, verifying that earth is correctly set up as a secure NIS+ client.

earth% su # nisinit -cH pluto NIS Server/Client setup utility. This machine is in the North.Abc.COM. directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.earth@North.Abc.COM Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.) Network password: xxx <Press Return> Warning, password differs from login password. Retype password: xxx <Press Return> # keylogin Password: #

To set up secure NIS+ for a user: 1. Add the user to the cred table on the root master server. Type the following command:

nisaddcred -p unix.UID@domainname -P username.domainname. des

Note that, in this case, the username-domainname must end with a dot (.)

2. To verify the setup, login as the client and type keylogin and press Return.

Example of Adding a User to Secure NIS+

The following example gives DES security authorization to user george.

# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des DES principal name : unix.1234@North.Abc.COM Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.) Password: Retype password: # rlogin rootmaster -l george # keylogin Password: #

· How to Set Up an NIS+ Client to Use DES Security

To create a new key for root on a client: 1. Become root on the client.

2. Type newkey -h hostname and press Return. hostname is the name of the client.

Example of Setting Up an NIS+ Client to Use DES Security

The following example sets up earth as a secure NIS client.

earth% su # newkey -h earth Adding new key for unix.earth@North.Abc.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #

To create a new key for a user: 1. Log in to the server as root. Only the system administrator, logged in to the NIS+ server, can generate a new key for a user.

2. Type newkey -u username and press Return. username is the name of the user. The system prompts for a password. The system administrator can type a generic password. The private key is stored encrypted with the generic password.

example% su # newkey -u george Adding new key for unix.12345@Abc.North.Acme.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #

3. Tell the user to log in and type the chkey command. This allows the user to re-encrypt their private key with a password known only to the user.

earth% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@Abc.North.Acme.COM Please enter the Secure-RPC password for usr1: Please enter the login password for usr1: Sending key change request to pluto... #

---

Note - The chkey command can be used to create a new key-pair for a user.

---

· How to Share and Mount Files With DES Authentication

Prerequisite The DES publickey authentication must be enabled on the network. See "How to Set Up NIS+ Security for a User or a Client" on page 58, and "How to Set Up an NIS+ Client to Use DES Security" on page 61.

To share a file system with DES authentication: * Type share -F nfs -o secure /filesystem and press Return.

To mount a file system with DES authentication: * Type mount -F nfs -o secure server:resource mountpoint and press Return.

The -o secure option mounts the file system with AUTH_DES authentication.

· How to Share and Mount Files With Kerberos Authentication

Prerequisite Kerberos authentication must be enabled on the network.

To share a file system with Kerberos authentication: * Type share -F nfs -o kerberos /filesystem and press Return.

To mount a file system with Kerberos authentication: * Type the following command: mount -F nfs -o kerberos server:resource mountpoint

The -o kerberos option mounts the file system with AUTH_KERB authentication.

· How to Acquire a Kerberos Ticket for Root on a Client

If the NFS file system that you need to access has not been mounted, you need to acquire a ticket for root on the client before mounting it.

To acquire a ticket for a not-yet-mounted file system: 1. Type su and press Return.

2. Type kinit root.hostname and press Return. hostname is the name of the client system.

earth% su # kinit root.earth Password: #

To acquire a ticket for a mounted file system: If the entry root.hostname for the client has been entered into the /etc/srvtab configuration file, you can use the ksrvtgt command to get a ticket for root. In this case, you are not required to give a root password. Consult the MIT documentation for information about initializing the /etc/srvtab file.

* As root, type ksrvtgt root.hostname and press Return.

earth% su #ksrvtgt root.earth #

· How to Log In to Kerberos Service

* Type kinit -l username and press Return. kinit prompts you for the ticket lifetime (-l option), and your password. It prints out ticket status using the verbose mode (-v option).

Example of Logging In to Kerberos Service

earth% kinit -l jjones SunOS (earth) Kerberos Initialization for "jjones" Kerberos ticket lifetime (minutes): 480 Password: earth%

· How to List Kerberos Tickets

* Type klist and press Return.

Example of Listing Kerberos Tickets

earth% klist Ticket file: /tmp/tkt8516 Principal: jjones@North.Abc.COM Issued Expires Principal Jan 14 20:40:54 Jan 15:04:40:54 krbtgt.North.Abc.COM@North.Abc.COM

· How to Access a Directory With Kerberos Authentication

* Type cd /mountpoint and press Return. Access the mounted directory, just as you would any other mounted directory. You can list the files in the directory with the ls command, or list the Kerberos tickets with the klist command.

Example of Accessing a Directory With Kerberos Authentication

In the following example, user jjones can change to the mounted directory mntkrb, and list the files in this directory.

The kerbd daemon has automatically secured a ticket on the user's behalf for the NFS server exporting the file system. At this point there are two valid tickets--the original ticket-granting ticket, and the server ticket. These two tickets are listed by klist.

earth% cd /mntkrb earth% ls -l /mntkrb -rw-r--r-- 1 marks staff 29 Jul 1994 sports drwxr-xr-x 3 jjones staff 512 Sep 13 13:44 market earth% klist Ticket file: /tmp/tkt8516 Principal: jjones@North.Abc.COM Issued Expires Principal Jan 14 20:40:54 Jan 15:04:40:54 krbtgt.North.Abc.COM@North.Abc.COM Jan 14 20:43:21 Jan 15:04:43:21 nfs.pluto@North.Abc.COM

· How to Destroy a Kerberos Ticket

* Type kdestroy and press Return. Destroy Kerberos tickets when the session is over, so that an unauthorized user cannot to gain access to it. If you want to reinitiate Kerberos authentication, use the kinit command.

Example of Destroying a Kerberos Ticket

The following example shows how to destroy the Kerberos ticket. If the user then tries to change to or list a Kerberos-protected directory, the ticket server denies access.

earth% kdestroy Tickets destroyed earth% ls /mntkrb Can't get Kerberos key: No ticket file (tf_util) NFS getattr failed for server pluto: RPC: Authentication error can not access directory /mntkrb.

· How to Set Up Security for Administration Tool

To use Administration Tool to add or update administration data on a remote system, a user must be a member of the sysadmin group with a group ID of 14 (GID=14). Use the following procedure to add users to this group.

To set up security using NIS+ name service: 1. Log on the NIS+ master server as root.

2. Start the Administration Tool Database Manager and open the

   group table.

3. Select the group table.

4. Add a comma-separated list of users to the Members List:

   Group Name: sysadmin Group ID: 14

   Members List: usera,userb,userc

   usera, userb, and userc will have permission to update data with Administration Tool.

   See Administration Application Reference Manual for details about how to set up Administration Tool using the NIS+ name service.

To set up security using NIS name service: 1. Log in to the NIS master server as root.

2. Edit the /etc/group file, adding users to the sysadmin group: sysadmin:*:14:usera,userb,userc

   usera, userb, and userc will have permission to update data with Administration Tool.

3. Change directory to /var/yp.

4. Type make group and press Return.

   This updates the group map on the NIS master server and sends the updated map to the NIS clients on the network.

· How to Set Up DES Authentication for Administration Tool

You can increase security for administration tasks by requiring DES authentication for Administration Tool. If you require DES authentication for Administration Tool, you need to set up the systems in the network with publickey security mechanisms.

Prerequisite All NIS+ principals who will use Administration Tool must have DES credentials in the cred table. This includes all hosts that are Administration Tool server systems and all users who are members of the sysadmin group.

1. As root, edit the /etc/inet/inetd.conf file. Add the -S 2 option to the admind entry:

100087/10 tli rpc/udp wait root /usr/sbin/admind admind -S 2

This entry changes the security level to Level 2, which requires DES authentication.

2. Check the entry for publickey in the file /etc/nsswitch.conf. Make sure that the source of the information for publickey is the network name service NIS+. The entry should be:

publickey: nisplus

---

Note - You will need to re-establish credentials for users who are added to the sysadmin group after their publickey entries were established in NIS+. This is because the Cred table contains a copy of the user's groups from the group database. The DES authentication mechanism uses the information in the cred table to set group identities on the server. Use the nisaddcred command to get the new group information in the cred table. (See "How to Set Up NIS+ Security for a User or a Client" on page 58.)

---

Reference Material for Administering Network Security

This section describes how Secure RPC and Kerberos provide authentication for users and clients accessing files on a network.

Implementation of Secure RPC

The NFS Administration Guide manual describes the procedure involved in implementing Secure RPC on a system. The process is outlined briefly here.

1. The system administrator runs a program that generates a public key and a secret key (or private key) for each user on the system.

   The keys are stored in a public database, /etc/publickey. This database contains the public key and an encrypted secret key for all principals. A principal is a client user or a client system who credentials have been stored in the NIS+ domain. A user's secret key is stored encrypted with the user's password.

2. The keyserver program (keyserv) must be running on both the client machine and the server.

   The keyserver is an RPC service that runs locally on every machine. The keyserver saves the decrypted secret key, and waits for the user to initiate a transfer with a server.

3. The keylogin program runs whenever a user logs in.

   The keylogin program runs automatically at login time, if it is included in the /etc/profile file. The login process gets the secret key from /etc/publickey, decrypts it using the user's password, and passes the decrypted secret key to the keyserver. This scheme relies on the user's choice of an appropriate password.

4. The user starts an initial transaction with a server.

   The keyserver uses the client's secret key and the server's public key to create a common key. In addition, the keyserver generates a random conversation key, which is encrypted using public key cryptography.

5. The client sends the transmission, including a time stamp and the conversation key, to the server.

The initial transmission includes a credential and a verifier. The credential contains three parts: the client user's netname, the conversation key, and a window. The conversation key is encrypted with the common key, and the window is encrypted with the conversation key.

The window is the difference that the client allows between the server's clock and the client's time stamp. If the difference between the server's clock and the time stamp is greater than the window, the server should reject the client's request. (For secure NFS, the window currently defaults to 30 minutes.)

The client's verifier contains the encrypted time stamp, and an encrypted verifier of the specified window, incremented by one. Using a window verifier makes it more difficult for an intruder to guess the credential.

6. The server receives the transmission from the client.

   The keyserver uses the client's public key and the server's secret key to generate the common key--the same common key computed by the client. (Only the server and the client can calculate the common key, since doing so requires knowing one secret key or the other.)

   The server decrypts the client's time stamp with the decrypted conversation key. Authentication is based on the sender's ability to encrypt the current time, which the server decrypts and checks against its current time. If it's close, then the sender must have encrypted it correctly. The server also checks if the time stamp is greater than the one previously seen from the client.

   The sender must base its time stamp on the correct time of the receiver, so that the receiver can check for replayed messages. It is important to synchronize the time on the server and the client.

7. The server stores four items in a credential table:

• The client user's netname
• The conversation key
• The window
• The client's time stamp

The server stores the first three items for future use. It stores the time stamp to protect against replays. The server will accept only time stamps that are chronologically greater than the last one seen, so that any replayed transactions are automatically rejected.

8. The server returns a verifier to the client.

   The verifier includes the index ID, which the server records in its credential table, and the client's time stamp minus one, encrypted by the conversation key. One is subtracted from the time stamp to ensure that it is invalid, and cannot be reused as a client verifier.

9. The client receives the verifier and authenticates the server.

   The server doesn't need to send a credential for verification, since the client called the server in the first place. However, the client needs to authenticate that the reply is really from the server. Only the server can send the correct time stamp, since only the server knows what time stamp the client sent.

10. The client returns the index ID to the server in its second transaction and sends another encrypted time stamp.

11. The server sends back the client's time stamp minus one, encrypted by the conversation key.

    With each transaction after the first, the client sends back its index ID and another encrypted time stamp, and the server returns the time stamp minus one.

Implementation of Kerberos Authentication

The following procedure assumes that the Kerberos key distribution center (KDC) is already installed on the network, using publicly available sources from MIT project Athena.

The /usr/sbin/kerbd daemon must be running on the NFS client and server.

This daemon is normally started automatically at system boot time by the /etc/init.d/rpc startup script. kerbd is the user-mode daemon. It interfaces with the kernel RPC and the KDC. It generates and validates authentication tickets.

You can use the ps command to see if the daemon is running.

earth% ps -ef |grep kerbd

1. The system administrator sets up the NFS server to use Kerberos authentication.

   The MIT Kerberos software is used to register the principal names in the Kerberos key distribution center (KDC) on the Kerberos server. The following entries are required:

• root.hostname (required for each NFS client)
• nfs.hostname (required for each NFS server)

2. The user mounts the shared file system.

   The user on the client must get a ticket for root on the client to mount the shared file system.

3. The user logs in to the Kerberos service, using the kinit command.

   The Kerberos authentication server authenticates the request, and grants a ticket for the ticket-granting service.

4. The user accesses the mounted directory.

   The kerbd daemon automatically secures a ticket on behalf of the client for the NFS server exporting the file system. At this point, there are two valid tickets, the original ticket-granting ticket and one for the server.

5. The user destroys the tickets at the end of the session to prevent them from being compromised.

   The kdestroy command destroys the user's active Kerberos authorization tickets by writing zeros to the file that contains the tickets. You can put the kdestroy command in your .logout file, so that all Kerberos tickets are automatically destroyed when you log out of the system.

6. If tickets have been destroyed before the session has finished, the user must request a new ticket with the kinit command.