Strategies to Minimize Logon Problems

The best way to solve a problem is to take all necessary measures to ensure that the problem doesn't happen in the first place. Although it is not possible to completely eliminate every source of failed logon problems, you can do a lot to keep your network users happy by taking a few precautions:

• Place a backup domain controller on every physical subnet—If a network link goes down, users can still be validated by the local BDC and continue to work with resources to which they can still connect. A BDC with enough available resources can simultaneously perform the same functions as any other Windows NT Server, so if you have a server on a subnet that is offering resources and it is not already overloaded, consider replacing it with a BDC and let it serve two roles. Remember, if the server is not already a domain controller, you will have to re-install the OS and select that option during setup.

• Enforce reasonable password policies—Some operating systems allow you to computer- generate random passwords that are very difficult to remember. If a user cannot remember a password, most of the time the user will just write it down somewhere, which can compromise security. If you force users to change passwords too frequently, they will most likely have a hard time remembering what the recent password is, unless they write it down somewhere. If you set the account policy lockout values too low, you will find that users get locked out because of simple typing errors, and the help desk will spend a lot of time unlocking these accounts.

• Keep track of user accounts—You can use a paper method or an electronic one such as a spreadsheet or database. Delete accounts for users who leave the company and create new ones for new employees. Getting rid of the dead wood will help avoid confusion when troubleshooting and will help keep the SAM databases down to a reasonable size.

• Never use generic accounts where more than one user logs in under the same username—Though this is a tempting idea because you have fewer user accounts to manage, it can be a security nightmare if something goes wrong and you are unable to use auditing measures to figure out the who, what, and when of the matter. Also, when more than one person is using the same account to log on, it takes only one person with fumble-fingers to incorrectly type a password a few times and lock an account, also preventing others who use the same account from logging in.

To fully understand how to troubleshoot problems with logons, you should make yourself knowledgeable about the Windows NT Event Viewer administrative tool.

Using a Shadow Password File of Unix and Linux

To plug the password security hole presented by the / etc / passwd file, a technique called a shadow password file is usually used. This file contains the actual passwords, also in encrypted format. However, the shadow password file is not world-readable, and permissions are set so that only the root account can access this file.

On many systems, the name of the shadow password file is /etc/shadow. Check your documentation to determine the exact path on your system. Also note that on some older systems (and a few current ones), you'll have to load an extra component to install the shadow password file capabilities. Keep up-to-date by consulting your vendor's Web site.

The contents of this file also can vary from one system to another. However, the following format contains the fields used in most implementations:

username:password:last:may:must:warn:expire:disable:reserved

The following list describes these fields:

• username—This field is used for the same purpose as it is in the /etc/ pa s swd file. It is the login name for this user's account.

• password—The user account password stored in encrypted format.

• last—The number of days, since January 1, 1970, that the password for this account was changed.

• may—The number of days that must pass before the password for this account can be changed.

• must—The number of days after which the password for this account must be changed.

• warn—The number of days before the password expires to warn the user about the upcoming password expiration.

• expire—The number of days that must pass before the account password expires and the account becomes disabled.

• disable—The number of days, since January 1, 1970, that the account has been disabled.

• reserved—This field is reserved for future use.

