Anonymous Restrictions
Windows 2000 (and also XP) 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. 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.
In this tutorial:
- Protecting Hosts
- Security Configuration Myths
- Myth 1: Security Guides Make Your System Secure
- Myth 2: If We Hide It, they Not Find It
- Myth 3: The More Tweaks, the Better
- Myth 4: Tweaks Are Necessary
- Myth 5: All Environments Should At Least Use <Insert Favorite Guide Here>
- Myth 6: "High Security" Is an End Goal for All Environments
- Myth 7: Start Securing Your Environment by Applying a Security Guide
- Myth 8: Security Tweaks Can Fix Physical Security Problems
- Myth 9: Security Tweaks Will Stop Worms/Viruses
- Myth 10: An Expert Recommended This Tweak as Defense in Depth
- Server Security Tweaks
- Software Restriction Policies
- Do Not Store LAN Manager Hash Value
- Anonymous Restrictions
- Security Identifiers (SIDs)
- Password Policies
- SMB Message Signing
- Networking LAN Manager Authentication Level
- TCP Hardening
- Restricted Groups
- Audit Settings
- Client Security Tweaks
- Firewalls
- IPsec Filters
- SafeDllSearchMode
- Local Administrator Account Control
- Limit Local Account Use of Blank Passwords to Console Logon Only
- Logon Events
- Allowed to Format and Eject Removable Media
- The Caution ListChanges You Should Not Make
- Crash on Audit Failure
- Clear Virtual Memory Page File
- Security Configuration Tools