Knowledge Base

IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios

Article ID: 811832

Article Last Modified on 10/26/2007

APPLIES TO

Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional Edition
Microsoft Windows XP Professional

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SUMMARY

The Internet Protocol Security (IPsec) feature in Windows 2000, Windows XP and Windows Server 2003 was not designed as a full-featured host-based firewall. It was designed to provide basic permit and block filtering by using address, protocol and port information in network packets. IPsec was also designed as an administrative tool to enhance the security of communications in a way that is transparent to the programs. Because of this, it provides traffic filtering that is necessary to negotiate security for IPsec transport mode or IPsec tunnel mode, primarily for intranet environments where machine trust was available from the Kerberos service or for specific paths across the Internet where public key infrastructure (PKI) digital certificates can be used.

The default exemptions to IPsec policy filters are documented in the Microsoft Windows 2000 and Microsoft Windows XP online help. These filters make it possible for Internet Key Exchange (IKE) and Kerberos 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 additional information about these filters, click the following article number to view the article in the Microsoft Knowledge Base:

253169 Traffic That Can--and Cannot--Be Secured by IPSec

MORE INFORMATION

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. Because of this, 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.

Microsoft strongly recommends that network administrators take the steps in this article to remove the default exemptions to IPSec. This is especially recommended if IPsec is used in scenarios where firewall-like functionality must prevent attackers from gaining network access to the computer. Remove the default exemptions for Kerberos to prevent attackers from defeating the protection that is intended to be provided by IPsec for certain IPsec policy configurations. After the exemptions are removed, existing security policies may have to be changed to work correctly.

Administrators can start to plan for these changes for all existing and new IPsec deployments by using the NoDefaultExempt=1 registry key on all Windows 2000-based and Windows XP-based computers. The purpose of this registry key is described later in this article.

Definition of IPsec Default Exemptions

The following table summarizes the equivalent filters that are implemented if all default exemptions to IPSec filtering are enabled, as they are by default, or if NoDefaultExempt is set to0.These filter definitions describe the default exemptions that are applied in the IPsec driver to permit traffic, regardless of other IPsec policy filters. Tools that are designed to show the IPSec policy filter details do not show these exemptions in their results.

Equivalent Filters for NoDefaultExempt=0:

Source Address	Destination Address	Protocol	Source Port	Destination Port	Filter Action
My IP Address	Any IP Address	UDP	Any	88	Permit
Any IP Address	My IP Address	UDP	88	Any	Permit
Any IP Address	My IP Address	UDP	Any	88	Permit
My IP Address	Any IP Address	UDP	88	Any	Permit
My IP Address	Any IP Address	TCP	Any	88	Permit
Any IP Address	My IP Address	TCP	88	Any	Permit
Any IP Address	My IP Address	TCP	Any	88	Permit
My IP Address	Any IP Address	TCP	88	Any	Permit
My IP Address	Any IP Address	UDP	500	500 (1)	Permit
Any IP Address	My IP Address	UDP	500	500	Permit
My IP Address	Any	46 (RSVP)			Permit
Any IP Address	My IP Address	46 (RSVP)			Permit
Any IP Address	<multicast> (2)				Permit
My IP Address	<multicast>				Permit
Any IP Address	<broadcast> (3)				Permit
My IP Address	<broadcast>				Permit
<All IPv6 protocol traffic> (5)	<All IPv6 protocol traffic> (4)				Permit

When the IP address is specified, the subnet mask is 255.255.255.255. When the IP address is Any, the subnet mask is 0.0.0.0.

In order for IPSec transport mode to be negotiated through an IPSec tunnel mode SA, ISAKMP traffic is not exempted if it needs to pass through the IPSec tunnel first.
Multicast traffic is defined as the class D range, with a destination address range of 224.0.0.0 with a 240.0.0.0 subnet mask. This includes the range of IP addresses from 224.0.0.0 to 239.255.255.255.
Broadcast traffic is defined as a destination address of 255.255.255.255, the limited broadcast address, or as having the host ID portion of the IP address set to all 1s, the subnet broadcast address.
IPSec does not support filtering for IP version 6 (IPv6) packets, except when IPv6 packets are encapsulated with an IPv4 header as IP protocol 41. For more information about IPv6 support in Windows, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/network/bb530961.aspx

Operating System Support for NoDefaultExempt

The following table describes the default exemption behaviors in the various releases of Windows 2000 and Windows XP:

	Retail, Released Version	SP1	SP2	SP3	SP4
