Windows 2000 Security

WINDOWS SUFFERS FROM THE WOOB syndrome: It’s wide open out of the box so that the user has all features and capabilities accessible to him automatically if he wants them. Unfortunately, the undesirables on the Internet have decided to take advantage of this unguarded default state and use it as a basis for staging attacks, hack attempts, and general computing mayhem.

This chapter focuses on protecting a Windows 2000 Professional and Server, Windows XP Professional, and Windows Server 2003 through the use of system updates and update audits, password policies, user-account protection, and basic local computer-security policies.

The first step to configuring any new Windows system is to update it with the latest service pack. Service packs are updates to critical Windows system files based on bug reports, security vulnerabilities, and (rarely) new features. Windows operating system service packs are normally cumulative, in that they contain all fixes and service packs previous to the current level.

As of this writing, the latest pack level available for the Windows 2000 platform is Service Pack 4. The Windows XP client platform also has Service Pack 1 available. Both of these update packs are offered in two distinct versions:

• Windows Update service: With this option, the Windows Update website downloads an ActiveX control to your computer and searches your installed operating system for updates that are needed. It then custom-delivers a service pack to you based on the update level of your current system. For example, you may have downloaded five of nine critical security updates. The version of the service pack you receive will be built to deliver the remaining four updates and anything else that hasn’t already been updated. Surf to http://www.windowsupdate.com to get started using this version.
  
  
• Network Download version. This is the complete service pack executable file designed to be stored on a file server and installed from a central location, either manually by a system administrator or automatically using automated tools like Systems Management Server or Microsoft Operations Manager. These files are usually hundreds of megabytes in size, so they’re apt to be burned on CD and stored for easy distribution. The network download version of Windows 2000 Service Pack 3 is available from http://download.microsoft.com/download/win2000platform/SP/
  SP3/NT5/EN-US/W2Ksp3.exe. The network download version of Windows XP Service Pack 1 is available from http://download.microsoft.com/download/whistler/SP/SP1/
  WXP/en-us/xpsp1_en_x86.exe.

Many administrators complain that as they receive new systems to deploy on the corporate network, it takes an increasing amount of time, relative to the age of the operating system (and therefore the number and complexity of updates released for that OS) to get said systems prepared for everyday usage. Even if the systems come with an operating system preinstalled and updated, it’s likely that you have your own way of initially configuring a system and its applications, and you probably wipe the system clean and reinstall the system.

You may have an image file to aid in new system deployment, created using a tool like Symantec’s Ghost or the Altiris line of network management and deployment tools, but you still must keep your master image updated. Hence, a real need is created for a standard Windows distribution CD-ROM with the latest service pack completely integrated, or “slipstreamed.”

Fortunately, Microsoft has made it easy to create this handy tool. You’ll need the network/administrative (in other words, the full) version of the service pack for your respective platform. To create the slipstreamed CD do the following:

1. Copy a stock Windows distribution CD into a directory on your hard drive. For the remainder of this example, let’s use c:\windist. You’ll likely need to create this directory.

2. Create a directory called c:\winsp, and copy the downloaded service pack file there. Let’s assume the service pack file is named w2ksp3.exe.

3. Extract the service pack to that directory by executing the following command from the command line or by selecting Start -> Run: w2ksp3.exe –x.
   
4. Now, update the files from the regular Windows distribution CD with the new service pack files by executing the following command from the command line or from Start -> Run: D:\win2ksp3\i386\UPDATE\UPDATE.EXE -S:C:\windist.

The files are then updated, and the process is complete. At this point, you can create a new CD for your own purposes, or create an administrative share for use with Remote Installation Service (RIS) and other tools. Slipstreaming is an easy way to make sure new systems are updated before they’re ever put into production.  

Of course, it takes time to create service packs and test them for wide distribution. And it seems new bugs and security vulnerabilities are discovered on a daily basis, if not more often. To address these problems, Microsoft releases “hotfixes,” which patch specific problems. Normally, these aren’t as widely tested as service packs, which have formal technical beta programs with thousands of testers with various systems and implementations, and they sometimes can cause instability. However, a cogent risk versus reward analysis would generally lead a prudent administrator to believe that applying hotfixes is a good protective measure.

