Learning Windows Server 2003

7.4. Locking Down Windows

Multi-user systems are security holes in and of themselves. The simplest systemsthose used by only one personare the easiest ones to secure because there's much less diversity and variance of usage on the part of one person than there is on the part of many. Unfortunately, most of our IT environments require multiple user accounts, so the following section focuses on some prudent ways to lock down Windows systems, including Windows Server 2003 machines and associated client workstation operating systems.

7.4.1. Password Requirements

Long passwords are more secure, period. As you might suspect, there are more permutations and combinations to try when one is attempting to crack a machine via brute force, and common English words, on which a dictionary attack can be based, are generally shorter than eight characters in length. By the same token, passwords that have not been changed in a long time are also insecure. Although most users grudgingly change their passwords on a regular basis when encouraged by administrators, some accountsnamely the Administrator and Guest accountsoften have the same password for life, which makes them an easy target for attack.

To counter these threats, consider setting some basic requirements for passwords. To set these restrictions on individual workstations and Windows Server 2003 member servers, follow these steps:

1. Open the MMC and navigate to the Local Security Policy snap-in. You usually access this by selecting Start All Programs Administrative Tools.

2. Navigate down the tree, through Security Settings, to Account Policies.

3. Click Password Policy.

4. Enable the Passwords must meet complexity requirements setting.

5. Change the Minimum password length to a decent length. I recommend eight characters. (I must note here that I prefer passwords longer than 14 characters, but I predict that you will encounter serious user resistance to such a move.)

6. Change the Maximum password age setting to a conservative setting. I recommend 90 days.

You can accomplish the same through GP if you have a Windows domain by selecting an appropriate GPO and loading the Group Policy Object Editor as I explained in Chapter 6. Keep in mind that changes to the domain password policy will affect all machines within the scope of the GP. The configuration tree within the Group Policy Object Editor remains the same.

One final note on passwords: encourage your users to use passphrases and not just passwords. This is a great way to enforce a 14-character minimum password length while still making it easy for your users to remember their codes. For example, suggest that they use something such as "My dog is named Molly!" as a password instead of something such as "jsx8q6sv8qtr3r." Tell your users to type their passwords in the password entry box as though they were typing into Microsoft Word or another common word processing program. Windows can accept it, and your users are more likely to remember it.

7.4.2. Account Lockout Policies

Three old-fashioned methods of gaining unauthorized access to a system are to attempt authentication using the following:

• A well-known username (e.g., administrator)

• A username not known but derived logically (e.g., admin)

• A different password for the username on each attempt, repeating as often as possible

Windows can thwart these styles of attack using an account lockout policy, which will disable an account for a specified period after a certain number of unsuccessful logon attempts.

To set the account lockout policy, follow these steps:

1. Open the MMC and load the Group Policy Object Editor for an appropriate GPO, or navigate to the Local Security Policy snap-in.

2. Navigate down the tree, through Security Settings, to Account Policies.

3. Click Account Lockout Policy.

4. Set the Account lockout threshold to a reasonably small number. I recommend three bad login attempts.

5. Set both the Account lockout duration and the Reset account lockout after options to 15 minutes. This setting resists attack while not seriously imposing on users who just suffer from "typo syndrome."

   As with password policy, you can configure account lockout policy at the local computer or domain level. However, because the password policies are domain dependent, the "local" level is in affect only when the computer is not logged onto the domain.

7.4.3. Local Options

In addition to securing local accounts, the newer Windows platforms give you the ability to lock down certain rights and configurations on the local computer in addition to any domain security policy that might be configured. Several of the available options do little to thwart attacks, so in this section I'll cover the six most effective changes you can make to your local security policy.

You can enable all of the hardening suggestions in this section through the Security Options section of the Local Security Policy snap-in to the MMC. You usually can find this snap-in under Start, All Programs, and Administrative Tools. To get to the appropriate section, navigate the snap-in tree by selecting Computer Configuration, Windows Settings, Security Settings, and Local Policies. Then click Security Options, and the different configuration switches will appear in the righthand pane.

The instructions in this section assume that you have already loaded the snap-in and navigated to the appropriate section.

7.4.3.1. Anonymous access

Windows allows access by an anonymous user to many shares and files using a null user account; this is a security hazard, of course. You still can enable anonymous access to files and directories by explicitly granting rights to the ANONYMOUS USER account in Windows inside the appropriate ACL. This setting merely disables that access by default, so you know exactly where connections are being made.

To fix this hazard, set Additional Restrictions for Anonymous Connections to No access without explicit anonymous permissions.

7.4.3.2. Shutdown without logon

Windows 2000 and Windows XP Professional machines come in a default configuration that allows you to shut down the system using the Shutdown...button on the logon screen, so you might be familiar with this feature. However, Windows 2000 Server and Windows Server 2003 machines disable this out of the box. Despite the convenience factor that this feature affords, it's best to leave rebooting a machine to administrators.