As you can see, using a shadow password file gives you additional control over accounts, such as setting password expiration values. It also gives you informational fields (such as last and disable that can be used when managing user accounts.

The /etc/groups File

This file contains a list of user groups and a numerical value used to identify the group. The syntax for entries in this file is as follows:

groupname:grouppassword:groupID:username1,username2

• groupname—A name associated with the group. Using a meaningful name can help you simplify user administration.

• grouppassword—Yes, you can place a password on a group, but this is generally not done. Instead, this field is usually left blank.

• groupID—This is the group's ID number, which is used by the operating system to identify the group. It is often referred to as the GID. This number can range from 0 to 32,767, and the numbers 0 to 10 are generally reserved for system groups. For example, in most Unix implementations, the root user has a GID of zero.

• usernamel,username2 . . . —This is a comma-delimited list of members of the group. Separate each using a comma.

Users can be members of more than one group. If this is the case, the first group is the user's primary group, and the GID of this group is used when files are created or saved. Users can use the groups command to view the group(s) of which they are a member. The command chgrp can be used to change the current default group.

Physical Security Measures continue...

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

• 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 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.

Enforcing Passwords Security

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 t is much harder for a simple password-cracking program to guess. Don't use words that natur 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 ch acters or punctuation characters, provided that the operating system you use will permit the

• 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 p word, 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 "0" 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 this happening, it's time to re-educate the employee. There are many methods in use today t can be used to provide "one password" for all applications on the network. You should inves gate these types of applications and, if appropriate for your network, justify the cost versus t 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 the operating system keeps track of a limited number of passwords that the user has previou used and will not allow them to be reused within a certain time frame. A common practice is 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 ruired 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

passwordusername

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 willallow 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.

PasswordGrabbers

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 thenruns 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.

Forged Email

Email is probably the most popular application used on the Internet. All people can have an email account, whether or not they have a computer at home. You can sign up for email accounts at several sites, such as Microsoft's Hotmail or Yahoo's email service, and use a computer at your school, at a library, or even at work to access the account.

Email messages, like Trojan horse programs, aren't always what they seem to be. Just because the FROM line contains the name of someone you know doesn't mean that the email actually came from that person. It's a simple matter when configuring an email account to use any name you want. And with the online email services that don't require you to use an email client (these services typically use an HTML interface—a Web browser), it can be difficult to determine where an email actually originated.

There are even programs freely available on the Net that allow you to create bogus email messages that appear perfectly normal in all respects. Although any intelligent person would probably not, in this day and age, open an email attachment from someone they do not know, they most likely would open an attachment from a friend. After all, if you can't trust your friends...

The problem is that email is easily forged and can be used to get a program into your network. As a rule, delete spam and other email from sources you don't recognize.

One of the more insidious things that can be done through email has occurred with alarming frequency in recent years. Worm viruses spread through email can read your address book, replicate themselves by mailing a copy of the virus code to everyone in your address book, and then start wreaking havoc on your system! About the only thing you can do in this situation is to disconnect the computer (or computers) from the network and clean out the mail store with a good virus program. If you have a mail server in your network, disconnect it and do the same. Until you've assured yourself that every computer in your network is free of such worm viruses, don't reconnect to the Internet, or any other part of your corporate network.

Password Protection and SecurlD and Smart Cards

Passwords and usernames have been the traditional method for authenticating a user to a computer operating system. There are much better methods you can use for environments that demand a high degree of security, such as smart cards and SecurlD cards.

Smart card devices are synchronized with software that runs on the host computer. To log on, the user simply consults the password code, which changes at regular intervals, generated by the smart card. Because the application on the host computer is operating to change the account password using the same algorithm as the smart card, a user's account password can be different every time she logs in. As long as the smart card and the application on the computer are kept in sync, it becomes very improbable for someone to "steal" your password. And most smart cards have passwords that can be used only one time. This means that even if someone happens to glance at the current password on your smart card, after you've used the password to log in, it can't be reused and abused.

SecurlD cards are based on digital certificates and require the user to enter a PIN for their use.

Computers and Privacy Part 1

When computers were standalone systems that were easily controlled by a central administrative group, keeping data out of the hands of those who didn't need to see it was already difficult. Usernames and passwords were designed to restrict individual users and their actions, as well as track the actions they performed. File and resource protections enforced by operating systems made it simple to keep most prying eyes out of sensitive files, but where there's a will, there's usually a way, and even operating system resource-protection techniques have their vulnerabilities.

For example, many passwords are either easy to guess or easy to obtain. If you don't enforce a strict security policy in your network, often users will use passwords that are so simple it makes a joke out of using passwords at all. Passwords such as the name of the local football team, a spouse, a child, or even a pet are often used because they're easy to remember. It is a good idea to create passwords using both uppercase and lowercase letters and alphabetic and numeric characters. These techniques can go a long way toward preventing a hacker from using a simple dictionary attack against your network. This kind of attack simply involves using a program that cycles through all the words in a dictionary to see whether any match up to your password. Hackers don't use just any dictionary, but instead can find huge lists of possible passwords (names, city names, baseball teams, and others we've just mentioned) to use. Another type of dictionary attack can be performed on Unix systems if the hacker steals the password file. Because the encryption scheme is known for most Unix systems, the program can simply encrypt every word found in a dictionary and compare it to the encrypted version in the simple /etc/passwd file!

When you consider the environment today, with large-scale networks and connections to the Internet, the security issues become even more complex and difficult to manage using simple schemes, such as username/password authentication. Encrypting the actual data files themselves, especially when they are to be transferred across an untrusted network link, can solve a large part of this problem.

Encryption techniques should be seriously considered in an environment in which security is considered an important part of the network and not assumed to be taken care of by the standard username/password mechanism.

What Is Encryption?

Encryption is the process of performing some function on a set of data that attempts to render it in a format that makes it unreadable or unusable by anyone but the intended recipient. A key is required to read something that has been encrypted. This might be a secret key, as is the case with single-key encryption, or it might be a key that can be known by many different people, as is the case with public-key encryption. Some cryptographic methods use the same key for encrypting and decrypting information, whereas others use a separate key for these functions.

Digital signatures and certificates are part of another interesting concept that has become increasingly important in networks today. You'll learn more about that later. First, take a quick look at basic encryption techniques.

Single-Key Encryption Symmetric Encryption

As its name implies, single-key encryption uses the same key to encrypt and decrypt information. The Data Encryption Standard (DES) is a technology developed by IBM in the 1970s and adopted as a federal government standard in the United States in 1976. DES was thought for many years to be extremely secure. It is still in use in many networks and businesses today. You'll find it in various forms, typically using more than one pass at encryption to secure the data. For example, a technique called triple-DES uses three different keys successively to encrypt and then re-encrypt the data. A 56-bit key is used, which results in a little over 72 quadrillion possible key values. You would think with such a large number of possible keys, and using multiple passes, that the data secured by DES would truly be secure.

That might have been true a few years ago. However, when you consider that the typical desktop PC today is a lot more powerful than the computers available back in the 1970s when DES was first developed, it's obvious that even this strong form of encryption is vulnerable to being broken, if only by a brute-force method in which every possible key value is tried. The National Institute of Standards and Technology (NIST) has decided not to recertify DES as a standard.