Table 9.3: Recommended Settings for the Account Lockout Policy Setting Description Recommended setting Account lockout duration The number of minutes a locked-out account will stay locked out. If this is set to 0, the account will have to be unlocked by an administrator or someone who has been given the right to do so. 30 minutes Account lockout threshold The number of incorrect attempts at guessing a password that can be made before the account is locked out. 5 invalid logons Reset account lockout counter after The number of minutes after which the count of invalid logon attempts will be reset. If the number of minutes between one invalid logon and another is greater than the number of minutes to which this setting is configured, the previous invalid logon attempts won't matter. 10 minutes N ote A good password policy is essential to network security, but, unfortunately, it is often overlooked. Here are several tips about the worst practices that you should avoid under all circumstances: • Do not create local Administrator accounts (or common domain-level administrator accounts) using a variation of the company name, computer name, advertising tag lines or dictionary words, such as %companyname%#1, win2k%companyname%, etc. • Do not create new user accounts with simple passwords that aren't required to change the password after the first logon. Be aware that none of the above-described settings can force your end users to create strong passwords. Similarly, even the strongest password policy can prevent users from writing down their passwords and attaching a note to their monitors, sharing passwords with other users, or complaining to management when they have to get help to reset a password they have forgotten. Protecting the Local Administrator Account When your Windows NT-based system is joined to a domain, the local Administrator account is still present (as was already mentioned, it resides in (%SystemRoot%\System32\Config\SAM). Actually, members of the Domain Admins group can administer the local system only because this group is added to the local Administrators group. Hence, it is necessary to protect the local Administrator's account from unauthorized use or misuse. This goal could be achieved by taking the following protective steps:  As aforementioned, physical security is essential. Although this recommendation might seem elementary, you must not overlook such obvious things. As statistics have shown, most security incidents in corporate environments occur from the inside. Therefore, it is necessary to physically secure all servers (they should be placed in a physically secure room with monitored access) and critical workstations (consider locking the cases or using removable hard drives that are locked up at night). On physically unsecured systems, disable the ability to boot from a CD or floppy. Also, for extra security, disable AutoRun functionality for CD-ROM drives on physically insecure systems. Finally, when considering physical security, do not forget about securing your backup media.  Use NTFS on all partitions. For Windows 2000, Windows XP, and Windows Server 2003, enable EFS (Encrypting File System)—a built-in powerful encryption system, which adds an extra layer of security to drives, folders, or files. Be sure to enable encryption on folders, not just files. All files that are placed in that folder will be encrypted. In particular, it is recommended that the user encrypt the TEMP folder, which is used by applications to temporarily store copies of files being modified (notice that applications do not always clean that folder after closing the files).  Restrict the number of unnecessary user accounts, such as any duplicate user accounts, accounts created for testing purposes, shared accounts, etc. Most generic accounts have weak passwords and provide lots of unnecessary access rights. In Windows NT 4.0, disable the Guest account. Although Windows 2000 and its successors disable the Guest account by default, it is still recommended that you make sure that someone has not enabled it. For additional security, assign a complex password to the account anyway, and restrict its logon hours.  Restrict the addition of local accounts to the local Administrators group, and require a strong password for the local Administrator account. Rename the Administrator account. Although this won't stop qualified intruders (they will use the SID to find out what is the name of the Administrator account), it will still result in a time delay. When renaming the local Administrator account, try to avoid using the word "Admin" in its name. Also, consider creating a dummy account named "Administrator", having a long, rather complex password and no privileges. Enable auditing on this account to get information when someone is tampering with it.  Shut down and disable unnecessary services, since they take up system resources and can open holes into your operating system. IIS, RAS, and Terminal Services have security and configuration issues of their own, and should be implemented carefully if required. You should be aware of all the services that run on your servers and audit them periodically. Also, on Windows 2000 systems, it is recommended that you remove OS/2 and POSIX subsystems if you do not use them (and, in fact, they are used quite rarely). Removing these subsystems will improve performance and reduce potential security risks. To remove the OS/2 and POSIX subsystems, delete the \%SystemRoot%\system32\os2 directory and all of its subdirectories, then use the Registry Editor to remove the following registry entries: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for NT key with all its subkeys, the Os2LibPath entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, the Optional entry and all entries for OS2 and POSIX under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems. The changes take effect the next time the computer is started. You might want to update the emergency repair disk to reflect these changes.  Disable DirectDraw. Here one should notice that disabling DirectDraw will impact the programs that actually require it (mainly, these are modern games), but it will not influence most business applications. Furthermore, this will prevent direct access to video hardware and memory, which is required by the basic C2 security. To do this, go to the HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\DCI registry key and set the Timeout value (REG_DWORD data type) to 0.  Disable the default hidden shares. Windows NT-based systems create hidden shares that are used by the SYSTEM account (also hidden). All Windows NT- based operating systems open hidden shares on each installation for use by the system account. However, you can view all shared folders on your computer by typing the net share command from a command prompt. There are two methods of disabling the default shares—first, you can stop or disable the Server service, which removes the ability to share folders on your computer. To use the second approach, edit the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServ er\Parameters registry key. For server platforms, create the AutoShareServer value (REG_DWORD) and set it to 0. For workstations, create the REG_DWORD value named AutoShareWks and set it to 0. Keep in mind, however, that this security measure might cause problems with applications.  Restrict anonymous access to the computer. Anonymous users or services that log on anonymously are automatically added to the Anonymous Logon built-in security group (S-1-5-7). In earlier versions of Windows NT, such users or services were able to access many resources (sometimes in cases where access should have only been granted to authenticated users). Starting with Windows 2000, Microsoft introduced stricter security settings which prevent anonymous access to all resources, except for those who have been explicitly assigned access. You can do this by using the Local Security Policy MMC snap-in or by editing the registry directly. To achieve this purpose using Local Security Policy, one had to select the Additional restrictions for anonymous connections option under Security Settings | Local Policies | Security Options, and then setting the No access without explicit anonymous permissions option. To do the same thing by editing the registry directly, it was necessary to create the REG_DWORD value named RestrictAnonymous under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA registry key and set this value to 0x2 (Hex). In addition to these standard protective measures, Windows XP and Windows Server 2003 include a set of powerful new security features, which will be briefly considered in the following few sections. Windows XP and Windows Server 2003 Enhancements and Compatibility Issues Windows XP and Windows Server 2003 have gone even further than Windows 2000 in tightening the security system, and introduced a range of additional protective steps. However, it is necessary to mention that if you decide to use them, this might cause some administrative inconvenience, especially in mixed environments. Therefore, you must test them carefully before deploying them. Restricting Anonymous Access In contrast to previous versions of Windows, the access token for anonymous users no longer includes the Everyone security group. Therefore, the access token for anonymous users contains SIDs for:  Anonymous Logon  The logon type (usually Network) When an anonymous user tries to access a resource on a computer that is running Windows XP, he or she is not granted permissions or group memberships that are available to the Everyone security group. The SID for the Everyone security group is present in the anonymous user's access token. It should be noted that in most cases this restriction is desirable and appropriate. However, in some situations, for the sake of backward compatibility, you may need to include the Anonymous Logon security group into the Everyone group. For this very purpose, Windows XP and Windows Server 2003 have introduced a new registry value, EveryoneIncludesAnonymous, which can be set using the methods described below. To enable anonymous access via MMC, proceed as follows: 1. Start the Local Security Policy MMC snap-in, expand the Security Settings tree, then select Local Policies | Security Options. 2. Double-click Network access: Let Everyone permissions apply to anonymous users. By default, this policy setting is disabled (Fig. 9.22 ). Figure 9.22: Setting EveryoneIncludesAnonymous registry value via Local Security Policy 3. To enable anonymous users to be members of the Everyone security group, click Enabled. To prevent the inclusion of the Everyone security group SID in the anonymous user's access token (the Windows XP and Windows Server 2003 default), click Disabled. To set the EveryoneIncludesAnonymous registry value by using Registry Editor, proceed as follows: 1. Start Regedit.exe and locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 2. Right-click EveryoneIncludesAnonymous, and then click Modify. 3. To enable anonymous users to be members of the Everyone security group, in the Value data box, type 1. To prevent the inclusion of the Everyone security group SID in the anonymous user's access token, type 0. 4. Quit Registry Editor. Disabling the Administrator Account This security option is only available in Windows XP and Windows Server 2003 and lets you disable the local Administrator account. To do so, simply right-click the local Administrator account, and select the Disable account command from the context menu. In contrast to previous Windows NT-based systems, where local Administrator accounts could not be disabled, Windows XP and Windows Server 2003 will allow you to do this (Fig. 9.23 ). This option is rather useful, since it eliminates the possibility of misusing the Administrator password. Figure 9.23: Disabling the local Administrator account N ote Because members of the Domain Admins group have administrative authority on computers joined in their domain, you still maintain the ability to administer the system. Also, the Administrator account will remain enabled when booting in safe mode. Selecting this feature, however, can have some interesting side effects. For example, if you change the password policy after disabling the Administrator account, and this account no longer meets the policy requirements, your attempt at reenabling it will fail. In this case, another administrator must log on and reset the Administrator account password. If there are no other administrative accounts, you will have to reboot to the safe mode to fix the problem. Limiting Local Account Use of Blank Passwords to Console-Logon Only Admittedly, the password policy should prevent the use of blank passwords entirely. However, you should recall that someone who has the password to the local Administrator's account (or other account with membership in the local Administrators group) could modify the local account and password policy to permit blank passwords and modify an account in order to use it. When the use of blank passwords is limited to console logon only (an option for only Windows XP and Windows Server 2003 systems), an account with a blank password cannot be used for network logon. The user must work on the Windows XP or Windows Server 2003 system in which the account exists. You have effectively prevented an intruder from using the local Administrator account (or any other privileged account) to access files, folders, registry keys, and so on, on this machine. This configuration also prevents applications such as FTP, Telnet, and terminal services from using an account with a blank password. However, Microsoft advises that applications requiring remote access be written to bypass this setting. Security Through Obscurity Of course, security through obscurity will not work, if obscurity is your only line of defense. However, making things more difficult for attackers is a useful practice, especially when it comes to protecting the local Administrator account. The option allowing one to rename this account existed already in Windows 2000, and remains a part of Windows XP and Windows Server 2003. However, as was mentioned earlier, it won't stop a qualified intruder, since the task of determining which of the accounts is the local Administrator's account would not be too difficult. Being well aware of this weak point, Microsoft has introduced several new protective measures, intended to make this harder. They can be enforced via Group Policy (under Local Policy | Security Options). The list of these new policies includes:  Network access: Allow Anonymous SID and Name Translation. When this setting is enabled, the system will answer anonymous requests for the name of the account associated with SID belonging to the local Administrator account. Since the local Administrator account is associated with the well-known SID, the task of determining the new name of this account becomes trivial. If you disable this setting, such an anonymous request will be denied. It is recommended that the user enable this setting for all domain-level accounts via the Default Domain Group Policy MMC snap-in. Local account settings can be different and may be set by changing this security option within a group policy linked to the specific organizational unit within which the machine account resides.  Network access: Do Not Allow Anonymous Enumeration of SAM Accounts. This Windows XP and Windows Server 2003 security option prevents anonymous access to a listing of Security Accounts Manager (SAM) accounts. N ote This option is useful in obscuring information about the domain, especially if your organization uses naming conventions for user accounts. If the attacker knows that your organization uses naming conventions, he or she can deduce the rules used in these conventions, and thus easily guess the correct account name for some employees. On the other hand, it has implications for trusts, because some functions require the ability to anonymously list accounts. For example, the administrator of a trusting domain must be an authenticated user of a trusted domain in order to perform administrative tasks such as accessing the list of accounts of the trusted domain when assigning access to resources to trusted domain users. Actually, when performing such tasks, Windows Server 2003 prompts for and account and password for the trusted domain. . performance and reduce potential security risks. To remove the OS /2 and POSIX subsystems, delete the \%SystemRoot%system 32 os2 directory and all of its. Enumeration of SAM Accounts. This Windows XP and Windows Server 20 03 security option prevents anonymous access to a listing of Security Accounts Manager (SAM)