IPsec default exemptions can be used to bypass IPsec protection in Some Scenarios

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 more information about these filters, click the following article number to view the article in the Microsoft Knowledge Base:

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

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

1. 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.
2. 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.
3. 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.
4. 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

   (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:

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

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

To configure this registry key:

1. Click Start, click Run, type regedit, and then click OK.
2. Click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC
   
   Note In Windows Server 2008 and in Windows Vista, the registry key is:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
3. Right-click IPSEC, point to New, and then click DWORD Value.
4. Name this new entry NoDefaultExempt.
5. 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.
6. Quit Registry Editor.
7. 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.
8. Double-click Services.
9. 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: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 more information on using this option, click the following article number to view the article in the Microsoft Knowledge Base:
  309798

  (http://support.microsoft.com/kb/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 more information on ICF, click the following article number to view the article in the Microsoft Knowledge Base:
  283673

  (http://support.microsoft.com/kb/283673/ )

  How to turn on or turn off the 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:

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 more information about how to disable the RSVP protocol signaling, click the following article number to view the article in the Microsoft Knowledge Base: 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 more information about how to do so, click the following article number to view the article in the Microsoft Knowledge Base: 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.

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

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: For more information about IP Security, click the following article numbers to view the articles in the Microsoft Knowledge Base: