The Two Sides of Security


Locking the computer-room door is a preventive measure intended to keep out those who have no business being there. Preventive measures should be taken for software access mechanisms also. However, no matter how good you are at putting into place the access control mechanisms to protect resources, there is always going to be someone who will try, and possibly succeed, in breaking through. For this reason, you also must be able to keep audit trails of events on the network so that you can determine whether someone is trying to break your security, or whether indeed they have done so.

Before the Fact: Controlling Access

Controlling access to the network is done by several common mechanisms:

  • User accounts and passwords

  • Physical identifiers

  • Resource protections

In many operating systems, the concept of a resource owner is important in this scheme. For example, OpenVMS and Windows 2000/Server 2003/XP keep track of the user who creates a resource, such as a file. That owner is able to change the protections applied to the file and can grant others the permissions needed to use the file. To a lesser degree, the same can be said for Unix/Linux operating systems.

Identifying Users

In a homogeneous network in which only one user account and password is required for access to permitted resources throughout the network, system management is not usually a complicated matter. Windows 2000/XP and Server 2003 allow for the creation of areas of control, called domains, that operate as security boundaries. Users in a domain can be granted access to resources on any computer, either server or workstation, that the network administrator wants to give them. In addition, trust relationships can be established between domains when administrators cooperate, making it possible for the user to still use only one username and password to connect to resources throughout the network. From Windows 2000 and more recent Windows versions, group policies can be used to further control access to important resources.

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 maintains 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 used to perform ordinary network functions such as copying or printing files or logging in to a remote system. This is very useful in the network environment in which a user performs functions on many different 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 commands execute, the user does not have to provide the password.

Note

Although most Telnet applications still use clear-text passwords for authentication purposes, there are some that use encrypted authentication. If security is of a great concern on your network, be sure to examine the documentation closely before using these utilities on any node in the network. This also applies to other TCP/IP utilities such as the r-commands and FTP.

Instead, an entry in the /etc/hosts.equiv file or the .rhosts file on a remote computer is what determines access. The remote machine trusts the computer on which the user executes an r-command if it 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 a user's home directory. The remote users entered in this file can perform functions based on the account associated with that user.

Note

Although you'll still find the basic r-commands in most Unix and Linux systems, there is an alternative. The Secure Shell (SSH) utilities offer authentication and encryption for data transfers using utilities that are similar to the r-commands. You can find out more about SSH by visiting the Web site www.ssh.com/products/ssh/. You can obtain free versions of SSH by visiting www.openssh.com/.

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 operating system, the next step to access a resource is for a check to be done to see whether the resource has any access controls placed on it. Typically, an operating system will grant access to a resource, such as a file, by granting users the right to do the following:

  • Read the file

  • Write to the file

  • Execute 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 file might 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.

Tip

Starting with Windows NT and continuing through Windows 2003 Server enables you to format a hard disk using the NTFS file system or the standard FAT system that is compatible with DOS and other operating systems, such as Windows 95/98. If you want to provide access controls on individual files and directories under Windows NT/2000/Server 2003/XP and so on, you must format your disk partitions using NTFS. The local access rights that you can assign to files and directories have no effect on FAT partitions. Also, Windows 2000/Server 2003/XP adds a new feature to Windows operating systems that enables you to encrypt individual files on disk. The encryption is done on-the-fly as a file is written or is read, so for a high-security environment this might be a good option to use.

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.

For more information on user rights and permissions, and on how they are implemented by different operating systems, see Chapter 43, "Rights and Permissions."


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.

You can learn more about monitoring successful as well as failed logon attempts by reading Chapter 47, "Auditing and Other Monitoring Measures."


There are several reasons for this. 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 that department would probably be the likely person to make the decision about what files the user should 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.

Passwords

It might not seem like an important thing to mention at this point, but you need to enforce a policy that makes users choose good passwords. And when you do that, you must decide what makes a good password for your environment. Simply put, a good password is one that is hard to guess. When you consider that a standard password-cracking technique used by hackers is to simply try every word in a dictionary, you can begin to understand that luck doesn't have a lot to do with penetrating a network. It comes mostly from lax security that allows doors that are easy to open .

Enforcing Good Passwords

