The window verifier makes guessing the right credential much more difficult, and increases security. After authenticating the client, the server stores the following items in a credential table:. The server only accepts time stamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected. The server returns to the client in the verifier an index ID into the credential table, plus the client's time stamp minus one, encrypted by CK.
The client knows that only the server could have sent such a verifier, since only the server knows what time stamp the client sent. The reason for subtracting one from the time stamp is to ensure that it is not valid and cannot be reused as a client verifier. After the first RPC transaction, the client sends just its ID and an encrypted time stamp to the server, and the server sends back the client's time stamp minus one, encrypted by CK.
DES authentication does its naming by using net names. A net name is a string of printable characters to authenticate. The public and secret keys are stored on a per-net-name rather than a per-user-name basis. The netid. User names are unique within each domain. A good convention for naming domains is to append the Internet domain name com, edu, gov, mil to the local domain name. Network names are assigned to machines as well as to users.
A net name of a machine is formed much like that of a user. For example, a machine named hal in the eng. Proper authentication of machines is important for diskless machines that need full access to their home directories over the network.
To authenticate users from any remote domain, you should make entries for them in two NIS databases. One is an entry for their public and secret keys; the other is for their local UID and group-access list mapping. Users in the remote domain can then access all of the local network services, such as the NFS and remote logins. The publickey map is used for secure networking. Each entry in the file consists of a network user name which may refer to either a user or a host name , followed by the user's public key in hexadecimal notation , a colon, and the user's encrypted secret key also in hexadecimal notation.
When restarting a machine after a power failure, all of the stored secret keys are lost, and no process can access secure network services, such as mounting an NFS. Root processes could continue if there were someone to enter the password that decrypts the root user's secret key. The solution is to store the root user's decrypted secret key in a file that the key server can read. Not all setuid subroutine calls operate as they should. For example, if a setuid subroutine is called by owner dave , who has not logged into the machine since it booted, the subroutine cannot access any secure network services as dave.
However, most setuid subroutine calls are owned by the root user, and the root user's secret key is always stored at startup time. Secure NFS affects system performance in two ways. First, both the client and server must compute the common key. The time it takes to compute the common key is about 1 second.
As a result, it takes about 2 seconds to establish the initial RPC connection, since both client and server have to perform this operation. After the initial RPC connection, the key server caches the results of previous computations, and so it does not have to recompute the common key every time. Since system performance is reduced by secure NFS, you will have to weigh the benefits of increased security and your system's performance requirements.
The following is a checklist of items to help ensure that secure NFS operates properly:. Access control is not possible for users, other than through file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators often allow read-only access or squash user permissions to a common user and group ID.
Unfortunately, these solutions prevent the NFS share from being used in the way it was originally intended. Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine.
At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount.
Wildcards should be used sparingly when exporting directories via NFS as it is possible for the scope of the wildcard to encompass more systems than intended. It is also possible to restrict access to the portmap service via TCP wrappers.
Access to ports used by portmap , rpc. For more information on securing NFS and portmap , refer to Section The users' login passwords are their assurance of network security. In a time-sharing environment, the system administrator has an ethical obligation not to change a password to impersonate someone.
In Secure RPC, the network administrator is trusted not to alter entries in a database that stores public keys. An RPC authentication system uses credentials and verifiers. Using ID badges as an example, the credential is what identifies a person: a name, address, and birthday.
The verifier is the photo that is attached to the badge. You can be sure that the badge has not been stolen by checking the photo on the badge against the person who is carrying the badge. However, because no verifier exists, a superuser could falsify appropriate credentials by using commands such as su. UNIX authentication breaks down when applied to other operating systems in a heterogeneous network.
DES is a standard encryption mechanism. Diffie-Hellman public-key cryptography is a cipher system that involves two keys: one public and one secret. The public keys and secret keys are stored in the namespace.
NIS stores the keys in the public-key map. These maps contain the public key and secret key for all potential users. For more information about how to set up the maps, see the Working With Oracle Solaris The security of DH authentication is based on a sender's ability to encrypt the current time, which the receiver can then decrypt and check against its own clock.
The timestamp is encrypted with DES. The two agents must agree on the current time, and sender and receiver must be using the same encryption key. If a network runs a time-synchronization program, the time on the client and the server is synchronized automatically. If a time-synchronization program is not available, timestamps can be computed by using the server's time instead of the network time.
The client asks the server for the time before starting the RPC session, then computes the time difference between its own clock and the server's. This difference is used to offset the client's clock when computing timestamps. If the client and server clocks become unsynchronized, the server begins to reject the client's requests. The DH authentication system on the client resynchronizes with the server. The client and server arrive at the same encryption key by generating a random conversation key , also known as the session key , and by using public-key cryptography to deduce a common key.
The common key is a key that only the client and server are capable of deducing.
0コメント