Article ID: 811832 - View products that this article applies to.
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:
(https://support.microsoft.com/kb/253169/ )Traffic that can--and cannot--be secured by IPsec
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=1registry 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 ExemptionsThe 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
NoDefaultExemptis 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
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.
Collapse this tableExpand this table
Operating System Support for NoDefaultExemptThe following table describes the default exemption behaviors in the various releases of Windows 2000 and Windows XP:
Collapse this tableExpand this table
Note IPSec in Windows 2000 and Windows XP does not support filtering of broadcast or multicast traffic.
Removal of Default ExemptionsThe following registry key controls the type of default exemptions for IPsec:
Description of possible values:
Data type: REG_DWORD
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
(https://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
To configure this registry key:
Affect of Default ExemptionsThe 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.
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
Affect of IKE ExemptionThe 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:
Affect of Kerberos Default ExemptionWith 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
NoDefaultExemptregistry 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:
(https://support.microsoft.com/kb/254949/ )IPSec support for client-to-domain controller traffic and domain controller-to-domain controller traffic
Affect of RSVP ExemptionFor 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 2000Windows 2000 uses the RSVP protocol under the following circumstances:
247103When used, the QoS RSVP service does not send RSVP signaling on the specified interface.
(https://support.microsoft.com/kb/247103/ )How to disable RSVP signaling
RSVP in Windows XPThe 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 AttacksTo enable IPsec to protect against potential attacks by using the RSVP protocol, the administrator must set the
NoDefaultExempt=1registry 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:
247103If 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.
(https://support.microsoft.com/kb/247103/ )How to disable RSVP signaling
Affect of Broadcast and Multicast ExemptionPackets 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:
To see UDP programs that will receive broadcast traffic by default, use the netstat command:
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:
Using IPsec with the Internet Connection FirewallFor 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:
http://technet.microsoft.com/en-us/library/bb726981.aspxFor more information about IP Security, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/253169/ )Traffic that can--and cannot--be secured by IPSec
(https://support.microsoft.com/kb/254728/ )IPSec does not secure Kerberos traffic between domain controllers
(https://support.microsoft.com/kb/308127/ )How to manually open ports in Internet Connection Firewall in Windows XP
(https://support.microsoft.com/kb/810207/ )IPSec default exemptions are removed in Windows Server 2003
Article ID: 811832 - Last Review: February 8, 2008 - Revision: 7.2