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 to
0.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:
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:
- Click Start, click
Run, type cmd, and then click
OK.
- 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).