When deciding how passwords are to be constructed , there are a few guidelines you can follow:

  • Use more than one word . Multiple words "glued" together make a pattern of characters that is much harder for a simple password-cracking program to guess. Don't use words that naturally go together. For example, Atlantabraves is not a good choice; Atlantayoko is a better choice. Never use a name of a celebrity or a popular institution.

  • Use nonalphabetic characters somewhere in the password . This can be numeric characters or punctuation characters, provided that the operating system you use will permit them.

  • In Unix and Windows NT/2000/Server 2003 Server editions as well as Windows XP, passwords are case sensitive . If you use both upper- and lowercase characters in a password, you can confound many password-guessing applications. Do not, however, substitute numeric characters that resemble alphabetic characters. One of the easiest things a password-hacker application can do is to substitute the letter "O" for zero. Don't fall for that one!

  • Don't make passwords too difficult to memorize . The last thing you want is to have frustrated users writing down passwords so that they will be able to remember them. If you find this happening, it's time to re-educate the employee. There are many methods in use today that can be used to provide "one password" for all applications on the network. You should investigate these types of applications and, if appropriate for your network, justify the cost versus the cost of a network intrusion. Many of these systems involve smart cards and PIN numbers . Again, although this may be an expensive up-front cost, justify it by the value of your data.

  • Use password history restrictions if the operating system permits it . This means that the operating system keeps track of a limited number of passwords that the user has previously used and will not allow them to be reused within a certain time frame. A common practice is to change your password when forced to do so and then to change it back to a value that you like and can easily remember.

Be sure that you do not create user accounts and assign them a password that never gets changed by the user. Most operating systems will allow you to set a password to be expired on its first use so that when a new user logs in the first time, he will be required to change his password.

Sometimes it is important to have a password that makes no sense whatsoever. In a highly secure environment this can make sense, in that you want something that is hard to guess. However, remember that when something is difficult to remember it usually gets written down somewhere, which can defeat the purpose of a password altogether. Unix has a command, passwd , that can be used to computer-generate a password for a user. For example, the command

 passwd  username  

displays a list of potential passwords that are generally difficult to guess. The user can select one from this list to use if he is having a difficult time thinking one up. The only problem with this method is in getting the user to memorize the password.

Password Policies

No user account, including one used by an administrator (or root for the Unix/Linux community), should ever be allowed to keep the same password for an extended period. A good idea for passwords is to require that they be changed every 30 “60 days, depending on the level of security you need at your site. You also should enforce a minimum length for passwords. Most operating systems will allow you to specify this value so that users cannot change their password to one that is shorter than the size you require.

On Unix systems, you can set the password minimum length by specifying it in a field in the file /etc/default/passwd .

On Novell NetWare servers, you can enforce a minimum password length by modifying the object properties of the template object used to create a user account, or by modifying the properties of an individual user object for a particular user.

Depending on the particular operating system, you can enforce other restrictions on passwords or user accounts to enhance security on the network. Some of the capabilities you might find include these:

  • Password expirations ” A password should not be used indefinitely.

  • Password history lists ” This feature prevents a password from being reused within a specified period.

  • Account lockouts ” When a hacker is trying to use the brute-force method to guess a password for an account, you should be able to lock out the account automatically after a specified number of attempts within a specific time frame.

Password Grabbers

About the oldest trick known to those who would want to break into another user's account is the use of a program that imitates the operating system's own logon procedure. This kind of program generally is executed by someone who logs in using his own account on another's workstation. He then runs a program that does nothing but wait until the unsuspecting user tries to log in. The program prompts for a username and password, mimicking the operating system in every respect. However, instead of logging the user on to the system, which the program is unable to do, it simply stores the password in a file and then generates a phony error message.

If the user is not too concerned about security, he will probably never know that he has been fooled. The user might think he has entered his password incorrectly and try again. The second time it will succeed because it is the operating system that is prompting the user this second time. The password grabber program has already done its job and it disappears.

The user who began this fraud simply retrieves the file, thus getting the password, and then can freely log in as that user and cause many problems when it comes to tracking down the real person who is abusing security. Because the perpetrator is now using someone else's username and password, he is difficult to catch.

Note

This subterfuge is one of the reasons Windows NT/2000/2003 Servers, as well as Windows XP, use the key sequence of Ctrl+Alt+Delete to begin the logon process. It is generally difficult to write a program that mimics the Windows logon screen because the Ctrl+Alt+Delete combination of keystrokes is trapped by a processor interrupt, and unless the system has been grossly compromised, any program attempting to pass as the logon screen will fail.



Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2003
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net