Threats and Countermeasures

This chapter provides additional information about registry entries (also called registry values) for the baseline security template file that are not defined within the Administrative Template (.adm) file. The .adm file defines the policies and restrictions for the desktop, shell, and security for Microsoft® Windows Server™ 2003.

On This Page

	Customized Security Configuration Editor
	TCP/IP-Related Registry Entries
	Miscellaneous Registry Entries
	Registry Entries Available in Windows XP with SP2 and Windows Server 2003 with SP1
	Registry Entries Available in Windows XP with SP2
	Registry Entries Available in Windows Server 2003 with SP1
	More Information

Customized Security Configuration Editor

When you load the Microsoft Management Console (MMC) Security Templates snap-in and view the security templates, the entries in the following tables are not represented. These entries were added to the .inf file by using a customized version of the Security Configuration Editor (SCE). These entries can also be viewed or modified with a text editor such as Notepad. They will be applied to computers when policies are downloaded to them, regardless of whether the computers have also had their SCE user interfaces modified.

These entries are embedded within the security templates to automate the changes. If the policy is removed, these entries are not automatically removed with it; they must be manually changed using a registry editing tool such as Regedt32.exe. The Microsoft Excel® workbook "Windows Default Security and Services Configuration" that is included with this guide documents the default settings.

How to Modify the Security Configuration Editor User Interface

The SCE is used to define security templates that can be applied to individual computers or any number of computers through Group Policy. Security templates can contain password policies, lockout policies, Kerberos protocol policies, Audit policies, event log settings, registry values, service startup modes, service permissions, user rights, group membership restrictions, registry permissions, and file system permissions. The SCE appears in a number of MMC snap-ins and administrator tools. It is used by the Security Templates snap-in and the Security Configuration and Analysis snap-in. The Group Policy Editor snap-in uses it for the Security Settings portion of the Computer Configuration tree. It is also used for the Local Security Settings, Domain Controller Security Policy, and the Domain Security Policy tools as well.

This guide includes additional entries that are added to the SCE by modifying the Seregvl.inf file (located in the %systemroot%\inf folder) and re-registering the Scecli.dll file. The original security settings, as well as the additional ones, appear under Local Policies\Security in the snap-ins and tools listed earlier in this guide. You should update the Sceregvl.inf file and re-register the Scecli.dll file on any computers for which you will edit the security templates and Group Policies that are provided with this guide as described in the following sections. However, the customization information for the Sceregvl.inf file uses features that only became available in Microsoft Windows® XP Professional with Service Pack 1 (SP1) and Windows Server 2003—do not try to install it on older versions of Windows.

After the Sceregvl.inf file has been modified and registered, the custom registry values are exposed in the SCE user interfaces on that computer. You will see the new settings at the bottom of the list of items in the SCE; the new settings all have names that start with "MSS:" MSS stands for Microsoft Solutions for Security, the name of the group that created this guide. You can then create security templates or policies that define these new registry values. These templates or policies can then be applied to any computer regardless of whether Sceregvl.inf has been modified on the target computer or not. Subsequent launches of the SCE UI will expose your custom registry values.

Instructions about how to modify the SCE user interface are provided in the following procedures. There are manual instructions that you should follow if you have already made other customizations to the SCE. A script is provided to add the settings with minimal user interaction, and although the script has error detection and recovery features built in, it may fail. If it fails, you should determine the cause of the failure and either correct the problem or follow the manual instructions. Another script is provided that you can use to restore the SCE user interface to its default state. This script will remove all custom settings and return the SCE to the way it appears in a default installation of Windows XP with SP2 or Windows Server 2003 with SP1.

To manually update sceregvl.inf

Subsequent launches of the SCE will display these custom registry values.

To automatically update sceregvl.inf

This procedure will remove only the custom entries made using the script that is described in the previous procedure, Update_SCE_with_MSS_Regkeys.vbs. You can also reverse the changes made by the automatic update script.

To reverse the changes made by the Update_SCE_with_MSS_Regkeys.vbs script

This procedure will remove any custom entries that you may have added to the SCE user interface, including those from this guide and others that may have been provided in earlier versions of this guide or in other security guides.

To restore the SCE to its default state for Windows XP with SP2 Windows Server 2003 with SP1

To manually restore the SCE user interface to its default appearance

Top of page

TCP/IP-Related Registry Entries

To help prevent denial of service (DoS) attacks, you should keep your computer updated with the latest security fixes and harden the TCP/IP protocol stack on your Windows Server 2003 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, Microsoft recommends 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 were added to the template file in 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 on the Microsoft Windows Server 2003 TCP/IP Implementation Details page at http://technet2.microsoft.com/WindowsServer/en/library/823ca085-8b46-4870-a83e-8032637a87c81033.mspx.

