Top 10 (or so) Server Security Tweaks

IPsec filters

Our favorite "tweak" is not actually a tweak at all. It is a technology that you can use to prevent systems from talking to each other. IPsec is a layer 3 and 4 host-based security mechanism that enables you to configure authentication and/or encryption settings on a per-port basis. It is one of the most powerful and important security tools ever devised. It is what we use to ensure that hosts cannot send or receive traffic that is not essential for their functioning. Chapter 10, "Preventing Rogue Access Inside the Network," describes in detail how to configure IPsec. Therefore, we do not elaborate on it any further here.

Caution

IPsec, incorrectly configured, can be hazardous to your network health; and your career.

As mentioned in Chapter 10, IPsec is an absolutely marvelous technology for blocking traffic. In fact, even if you did not intend to block any traffic, that usually is the end result in the first few tries . Do not deploy an IPsec policy on a production network until you have thoroughly tested it and are sure it will work as intended.

Software Restriction Policies

Our second favorite "tweak" is also not a tweak. It is technology used to prevent, or allow, software to execute on the system. Software restriction policies (SRPs) can be used, for example, to prevent any account from executing certain files even when those files cannot be removed. For instance, in Chapter 2, we used the tftp.exe tool to upload the attack tools to a compromised server. You cannot delete tftp.exe unless you disable system file protection. However, you can set up an SRP that prevents attackers from executing tftp.exe. Software restriction policies can identify the file four different ways:

By Internet Explorer security zone
By full or relative path
By a certificate used to sign the files
By a hash

Figure 12-1 shows an SRP that is quite restrictive . It consists of the following rules:

All files underneath the %systemroot% directory can execute (a path rule).
All files underneath the %systemroot%\system32 directory can execute (a path rule).
Certain chosen files underneath the %systemroot% directory are restricted (a path rule).
Certain chosen files underneath the %systemroot% directory are restricted (a hash rule).

Figure 12-1. Software restriction policies on a domain controller.

In addition, the default security level is set to Disallowed, meaning only those files explicitly listed can be executed. With this policy set, the system will boot and you can log on. However, many of the Start menu items are blocked because they are located under \Documents and Settings and that location is blocked. For instance, you cannot launch the command prompt from the Start menu, but you can do it from the Run dialog. Figure 12-1 shows the rules.

SRP applies in order of specificity. Because the %systemroot% rule is more specific than the blanket rule, it takes precedence. Because a hash rule is always more restrictive than a path rule, the hash rules take precedence. Note, however, that a hash rule is specific to a particular version of a file. If the file is updated to a newer version, the hash rule is no longer valid. Hence, we also have a path rule to restrict these files, just in case we forget to update the hash rule.

A full discussion of how to use these options is quite lengthy, and the interested reader is referred to the Security Resource Kit , by Smith and Komar, MS Press, 2002, which has a lengthy discussion on SRP. The Windows XP Security Guide also has a discussion on SRP.

Of course, ideally , you should set up an SRP that allows execution only of those files that are necessary for operating the server, but doing so is quite complicated. Windows binaries are not signed directly, and therefore a certificate rule would not be valid. (Windows binaries do have an associated digital signature, but it is not attached to the file; it is stored in the manifest, called nt5.cat.) Thus the simplest approach is the one we used above where everything is restricted and particular things are allowed using a combination of hash and path rules.

What breaks? The simple answer is potentially everything, but hopefully nothing. SRP, correctly used, will ensure that the system can perform its intended function and absolutely nothing else. SRP, incorrectly used, will turn your system into a boat anchor. SRP is another setting you should never roll out on a production network until you are 100 percent certain that the systems will not break. Virtual machines are absolutely wonderful for developing and troubleshooting software restriction policies because you just reboot and discard the undo file should the system not function properly.

Do Not Store LAN Manager Hash Value

This is actually a tweak. NoLMHash is the name of the Registry value (on Windows XP and Server 2003) or key (Windows 2000) that you set to turn on this tweak. In Group Policy on Windows XP and higher, the setting is called "Network Security: Do not store LAN Manager hash value on next password change."

Using this setting, you can turn off creation of LM hashes across a domain or system. (See Chapter 11, "Passwords and Other Authentication MechanismsThe Last Line of Defense," for a detailed discussion of passwords.) Ideally, this setting will never have any direct impact on security because if it does it means your domain controller has been hacked; but just in case, we recommend disabling storage of LM hashes . In most cases, the primary benefit of this setting is that it breaks compatibility with Windows 9x.

NOTE: If bad guys have access to your password hashes, you have already been hacked. Cracking hashes will not give them any additional access on the domain where they came from. Cracking hashes will only allow them to access other domains where the same users are using the same passwords. In addition, with the proper tools, attackers do not need to crack passwords at all; they can use the hashes directly. Therefore, the actual security benefit of turning off LM hash storage is realistically quite minimal.

Anonymous Restrictions

Windows 2000 (and also XP), as was shown in Chapter 2, volunteers large volumes of information about itself to anonymous users. Turning on anonymous restrictions will block it from doing so. There are a number of settings involved here, such as RestrictAnonymous, EveryoneIncludesAnonymous, and so on. On Windows Server 2003, except for on domain controllers, most of these settings are on by default, eliminating the need to configure them.

The settings include the following:

Network access: Allow anonymous SID/Name translation Windows XP and Server 2003 only. This setting governs whether anonymous users can call the LookupAccountSid API (for more information on this and other APIs discussed here, refer to the MSDN library at http://msdn.microsoft.com) and other functions that resolve a security identifier (SID) to a username. Configuring this setting prevents anonymous users from "SIDwalking," which is the process of resolving each SID separately. The dumpinfo tool used in Chapter 2 implements SIDwalking. Had this setting been made, that tool would not have returned any usernames or the administrator name. This setting will break certain interactions with Windows NT 4.0 and Windows 9x, as well as some poorly written software that requires anonymous enumeration. We recommend that you disable anonymous SID/Name translation.
Network access: Do not allow anonymous enumeration of SAM accounts The Registry key this setting configures is called RestrictAnonymousSAM on Windows XP and higher. On Windows 2000, this setting is equivalent to RestrictAnonymous at level 2. It does very little good actually. It only prevents calling the NetUserEnum API, but as long as LookupAccountSid is still allowed, getting a list of all users is trivial. On the other hand, this setting really does not break very much, so you may as well set it.
Network access: Do not allow anonymous enumeration of SAM accounts and shares This is the RestrictAnonymous setting on Windows XP and Server 2003. On Windows 2000, this is equivalent to setting RestrictAnonymous to 2. This setting breaks not only NetUserEnum but also the NetShareEnum API on all platforms and LookupAccountSid on Windows 2000 only. If this setting is configured, dumpinfo and similar tools would not return any information at all to anonymous users. However, configuring this setting has a significant adverse impact on compatibility with older software, as well as with Windows NT 4.0 and Windows 9x. We recommend that you restrict anonymous enumeration.
Network access: Let Everyone permissions apply to anonymous users This setting, available on Windows XP and Server 2003, controls the membership in the Everyone group. Up through Windows 2000, access tokens generated for the ANONYMOUS user included SID S-1-1-0, the Everyone SID. (See the sidebar on SIDs for more information.) Starting with Windows XP, the inclusion of SID S-1-1-0 in anonymous access tokens is controllable with this setting known technically as the EveryoneIncludesAnonymous after the Registry key that configures it. By default, the setting is turned off. This will break access from systems that cannot authenticate as anything other than ANONYMOUS, notably Windows NT 4.0. Of important note, however, is that resources available to the NETWORK identity (SID S-1-5-2) are still available to ANONYMOUS as the NETWORK SID is added to an ANONYMOUS access token. We recommend that you ensure that the default setting of not including the Everyone SID is still in force.
Network access: Named Pipes that can be accessed anonymously This setting controls which named pipes are available anonymously. Named pipes is a data-sharing mechanism that basically acts as a virtual file. By default on Windows XP and Server 2003, only those named pipes listed in this setting, known as NullSessionPipes, are available anonymously. Many systems do not even need those. Things that will break if you remove them depend on what you are doing with the system. For instance, removing the Browser entry will break anonymous (Windows NT 4.0 and 9x) access to the browse list. Note also that although this setting is available on Windows 2000, it has no effect immediately. The reason is that by default on Windows 2000 all named pipes can receive remote requests . To restrict anonymous access to named pipes on that platform, you need to create the RestrictNullSessAccess value and set it to 1. This value is not exposed in the Group Policy editor UI by default, although the Windows 2000 Security Hardening Guide from Microsoft adds it. To manually add it, create a REG_DWORD value called RestrictNullSessAccess under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters and set it to 1. Although you can configure RestrictNullSessAccess on Windows XP and Server 2003, as well, it is turned on by default even if the setting is missing from the Registry. Thus, you would only need to configure it if you want to enable anonymous access to all null session pipes. In Windows Server 2003 Group Policy, RestrictNullSessAccess is exposed as "Network access: Restrict anonymous access to Named Pipes and Shares." We recommend you leave RestrictNullSessAccess turned on, or configure it if you are running Windows 2000.
Network access: Shares that can be accessed anonymously This setting is analogous to the named pipes setting above, but it governs anonymous access to shares. Unless you are publishing DFS shares or hosting COM objects for down-level systems, you can probably get away with clearing out all values in this setting. The implications of RestrictNullSessAccess on this setting are identical to how it affects null session named pipes access. We recommend that you investigate which values you can remove on each of your systems and present only those named pipes and shares that are necessary for operation.
Network access: Remotely accessible registry paths Remote access to the Windows Registry is governed by the ACL on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\ winreg registry key. However, underneath that key is another key called AllowedPaths. On Windows Server 2003, there is also a key called AllowedExactPaths. In Windows Server 2003, AllowedPaths is exposed as "Network access: Remotely accessible registry paths and sub-paths," and AllowedExactPaths is exposed as "Network access: Remotely accessible registry paths." In Windows 2000 and XP, only AllowedPaths is available and it is exposed as "Network access: Remotely accessible registry paths." These keys govern exceptions to the ACL on the winreg key. Any Registry path listed in these keys is available anonymously over the network. In Windows XP and 2000, this includes the entire Registry tree underneath that key. In Windows Server 2003, AllowedExactPaths specifies that only that key is accessible. Its subkeys are not available. The default settings for these keys are mostly fine unless automatic administrative logon (autoadminlogon) is used on Windows 2000 primarily. Credentials for autoadminlogon (which is a bad idea all by itself) are stored in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion is available remotely to anyone . When you remove paths from AllowedPaths or AllowedExactPaths, you will break things. For instance, if you remove the "printers" entry from a print server, users will no longer be able to print to it. Tread carefully here. The primary reason to worry about this key is to ensure that autoadminlogon credentials are not available remotely; however, the proper way to ensure that is to not allow autoadminlogon. We recommend that autoadmin logon be disabled on all systems.
Hide browsers By default, all Windows systems will announce themselves and all services they provide to others across the network, even if they do not provide any services at all! Not only does this create an awful lot of unnecessary network traffic, it also can be considered an information disclosure threat. However, the primary reason to turn this off is for pure performance reasons. To do so, set the hidden value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\parameters to 1. This setting is not exposed in Group Policy by default. The Windows 2000 Security Hardening Guide will install it in the Group Policy UI, and the Windows XP and Server 2003 security guides contain instructions for how to do the same on those platforms. We recommend that all systems that should not act as general-purpose file or print servers have this value configured.

Security Identifiers (SIDs)

Every user in Windows NT is represented by a unique security identifier (SID). SIDs for users always start with S-1-5-21 in Windows, denoting that they are issued by the NT identifying authority and that they may not be unique within the universe of SIDs. User SIDs are based on machine SIDs. For instance, S-1-5-21-1095672315-1787444531-3518664281 may be the SID of a machine. Users, in turns, will have SIDs based on the machine or domain SID, with a relative identifier (RID) appended. For example, the administrator on the machine will have a SID of S-1-5-21-1095672315-1787444531-3518664281-500.

For a more thorough discussion on SIDs, refer to the MSDN library.

Password Policies

Everyone needs a password policy. In Chapter 11, we discussed what the password policy should look like. The password policy settings in Group Policy help you enforce it, and the options in there are relatively self-explanatory. The exact options to configure vary by environment, but in virtually all enterprise environments you should enforce at least 7-character complex passwords that change no less often than 180 days. In many, if not most, environments, you probably want to go to 8-character complex passwords that change every 90 days. For a more thorough discussion about passwords, see Chapter 11.

You cannot enforce some things using the built-in policies, however. For example, in many environments, we make policies such that administrators cannot use the same password on two different systems. Since you cannot enforce that with built-in technical means, we need a different way to do so. One option that works is to use a logon script. For example, if you are not allowed to use the same password on system A as on system B, you put a logon script on system A that connects, without specifying credentials, to system B, and vice versa. If the connection succeeds, you have a violation of the policy. At this point, you can automatically generate a termination notice or take some other appropriate action.

SMB Message Signing

SMB message signing is actually four different settings:

Microsoft network client: Digitally sign communications (always) Sets the Workstation service to require message signing on outbound requests to SMB servers. We recommend you turn this setting on for all systems making outbound Windows networking requests to other systems, including all systems that are used for browsing the Web.
Microsoft network client: Digitally sign communications (if server agrees) Sets the Workstation service to request message signing on outbound request to SMB servers. This is the only setting of the four that is on by default.
Microsoft network server: Digitally sign communications (always) Sets the Server service to require message signing on inbound requests from SMB clients . We recommend you turn this setting on for all systems if possible.
Microsoft network server: Digitally sign communications (if client agrees) Sets the Server service to request message signing on inbound requests from SMB clients. We recommend that at a bare minimum this setting is configured on all systems acting as servers.

Turning on SMB message signing is a tricky operation. The reason is that if you set it to require signing on the Workstation service, the system will fail to connect to any Windows system in a default configuration because message signing on the Server service is not enabled by default. The reason it is not on by default is that it generates a small overheadup to about 5 percentwhich was believed to be unacceptable on many systems.

We think, however, that this setting is incredibly valuable and should be required on all systems. The reason is that SMB message signing helps thwart entire classes of man-in-the-middle attacks known as the SMB reflection attack (see Chapter 8). These have been used in the wild since at least 2000. It also breaks other types of man-in-the-middle attacks that rely on forwarding SMB messages.

On Windows XP Service Pack 2 and higher, the SMB reflection attack is broken even if SMB message signing is not enabled. However, because there are other man-in-the-middle attacks that are not mitigated this way, it is still important to configure SMB message signing on Windows XP.

LAN Manager Authentication Level

LMCompatibilityLevel, or "Network security: LAN Manager authentication level" as it is called in Group Policy on Windows XP and higher (it is called "LAN Manager authentication level" on Windows 2000), governs the authentication protocols a system is allowed to use and accept. We discussed this setting at length in Chapter 11 and therefore do not repeat this discussion here. We recommend that it be set to at least 4 or "Send NTLMv2 response only\ refuse LM" on all systems. When you do so, you will break access to and from Windows 9x systems as well as some versions of SAMBA.

It is important to recognize that even with LAN Manager authentication level configured to 4, the system will still emit LM and NTLM responses in certain cases; for instance, with programs that use the NTLM Security Support Provider (SSP) directly, such as RPC. To prevent this, you need to configure the "Network security: Minimum session security for NTLM SSP based (including secure RPC) clients/servers" settings. These settings govern the protocols used by the SSP. There are four combinations of settings.

Require message integrity
Require message confidentiality
Require NTLMv2 session security
Require 128-bit encryption

To use NTLMv2, you need to select at least option 3. In addition, if you turn off storage of LM hashes, you must select options 1, 2 and 3 to allow RPC authentication over UDP to function properly. Services that use such authentication include the Windows Clustering Service. If you simply disable LM hash storage, you may break your clusters unless you also configure the NTLM SSP client-side settings. We recommend setting the NTLM SSP client to require message integrity, confidentiality, as well as NTLMv2. Use 128-bit encryption at your discretion, but most applications will use that anyway. Configuring this setting will only break applications that are specifically coded not to allow use of NTLMv2.

TCP Hardening

The TCP stack in Windows 2000 and higher is quite solid actually. However, you should consider making at least one tweak on servers. SynAttackProtect makes the system considerably more resilient to TCP SYN-flood attacksan attack where the attacker simply attempts to make many concurrent connections to a system to exhaust its capability to service legitimate users. SynAttackProtect is a REG_DWORD under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters. Note that it may not be there by default, in which case you have to add it. It can take three values: 0, 1, and 2. 0, the default, is appropriate for clients and servers on slow links. We recommend that servers on the Internet or otherwise subject to SYN-floods have SynAttackProtect set to 2. Systems on slow links cannot have this value set because it would cause legitimate connections to be timed out. The Windows 2000 Hardening Guide will add this value to the Group Policy UI. The Windows Server 2003 guide contains information on how to manually add it.

There are several other TCP hardening settings, but the majority of them have a relatively low or specialized impact. For information about the remaining values, refer to the "Threats and Countermeasures" guide at http://go.microsoft.com/fwlink/?LinkId=15159.

Restricted Groups

Restricted groups is a way to control group membership with Group Policy. A lot of administrators have tried to control groups by making wholesale ACL changes on the system. This typically has the result that the system ends up being less secure than it was before and that they still have not achieved complete control of the group they wanted to restrict.

Restricted groups provides a much better way to control certain groups, such as Power Users, Server Operators, and Backup Operators. For instance, if you do not want anyone who is a member of Server Operators to be able to access any files because of that membership, make Server Operators a restricted group and control who can be a member of it.

Restricted groups also provide a very strong way to control who is an administrator. For instance, at one point we had an administrator who was running a lab for one of the authors. That must have been a terrible job because he was charged with keeping us out of his lab. We, on the other hand, kept trying to hack him. To prevent us from becoming administrators, he made that group a restricted group using domain policy; and we were not in it. That means that we had only 15 minutes from the time we became administrators to turning off the policy. Some of the time, that actually worked. To stop this, he then set the Group Policy refresh interval to one minute, which pretty much stopped us cold. Although we cannot recommend refreshing Group Policy every minute, we do recommend using restricted groups to manage group membership for certain sensitive groups.

Audit Settings

By and large, the default audit settings on Windows Server 2003 are fine. However, on Windows 2000, they could use a little adjusting. Well, actually, they are basically turned off on Windows 2000 by default.

We recommend that you tweak the audit policies as follows :

Account logon events Success and failure
Account management Success and failure
Logon events Success and failure
Object access Success and failure
Policy change Success
Privilege use Success and failure
System events Success

You should also adjust the log sizes; however, do not just increase sizes blindly. There are some practical limits on event log sizes. Event logs are loaded in services.exe, along with several other things. They are also memory-mapped files, and each process can only have 1 GB of those. That means that the log files have to share the 1 GB of available memory in the services.exe process with everything else in there. In addition, event logs cannot be fragmented in memory, so the system has to find sufficient contiguous memory. It is pretty likely that these issues will constrain you to about 300 MB as a practical limit on total event log size (not 300 MB each). Take that into account when setting log sizes. Of course, you must also analyze the logs, but that is a different topic.