Change Allow system to shut down without having to log on to Disabled to secure this.

7.4.3.3. Automatic logoff

Some users log on to the network and then don't log off for months. This is a prominent security hole, as when that user leaves her desk, she still is authenticated to the network with her credentials. Malicious people can use this to do destructive things: delete and transfer files, plant a "root kit" or backdoor program, or change passwords.

You can make automatic logoff work in two ways: first, each valid user needs to have a time when she is not permitted to log on. This can be sometime in the early morning, perhaps 3:00 to 3:30 a.m. Then, a change to the local security policy needs to be made so that when the user's logon time expires, she is not permitted to log on.

To set up a logon time restriction on a domain controller for an Active Directory-enabled domain, follow these steps:

1. Go to the Active Directory Users and Computers snap-in.

2. Expand the icon for your domain and click the Users container.

3. Right-click a user and select Properties.

4. Click the Account tab, and then click the Logon Hours...button.

5. Select the appropriate region of time in the calendar block, and click the radio buttons to the right to either permit or deny logons during that time.

6. Click OK, and then OK once more to exit the user property sheet.

   This option is available only for members of an Active Directory domain.

Now, make the change to the computer's local security policy. Inside the Local Computer Policy snap-in, change Automatically log off users when logon time expires to Enabled. If you do not have a domain, instead change Automatically log off users when logon time expires (local) to Enabled. This will work even if users have locked their workstations.

7.4.3.4. Digitally signing communication

It's a good idea these days for a computer to authenticate itself to other computers during a communication. Otherwise, a technique called "spoofing" can be used, and a cracker's computer can pose as the remote end of a connection and receive potentially sensitive information. You can prevent this by using digital signatures . However, these are not pervasive; Windows compensates for this limited use by providing two options in the local policy: require it when possible, or require it, period.