Table 10.1 TCP/IP-Related Registry Entries in Windows Server 2003 with SP1 and Windows XP with SP2

DisableIPSourceRouting: IP source routing protection level (protects against packet spoofing)

This entry appears as MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) in the SCE. IP source routing is a mechanism that allows the sender to determine the IP route that a datagram should follow through the network.

Vulnerability

An attacker could use source routed packets to obscure their identity and location. Source routing allows a computer that sends a packet to specify the route that the packet takes.

Countermeasure

Configure the MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) entry to a value of Highest protection, source routing is completely disabled.

The possible values for this registry entry are:

In the SCE UI, the following list of options appears:

Potential Impact

If you configure this value to 2, all incoming source routed packets will be dropped.

EnableDeadGWDetect: Allow automatic detection of dead network gateways (could lead to DoS)

This entry appears as MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways (could lead to DoS) in the SCE. When dead gateway detection is enabled, the IP may change to a backup gateway if a number of connections experience difficulty.

Vulnerability

An attacker could force the server to switch gateways, potentially to an unintended one. This would be very difficult to do, so the value of this entry is small.

Countermeasure

Configure the MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways (could lead to DoS) entry to a value of Disabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

Potential Impact

If you configure this value to 0, Windows cannot detect dead gateways and automatically switch to alternates.

EnableICMPRedirect: Allow ICMP redirects to override OSPF generated routes

This entry appears as MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes in the SCE. Internet Control Message Protocol (ICMP) redirects cause the stack to plumb host routes. These routes override the Open Shortest Path First (OSPF)-generated routes.

Vulnerability

This behavior is expected. The problem is that the 10 minute time-out period for the ICMP redirect-plumbed routes temporarily creates a network situation in which traffic will no longer be routed properly for the affected host.

Countermeasure

Configure the MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes entry to a value of Disabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

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 can not 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.

KeepAliveTime: How often keep-alive packets are sent in milliseconds (300,000 is recommended)

This entry appears as MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds (300,000 is recommended) in the SCE. It 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.

Vulnerability

An attacker who is able to connect to network applications could establish numerous connections to cause a DoS condition.

Countermeasure

Configure the MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds (300,000 is recommended) entry to a value of 300000 or 5 minutes.

The possible values for this registry entry are:

In the SCE UI, the following list of options appears:

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, you can lower this value from the default setting of two hours to five minutes to disconnect inactive sessions more quickly.

PerformRouterDiscovery: Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS)

This entry appears as MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS) in the SCE. 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.

Vulnerability

An attacker who has gained control of a computer on the same network segment could configure a computer on the network to impersonate a router. Other computers with IRDP enabled would then attempt to route their traffic through the already compromised computer.

Countermeasure

Configure the MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS) entry to a value of Disabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

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: Syn attack protection level (protects against DoS)

This entry appears as MSS: (SynAttackProtect) Syn attack protection level (protects against DoS) in the SCE. 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).

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 the MSS: (SynAttackProtect) Syn attack protection level (protects against DoS) entry to a value of Connections time out sooner if a SYN attack is detected.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

Potential Impact

This value 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. The reasons these options cannot be enabled is 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: SYN-ACK retransmissions when a connection request is not acknowledged

This entry appears as MSS: (TcpMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged in the SCE. This entry determines the number of times that TCP retransmits a SYN before it aborts the attempt. The retransmission time-out is doubled with each successive retransmission in a given connect attempt. The initial time-out value is three seconds.

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 MSS: (TcpMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged entry to a value of 3 seconds, half-open connections dropped after nine seconds.

The possible values for this registry entry are:

In the SCE UI, the following options appear and correspond to a value of 0, 1, 2, and 3, respectively:

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 clean up a half-open TCP connection. A site that is under heavy attack might set the value as low as 1. A value of 0 is also valid. However, if this parameter is set to 0, SYN-ACKs will not be retransmitted at all and will time out in 3 seconds. If the value is this low, legitimate connection attempts from distant clients may fail.

TcpMaxDataRetransmissions: How many times unacknowledged data is retransmitted (3 recommended, 5 is default)

This entry appears as MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) in the SCE. This entry controls the number of times that TCP retransmits an individual data segment (non-connect segment) before it aborts the connection. The retransmission time-out is doubled with each successive retransmission on a connection. It is reset when responses resume. The base time-out value is dynamically determined by the measured round-trip time on the connection.

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 MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) entry to a value of 3. The possible values for this registry entry are:

In the SCE UI, this setting can be adjusted using a text entry box:

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, then the segment is retransmitted up to three times.

Top of page

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.

Table 10.2 Non-TCP/IP Entries Added to Registry in Windows Server 2003

Disable Automatic Logon: Disable Automatic Logon

This entry appears as MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) in the SCE. This entry determines whether the automatic logon feature is enabled. (This entry is separate from the Welcome screen feature in Windows XP; 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 log on dialog box is not displayed.

For additional information, see the Microsoft Knowledge Base article "How to turn on automatic logon in Windows XP" at http://support.microsoft.com/default.aspx?kbid=315231.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
CurrentVersion\Winlogon\

subkey.

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 see the registry.

Countermeasure

Do not configure the MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) entry except on highly secure computers, where it should be configured to a value of Disabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

Potential Impact

None. By default this entry is not enabled.

Configure Automatic Reboot from System Crashes

This entry appears as MSS: (AutoReboot) Allow Windows to automatically restart after a system crash (recommended except for highly secure environments) in the SCE. It determines whether the computer restarts automatically after it fails.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\

subkey.

Vulnerability

There is some concern that a computer could get stuck in an endless loop of failures and reboots. However, the alternative to this entry may not be much more appealing—the computer will simply stop running.

Countermeasure

Configure the MSS: (AutoReboot) Allow Windows to automatically restart after a system crash (recommended except for highly secure environments) entry to a value of Disabled.

The possible values for this registry entry are:

For more information, see the Microsoft Knowledge Base article "How To Configure System Failure and Recovery Options in Windows" at http://support.microsoft.com/?kbid=307973.

In the SCE UI, the following options are available:

Potential Impact

The computer will no longer reboot automatically after a failure.

Enable Administrative Shares

This entry appears as MSS: (AutoShareWks) Enable Administrative Shares (not recommended except for highly secure environments) in the SCE. By default, Windows XP Professional automatically creates administrative shares such as C$ and IPC$.

For additional information, see the Microsoft Knowledge Base article "How to create and delete hidden or administrative shares on client computers" at http://support.microsoft.com/default.aspx?kbid=314984.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\
Parameters\

subkey.

Vulnerability

Because these built-in administrative shares are well-known and present on most Windows computers, malicious users often target them for brute-force attacks to guess passwords as well as other types of attacks.

Countermeasure

Do not configure the MSS: (AutoShareWks) Enable Administrative Shares (not recommended except for highly secure environments) entry except on highly secure computers, where it should be configured to a value of Enabled.

The possible values for this registry entry are:

●    1 or 0. The default configuration is 1 (enabled).

In the SCE UI, these options appear as:

●    Enabled

●    Disabled

●    Not Defined

Potential Impact

If you delete these shares you could cause problems for administrators and programs or services that rely on these shares. For example, both Microsoft Systems Management Server (SMS) and Microsoft Operations Manager 2000 require administrative shares for correct installation and operation. Also, many third-party network backup applications require administrative shares.

Disable Saving of Dial-Up Passwords

This entry appears as MSS: (DisableSavePassword) Prevent the dial-up passsword from being saved (recommended) in the SCE. 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 template in the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\
Parameters\

subkey.

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 enabled for the dial-up entry.

Countermeasure

Configure the MSS: (DisableSavePassword) Prevent the dial-up password from being saved (recommended) entry to a value of Disabled.

The possible values for this registry entry are:

For more information, see the Microsoft Knowledge Base article "Disabling Save Password Option in Dial-Up Networking" at http://support.microsoft.com/default.aspx?kbid=172430.

In the SCE UI, the following options are available:

Potential Impact

Users won’t be able to automatically store their logon credentials for dial-up and VPN connections.

Hide the Computer from Network Neighborhood Browse Lists: Hide Computer From the Browse List

This entry appears as MSS: (Hidden) Hide Computer From the Browse List (not recommended except for highly secure environments) in the SCE. 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 Browser list; it does not announce itself to other computers on the same network.

For more information, see the Microsoft Knowledge Base article "HOW TO: Hide a Windows 2000–Based Computer from the Browser List" at http://support.microsoft.com/default.aspx?kbid=321710.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\
Parameters\

subkey.

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 MSS: (Hidden) Hide Computer From the Browse List (not recommended except for highly secure environments) entry except on highly secure computers, where it should be configured to a value of Enabled.

The possible values for this registry entry are:

●    1 or 0. The default configuration is 0 (disabled).

In the SCE UI, these options appear as:

●    Enabled

●    Disabled

●    Not Defined

Potential Impact

The computer will no longer appear on the Browser list or in Network Neighborhood on other computers on the same network.

Enable IPSec to protect Kerberos RSVP Traffic: Enable NoDefaultExempt for IPSec Filtering

This entry appears as MSS: (NoDefaultExempt) Enable NoDefaultExempt for IPSec Filtering (recommended) in the SCE. The default exemptions to IPsec policy filters are documented in the Microsoft Windows Server 2003 and Microsoft Windows XP online help. These filters make it possible for Internet Key Exchange (IKE) and the Kerberos authentication protocol to function. The filters also make it possible for the network Quality of Service (QoS) to be signaled (RSVP) when the data traffic is secured by IPsec, and for traffic that IPsec might not secure, such as multicast and broadcast traffic.

For more information, see the TechNet article "Specifying Default Exemptions to IPSec Filtering" at http://technet2.microsoft.com/WindowsServer/en/library/c9a7d986-5b9a-4e01-bb80-82d5e3a87d5c1033.mspx. Also, see the Microsoft Knowledge Base article "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" at http://support.microsoft.com/default.aspx?kbid=811832.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\

subkey.

Vulnerability

As IPsec is increasingly used for basic host-firewall packet filtering, particularly in Internet-exposed scenarios, the affect 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 MSS: (NoDefaultExempt) Enable NoDefaultExempt for IPSec Filtering (recommended) entry except on computers that use IPsec filters, where this entry should be configured to a value of Enabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

Potential Impact

After you enable this entry, security policies that already exist may have to be changed to work correctly. For details, refer to the Microsoft Knowledge Base article "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios" at http://support.microsoft.com/default.aspx?kbid=811832, which was referenced earlier in this section.

Disable Autorun: Disable Autorun for all drives

This entry appears as MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) in the SCE. 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 to the template file 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 template file in the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Cdrom\

subkey.

Vulnerability

To prevent a possible malicious program from execution when media is inserted, the Group Policy disables Autorun on all drives.

An attacker with physical access to the computer could insert an Autorun-enabled DVD or CD into the computer that will automatically launch a malicious program.

Countermeasure

Configure the MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) entry to a value of 255, disable Autorun for all drives.

The possible values for this registry entry are:

For more information, see Microsoft Knowledge Base article "The AutoRun feature or the AutoPlay feature does not work when you insert a CD-ROM in the drive" at http://support.microsoft.com/default.aspx?kbid=330135.

In the SCE UI, the following options are available:

Potential Impact

Autorun will no longer work when Autorun-enabled discs are inserted into the computer. Also, CD-burning utilities may not work as expected because blank CDs may 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 launch them.

Configure NetBIOS Name Release Security: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers

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 SCE. 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 template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\

subkey.

Vulnerability

The 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.

For more information, see the Microsoft Knowledge Base article "MS00-047: NetBIOS Vulnerability May Cause Duplicate Name on the Network Conflicts" at http://support.microsoft.com/default.aspx?kbid=269239.

Countermeasure

Configure the MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers (Only recommended for servers) entry to a value of Enabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

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. For more information about how to pre-load the LMHOSTS file, see the Microsoft Knowledge Base article "MS00-047: NetBIOS Vulnerability May Cause Duplicate Name on the Network Conflicts" that was referenced earlier in this section.

Note: Maintenance of LMHOSTS files in most environments requires a significant amount of effort. Microsoft encourages the 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, Microsoft recommends that you test this change in a non-production environment before you change the production environment.

Disable Auto Generation of 8.3 File Names: Enable the computer to stop generating 8.3 style filenames

This entry appears as MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) in the SCE. Windows Server 2003 supports 8.3 file name formats for backward compatibility with16-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 template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\

subkey.

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 (NTFS) 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 execute applications.

Countermeasure

Configure the MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) entry to a value of Enabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

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; those that are designed to run on multiple CPU architectures are likely to be 16-bit applications. The installation of Exchange 2000 SP2 will fail if this entry is enabled. The installation of service packs for SQL 2000 will fail if this entry is enabled and the path for the system variable %temp% includes a space; a simple workaround for this problem is to redefine the variable to a path without spaces (for example, C:\temp).

Note: 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.

Enable Safe DLL Search Order: Enable Safe DLL search mode (recommended)

This entry appears as MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended) in the SCE. The dynamic-link library (DLL) search order can be configured to search for requested DLLs in one of two ways:

If SafeDllSearchMode is configured to 1, the search order is as follows:

If SafeDllSearchMode is configured to 0, the search order is as follows:

You can add this registry value the template file in the

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\

subkey.

Vulnerability

If a user unknowingly executes hostile code that was packaged with additional files that include modified versions of system DLLs, the hostile code could load its own versions of those DLLs and potentially increase the type and degree of damage the code can render.

Countermeasure

Configure the MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended) entry to a value of Enabled.

The possible values for this registry entry are:

In the SCE UI, these options appear as:

Potential Impact

Applications will be forced to search for DLLs in the system path first. For applications that require unique versions of these DLLs that are included with the application, this entry could cause performance or stability problems.

Make Screensaver Password Protection Immediate: The time in seconds before the screen saver grace period expires (0 recommended)

This entry appears as MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) in the SCE. Windows includes a grace period between when the screen saver is launched and when the console is actually locked automatically if screen saver locking is enabled.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\
Winlogon\

subkey.

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 MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) entry to a value of 0.

The possible values for this registry entry are:

In the SCE UI, the value for this entry appears as a text entry box:

Potential Impact

Users will have to enter their passwords to resume their console sessions as soon as the screen saver activates.

Security Log Near Capacity Warning: Percentage threshold for the security event log at which the system will generate a warning

This entry appears as MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning in the SCE. Windows Server 2003 and Service Pack 3 for Windows 2000 include a new feature to generate a security audit in the Security event log when it reaches a user-defined threshold. For example, if this value is set to 90, an event entry with eventID 523 will be entered in the log when the Security log reaches 90 percent of capacity. This entry contains the following text:

The security event log is 90 percent full.

Note: This setting will have no effect if the Security event Log is configured to overwrite events as needed.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Eventlog\Security\

subkey.

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 shut down and will no longer be available to provide network services.

Countermeasure

Configure the MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning entry to a value of 90.

The possible values for this registry entry are:

In the SCE UI, the following options are available:

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.

Top of page

Registry Entries Available in Windows XP with SP2 and Windows Server 2003 with SP1

The registry entries that are described earlier in this chapter apply to Microsoft Windows XP with SP1 and Windows Server 2003.

The release of Windows XP SP2 and Windows Server 2003 SP1 provided additional security-related registry entries that you can configure to address specific security requirements in your environment.

The following registry entries are available in both Windows XP with SP2 and Windows Server 2003 with SP1.

RestrictRemoteClients

When an interface is registered through RpcServerRegisterIf, 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.

The RestrictRemoteClients registry key can have one of three DWORD values:

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 to remotely exploit buffer overruns and spread malicious code.

Countermeasure

The default configuration of the RestrictRemoteClients value in both Windows Server 2003 with SP1 and Windows XP with SP2 allow 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.

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 on Windows XP with SP2 because of the default value for the new 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.

Vulnerability

RPC interfaces that allow unauthenticated connections can potentially be used to remotely exploit buffer overruns and spread malicious code.

Countermeasure

To add protection against worms that may attempt to remotely exploit buffer overflows in RPC services, configure RestrictRemoteClients as described in the previous section 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.

RunInvalidSignatures

By default, Windows Server 2003 with SP1 and Windows XP with SP2 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 the service pack 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.

Top of page

Registry Entries Available in Windows XP with SP2

The following registry entries are available only in Windows XP with SP2.

Security Center Registry Entries for XP

There are three registry values for the Security Center that determine whether or not the user receives alerts for a given feature. If a key has a value of 0 or is nonexistent, the notification icon and alert system for that feature are enabled. If a value exists and is not 0, the notification icon and alert system for the feature is disabled.

All three of these values are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Security Center. The values are:

Vulnerability

Users who disable the alert features of Security Center may not receive appropriate warnings if the antivirus, firewall, or automatic update services that are installed on their computers do not work properly for some reason.

Countermeasure

Apply a Group Policy registry entry to enforce the appropriate warning configuration for your environment.

Potential Impact

These registry values are visible in the Security Center user interface if the Security Center functionality is enabled. Users with local administrator access will be able to change the Security Center values.

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 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 WriteProtect DWORD value to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies 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

When the WriteProtect value is set to 1, Windows XP with SP2 will block writes 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 wish 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.

Top of page

Registry Entries Available in Windows Server 2003 with SP1

The following registry entries are available only in Windows Server 2003 with SP1.

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.

In 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.)

Windows Server 2003 SP1 introduces 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, then trick or spoof users and make them attempt to connect to it to capture their credentials.

Countermeasure

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 only supports 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 the user responds, they would 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, 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 only support 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.

Top of page

More Information

The following links provide additional information about some of the entries that are discussed in this chapter:

Top of page

11 of 14