There are a couple of different ways to get your systems updated with the latest hotfix files. As described earlier in this chapter, you can visit Windows Update (http://www.windowsupdate.com) and dynamically receive any updates that Microsoft deems important. Also, with Windows 2000 Service Pack 3 and all versions of Windows XP Home and Professional, the Critical Update Notification (CUN) service is available. This tool periodically checks the Windows Update catalog for new updates and alerts you to their presence. Upon installation of either the service pack or Windows XP itself, you should be prompted to configure this service.

While the CUN tool and Windows Update are nice for individual users and small organizations, there is a more appropriate tool for network administrators. Microsoft has licensed a utility from Shavlik Technologies called HFNetChk. HFNetChk is a command-line tool that scans client computers for installed updates and patches. The comparison is based on an XML file of all available updates and the criteria for those updates, and Microsoft constantly updates the list.

The first time you run the tool, the tool will download the signed XML file, verify its authenticity, and decompress the file. HFNetChk then scans the selected computers to figure out the level of the operating system, service packs, and programs installed on the systems. HFNetChk looks at three aspects of your system to determine if a patch is installed: the Registry key that’s installed by the patch, the file version, and the checksum for each file that’s installed by the patch. By default, HFNetChk compares the files and Registry details on the computer that’s being scanned to the XML file it downloads. If any of the three criteria discussed previously aren’t satisfied, the tool considers the associated patch to be absent, and the results are displayed on the console. In the default configuration, HFNetChk output displays only those patches that are necessary to bring your computer up to date.

To use the tool, enter and run hfnetchk from the command line. Table 3-1 lists some command-line switches and their use.

Security Templates

Microsoft wisely decided to ship Windows 2000 with a few predefined security settings files, hereafter referred to as “security templates.” These files contain what are essentially recipes for configuring a machine’s security policy based on its daily role. There are six predefined security templates:

• For computers running Windows 2000 Professional, basicwk.inf and securewk.inf

• For computers running Windows 2000 Server, basicsv.inf and securesv.inf

• For computers running Windows 2000 Server and functioning as a domain controller, basicdc.inf and securedc.inf

Inside these templates are specifications for almost all aspects of local security policy—the only area of local policy not included is user rights and groups. You’ll need to configure any desired user rights and groups modifications yourself. Additionally, Microsoft chose to include incremental security templates that go above and beyond the specifications made in the basic templates. These templates, designed to be applied to new Windows 2000 installations that have already had a basic template applied, must be used on systems formatted with NTFS, at least on the boot partition (the one containing the operating system files). The incremental security templates are as follows:

• For workstations or servers in which users ought to be prevented from being in the Power Users group, apply the compatws.inf template. This template compensates for the lack of additional privileges afforded to members of the Power Users group by relaxing the rights restrictions on the normal Users group.
  
• To further secure workstations or servers, the securews.inf template increases the overall security level of a machine by tightening areas of the OS not under the purview of rights and restrictions. Areas that are more secured using this template include account policy settings, auditing controls, and Registry keys that are prominent in security policy. The appropriate version of this template for Windows 2000 domain controllers is securedc.inf.

• For the ultraparanoid and those with the most stringent security requirements, the hisecws.inf file (and for domain controllers, the hisecdc.inf file) can be used; however, because all network transmissions must be signed and encrypted by Windows 2000 machines, this template is appropriate only in pure Windows 2000 or greater environments.

These convenient templates are designed to be used with the Security Templates snap-in to the Microsoft Management Console (MMC). Using the snap-in, you can apply the basic and incremental security templates included with the product, or you can make custom modifications to the templates and create your own easily distributable template.

To begin using the Security Templates snap-in, follow this procedure:

1. Enter and run mmc /s from a command line. This loads the Microsoft Management Console in author mode, allowing you to add a snap-in.

2. From the Console menu, select Add/Remove Snap-in. Then select Add. This opens a dialog box titled Add Standalone Snap-in.

3. From the list, select Security Templates, click Add, and then click Close.

4. Click OK in the next dialog box to confirm the addition of the snap-in.

You now have the Security Templates snap-in added to a console. From this snap-in, you can expand the Security Templates section in the console tree on the left, and then expand the C:\WINNT\security\templates folder to view the predefined security templates that were previously discussed.

You may wish to make your own customized policy modifications that go above and beyond those made in the templates shipped with Windows 2000. Creating a custom security template affords you an easy way to package, deploy, and apply these modifications with minimal administrative headaches. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis tool to assess the overall “hardness,” or state of security, of your machines.

To create your own security template, do the following:

1. In the Security Templates console, expand Security Templates in the tree view on the left, and right-click C:\WINNT\security
   \templates (this is the default templates folder in the system).

2. Select New Template from the context menu that appears.

You may now make any policy modifications you wish in any one of the policy areas supported by the tool: account policies, local policies, the event log, restricted groups, system services, the Registry, and the file system. Your additions, deletions, and other changes are saved directly into the template as they’re made.

To take this one step further, you may decide to build on the basic policy settings provided by the basic and incremental templates shipped with Windows 2000. In that case, it’s quite simple to open the basic or incremental templates, resave to a different name, and make further modifications to it in order to create your own custom template, as shown in the following procedure:

1. Select an existing template inside the Security Templates console. In this example, I’ll use the securews.inf file.

2. Right-click the existing template, and choose Save As from the context menu.

3. Give the new template a name, as shown in Figure 3-1.
   
   
   
   Figure 3-1. Creating a new security template.
   
4. Click OK. The new template is created with the settings from the old basic template.

In the following subsections, I’ll discuss the security-policy settings that I recommend for a hardened Windows 2000 installation, regardless of whether you use the predefined security templates covered earlier in the chapter or not. I’ve broken these down into two sections: user accounts that cover ways to harden multiuser environments against attacks from both the outside and the inside, and local options, which give you ways to configure the operating system to protect itself against data hijacking, hacked transmissions, and unauthorized logons.

Multiuser systems are security holes in and of themselves. If you recall, the Windows NT operating system achieved government C2-level (orange book) security accreditation back in the mid-1990s. Although this seemed impressive initially, the joke was that the OS was only C2-certifiable in a nonnetworked, standalone environment. Given that NT was billed as a network operating system that would be used by many people, it was effectively a nonstarter to use C2 as a selling point.

Unfortunately, everyone needs multiple user accounts, so this section focuses on hardening these accounts as much as possible.

Password Requirements

Long passwords are more secure, period. The mathematics of the issue are fairly obvious: There are more permutations and combinations to try when brute-force cracking a longer password. Additionally, common English words (on which a dictionary attack can be based) are usually shorter than eight characters, making them easy to crack. Finally, aging passwords are insecure. Though most users tend to change their passwords on a regular basis when encouraged by administrators, some accounts—namely the Administrator and Guest accounts—often have the same password for life, which makes them an easy target for attack. To set these restrictions, do the following:

1. Open the Microsoft Management Console and navigate to the Local Computer Policy snap-in. This is normally under Start -> 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 8 characters.

6. Change the Maximum Password Age setting to 90 days.

Account Lockout Policies

An old-fashioned method for gaining unauthorized access to a system is to attempt authentication using a known username, or an unknown username that’s derived logically along with a different password on each attempt. Windows can thwart this attack using an account lockout policy, which will disable an account for a specified period of time after a certain number of unsuccessful logon attempts.

To set the account lockout policy, do the following:

1. Open the Microsoft Management Console and navigate to the Local Computer Policy snap-in. This is normally under Start -> Programs -> Administrative Tools.

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

3. Click Account Lockout Policy.

4. Set the Account Lockout Threshold to 3 for the maximum number of bad login attempts.

5. Set both the Account Lockout Duration and Reset Account Lockout After options to 15 minutes.

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, beyond any domain security policy that might be configured. Several of the options available do little to thwart attacks, so in this section I’ve covered the seven most effective changes you can make to your local security policy.

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

Anonymous Access

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

To fix this hazard, set the Additional Restrictions for Anonymous Connections selection to No Access Without Explicit Anonymous Permissions.  

Shut Down Without Logon

Windows 2000 and Windows XP Professional machines come in a default configuration that allows you to shut down the system through the use of the Shutdown button on the logon screen. Windows 2000 and .NET servers disable this out of the box. Despite the convenience factor that this feature affords, it’s best to leave rebooting a machine to an aware user.

Disable the Allow System to Shut Down Without Having to Log On selection to secure this.

Automatic Logoff

Some users log on to the network and then don’t log off for months. This is a prominent security hole, because when that user leaves her desk, she is still authenticated to the network with her credentials. These can be used to do destructive things: file deletion and transfer, planting of a “root kit” or backdoor program, or password changing.

The way to make this work is twofold: First, each valid user needs to have a time when he isn’t permitted to log on. This can be somewhere in the morning for a standard 9 AM to 5 PM office, perhaps at 3 AM to 3:30 AM. Then, you need to make a change to the local security policy so that when the user’s logon time expires, he isn’t permitted to log on.

To set up a logon time restriction on a domain controller for an Active Directory–enabled domain, do the following:

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

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

3. Right-click a username, 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 once, and then again to exit the user property sheet.

This option is only available on Active Directory–enabled machines.

Now, make the change to the computer’s local security policy. In the Local Computer Policy snap-in, enable the Automatically Log Off Users When Logon Time Expires option. If you don’t have a domain, you should enable the Automatically Log Off Users When Logon Time Expires (local) option.

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” could be used, and a cracker’s computer could pose as the remote end of a connection and acquire potentially sensitive information. You can prevent this by using digital signatures. However, they aren’t pervasive; Windows compensates for this limited use by providing two options in the local policy: require them when possible, or require them, period.

I recommend requiring the signatures when possible on both ends of a connection (the remote procedure call, or RPC) protocol refers to the requesting end as the “client” and the responding end as the “server,” no matter the systems’ usual roles). Unsigned transmissions should only occur when signatures aren’t available, supported, or possible.