Windows 2000	Has default exemptions. `NoDefaultExempt` key is not supported.	Has default exemptions, `NoDefaultExempt` key is supported, values 0 or 1.	Has default exemptions. `NoDefaultExempt` key is supported, values 0 or 1.	Has default exemptions. `NoDefaultExempt` key is supported, values 0 or 1.	Changes default, `NoDefaultExempt=1` that removes Kerb and RSVP exemptions.
Windows XP	Has default exemptions, `NoDefaultExempt` is supported, values 0 or 1.	Has default exemptions, `NoDefaultExempt` is supported, values 0 or 1.	Changes default, `NoDefaultExempt=1`, that removes Kerb and RSVP exemptions.

Note IPSec in Windows 2000 and Windows XP does not support filtering of broadcast or multicast traffic.

Removal of Default Exemptions

The following registry key controls the type of default exemptions for IPsec:

NoDefaultExempt
Data type: REG_DWORD
Range: varies:
Windows 2000: 0-1 supported only
Windows XP: 0-1 supported only
Windows Server 2003: 0-3 supported only
Default behavior (Windows 2000 and Windows XP): 0
Default behavior (Windows Server 2003): 3
Present by default: No

Description of possible values:

A value of 0 specifies that multicast, broadcast, RSVP, Kerberos, and IKE (ISAKMP) traffic are exempt from IPSec filtering. This is the default filtering behavior for Windows 2000 and Windows XP. Use this setting only if you have to for compatibility with an existing IPsec policy or Windows 2000 and Windows XP behavior.
A value of 1 specifies that Kerberos and RSVP traffic are not exempt from IPSec filtering, but multicast, broadcast, and IKE traffic are exempt. This 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 filtering, but RSVP, Kerberos, and IKE traffic are exempt. Supported only in Windows Server 2003.
A value of 3 specifies that only IKE traffic is exempt from IPSec filtering. Supported only in Windows Server 2003. Windows Server 2003 contains this default behavior although the registry key does not exist by default.

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To configure this registry key:

Click Start, click Run, type regedit, and then click OK.
Click the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC
Right-click IPSEC, point to New, and then click DWORD Value.
Name this new entry NoDefaultExempt.
Change the value of the NoDefaultExempt key from 0 to 1. If you want to, you can use a value other than 1 if another value is best suited to your environment.
Quit Registry Editor.
In Windows XP, click Start, click Control Panel, and then double-click Administrative Tools. In Windows 2000 click Start, click Settings, click Control Panel, and then double-click Administrative Tools.
Double-click Services.
Stop, and then restart the IPSec Services service. Windows XP requires that you restart the computer after you do so.

Affect of Default Exemptions

The following example shows a Windows 2000 or Windows XP IPSec policy that is configured as a one-way block filter. The effects of applying a block filter with these rules is that all inbound traffic is blocked. This filter rule is provided only to demonstrate the effect of the IPSec exemptions against this rule:

Source Address:     Any
Source Mask:        0.0.0.0
Destination Address:    My IP Address (10.10.1.2)
Destination Mask:   (255.255.255.255)
Protocol:       Any
Source Port:        Any
Destination Port:   Any
Mirrored:       No

The administrator’s intent in this example is to block all inbound unicast traffic that is going to the 10.10.1.2 IP address. The following sections describe the affect of the default exemptions as they apply to this filter.

Affect of IKE Exemption

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

IKE use various methods of denial of service (DoS) avoidance. Windows 2000 Service Pack 3 and Windows XP provide improved DoS avoidance to IKE flooding attacks. IKE cannot be disabled independent from the IPsec service and IPsec driver. IKE can only be disabled by stopping the IPsec service that also disables the IPsec filtering.

If IKE is being attacked from the Internet and is not needed, but IPsec filtering is needed, a number of options are available:

A blocking filter for UDP 500 traffic can be used on the default gateway or firewall.
Configure a TCP/IP Advanced Properties filter on the Internet interface. Use Permit Only, and then add UDP ports required other than UDP 500. For additional information about using this option, click the following article number to view the article in the Microsoft Knowledge Base:

309798 HOW TO: Configure TCP/IP Filtering in Windows 2000

Use the netstat –a command to see open UDP ports.
On Windows XP the Internet Connection Firewall (ICF) can be enabled on the Internet interface to block all incoming traffic. Specific holes can be configured for UDP ports other than UDP 500. For additional information about ICF, click the following article number to view the article in the Microsoft Knowledge Base:

283673 HOW TO: Enable or Disable Internet Connection Firewall in Windows XP

Affect of Kerberos Default Exemption

With this example that blocks all one-way inbound traffic, all inbound or outbound unicast Kerberos traffic would be exempted from matching this filter. Because of this, an attacker can construct a unicast UDP or TCP packet that uses source port 88 to access any open port at 10.10.1.2. This would enable a UDP and TCP port scan, even with the block filter. The administrator must set the NoDefaultExempt registry key to prevent attacks. If a filtering router or firewall is in use, it may or may not allow such traffic from an attacker, depending on how it handles traffic that is using the Kerberos ports.