I recommend requiring the signatures when possible on both ends of a connection (the RPC protocol refers to the requesting end as the "client" and the responding end as the "server," regardless of the systems' usual roles). Unsigned transmissions should occur only when signatures are not available, supported, or possible.

To require digitally signed communication when possible, change "Digitally sign client communication (when possible)" to Enabled and "Digitally sign server communication (when possible)" to Enabled.

7.4.3.5. Requiring the three-keystroke salute at logon

The logon screen is one of the most trusted aspects of a computer to a normal user. He trusts it enough that he gives his password and username, and then the computer trusts him, too, if all of that is correct and verified. A cracker can take advantage of this mutual trust by writing a program that runs as a system servicein other words, it doesn't need user privileges. The program will mimic the logon box, grab the user's input, and do something with it such as email the password to the cracker, save the credentials to a backdoor program data file, or any number of other nefarious things. However, pressing Ctrl-Alt-Del brings Windows to attention, and you get the authentic Windows logon and not a shell of one that a cracker creates. This easy step makes your system much more secure.

To require this keystroke to begin, change Disable CTRL+ALT+Delete requirement for logon to Disabled. (Yes, that's right. Microsoft uses some questionable terminology.)

7.4.3.6. Last username display

By default, Windows displays the username of the last successfully authenticated person to use that particular system on the logon screen. This is giving away needless information, although some of your users are probably accustomed to it.

To disable the last username from being displayed, change the "Do not display last user name in logon screen" setting to Enabled.

7.4.3.7. Password expiration prompt

Earlier in this chapter, I discussed setting password policies to prevent brute force attacks. Of course, changing passwords is a problem for some users who'd rather not be bothered with IS minutiae and simply would like to use their computers to be productive. With this policy setting, you can tell the system to automatically remind a user when his or her password will expire and prompt him or her to change it. Setting this value to 14 days gives a user ample opportunity to change their password because that is in excess of most scheduled vacations and business trips.

To enable the password expiration prompt, change the Prompt user to change password before expiration setting to 14 days at minimum.

7.4.4. Network Options Via Group Policy

Windows Server 2003 and GP allow you to configure security options that reside inside GPOs that will apply to groups of computers. GP can manage security settings throughout an Active Directory environment in seven areas. They are shown in Table 7-2.

7.4.4.1. Viewing the default domain policy

When you install Windows Server 2003, a default domain security policy is created. The default domain security policy is simply a set of configurations that apply certain security settings to all members of the domain: these can include security settings for displaying the username of the last user that logged on to a system, how long a password should be, whether workstations should digitally sign transmissions to and from a server, and so on. It's a simple task to use this default policy as a base and customize settings based on your individual implementation. Let's look at this default policy first, and then work through customizing it.

To view the default domain security policy, follow these steps:

1. Open the Active Directory Users and Computers snap-in.

2. Expand the domain tree corresponding to your domain's name in the left pane.

3. Right-click the domain name and select Properties.

4. Click the Group Policy tab, select Default Domain Policy in the details box, and then click the Edit button. Windows opens the Group Policy Object Editor window.

5. To view each default domain policy, drill down through Computer Configuration, Windows Settings, and Security Settings, and click Account Policies.

6. Look at the right pane. You'll see Password Policy, Account Lockout Policy, and Kerberos Policy. By clicking each, you can view or change their default configuration.

Figure 7-12 shows the default domain policy on a standard, out-of-the-box installation of Windows Server 2003.

7.4.4.2. Viewing the default domain controller security policies

The default domain controller security policy, like the default domain security policy, applies a common configuration to a group of computers, but this time the focus is on only domain controllers. Domain controllers often have special security considerations that ought to be addressed separately, and this default policy does that. You will need to use the Group Policy Object Editor MMC snap-in to look at the default security policy on the Domain Controllers organizational unit. To do that, follow these steps:

1. Load the snap-in as described a bit earlier in the chapter. Ensure that in step 4, you selected the Domain Controllers.yourdomain.com object.

2. In the left pane, drill down through Computer Configuration, Windows Settings, and Security Settings.

3. Click Account Policies. In the right pane, you'll see the possible security options for this organizational unit.

Figure 7-13 shows the default domain controller security policy on a standard, out-of-the-box installation of Windows Server 2003.

There is a special way in which account policies are distributed to domain controllers which deserves comment. All domain controllers in a specific domain will apply security policies established at the domain level regardless of where the actual computer

object for that domain controller resides in Active Directory. This helps to ensure that consistent account policies apply to any domain account. All other policies are applied at the normal hierarchical level, both to domain controllers and to other workstations and servers in the domain. Only domain controllers are affected by this special exception. This is just a tip to remember when you're planning account policy distribution among your organizational units.

7.4.4.3. Viewing a domain controller's effective security policy

To view the effective security policy from a domain controller, complete the steps explained next.

1. Choose Start, click Run, and type GPEdit.msc. The Group Policy Object Editor will open.

2. In the left pane, drill down through Computer Configuration Windows Settings Security Settings, and click Local Policies.

Now you can view the domain controller's effective security policy. When you're finished, close the Group Policy/Local Computer Policy snap-in. (When prompted to save console settings, click No, unless you've done something you want to hold on to.)

At this point, you have all the tools you need to begin pushing automated security configurations to clients running Windows 2000 and later. Do note that all settings covered in this book, unless noted at the time each is presented, are fair game for distribution under GP.

7.4.4.4. Final words: organizing policy layout

With power comes complexity, and GP is no exception. Windows administrators have squandered away many hours of their lives on basic GP troubleshooting. Answers to quandaries such as, "Why isn't this policy in effect on this system?" or "I thought I turned off IPSec!" can be difficult to track down if your Active Directory is full of GPOs that are applied inconsistently, redundantly, and inappropriately.

To curtail your security policies and make them easier to locate, disable, change, and apply, try to follow these guidelines:

Organize your policies logically and define boundaries to contain them.

Although your Active Directory might be organized by geographic location, your system management needs might revolve around a different paradigm: for instance, you might need IPSec for all company executives' laptops, but all of them might not be in your New York office. Or all middle managers in your corporation might require a customized version of Internet Explorer that doesn't lock them out from accessing the Internet, which might be the default configuration for all computers in the domain. The idea is to map out the kinds of restrictions you need, and then define boundaries to which those policies apply. This will make it easier to apply them to the target users and computers even if the geographical and managerial boundaries do not match.

Inside those boundaries configure policies that represent common values in your organization.

Do you usually configure workstations in your finance department to lock a computer after three unsuccessful logon attempts? Does a particular domain in your forest need additional desktop restrictionsshould they not be allowed to run the Control Panel, for instance? Change their wallpaper? Install software on their own? These are the kinds of policy sets that likely sound familiar. Group these together and create GPOs for each of these like sets of policy settings.

Configure organizational units inside Active Directory that contain machines grouped according to similar roles or functions within an organization.

This gets further into the granularity of your security policies. For example, Windows comes by default with domain controllers residing in a separate organizational unit in Active Directory. You might consider putting desktops, laptops, and servers into their own organizational units, which makes it easier to apply policies, such as requiring use of the EFS, only to laptops.

Now I'll present an understatement: it can require some work to configure GP correctly and effectively. The most difficult parts of the process are planning and laying out the policy settings; Windows takes care of the actual deployment to client computers, which is one of the features that makes GP a compelling management tool. This ease of deployment is a double-edged sword, however: it is equally simple to misconfigure an ACL or change a setting (anybody who has played with the "require signed communications" settings knows this all too well) and wreak utter havoc on your domain. The process also is made more difficult by the lack of an API, so you can't write simple automation programs to help you out. You have to go the long way.

Even more difficult sometimes is getting the big picture. That is to say, it is hard to see how your Active Directory layout and structurewhich logically and traditionally have likely mimicked your organization's hierarchical personnel structurecan co-exist with GPOs, which seem to cross hierarchy boundaries and rely on other scopes of application. With careful planning, however, GP can overlay your existing directory structure and complement it with its own management boundaries.