The example IPSec policy rules for CORPSRV, CORPCLI, and WEBSRV that are provided in this paper reflect best practices that were developed during the network penetration testing conducted by Foundstone and the production use of IPSec on internal Microsoft networks. The successful deployment of this policy was in large part due to initial small-scale lab testing and initial pilot testing conducted by the IPSec administrative team on less utilized servers. Before you deploy IPSec in a production environment, make sure that you conduct similar testing and perform additional security and performance assessments as required for your environment. The following sections describe policy modifications that were implemented in the Microsoft network. You might want to make similar modifications in your own production environment. Customized Rules for IPSec Policies Assigned to Microsoft Servers and Clients
When the example policies were placed into production use at Microsoft, the following additional rules were required to customize these policies for the Microsoft environment:
• A rule to control the use of IPSec in subnets used by remote access clients. This rule allowed IPSec to be disabled on remote access clients when troubleshooting was required. This rule is similar to Rule 5 of the CORPSRV IPSec policy, but, rather than specifying Any IP Address, this rule specified the subnets that remote access clients used (these clients typically used IPSec when communicating with internal corporate network servers).
• A rule to control the use of IPSec on each of the subnets in the internal corporate network, after several production servers were connected to a separate multihomed administrative network.
• A rule to exempt traffic that was required by a computer that ran server-monitoring software. • A rule to exempt traffic that was required for a network backup system to run on some
servers, to accommodate systems that did not support IPSec. For example, one backup system was a non-Microsoft device that did not support IPSec. In another case, the backup system was in the same protected room as the server using Gigabit Ethernet, and an IPSec hardware offload network adapter was not available.
• Several rules to allow clients running the Macintosh operating system to access servers. The filters for these rules allowed traffic from either the IP addresses of specific clients or from all clients on a specific subnet.
You might want to add similar rules to permit other traffic types that are required in your network environment. When you create such rules, however, make sure to evaluate whether they allow your servers to operate safely within the security requirements of your organization.
Fall Back to Clear and Inbound Passthrough Configuration for Initial Deployment
During the initial deployment of IPSec, the Allow unsecured communication with non-IPSec- aware computers (fall back to clear) and Allow unsecured communication, but always respond using IPSec (inbound passthrough) check boxes were both selected on the IPSec policy assigned to the servers, so that traffic could be sent unsecured to the servers. This configuration allowed server administrators to identify and troubleshoot authentication problems, while providing an option to restore connectivity to the servers. To restore connectivity, the administrators stopped the IPSec service on the client, not on the server.
To determine which domain members had not received Active Directory-based IPSec policy, which clients were not domain members, and on which clients the IPSec service was stopped for other reasons, administrators used the IP Security Monitor snap-in that is available in Microsoft Management Console (MMC) to identify clients that had established soft SAs (non-IPSec-secured communication) with servers.
Fall Back to Clear and Inbound Passthrough Configuration for Final Deployment
On some servers, the IPSec policy used for final deployment was configured so that the Accept unsecured communication, but always respond using IPSec check box was cleared. Accordingly, those servers would not accept unsecured traffic. However, the Allow unsecured communication with non-IPSec aware computers check box was left selected so that these servers could initiate connections to computers that were not configured to use IPSec (for example, Internet proxy servers).
Note For this behavior to be implemented, computers must be running Windows 2000 Service Pack 3 or later, Windows XP Service Pack 1, or Windows Server 2003. On computers running Windows 2000 or Windows XP without an appropriate service pack installed, when you clear the Accept unsecured communication, but always respond using IPSec check box and select the Allow unsecured communication with non-IPSec-aware computers check box, then unsecured traffic is still accepted. This behavior occurs because, when the Allow unsecured communication with non- IPSec-aware computers check box is selected, IPSec processes the associated inbound filter as an inbound passthrough filter (the same behavior that occurs when the Accept unsecured
communication, but always respond using IPSec check box is selected).
On computers running Windows 2000 or Windows XP with an appropriate service pack installed, or on computers running Windows Server 2003, when you select the Allow unsecured
communication with non-IPSec-aware computers check box, IPSec does not process the associated inbound filter as an inbound passthrough filter. Therefore, these two settings result in independent actions, and they behave in a consistent way on computers running Windows 2000, Windows XP with an appropriate service pack installed, and Windows Server 2003.
To communicate with the servers, clients in the Microsoft corporate network were required to have an IPSec policy assigned and to have successfully authenticated and negotiated security with the server. On these clients, the IPSec policy used for final deployment was configured so that the Allow unsecured communication with non-IPSec aware computers check box was selected and associated with the filter for the servers. This policy allowed clients to request to negotiate security with IPSec-secured servers but to fall back to clear if the servers did not respond to the clients’ requests. As a result, clients could establish connectivity with servers even when IPSec was disabled on those servers.
Foundstone performed penetration testing for servers that were configured to accept unsecured inbound traffic but to not fall back to clear and on servers that were configured to not accept unsecured inbound and to not fall back to clear. In both cases, Foundstone was unable to
compromise the security that IPSec provided. Keep in mind, though, that if you select the Accept unsecured communication, but always respond using IPSec check box on a server, then IPSec does not secure inbound traffic. When this configuration is used, an unauthenticated attacker might be able to mount successful inbound denial-of-service and buffer overflow attacks against ports that are open on the server and against other parts of the TCP/IP stack. Likewise, if you select the Allow unsecured communication with non-IPSec-aware computers check box on a server, an attacker might be able to mount an attack from the computer that is not secured by IPSec when an active, soft SA between that computer and the server is established.