Novell NetWare provides this functionality by giving the user a logon to the network that is controlled by the Novell Directory Services. Each user is represented in the directory by a User object, the properties of which specify information about passwords and connections.
The Unix operating system does not use the concept of a domain. Instead, each Unix host maintain a password file that stores information about each user, including an encrypted password. To access resources on other network hosts, the Unix user must either log on when accessing the computer or use a proxy mechanism. TCP/IP utilities such as FTP and Telnet often send user passwords across the network in clear-text format and are easy targets for interception.
The Unix remote utilities, usually called r-commands because they all start with the letter r, are use to perform ordinary network functions such as copying or printing files or logging in to a remote s tern. This is very useful in the network environment in which a user performs functions on many( ferent machines. These utilities are not necessarily good when looked at from a security standpoint however. Although the user must have a valid user account on the remote hosts on which these co mands execute, the user does not have to provide the password.
Instead, an entry in the /etc/hosts .equv file or the. rhosts file on a remote computer is what deter mines access. The remote machine trusts the computer on which the user executes an r-command if can find an entry in either of these files for it. Each entry in the /etc/hosts . equiv file contains a hostname and a username, to identify users and the hosts that are allowed to execute these commands without providing a password. The assumption is that if you have logged in to the remote host, you have already been authenticated. The . rhosts file works in a similar manner but resides in user's home directory. The remote users entered in this file can perform functions based on the account associated with that user.
Although this sounds a lot like the Windows NT/2000/Server 2003/XP trust mechanism, it is not. It is quite easy to impersonate a remote node and gain entry into a Unix/Linux system by using the r-commands.
Resource Protections
After a user has been authenticated by the erating system, the next step to access a resource is for check to be done to see whether the resource has any access controls placed on it. Typically, an open rating system will grant access to a resource, such as a file, by granting users the right to do the folioing:
- lRead the file
- Write to the file
- Take ownership of the file
- Delete the file
These concepts also can be extended to resources such as printers and modems. When granting these rights, most operating systems also enable you to specify which rights are applied to users or groups of users. For example, Windows NT enables you to group users into local or global groups. When you set the access controls on a file, you can specify the access rights by group. Using this method, one group of ordinary users might be able to read a file, while a group of users that manages the filemight be granted read and write access, as well as delete access to the file. To prevent programs from being run by unauthorized users, the execute right can be granted or denied to a user or a group of users.
It is important to understand the features of your operating system that pertain to granting rights or permissions. Rights generally enable a user to perform an action. Permissions are placed on resources and define who can access and what kind of access can be made of a resource.
After the Fact: Auditing Use
As you may be aware, there are auditing tools you can use to keep track of resource use, both attempted and successful logon attempts. Here it is important only to note that it is not enough to organize users into groups and grant them resource permissions throughout the network. A large user base, combined with multiple servers that hold valuable resources, makes it difficult at times for an administrator who is not familiar with the information resources provided by a specific server to understand the permissions needed. For example, a new user in the accounting department might or might not need access to accounts receivable files or accounts payable files. They might need access to one or the other or maybe both files. A manager in thatdepartment would probably be the likely person to make the decision about what files the usershould be able to access.
However, if the user is placed into a group, which is generally done to make administration easier,, compromises sometimes happen, and the user might be granted access through the group to resources that they do not need to access. Another reason is that sometimes mistakes are made. It is a fact of life that no one is perfect and that no system for allocating resources is going to get it right 100% of the time. When users are granted the capability to read a file, you can be sure, if the data contained in it is interesting enough, that they will do so.
Indeed, even if a user does not have appropriate access rights to a file, sometimes the user will try to get at interesting information anyway.
For these reasons, a good operating system provides auditing controls that enable you to look back after a security breach to try to determine who did what and where they did it. Unix (and its variants, such as Linux), Windows NT/2000/Server 2003, and Novell all provide features that enable you to record both successful and failed attempts to access resources. They all do it in different ways, and many of these auditing and security features are not enabled out-of-the-box; so if you have multiple operating systems on the network, it will be important that you understand each of them so that you can best enable and use these capabilities.