To require digitally signed communication when possible, enable the Digitally Sign Client Communication (When Possible) and Digitally Sign Server Communication (When Possible) options.

Requiring the Three-Keystroke Salute at Logon

The logon screen is one of the most trusted aspects of a computer to a normal user. She trusts it enough that she gives her password and username, and then the computer trusts her, 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 service—that is, it doesn’t need user privileges. The program will mimic the logon box, grab the user’s input, and do something with it. “It” could be emailing the password to the cracker, saving the credentials to a backdoor program data file, or any number of other nefarious things. However, pressing Ctrl-Alt-Del brings Windows itself to attention, and you get the authentic Windows logon instead of a shell of one that a cracker creates. This is an easy step that makes your system much more secure.

To require this keystroke, disable the Disable Ctrl-Alt-Del Requirement for Logon option. (Yes, that’s right. Microsoft uses some questionable terminology.)

Last Username Display

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

To disable the last username from being displayed, enable the Do Not Display Last User Name in Logon Screen option.

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 Internet security (IS) minutia and would like to simply use their computers to be productive. With this policy setting, you can tell the system to automatically remind a user when his password will expire and prompt him to change it. Setting this value to 14 days gives a user ample opportunity to change his password, because that’s in excess of most scheduled vacations and business trips.

To enable the password expiration prompt, set the Prompt User to Change Password Before Expiration option to 14 Days at Minimum.   