Note Many port scan tools do not detect this behavior because these tools do not allow setting the source port to 88 when the check for open ports occurs. Also note that many port scan tools expect an ICMP message in response to a probe that is sent to a TCP or UDP port that is not open. If IPsec is blocking ICMP traffic, the scanning tool may falsely report that the port is open. Use a network trace with the Network Monitor tool to make sure that the traffic is being sent and received on the network.

When the Kerberos exemption is removed, and if IPsec is also used to secure traffic by using Kerberos authentication in IKE, the following IPsec policy design considerations must be followed:

A computer that is using IKE Kerberos authentication with NoDefaultExempt=1 cannot communicate with a peer computer that is using IKE Kerberos authentication if it also does not have the same registry key value. Use certificate authentication for IKE instead of Kerberos where this is required.
Explicit exemptions for Kerberos and UDP 389 traffic to and from all relevant DC IP addresses must be specified in the IPsec policy. Because as of March 2003, Microsoft does not support IPsec securing traffic from a domain member to its domain controllers, add filters to the IPsec policy to explicitly permit all traffic to the domain controller IP addresses. This may require many permit filters if there are many DCs. DC IP addresses must be permanently assigned to the DCs (static IP addresses). The filter list for all DCs in a domain must be manually maintained by the administrator to have the current list of IP addresses. This can be more easily updated by the administrator if the filter specifies the DNS name of the domain as the source or destination address during the creation of a new filter. This resolves the domain name against DNS to all current IP addresses in the domain and create filters for each individual IP. Verify the IP address list before you using the filter list in production. Adding a new DC will require adding a new filter in this filter list. Microsoft recommends using one filter list for all DCs in a particular domain that is then shared across IPsec policy rules. Make sure that the filter list name indicates the last update time of the IP address list for easy reference.

For more information about communication between domain controllers, click the following article number to view the article in the Microsoft Knowledge Base:

254949 IPSec support for client-to-domain controller traffic and domain controller-to-domain controller traffic

Affect of RSVP Exemption

For a computer that uses RSVP, an attacker may be able to cause a denial of service by flooding or sending spoofed or malicious RSVP packets to 10.10.1.2. This is the IP address that is used in the previous example, and this attack would bypass the one-way inbound block IPsec filter in the example.

The RSVP protocol is IP protocol 46. It is a signaling protocol that is used to reserve bandwidth in routers for program traffic.

RSVP in Windows 2000

Windows 2000 uses the RSVP protocol under the following circumstances:

The QoS Admission Control Service is installed. This is an optional networking component in Windows 2000 Server computers. If this is installed, it receives and sends RSVP traffic.
The Quality of Service (QoS) RSVP service is running. By default, this service is installed and configured as an autostart service. When it is started, the service loads the Rsvp.exe program that uses the RSVP protocol, and then unloads it if there is no traffic that requires RSVP signaling. It loads the Rsvp.exe program dynamically when QoS services are needed.
A program opens a socket with a GQoS socket option. The Rsvp.exe program runs continuously to manage the signaling for the socket traffic.
The pathping –r command uses the RSVP protocol to determine if routers are RSVP enabled.

For additional information about how to disable the RSVP protocol signaling, click the following article number to view the article in the Microsoft Knowledge Base:

247103 How to Disable RSVP Signaling

When used, the QoS RSVP service does not send RSVP signaling on the specified interface.

RSVP in Windows XP

The RSVP protocol was deprecated in Windows XP. Although the Quality of Service (QoS) RSVP service is installed by default, it is configured for a manual start. The service does not send or process received RSVP protocol messages. It still registers the RSVP protocol so the TCPIP stack receives IP protocol 46 type packets. But these inbound packets are then discarded. If the QoS RSVP service is not started, the TCP/IP protocol stack will drop the incoming RSVP packet, and then send an ICMP "destination unreachable" packet in response.

Windows XP only uses the RSVP protocol when the pathping –r command uses the RSVP protocol to determine if routers are RSVP enabled.

Protecting Against RSVP Attacks

To enable IPsec to protect against potential attacks by using the RSVP protocol, the administrator must set the NoDefaultExempt=1 registry key to disable the RSVP exemption in IPsec. Instead, you can disable the QoS RSVP service, or disable RSVP as a protocol. For additional information about how to do so, click the following article number to view the article in the Microsoft Knowledge Base:

247103 How to Disable RSVP Signaling

If RSVP protocol operation is required, explicit permit filters can be defined in the IPsec policy to permit IP protocol 46 to the appropriate source and destination addresses. Because RSVP is intended to communicate with routers, Microsoft does not recommend using IPsec to negotiate security for RSVP. Note that RSVP may also use a multicast address that cannot be filtered by IPSec. For additional information about this topic, click the following article number to view the article in the Microsoft Knowledge Base:

