Additional Registry Entries
Applies To: Windows Server 2003, Windows Vista
This section provides information about registry entries (also called registry values) that can be used in addition to the Group Policy settings you define for Windows Server® 2003 and Windows Vista.
The following settings include registry entries that do not display by default through the Group Policy Object Editor. These settings, which are all prefixed with "MSS:," were developed by the Microsoft Solutions for Security group for previous security guidance. The GPOAccelerator.wsf script provided with the Windows Vista Security Guide (https://go.microsoft.com/fwlink/?LinkId=74027) modifies Group Policy Object Editor so that the Group Policy Object Editor properly displays the MSS settings.
TCP/IP-Related Registry Entries
To help prevent denial of service (DoS) attacks, keep your computer updated with the latest security fixes and harden the TCP/IP protocol stack on your Windows Server 2003-based and Windows Vista-based computers that are exposed to potential attackers. The default TCP/IP stack configuration is tuned to handle standard intranet traffic. If you connect a computer directly to the Internet, we recommend that you harden the TCP/IP stack to protect against DoS attacks.
DoS attacks that are directed at the TCP/IP stack tend to be of two classes: attacks that use an excessive number of system resources (one way to do this is to open numerous TCP connections) or attacks that send specially crafted packets that cause the network stack or the entire operating system to fail. The following registry settings help to protect against the attacks that are directed at the TCP/IP stack.
The registry settings in the following table can be added to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ subkey.
More detailed information about each of the settings is provided in the subsections that follow the table and in Microsoft Windows Server 2003 TCP/IP Implementation Details (https://go.microsoft.com/fwlink/?LinkID=59670).
Note
Windows Vista is the first operating system to implement next-generation TCP/IP support, which improves the reliability and connectivity of both IPv4 and IPv6 networks.
| Registry entry | Format | Windows Vista default setting | Windows Server 2003 default setting | Recommended setting |
|---|---|---|---|---|
DisableIPSourceRouting |
DWORD |
Not available |
1 |
2 |
EnableDeadGWDetect |
DWORD |
Not available |
1 |
0 |
EnabledICMPRedirect |
DWORD |
Not available |
1 |
0 |
KeepAliveTime |
DWORD |
Not available |
1 |
2 |
PerformRouterDiscover |
DWORD |
Not available |
2 |
0 |
SynAttackProtect |
DWORD |
Not available |
1 |
1 |
TCPMaxConnectReponseRetransmissions |
DWORD |
Not available |
2 |
1 |
TCPMaxDatRetransmissions |
DWORD |
Not available |
5 |
3 |
DisableIPSourceRouting
This entry appears as MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) in the Group Policy Object Editor. IP source routing is a mechanism that allows the sender to determine the IP route that a datagram should follow through the network.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
No additional protection, source routed packets are allowed |
1 |
Medium, source routed packets ignored when IP forwarding is enabled |
2 |
Highest protection, source routing is completely disabled |
<Null> |
Not Defined |
The default configuration in Windows Server 2003 is 1.
Vulnerability
Source routing allows a computer that sends a packet to specify the route that the packet takes. Attackers can use source routed packets to obscure their identity and location.
Countermeasure
Configure the DisableIPSourceRouting entry to a value of 2.
Potential impact
If you configure this value to 2, all incoming source routed packets will be dropped.
EnableDeadGWDetect
This entry appears as MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways (could lead to DoS) in Group Policy Object Editor. When this setting is enabled, the IP may change to a backup gateway if a number of connections experience difficulty.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled) on Windows Server 2003.
Vulnerability
An attacker could force the server to switch gateways, potentially to an unintended one. This would be very difficult to do, so the amount of additional security imparted by implementing this setting is minimal.
Countermeasure
Configure the EnableDeadGWDetect entry to 0 - Disabled.
Potential impact
If you configure this value to 0, Windows cannot detect dead gateways and automatically switches to alternate gateways.
EnableICMPRedirect
This entry appears as MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes in the Group Policy Object Editor. Internet Control Message Protocol (ICMP) redirects cause the stack to plumb host routes. These routes override the Open Shortest Path First (OSPF)-generated routes.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
This behavior is expected. The problem is that the 10 minute timeout period for the ICMP redirect-plumbed routes temporarily creates a network situation in which traffic is not routed properly for the affected host.
Countermeasure
Configure the EnableICMPRedirect entry to 0 (disabled).
Potential impact
When Routing and Remote Access Service (RRAS) is configured as an autonomous system boundary router (ASBR), it does not correctly import connected interface subnet routes. Instead, this router injects host routes into the OSPF routes. However, the OSPF router cannot be used as an ASBR router, and when connected interface subnet routes are imported into OSPF, the result is confusing routing tables with strange routing paths that can result in higher network latency and inability to connect to network resources.
KeepAliveTime
This entry appears as MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds (300,000 is recommended) in the Group Policy Object Editor and is stored in the HKLM\System\CurrentControlSet\Services|Tcpip\Parameters\KeepAliveTime registry key. This setting controls how often TCP sends a keep-alive packet to verify that an idle connection is still intact. If the remote computer is still reachable, it acknowledges the keep-alive packet.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
150000 |
150000 or 2.5 minutes |
300000 |
300000 or 5 minutes (recommended) |
600000 |
600000 or 10 minutes |
1200000 |
1200000 or 20 minutes |
2400000 |
2400000 or 40 minutes |
3600000 |
3600000 or 1 hour |
7200000 |
7200000 or 2 hours (default value) |
<Null> |
Not Defined |
You can specify settings with values 1 through 0xFFFFFFFF in the registry. The values identified in the Group Policy Object Editor UI and in the preceding table are provided as an aid in choosing the most useful keep-alive time periods. The default configuration is 7,200,000 (two hours).
Vulnerability
An attacker who is able to connect to network applications could establish numerous connections to cause a DoS condition.
Countermeasure
Configure the KeepAliveTime entry to a value of 300000 or 5 minutes.
Potential impact
Keep-alive packets are not sent by default by Windows. However, some applications may configure the TCP stack flag that requests keep-alive packets. For such configurations, lowering this value from the default setting of two hours to five minutes helps disconnect inactive sessions more quickly.
PerformRouterDiscovery
This entry appears as MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS) in the Group Policy Object Editor. It enables or disables the Internet Router Discovery Protocol (IRDP). IRDP allows the computer to detect and configure default gateway addresses automatically (as described in RFC 1256) on a per-interface basis.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
0 (Disabled) |
1 |
1 (Enabled) |
2 |
2 (enable only if DHCP sends the Perform Router Discovery option) |
<Null> |
Not Defined |
The default configuration is 2.
Vulnerability
An attacker who has gained control of a computer on the same network segment as a router could configure a computer on the network to impersonate the router. Other computers with IRDP enabled would then attempt to route their traffic through the already compromised computer.
Countermeasure
Configure the PerformRouterDiscovery entry to a value of 0 - Disabled.
Potential impact
If you disable this entry, Windows Server 2003 (which supports the IRDP) cannot automatically detect and configure default gateway addresses on the computer.
SynAttackProtect
This entry appears as MSS: (SynAttackProtect) Syn attack protection level (protects against DoS) in the Group Policy Object Editor. This entry causes TCP to adjust retransmission of SYN-ACKs. When you configure this entry, the overhead of incomplete transmissions in a connect request (SYN) attack is reduced.
You can use this entry to configure Windows to send router discovery messages as broadcasts instead of multicasts, as described in RFC 1256. By default, if router discovery is enabled, router discovery solicitations are sent to the all-routers multicast group (224.0.0.2).
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
No additional protection, use default settings |
1 |
Connections time out more quickly if a SYN attack is detected |
<Null> |
Not Defined |
The default configuration is 1 for Windows Server 2003 with Service Pack 1 (SP1).
Vulnerability
In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server. The server leaves the half-open connections open until it is overwhelmed and is no longer able to respond to legitimate requests
Countermeasure
Configure SynAttackProtect entry to a value 1.
Potential impact
Configuring this setting to 1 adds more delays to connection indications, and TCP connection requests quickly time out when a SYN attack is in progress. If you configure this registry entry, the scalable windows and TCP parameters that are configured on each adapter (including Initial Round Trip Time (RTT) and window size), socket options no longer work. When the computer is attacked, the scalable windows (RFC 1323) and per-adapter configured TCP parameters (Initial RTT, window size) options on any socket can no longer be enabled. These options cannot be enabled because when protection is functioning, the route cache entry is not queried before the SYN-ACK is sent and the Winsock options are not available at this stage of the connection.
TcpMaxConnectResponseRetransmissions
This entry appears as MSS: (TcpMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged in the Group Policy Object Editor. This entry determines the number of times that TCP retransmits a SYN before it aborts the attempt. The retransmission timeout is doubled with each successive retransmission in a given connect attempt. The initial timeout value is three seconds.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
No retransmission, half-open connections dropped after 3 seconds |
1 |
3 seconds, half-open connections dropped after 9 seconds |
2 |
3 & 6 seconds, half-open connections dropped after 21 seconds |
3 |
3, 6, & 9 seconds, half-open connections dropped after 45 seconds |
<Null> |
Not Defined |
The default configuration is 1.
Vulnerability
In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server. The server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests.
Countermeasure
Configure the TcpMaxConnectResponseRetransmissions entry to 1.
Potential impact
If you configure this value to greater than or equal to 2, the stack will employ SYN-ATTACK protection internally. If you configure this entry to less than 2, the stack cannot read the registry values at all for SYN-ATTACK protection. This entry shortens the default amount of time that is needed to close a half-open TCP connection. If you are administering a site that is routinely under heavy attack, you might benefit from setting the value to 1 or 0. However, if this parameter is set to 0, SYN-ACKs will not be retransmitted at all and will time out in three seconds. When using such a limited response time, there is a chance that legitimate connection attempts from distant clients may fail.
TcpMaxDataRetransmissions
This entry appears as MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) in the Group Policy Object Editor. This entry controls the number of times that TCP retransmits an individual data segment (non-connect segment) before it aborts the connection. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume. The base timeout value is dynamically determined by the measured round-trip time on the connection.
Possible values:
- 0 to 0xFFFFFFFF
The default configuration is 5.
In the Group Policy Object Editor UI, this setting can be adjusted using a text entry box:
A user-defined number
Not Defined
Vulnerability
A malicious user could exhaust a target computer's resources if it never sent any acknowledgment messages for data that was transmitted by the target computer.
Countermeasure
Configure the TcpMaxDataRetransmissions entry to a value of 3.
Potential impact
TCP starts a retransmission timer when each outbound segment is passed to the IP. If no acknowledgment is received for the data in a given segment before the timer expires, the segment is retransmitted up to three times.
Miscellaneous Registry Entries
The registry entries in the following table are also recommended. Additional information about each entry, including the location of each registry key setting, is provided in the subsections that follow the table.
Non-TCP/IP-related entries added to the registry in Windows Server 2003
| Registry entry | Format | Most secure value (decimal) |
|---|---|---|
AutoAdminLogon |
DWORD |
Not defined, except for highly secure environments, which should use 0. |
AutoReboot |
DWORD |
Not defined, except for highly secure environments, which should use 0. |
AutoShareWks |
DWORD |
Not defined, except for highly secure environments, which should use 1. |
DisableSavePassword |
DWORD |
1 |
Hidden |
DWORD |
Not defined, except for highly secure environments, which should use 1. |
NoDefaultExempt |
DWORD |
1 for computers that run Windows Vista, 3 for computers that run Windows Server 2003. |
NoDriveTypeAutoRun |
DWORD |
0xFF |
NoNameReleaseOnDemand |
DWORD |
1 |
NtfsDisable8dot3NameCreation |
DWORD |
1 |
ScreenSaverGracePeriod |
DWORD |
0 |
WarningLevel |
DWORD |
0 |
RestrictRemoteClients |
DWORD |
1 |
EnableAuthEpResolution |
DWORD |
1 |
RunInvalidSignatures |
DWORD |
0 |
StorageDevicePolicies\WriteProtect |
DWORD |
1 |
UseBasicAuth |
DWORD |
0 |
DisableBasicOverClearChannel |
DWORD |
1 |
AutoAdminLogon
This entry appears as MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) in the Group Policy Object Editor. This entry determines whether the automatic logon feature is enabled. (This entry is separate from the Welcome screen feature; if you disable that feature, this entry is not affected.) By default, this entry is not enabled. Automatic logon uses the domain, user name, and password that is stored in the registry to log users on to the computer when the computer starts. The logon dialog box is not displayed.
You can add this registry value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
If you configure a computer for automatic logon, anyone who can physically gain access to the computer can also gain access to everything that is on the computer, including any network or networks that the computer is connected to. Also, if you enable automatic logon, the password is stored in the registry in plaintext. The specific registry key that stores this setting is remotely readable by the Authenticated Users group. As a result, this entry is appropriate only if the computer is physically secured and if you ensure that untrusted users cannot remotely view the registry.
Countermeasure
Do not configure the AutoAdminLogon entry except on highly secure computers, where it should be configured to a value of Disabled.
Potential impact
None. By default this entry is not enabled.
AutoReboot
This entry appears as MSS: (AutoReboot) Allow Windows to automatically restart after a system crash (recommended except for highly secure environments) in the Group Policy Object Editor. It determines whether the computer restarts automatically after it fails.
You can add this registry value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
There is some concern that a computer could get stuck in an endless loop of failures and restarts. However, the alternative to this entry may not be much more appealing—the computer will simply stop running.
Countermeasure
Configure the AutoReboot entry to a value of 0 (disabled).
Potential impact
When this setting is enabled, the computer does not restart automatically after a failure.
AutoShareWks
This entry appears as MSS: (AutoShareWks) Enable Administrative Shares (not recommended except for highly secure environments) in the Group Policy Object Editor. By default, Windows XP Professional and Windows Vista automatically create administrative shared folders such as C$ and IPC$.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
Because these built-in administrative shared folders are well-known and present on most Windows computers, malicious users often target them for brute force attacks such as guessing passwords as well as other types of attacks. In Windows Vista, these shared folders are configured to not be remotely accessible by default.
Countermeasure
Do not configure the AutoShareWks entry except on highly secure computers, where it should be configured to a value of 1 (enabled).
Potential impact
If you delete these shared folders, you could cause problems for administrators and programs or services that rely on these shares.
Note
To enable administrative shares to be access remotely on Windows Vista, you must modify the registry setting HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System by adding the LocalAccountTokenFilterPolicy value as a DWORD with the setting of 1. We do not recommend this because it decreases the security of your system. However, if you have an operational requirement to access these shared folders remotely, make sure to monitor their use and implement additional security measures on the computers with this setting.
DisableSavePassword
This entry appears as MSS: (DisableSavePassword) Prevent the dial-up password from being saved (recommended) in the Group Policy Object Editor. It determines whether the passwords that are associated with Network Connections phone book entries are saved. If the user has many phone book entries, accumulated saved passwords can cause a slight delay after the user's credentials are entered in the Connecting To dialog box.
You can add this registry value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
An attacker who steals a mobile user's computer could automatically connect to the organization's network if the Save This Password check box is selected for the dial-up networking entry used to connect to your organization's network.
Countermeasure
Configure the DisableSavePassword entry to a value of 0 (disabled).
Potential impact
Users will not be able to automatically store their logon credentials for dial-up and VPN connections.
Hidden
This entry appears as MSS: (Hidden) Hide Computer From the Browse List (not recommended except for highly secure environments) in the Group Policy Object Editor. You can configure a computer so that it does not send announcements to browsers on the domain. If you do, you hide the computer from the Network Browser list; it does not announce itself to other computers on the same network.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
An attacker who knows the name of a computer can more easily gather additional information about the computer. If you enable this entry, you remove one method that an attacker might use to gather information about computers on the network. Also, if you enable this entry you can help reduce network traffic. However, the vulnerability is small because attackers can use alternative methods to identify and locate potential targets.
Countermeasure
Do not configure the Hidden entry except on highly secure computers, where it should be configured to a value of 1 (enabled).
Potential impact
The computer will no longer appear on the Browser list or in Network list on other computers on the same network.
NoDefaultExempt
This entry appears as MSS: (NoDefaultExempt) Enable NoDefaultExempt for IPSec Filtering (recommended) in the Group Policy Object Editor. The default IPsec exemptions that were present in Windows XP and Windows 2000 except for the Internet Key Exchange (IKE) exemption were removed from Windows Server 2003. The IKE exemption is specific to source and destination port UDP 500. IKE always receives this type of packet from any source address because of the default IKE exemption. It may be possible for an attacker to use the IKE ports to attack IKE itself, and perhaps cause problems. However, the IKE ports cannot be used to attack other open UDP or TCP ports. IKE will perform an IPsec policy lookup to determine whether it should reply to an incoming packet. Because IKE is used to negotiate security settings between two IPSec hosts, and IPsec filters are used only for permit and block control of traffic, IKE will fail to find a matching security policy, and will not reply to incoming requests.
If you have Windows XP clients or other older operating systems on your network, you can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
0 |
1 |
1 |
2 |
2 |
3 |
3 |
A value of 0 specifies that multicast, broadcast, RSVP, Kerberos, and IKE (ISAKMP) traffic are exempt from IPsec filters, which is the default configuration for Windows 2000 and Windows XP. Use this setting only if you require compatibility with an IPsec policy that already exists or Windows 2000 and Windows XP.
A value of 1 specifies that Kerberos protocol and RSVP traffic are not exempt from IPsec filters, but multicast, broadcast, and IKE traffic are exempt. This setting is the recommended value for Windows 2000 and Windows XP.
A value of 2 specifies that multicast and broadcast traffic are not exempt from IPsec filters, but RSVP, Kerberos, and IKE traffic are exempt. This setting is supported only in Windows Server 2003.
A value of 3 specifies that only IKE traffic is exempt from IPsec filters. This setting is supported only in Windows Server 2003, which contains this default behavior although the registry key does not exist by default.
Vulnerability
As IPsec is increasingly used for basic host-firewall packet filtering, particularly in Internet-exposed scenarios, the effect of these default exemptions has not been fully understood. Some IPsec administrators may create IPsec policies that they think are secure, but are not actually secure against inbound attacks that use the default exemptions. Attackers could forge network traffic that appears to consist of legitimate IKE, RSVP, or Kerberos protocol packets but direct them to other network services on the host.
Countermeasure
Do not configure the NoDefaultExempt entry except on computers that use IPsec filters, where this entry should be configured to a value of 3.
Potential impact
This is the default behavior for Windows Server 2003. If you are supporting Windows XP and Windows 2000 in your environment as well as enabling this entry, security policies that already exist may have to be changed to work correctly, for example if you are supporting IPsec deployments that use IKE to negotiate security and IPsec protection for upper-layer protocol traffic.
NoDriveTypeAutoRun
This entry appears as MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) in the Group Policy Object Editor. Autorun starts to read from a drive on your computer as soon as media is inserted in it. As a result, the setup file of programs and the sound on audio media starts immediately.
To disable Autorun in all drives, you can add this registry value in the **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\**subkey.
Alternatively, to disable Autorun for CD/DVD drives only, you can add this registry value to the **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cdrom\**subkey.
Possible values:
- A range of hexadecimal values
For more information, see article 330135, The AutoRun feature or the AutoPlay feature does not work when you insert a CD-ROM in the drive, in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=116876).
In the Group Policy Object Editor UI, the following options are available:
Null, allow Autorun
255, disable Autorun for all drives
Not Defined
Vulnerability
An attacker with physical access to the computer could insert an Autorun-enabled DVD or CD into the computer that will automatically run a malicious program.
Countermeasure
Configure the NoDriveTypeAutoRun entry to a value of 255, disable Autorun for all drives.
Potential impact
Autorun will no longer work when Autorun-enabled discs are inserted into the computer. Also, CD-burning tools might not work as expected because blank CDs might not be recognized. Media applications such as Windows Media Player® will not recognize new CDs or DVDs that are inserted, which will force users to manually start them.
NoNameReleaseOnDemand
This entry appears as MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers (Only recommended for servers) in the Group Policy Object Editor. NetBIOS over TCP/IP (NetBT) is a networking protocol that, among other things, provides a way to easily resolve NetBIOS names that are registered on Windows–based computers to the IP addresses that are configured on those computers. This value determines whether the computer releases its NetBIOS name when it receives a name-release request.
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 1 (enabled).
Vulnerability
The NetBIOS over TCP/IP (NetBT) protocol is designed not to use authentication and is therefore vulnerable to spoofing. Spoofing makes a transmission appear to come from a user other than the user who performed the action. A malicious user could exploit the unauthenticated nature of the protocol to send a name-conflict datagram to a target computer, which would cause the computer to relinquish its name and not respond to queries.
The result of such an attack could be to cause intermittent connectivity issues on the target computer, or even to prevent the use of Network Neighborhood, domain logons, the NET SEND command, or additional NetBIOS name resolution.
Countermeasure
Configure the NoNameReleaseOnDemand entry to a value of 1 (enabled).
Alternatively, you could disable the use of WINS in your environment, and further ensure that all applications rely upon DNS for name resolution services. Although this approach is a recommended long-term strategy, it is generally impractical for most organizations to attempt as a short-term solution. Organizations that still run WINS generally have application dependencies that cannot be quickly resolved without upgrades and software rollouts, which require careful plans and significant time commitments.
If you cannot deploy this countermeasure and you want to guarantee NetBIOS name resolution, you can take the additional step of "pre-loading" NetBIOS names in the LMHOSTS file on certain computers. Maintenance of LMHOSTS files in most environments requires a significant amount of effort. You are encouraged to use of WINS instead of LMHOSTS.
Potential impact
An attacker could send a request over the network and query a computer to release its NetBIOS name. As with any change that could affect applications, we recommend that you test this change in a non-production environment before you change the production environment.
NtfsDisable8dot3NameCreation
This entry appears as MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) in the Group Policy Object Editor. Windows Server 2003 supports 8.3 file name formats for backward compatibility with 16-bit applications. (The 8.3 file name convention is a naming format that allows file names that are up to eight characters in length.)
You can add this registry value to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\ subkey.
Possible values:
| Registry value | Corresponding Group Policy Object Editor option |
|---|---|
0 |
Disabled |
1 |
Enabled |
<Null> |
Not Defined |
The default configuration is 0 (disabled).
Vulnerability
If you allow 8.3 style file names, an attacker only needs eight characters to refer to a file that may be 20 characters long. For example, a file named Thisisalongfilename.doc could be referenced by its 8.3 filename, Thisis~1.doc. If you do not use 16-bit applications, you can turn this feature off. Also, directory enumeration performance is improved if you disable short name generation on an NTFS file system partition.
Attackers could use short file names to access data files and applications with long file names that would normally be difficult to locate. An attacker who has gained access to the file system could access data or run applications.
Countermeasure
Configure the NtfsDisable8dot3NameCreation entry to a value of 1 (enabled).
Potential impact
The 16-bit applications in your organization will not be able to access files that are not named with the 8.3 format. Some 32-bit applications also rely on the presence of short names, because short names tend not to contain embedded spaces and therefore do not require quotation marks when used in command lines. The installation routines for some programs may fail.
If you apply this entry to a server that already has files with auto-generated 8.3 file names, it does not remove them. To remove existing 8.3 file names, you will need to copy those files off the server, delete the files from the original location, and then copy the files back to their original locations.
ScreenSaverGracePeriod
This entry appears as MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) in the Group Policy Object Editor. Windows includes a grace period between the time when the screen saver is started and the time when the console is actually locked automatically if screen saver locking is enabled.
You can add this registry value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ subkey.
Possible values:
- 0 to 255
The default value is 5 seconds.
In the Group Policy Object Editor UI, the value for this entry appears as a text entry box:
A user-defined number
Not Defined
Vulnerability
The default grace period that is allowed for user movement before the screen saver lock takes effect is five seconds. If you leave the default grace period configuration, your computer is vulnerable to a potential attack from someone who could approach the console and attempt to log on to the computer before the lock takes effect. An entry to the registry can be made to adjust the length of the grace period.
Countermeasure
Configure the ScreenSaverGracePeriod entry to a value of 0.
Potential impact
Users will have to enter their passwords to resume their console sessions as soon as the screen saver activates.
WarningLevel
This entry appears as MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning in the Group Policy Object Editor. Windows Server 2003 generates a security audit in the Security log when it reaches a user-defined threshold. For example, if this value is set to 90, an event ID 523 will be entered in the log when the Security log reaches 90 percent of capacity. In this example the log entry would contain the following text:
"The security event log is 90 percent full."
This setting will have no effect if the Security log is configured to overwrite events as needed.
You can add this registry value to the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Eventlog\Security\ subkey.
Possible values:
- 0 to 100
The default configuration is 0 (no warning event is generated).
In the Group Policy Object Editor UI, the following options are available:
50%
60%
70%
80%
90%
Not Defined
Vulnerability
If the Security log reaches 90 percent of its capacity and the computer has not been configured to overwrite events as needed, more recent events will not be written to the log. If the log reaches its capacity and the computer has been configured to shut down when it can no longer record events to the Security log, the computer will be shut down and will no longer be available to provide network services.
Countermeasure
Configure the WarningLevel to a value of 90.
Potential impact
This setting will generate an audit event when the Security log reaches the 90 percent-full threshold unless the log is configured to overwrite events as needed.
RestrictRemoteClients
When an interface is registered through the RpcServerRegisterIf function, RPC allows the server application to restrict access to the interface, typically through a security callback. The RestrictRemoteClients registry key forces RPC to perform additional security checks for all interfaces, even if the interface has no registered security callback. RPC clients that use the named pipe protocol sequence (ncacn_np) are exempt from these restrictions. The named pipe protocol sequence cannot be restricted because of several significant backward-compatibility issues.
This key is located at HKLM\Software\Policies\Microsoft\Windows NT\Rpc\RestrictRemoteClients.
Possible values:
The RestrictRemoteClients registry key can have one of three DWORD values:
0. This value is the default value in Windows Server 2003 with SP1, and it causes the computer to bypass the RPC interface restriction. It is entirely the responsibility of the server application to impose appropriate RPC restrictions. This configuration is equivalent to the configuration of previous versions of Windows.
1. This value is the default value in Windows Vista. All remote anonymous calls are rejected by the RPC runtime except calls that come in through named pipes (ncacn_np).
2. All remote anonymous calls are rejected by the RPC runtime with no exemptions. In this configuration, a computer cannot receive remote anonymous calls using RPC.
Developers can modify their applications to pass flags to the RPC subsystem that indicate whether the client or server will accept anonymous RPC requests.
Vulnerability
RPC interfaces that allow unauthenticated connections can potentially be used by attackers to remotely exploit buffer overruns and spread malicious code.
Countermeasure
The default value of 0 for the the RestrictRemoteClients entry in Windows Server 2003 with SP1 allows backward compatibility. To add protection against worms that may attempt to remotely exploit buffer overflows in RPC services, configure RestrictRemoteClients to 1 or 2.
Potential impact
If you enable the RestrictRemoteClients registry key, the RPC Endpoint Mapper interface will not be accessible anonymously. This restriction is a significant security improvement, but it changes how endpoints are resolved. Currently, an RPC client that attempts to make a call by using a dynamic endpoint will first query the RPC Endpoint Mapper on the server to determine what endpoint it should connect to. This query is performed anonymously, even if the RPC client call uses RPC security. Anonymous calls to the RPC Endpoint Mapper interface will fail on Windows Server 2003 with SP1 if the RestrictRemoteClients key is set to 1 or higher. Therefore, the RPC client runtime must be modified to perform an authenticated query to the Endpoint Mapper. If the EnableAuthEpResolution key is set, the RPC client runtime will use NTLM to authenticate to the Endpoint Mapper. This authenticated query will take place only if the actual RPC client call uses RPC authentication.
Important
Enabling this setting will cause a substantial increase in NTLM authentication requests for applications that use the Endpoint Mapper. If you support applications that make heavy use of the RPC Endpoint Mapper (for example, Exchange MAPI clients) enabling EnableAuthEpResolution will also cause a significant increase in NTLM Authentication load. In this case, you may want to increase the Netlogon registry entry MaxConcurrentAPI to 10. The registry entry needs to be set on all domain member servers and domain controllers along the trust path to the user domain. You can monitor NTLM authentication performance using the performance monitor “Netlogon” object. For more information on making this object available on Windows Server 2003 SP1, see article 928576.
Some applications and services may not work properly when this key is enabled. Therefore you should test it thoroughly before you deploy it in your environment. If you plan to enable this key, you should also use the EnableAuthEpResolution key to enable authentication for the RPC Endpoint Mapper.
EnableAuthEpResolution
Anonymous calls to the RPC Endpoint Mapper interface will fail by default because of the default value for RestrictRemoteClients key. Therefore, the RPC client runtime must be modified to perform an authenticated query to the Endpoint Mapper. To do so, configure the EnableAuthEpResolution key to 1. When this configuration is in place, the RPC client runtime will use NTLM to authenticate to the Endpoint Mapper interface. This authenticated query will only take place if the actual RPC client call uses RPC authentication.
This registry key is located at HKLM\Software\Policies\Microsoft\Windows NT\Rpc\EnableAuthEpResolution.
Vulnerability
RPC interfaces that allow unauthenticated connections can potentially be used by attackers to remotely exploit buffer overruns and spread malicious software.
Countermeasure
To add protection against worms that may attempt to remotely exploit buffer overflows in RPC services, configure RestrictRemoteClients and then use EnableAuthEpResolution to enable NTLM authentication for computer RPC requests.
Potential impact
Clients that do not have the EnableAuthEpResolution key set will not be able to make RPC service requests of servers that have RestrictRemoteClients enabled. This restriction may cause RPC-based services to stop working.
Important
Enabling this setting will cause a substantial increase in NTLM authentication requests for applications that use the Endpoint Mapper. If you support applications that make heavy use of the RPC Endpoint Mapper (for example, Exchange MAPI clients) enabling EnableAuthEpResolution will also cause a significant increase in NTLM Authentication load. In this case, you may want to increase the Netlogon registry entry MaxConcurrentAPI to 10. The registry entry needs to be set on all domain member servers and domain controllers along the trust path to the user domain. You can monitor NTLM authentication performance using the performance monitor “Netlogon” object. For more information on making this object available on Windows Server 2003 SP1, see article 928576.
RunInvalidSignatures
By default, Windows Server 2003 with SP1 and Windows Vista prevent the installation of signed code objects that have invalid signatures. These signatures may be invalid because the code has been modified, because the signing certificate has expired, or because the signing certificate appears on a certificate revocation list (CRL). Internet Explorer® 6.0 already blocked the installation of signed code with invalid signatures, but Windows Server 2003 SP1 extends this behavior to all applications.
Vulnerability
A signed Microsoft ActiveX® control that has been tampered with may be downloaded and run by an application, which could compromise the computer on which it runs.
Countermeasure
The default value of RunInvalidSignatures blocks this vulnerability.
Potential impact
Applications that depend on legitimate signed controls will not function if those controls' signatures are invalid for any reason. If you have an application whose signature appears to be invalid, you can change this key configuration to allow the control to download and run. However, doing so creates a security vulnerability. The preferred solution is to contact the developers of the control that is used in the application to obtain a version with a valid signature.
StorageDevicePolicies\WriteProtect
By default, users can mount USB block storage devices on their Windows XP computers and read from, or write to, these devices without limitation. In Windows XP with SP2, Microsoft added the ability for administrators to restrict the ability of users to write to USB block storage devices.
To restrict users' ability to write to these devices, you can add the StorageDevicePolicies key and then add the WriteProtect DWORD value to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ registry key and configure it to 1. When this value is configured, the Windows driver for USB block storage devices will reject write requests to mounted USB block storage devices.
Vulnerability
An attacker could copy data to a removable USB device and steal it.
Countermeasure
Configure the WriteProtect value to 1, to prevent the computer from writing data to USB block storage devices.
Potential impact
This registry key provides partial mitigation of a serious threat. However, there are many other ways that a skilled attacker can steal data with a USB device. For example, a USB device can be programmed to enumerate as a non-block storage device (like a printer or CD-ROM device), which will bypass this control. Organizations that want to prevent the theft of sensitive data by users or attackers can use this entry as part of a broader security strategy, in conjunction with physical access controls and other measures to restrict access to writable USB devices.
UseBasicAuth
Distributed Authoring and Versioning (DAV) is an HTTP–based protocol that allows remote access to file systems and file servers. Users can use UNC paths to access resources on DAV servers. However, the WebDAV redirector in Windows Server 2003 communicates with Web servers that support DAV through HTTP; it cannot use SSL-protected HTTP sessions. When these Web sites allow the use of basic authentication, DAV requests will transmit the user's authentication credentials in plaintext.
Starting with Windows Server 2003 with SP1, the WebDAV redirector has been modified so that it never sends user credentials with basic authentication. This modification may affect applications or business processes that depend on the computer's default DAV redirector. (Note that Microsoft Office uses its own independent DAV client and is not affected by this entry.)
This setting can be specified in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\UseBasicAuth subkey. If you configure its value to 1, the computer WebDAV redirector can communicate with Web servers that only support basic authentication.
Vulnerability
An attacker could set up a Web server that uses basic authentication, and then trick or spoof users and make them attempt to connect to it to capture their credentials.
Countermeasure
Keep the default setting. By default, the Windows Server 2003 WebDAV redirector will not use basic authentication, which effectively blocks this vulnerability.
Potential impact
Applications that use the built-in WebDAV redirector to access Web resources will fail if the Web server supports only basic authentication. To resolve this problem, you can either configure the Web server to support more secure authentication methods or enable the UseBasicAuth value. However, the preferred mechanism is to reconfigure the Web server, which does not allow exposure of users' credentials.
DisableBasicOverClearChannel
The WebDAV redirector is part of the remote file system stack. When users attempt to open URLs on remote computers, their credentials may be exposed if the remote server supports only basic authentication. An attacker may be able to spoof a user and direct them to a Web site that requests credentials (through DAV) and uses basic authentication. If users respond, they expose their credentials to the malicious host.
The UseBasicAuth registry entry controls whether basic authentication can be used for WebDAV requests. If you configure the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\ DisableBasicOverClearChannel value to 1, the use of basic authentication with other Web resources is blocked.
Vulnerability
An attacker could set up a Web server that uses basic authentication, and then trick or spoof users and make them attempt to connect to it to capture their credentials.
Countermeasure
Configure the DisableBasicOverClearChannel value to 1 on client computers to restrict their ability to connect to HTTP servers by using basic authentication.
Potential impact
Many embedded devices (such as routers, print servers, and copiers) that offer HTTP access support only basic authentication, as do some business applications. When DisableBasicOverClearChannel is configured to 1, client computers will not be able to authenticate to these devices or applications.
Enable Additional Software Restriction Policies Levels
Additional software restriction policy levels can be enabled for greater flexibility in software restriction policy creation. There is an additional registry setting that can be used to make specific applications (or even all applications except for excluded ones) run under basic user privileges, even if the user has administrative privileges by extending the software restriction policies behavior on the computer. Configure the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\Levels registry key by adding a DWORD with the value of 0x0031000 to enable additional software restriction policy levels.
Vulnerability
Basic users may need to run applications that require membership in the local Administrators group, which represents an inherent escalation of privilege risk. Once the user has access to administrative credentials, the system and the data it contains or can access may be inadvertently or consciously compromised.
Countermeasure
Once the levels are enabled, you can create a blanket software restriction policy rule to lower rights for all the applications as a default and creating exceptions only for the applications that need to have administrative right. To do this, you specify a path rule that requires that all programs run from the specified drive (such as C:\) be run with the Basic User security level. With this rule in effect, even if a user is logged on with an account that has Administrator privileges, all processes started by the user will be running with basic user privileges. If you have programs that run from additional drives, create path rules to restrict those drives to basic user as well. Supplement this rule (or rules) by identifying the programs that need to be run with higher privileges and then create hash rules that allow those programs to be run with the Unrestricted security level.
Potential impact
With these rules in effect, all programs run on the computer except for those specified by the hash rules will be run at the basic user level, regardless of the user account credentials. Any programs that require a higher privilege rule must be explicitly added to the software restriction policy for the computer. For this reason, it is recommended that this countermeasure only be used on very tightly controlled, specialized workstations.
This countermeasure does not guarantee that there will not be opportunities for escalation of privileges through other means, but it does provide one means of limiting exposure. When making program exceptions, you should carefully consider any processes that can be created by the program that you are allowing to run at a higher privilege level when assessing the risk. For example, a program such as the Microsoft Management Console (mmc.exe) requires higher privilege access but is not a good candidate for adding to the exception list because it encompasses so many other processes and tasks.