Although the earlier sections discussed policy modifications that will harden a Windows 2000 installation, there are other facets of the operating system that do require attention. Although simply making the policy modifications takes you partially on the journey to a hardened system, it’s only a portion of the full process. This section presents some areas that deserve your consideration.

Security is a minimalist attitude: That is to say, when you harden a system, you want as few basic entry points as possible. This in effect shortens the length of the playing field for an intruder: She has fewer processes and fewer software products whose flaws she can exploit, and there’s less chance that you, the administrator, will configure something improperly or forget it entirely. Windows 2000 makes this a little more difficult, especially at install time, when it isn’t possible to select components that you would like not to be installed.

If I might offer a slight editorial aside, this is a serious flaw in Windows and a HUGE mistake on Microsoft’s part. It would have been bad enough if Microsoft decided that none of their operating systems should ever present the user with component installation options. But this functionality remains available in the Windows 9x line and even in Windows NT! And yet mysteriously, it isn’t present in Windows 2000 or Server 2003. It’s baffling to me why these options were removed at the point of installation. If anyone from Microsoft is reading this, please return the power of choice to me, the user!

Continuing with the minimalist approach, you need to ensure that the only services or processes running on your system are those that (a) you know about and (b) are critical to the functioning of a particular system or resource. This seems like a simple task initially, but Microsoft has made life a bit more difficult than it should be by failing to properly document which services are dependent on others. Therefore, it’s foolhardy to open the Services console and simply begin turning off services at random, hoping to tighten the network through broad, sweeping motions. It just won’t work. Instead, peruse the following list, making note of the bare minimum of services required to run Windows 2000:

• DNS Client

• Event Log

• File Replication (only on a domain controller)

• Kerberos Key Distribution Center (only on a domain controller)

• Logical Disk Manager

• Net Logon (only on a domain controller)

• NT LM Service Provider (only on a domain controller)

• Plug & Play

• Protected Storage

• RPC Locator (only on a domain controller)

• Security Accounts Manager

• Server (only on machines hosting resources to be shared)

• Windows Time (only on a domain controller)

• Workstation (only on machines connecting to other machines’ shared resources)

In this chapter, I’ve discussed updating your Windows 2000, XP, or .NET machine to the latest levels available and securing your system through password, account, and computer policies. Use the following quick-reference checkpoints to ensure that you’ve covered each step in the chapter appropriately.

• Update to the latest service-pack level for your platform.

• Create a “slipstreamed” distribution CD to deploy the latest service-pack update to any new OS installs.

• Use the latest hotfix file patches from Microsoft to relieve your system of vulnerabilities.

• Download and use HFNetChk to scan and inventory your network for security-patch installations.

• Set restrictions on Windows passwords. They should be at least six characters long, they shouldn’t be based on a dictionary word, and they shouldn’t last longer than 90 days.

• Configure Windows to disable or “lock out” accounts for at least 15 minutes after three unsuccessful authentication attempts.

• Disable all anonymous access except where explicitly allowed in file-system permissions.

• Disable the ability to shut down a system without first logging in to it.

• Enable automatic logoff upon logon time expiration, and set up at least one half hour each night during which no user is permitted to log on.

• Require digitally signed communications when possible, but not always.

• Require the user to press Ctrl-Alt-Del before logging on, a key sequence recognized only by the Windows operating system.

• Do not permit the username of the last user to be displayed at logon.

• Remind users to change their password automatically at least 14 days before its expiration.