278517 Resource Reservation Setup Protocol Packets Use Local Multicast Address

Affect of Broadcast and Multicast Exemption

Packets with multicast and broadcast destination addresses would not match the example inbound filter because the inbound filter has a destination address of a specific unicast IP address (10.10.1.2). Windows 2000 and Windows XP IPsec filtering does not make it possible to filter multicast or broadcast traffic.

If an attacker constructs multicast or broadcast packets and if the network permits these packets to be received by the computer, the attacker can bypass the IPsec filter that is used in the previous example. Typically the attacker would have to be on the local subnet to conduct an attack by using this traffic because the default gateway router configuration would not forward unsolicited inbound multicast or broadcast traffic. In some IPsec policy designs that use the filter option to “Allow unsecured communication with non-IPsec aware computer”, an attacker may be able to use multicast or broadcast traffic inbound to cause a destination computer to send a unicast response. This would then trigger an IKE negotiation outbound that will create a Soft SA packet and open the path for the attacker to connect. An attacker may construct an invalid TCP packet by using a multicast or broadcast destination address to try to bypass IPsec filters. If a program or protocol is running that requests to receive multicast or broadcast packets, the attacker may be able to communicate with that program if the attacker and the program both use only broadcast and multicast traffic.

Microsoft recommends that the IPsec administrator discuss the router and firewall configuration with the network administrator to further investigate the feasibility of such an attack that is based on the current IPsec policies.

TCP-based communication requires a three-way handshake that uses unicast IP traffic, and therefore cannot use multicast or broadcast traffic types. In Windows 2000 and Windows XP, programs and services that use UDP and raw sockets by default receive broadcast traffic if it is sent to ports that the programs open. By default, RFC 2644 states that directed broadcast traffic must not be forwarded by routers. There are two other types of broadcast traffic that might be used from the local link:

Limited Broadcast Address – This is if the destination IP address is 255.255.255.255.
Network Prefix Directed Broadcast - This is if the destination IP address is x.y.255.255 or x.y.z.255 with appropriate subnet masks.

Programs typically define their own communication model by using this traffic. Typically multicast and broadcast traffic is used to initially announce and discover a service. Then the source and destination computers will use unicast IP traffic between their IP addresses to continue the communication.

To see UDP programs that will receive broadcast traffic by default, use the netstat command:

Windows 2000: netstat -a -p UDP There is no method for displaying the programs that opened these ports.
Windows XP: netstat –ao –p UDP The -ao switch shows the process ID to help identify the programs that are using open ports.

What Programs Can Receive Multicast Traffic?

Programs must explicitly register with the TCPIP stack to receive inbound multicast traffic. If the program has not registered to receive this type of traffic, inbound multicast packets are dropped. However, multicast packets can be dropped at the network adapter (the most common), at the miniport, the IP layer, or the UDP layer. Administrators should check to determine what multicast traffic types are routable through the network to better assess if multicast traffic can be used to attack a computer. To determine which multicast groups have been joined by a program:

Windows 2000: no method available
Windows XP:
1. Click Start, click Run, type cmd, and then click OK.
2. Type netsh interface ip show joins, and then press ENTER.

Using IPsec with the Internet Connection Firewall

For Windows XP, the Internet Connection Firewall (ICF) may better meet the security requirements for filtering traffic. ICF does filter and can block inbound multicast and broadcast traffic in Windows XP SP1. However, ICF is not aware of traffic that is protected by IPsec AH or ESP in transport or tunnel mode. IPsec is in the network layer below ICF. IKE is layered above ICF. Because of this, ICF should statically permit IKE (UDP port 500) inbound, and will not see IPsec AH or ESP protocols, but the TCP or UDP traffic after IPsec has decapsulated it in the receive processing. If IPsec blocks traffic, the ICF dropped packet log will not contain the packets that IPsec discarded.

IPsec functionality can be combined together with ICF filtering for advanced filtering behavior. For example, ICF can only be configured to open TCP port 445 from any IP address, and an IPsec filter might be used to further restrict this to only packets containing an internal subnet as the source address. Another example might be that IPsec is configured to negotiate security for all traffic, but the ICF configuration restricts what inbound connections are permitted to be accepted, permitting only inbound IKE (UDP port 500) and SMB file sharing (TCP port 445).

REFERENCES

For more information about TCP/IP implementation, view the Windows 2000 TCP/IP Detailed Implementation white paper. To do so, visit the following Microsoft Web site:

http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx

For additional information about IP Security, click the following article numbers to view the articles in the Microsoft Knowledge Base: