Server and Domain Isolation Using IPsec and Group Policy
Chapter 2: Understanding Server and Domain Isolation
In the time since local area networks (LANs) became prevalent, information technology (IT) professionals have struggled to provide resilient, highly available services while maintaining adequate security. Many different technologies have been introduced to work with TCP/IP to address the issue of implementing security at the network and transport layers. These technologies include IPv6, 802.1X, network switches, virtual LAN (VLAN) segmentation, Internet Protocol security (IPsec), and many more. The unintentional result of the introduction of these technologies is a multi-layered approach to network security. These layers can be used to separate, segment, or isolate one or more hosts or networks from other hosts or networks. The purpose of this chapter is to organize the layer of security that IPsec provides with respect to other layers and explain how it is used with Group Policy in a solution that will achieve isolation in a manageable and scalable manner in an enterprise-class environment. On This PageChapter PrerequisitesBefore using the information provided within this chapter, you should be completely familiar with the following concepts and technologies. Although you might benefit from this guidance without meeting these prerequisites, a successful implementation will be far more likely if you meet all these prerequisites. Knowledge PrerequisitesFamiliarity with Microsoft® Windows Server™ 2003 is required in the following areas:
Note Chapter 6, "Deploying IPsec," of the Windows Server 2003 Deployment Kit discusses certain scenarios for IPsec transport mode that were not recommended at the time. However, the work that Microsoft has done for its own internal deployment of IPsec, along with the availability of additional guidance, means that the recommendation can now be changed. While multicast and broadcast traffic still cannot use IPsec, all types of unicast IP traffic should be able to be secured with IPsec. Each customer must evaluate the benefits of deploying IPsec in domain or server isolation scenarios against the costs, impact, and other tradeoffs. However, Microsoft now recommends and supports the wider use of IPsec on customer networks in accordance with this guidance. Organizational PrerequisitesPlanning the security for an organization is unlikely to be the responsibility of a single individual. The information that is necessary to determine the exact requirements for an organization will often come from a number of sources within the organization. You should consult with other people in your organization who may need to be involved in the isolation planning, including those people who perform the following roles:
Note Depending on the structure of your IT organization, these roles may be filled by several different people, or fewer people may span several roles. The scope of a server and domain isolation project requires a comprehensive team to understand the business requirements, technical issues, user impact, and the overall project process. It is often beneficial to have a high-profile individual who can act as the primary point of contact for this project when wider input is required, such as with the support staff or the users who will be affected during the deployment. Two leading causes of failure in complex projects are poor planning and poor communications. The project team must understand these potential risks and ensure that steps are taken to mitigate them. Who Should Read This ChapterThis chapter is designed for technical decision makers and technical architects who will be responsible for designing a customized server and domain isolation solution for an organization. Technical understanding of both the technologies involved and the organization's current infrastructure is required to obtain the greatest benefit from this chapter. Business RequirementsIt is important to understand that the business requirements of your organization should drive the solution. Isolation is defined as a logical or physical separation of one or more computers from network communication with other computers. Security restrictions will always have an impact on the day-to-day operations of employees within an organization. The changes introduced as part of the solution will alter the way that computers in the domain communicate with one another and with untrusted computers. This solution will require time for a project team to plan and investigate feasibility and will also require training of IT support staff and the provision of, at least, a minimal employee awareness program. The additional security services being provided for network traffic may also require additional server memory or hardware acceleration network cards in some cases. Also, other solutions may be available to accomplish the same or similar isolation goals. Therefore, it is important to assess the monetary value that the solution is intended to deliver to the business. Ensuring Regulatory ComplianceAs more personal information is stored on computers, the focus on data privacy has also increased. Controlling access to customer and employee information is no longer just good business practice. Depending on the local laws for the countries in which it operates, an organization that fails to protect confidential information can be open to significant financial and legal liability. For example, organizations that operate in the United States may need to meet the requirements of one or more of the following regulations:
HIPAA has a security rule that specifies strict guidelines about how healthcare organizations must handle electronic personal healthcare information (ePHI). Although HIPAA does not mandate or recommend specific technology, it does specify what capabilities are required for compliance and how to mitigate risks to ePHI. You should evaluate the use of domain or server isolation with IPsec protection as a technical safeguard to help address requirements of the following HIPAA sections:
Frequently, you can meet these requirements by using Secure Sockets Layer (SSL) and Transport Layer Security (TLS). For example, applications can use Microsoft .NET technology with SSL/TLS to help meet HIPAA security regulations. See the white paper "Healthcare Without Boundaries: Integration Technology for the New Healthcare Economy". However, application communications must properly integrate SSL/TLS usage and algorithm controls. The main advantages of an IPsec isolation solution are that it protects all applications as well as the host computer operating system and can provide network traffic security for existing applications without changing them. For more details, see the "Comparison of SSL/TLS and IPsec" section later in this chapter. Compliance of This Solution with U.S Government RegulationsOn December 16, 2003, the U.S. Office of Management and Budget (OMB) released a memorandum on the subject of "E-Authentication Guidance for Federal Agencies," which is available as a PDF file format. This memorandum specifies that the level of risk of an authentication compromise corresponds to the level at which electronic authentication (e-authentication) is required. NIST Special Publication 800-63, "Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology," identifies the technical requirements of authentication levels 1-4. In many cases, strong levels (3 and 4) of user authentication require applications to be rewritten or replaced. If the overall security risks can be reduced, you can use a less costly level of user authentication for access to highly sensitive information. On the Windows platform, server and domain isolation solutions add an initial layer of trusted computer authentication, access controls, network traffic authentication, and encryption prior to user authentication at the application layer. Thus, using a server and domain isolation solution might reduce or delay the requirement for application changes and help comply with risk management mandates. To enable compliance with government regulations for information assurance products, Microsoft is committed to several certification processes. Windows 2000, Windows XP with SP2, and Windows Server 2003 with SP1 have been certified to meet the Common Criteria for IT Security Evaluation (ISO Standard 15408) evaluation assurance level 4 (EAL4) augmented with ALC_FLR.3 Systematic Flaw Remediation. This certification applies to both the operating system and sensitive data protection categories. Also, Windows 2000, Windows XP, and Windows Server 2003 IPsec cryptographic components have been certified to meet FIPS 140-1 cryptographic requirements. Thus, server and domain isolation solutions can be used in military, government, and related IT environments. For more information, see the following links:
The information that this section provides is specific to organizations operating in the United States. However, related regulation is emerging all over the world, as demonstrated by statutes such as the European Union Data Protection Directive of 1998 and Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), both of which impose strict guidelines regarding identity management and data privacy. Business Risk Assessments of IT InfrastructureBusiness risk assessments should identify how the business is dependent on the IT infrastructure. An IT security risk assessment should identify and prioritize risks to the integrity of information and stability of services. The security risk assessment should provide clear justification for why these risks must be addressed and should estimate the costs associated with not addressing the risks. The cost estimates are extremely important for evaluating different technical solutions for each problem. Because no single solution will address 100 percent of the risk, compare each solution against the others and their associated costs. Decision makers may want to evaluate the cost of an isolation solution in terms of how it will reduce the risk of degraded or lost service due to network propagation of virus and worm infections. For some organizations, the business impact and costs of a successful hacker attack against their high-value data are of more concern. Note In some countries and states, laws require that all security breaches be reported to customers that may be affected. Refer to your local government agencies or legal counsel for specific legislative issues that pertain to your organization. Consider the following categories as a guide for estimating the total cost of a security incident:
Invest in Long-Term Directions for Information SecurityThe Microsoft Network Access Protection (NAP) initiative establishes the long term direction to firmly control policy compliance of devices connecting to the network and to one another. Remote access quarantine and server and domain isolation are two parts of this direction that can be implemented now with current Windows 2000 and later platforms. By combining both perimeter and internal isolation capabilities, the organization has significant defenses against infection and other attacks from untrusted computers and from compromised user credentials. For more information about the NAP initiative, see the Network Access Protection Web site. For more information about virtual private networking (VPN) and quarantine access controls, see the Virtual Private Networks Web site. In future releases of Windows, Microsoft plans to deliver more manageable and comprehensive network access protection. For more information, see the "Introduction to Network Access Protection" white paper. Identifying Trusted ComputersA discussion of trust and how it relates to computers is an important part of the topic of server and domain isolation. At its core, isolation is the ability for any particular trusted host to decide who can have network-level access to it. Thus, regardless of how the remote computers are connected at the remote end of the connection (for example, wireless, LAN, Internet), the remote computer must use IPsec to negotiate trust and to secure TCP/IP traffic end-to-end with the destination computer. This end-to-end security model provides a level of protection of network communications that other link-based network access control and security technologies cannot (for example, VPN, 802.1x, 802.11 WEP). There is significant value in trusting the remote computer first to protect against stolen, compromised, or misused user credentials. In the context of this solution, trust is the ability for an organization to be reasonably assured that a particular computer is in a known state and that it meets the minimum security requirements that the organization has agreed on. These requirements can be technical in nature, security-focused, business-related, or any combination. These requirements also dictate the state that a computer should be in before establishing communications with other computers. Microsoft recommends that the specification for trusted computers includes a regularly updated list of security updates and service packs that are required. Ideally, you should manage and enforce these updates by using a patch management system such as the Windows Update Service or Microsoft Systems Management Server (SMS). How frequently these updates are applied will depend on the length of time your organization needs to test and deploy each update. However, for optimal security, you should apply updates as soon as is possible for your environment. Untrusted computers are computers that cannot be assured of meeting these security requirements. In general, a computer is considered untrusted if it is either unmanaged or unsecured. The purpose of the server and domain isolation solution is to mitigate the risk posed to trusted resources by implementing tools, technologies, and processes that will safeguard the organization's assets. The solution ensures that:
You should allow trusted resources, by default, network-level access only from other trusted resources. In addition, control access at the network layer by using permit or deny permissions and ACLs for specific users and computers within the trusted environment. By creating this trusted environment and restricting the permitted communications inside and outside of this environment, the business can reduce the overall risk to its data assets. Additional business benefits may include:
For example, in the Woodgrove Bank scenario, trusted computers include all computers running Windows 2000 Service Pack (SP) 4, Windows XP SP2 or higher, or Windows Server 2003 or later in any of the domains that Woodgrove owns and manages. In addition, trusted assets, which include all computers running Windows 2000 or later that use Group Policy to provide security settings, are periodically examined by IT staff to ensure that they continue to meet the minimum requirements. IT also examines trusted assets to ensure that the installation and configuration of specialized security software (such as antivirus software) is centrally controlled according to Woodgrove's own security requirements. For more information about which computers are considered trusted within the context of the solution, see the "Trust Determination" section of Chapter 3, "Determining the Current State of Your IT Infrastructure," in this guide. Unmanaged ComputersAn unmanaged computer is one whose security settings the IT department does not centrally control. In addition, a computer that does not provide the required security management capabilities is also considered unmanaged. Unmanaged computers are considered untrusted because the organization cannot be assured that they will meet the security requirements of the trusted computers they seek to access. Unsecured ComputersUntrusted computers also include those computers that use an operating system that has not or cannot be configured to the required level of security. Unsecured computers may fall into one of the following four groups:
Those devices that fall into one of these four groups are categorized as untrusted because the organization cannot be certain that they have not been compromised in some manner. Therefore, they represent a significant risk to the trusted computers that they attempt to access. Goals Directly Achievable Using Server and Domain IsolationOverall, the goal of server and domain isolation is to mitigate the threat posed by unauthorized access to a trusted computer by an untrusted computer. With current platforms, the ability to isolate a remote computer by restricting inbound network access is based on the ability to successfully authenticate as a domain member computer using the IPsec Internet Key Exchange (IKE) security negotiation protocol. User authentication is involved only after successful computer authentication has been achieved and IPsec security associations protect all upper layer protocol and application connections between the two computers. Thus, you can achieve the following goals by using server and domain isolation:
Server and domain isolation seeks to protect all network services on the trusted host from untrusted network access and attacks. Server and domain isolation makes hosts less vulnerable to weaknesses and mistakes in the other types of network-based security, and to weaknesses in user credential protection. Lastly, server and domain isolation solutions address similar network threats but provide different levels of network access control and traffic protection than other types of network-based security technology. For example, a server and domain isolation solution can authorize inbound access for specific trusted host computers based on host and user domain identity, thus ensuring end-to-end protection for that authorized communication. Most network-based security technologies, however, only support the user identity. Risks Addressed Using Server and Domain IsolationThe number one risk that server and domain isolation addresses is the risk posed by unauthorized access to a trusted computer by an untrusted computer. Certain security risks cannot be mitigated fully using the solution alone. Failure to address these security risks with additional security processes and technology could ultimately negate the security benefits of the isolation solution. Examples of serious security risks that will not be directly mitigated by this solution include:
To address these issues, the recommended security hardening configurations and templates were applied to all systems in the Woodgrove lab environment. For more information about Windows platform security technologies and management procedures, see the TechNet Security Center. How Does Server and Domain Isolation Fit into My Overall Network Security Strategy?Server and domain isolation is employed in addition to other proactive and reactive mechanisms to defend the network and its connected devices, including computers. Because security is a multi-faceted problem that requires multiple layers, it is helpful to review the concept of defense-in-depth and the high-level ideas behind it. A comprehensive network security strategy applies the appropriate technologies to mitigate the highest priority risks without significant dependence on single points of failure. For example, if perimeter security failed due to a misconfiguration or a malicious employee, what other layer of defense would stop network attacks and infections on internal trusted hosts? What stops attacks on all trusted hosts in Europe or Asia when the attacker connects to the Ethernet port in a conference room in any U.S. office? Defense in DepthDefense in depth is best described as a layered approach to protecting a computer instead of reliance on a single mechanism for that protection. To successfully layer defenses, it is necessary to first understand the infection sources and adversaries who stand ready to attack an organization, as well as to have some idea what their targets might be. For example, an adversary could be a competitor who hires a corporate espionage firm to steal information about a new product or service that is under development. After gaining an understanding of the attackers and their possible targets, it is then necessary to apply incident response procedures for computers that could be compromised. These methods include authentication, authorization, confidentiality, and non-repudiation. An organization that follows the industry best practice of protect-detect-react realizes that attacks will occur and understands that detecting them quickly and minimizing service interruptions or loss of data is paramount. Practicing protect-detect-react makes it possible to recognize that because the probability of an attack is high, more effort should be spent on protecting data and assets rather than on preventing an attack from occurring. Generally speaking, it is more cost-effective to defend against an attack than it is to clean up after one has occurred. All information assurance mechanisms focus on people, processes, and technologies. Isolation involves all three of these areas: it is achieved through a thorough understanding of the risks, requirements, and assets that demand protection, an understanding that encompasses the people and process elements. In addition, isolation requires knowledge of the current state of the network and its devices, the communication requirements that define how computers should interact with one another, and the security requirements that may limit those requirements to achieve the appropriate balance between security and communication. A more detailed discussion of this subject can be found in the U.S. National Security Agency's “Defense in Depth” white paper in PDF format. For information and practical design examples for this process, see the Enterprise Design chapter of the Security Architecture Blueprint within the Windows Server System Reference Architecture. The following figure illustrates how a logical isolation solution would fit into the defense-in-depth approach used in the Windows Server System Reference Architecture: One important point to understand from this figure is that the logical isolation layer of security is aimed directly at securing the host computer through controlling network communications. This role is most similar to that of a host-based firewall. However, instead of the host firewall providing permit and block services for ports, IPsec provides permit and block services and negotiates trusted network access services. After access is granted, IPsec can secure all packets between the two computers. As defined within the context of this solution, a "logical isolation" solution such as server and domain isolation:
You should consider security at each layer as part of IT security risk mitigation analysis. For example, if a certain computer is not allowed access to a server at the logical isolation layer, it does not matter which user logs on at that computer. Any users—even an administrator—will be denied access to the server. Comparison of SSL/TLS and IPsecIPsec is not intended as a replacement for application level security, such as SSL/TLS. One of the advantages of using IPsec is that it can provide network traffic security for existing applications without having to change them. Using IPsec in environments in which applications use SSL/TLS can provide the following benefits:
IPsec secures traffic between source and destination IP addresses. SSL/TLS can secure traffic through the entire application path (for example, from a Web browser through a Web proxy to a Web server). The National Institute for Standards and Technology (NIST) is developing guidance on using TLS. Special Publication 800-52, "Guidelines on the Selection and Use of Transport Layer Security," is a guideline for implementing TLS in the federal government. For more information about this guidance, see the NIST Computer Security Division Web site. Similar guidelines do not exist for the use of IPsec. However, the U.S. National Security Agency has released guides for using Windows 2000 IPsec. These guides are available from the NSA Security Recommendation Guides download site. Organizations that need to meet NSA guidelines should evaluate the design of this solution in addition to the NSA guides. IPsec with certificate authentication provides protection that is similar to SSL/TLS, but there are some differences. Windows IPsec supports a small subset of the cryptographic algorithms supported by TLS and recommended by NIST 800-52 (for example, 3DES, SHA-1, and 1024-bit ephemeral Diffie-Hellman). The solution presented in this guide uses Kerberos protocol signatures for IKE authentication between domain members instead of certificate-based signatures. Windows IPsec IKE negotiation establishes mutual trust between computers using the Kerberos protocol and certificate-based authentication. Because IKE is not integrated with applications, it cannot verify that the destination computer name is the one to which the application is expected to connect, thereby allowing a sophisticated man-in-the-middle attack from another trusted host. But because the application integrates with SSL/TLS, the destination name is not only authenticated (trusted), the name can also be verified against the name that was expected. Terminology RefresherBefore continuing with this chapter, it would be a good idea to review a number of the terms that are often used in the context of this solution. If you are already familiar with these terms, you can skip this section. However, if you do not understand these terms adequately, you may find that some of the explanations in this guide will be confusing. Isolation TermsThe following terms are unique to the concept of logical isolation. Ensure that you understand these terms fully before continuing with this chapter:
Security TermsEnsure that you thoroughly understand the following security-related terms:
Network TermsThe following terms refer to the network elements of this solution:
Group Policy TermsThe following terms relate to Windows Group Policy:
Basic IPsec TermsEnsure that you thoroughly understand the following IPsec terms:
Note If you have Inbound passthrough enabled, but not Fall back to clear on a responder, the responder will not successfully communicate with a non-IPsec-aware initiator. Additional terms are important to understand that refer to elements of IPsec specifically. Appendix A, "Overview of IPsec Policy Concepts," of this guide provides an overview of these IPsec terms and explains the overall IPsec process that the computers in the isolation groups created in this solution will use. How Can Server and Domain Isolation Be Achieved?The concept of isolating computers from risk is not new. Techniques such as using firewalls to provide segmentation, applying access control and filtering to routers, and physically segmenting network traffic all provide a level of isolation. The solution presented in this guide is designed to work with the existing devices and techniques in your network infrastructure. The key point is that isolation is implemented by making changes to existing host software in Windows 2000 and later platforms. Technologies and procedures such as network segmentation, VLANs, perimeter network access controls, network quarantine, and network-based intrusion detection are achieved by implementing or changing the configuration of network devices. Server and domain isolation complement all of these existing techniques and provides a new protection level for managed Windows domain members. Windows IT administrators can implement server and domain isolation with little or no change in the existing network paths and connection methods, with little or no change to applications, and with an existing Windows 2000 or Windows Server 2003 domain infrastructure. Server and Domain Isolation ComponentsThe server and domain isolation solution is made up of a number of important components that collectively enable the solution. The following subsections describe these components. Trusted HostsTrusted hosts are computers that the IT organization can manage to meet minimum security requirements. Very often, you can achieve this trusted status only if the computer is running a secure and managed operating system, antivirus software, and current application and operating system updates. After the computer is determined to be trusted, the next component of the solution is to confirm the computer's status through authentication. For more information about determining status, see Chapter 3, "Determining the Current State of Your IT Infrastructure." Note IPsec cannot make any determination of a computer's compliance to particular host criteria by itself. Monitoring technology will be required to determine the computer's baseline configuration and report any changes from that configuration. Host AuthenticationThe host authentication mechanism determines whether the computer attempting to initiate a session has a valid authentication credential, such as a credential from the Kerberos ticket, a certificate, or perhaps a preshared key. Currently there are two technologies that can provide this type of authentication mechanism on Windows-based computers. The following sections explain these two technologies. The 802.1X Protocol802.1X is a standards-based protocol for authenticating users and devices so that they can be authorized to gain connectivity through a link-layer network port, such as an 802.11 wireless link or an 802.3 Ethernet port. This allows for control of the user experience (for purposes such as billing), control of authorization, and additional features. This protocol requires one or more dedicated servers (for example, the Remote Authentication Dial-In User Service [RADIUS]) and a network infrastructure that supports the protocol. 802.1X is designed to provide controls over network access and cryptographic keys for 802.11 Wired Equivalent Privacy (WEP) encryption of wireless traffic between the client and wireless access point. After the device is granted network access, it typically has open connectivity to the rest of the internal network. After data is decrypted at the wireless access point, it is forwarded in normal plaintext TCP/IP form to the end destination, perhaps secured by various application-layer mechanisms. Woodgrove security requires protection of all trusted hosts from untrusted computers on the internal network. Although 802.1X could enforce that only trusted computers be granted access through wireless and some wired links, the switches used for most internal 802.3 Ethernet ports is not capable of 802.1X authentication. A significant hardware purchase and installation cost would be required to upgrade every physical LAN access wall port and all buildings worldwide. Thus, Woodgrove decided to use 802.1X for wireless security, but not for hard-wired Ethernet ports. Another Woodgrove security requirement was to encrypt traffic end-to-end between trusted clients and the encryption servers. 802.1X has not been developed to provide encryption for wired connections, only wireless. Even when wireless connections are encrypted, the data is not protected after packets are forwarded onto the internal LAN after decryption by the wireless access point. Consequently, 802.1X is not able to meet the end-to-end encryption requirement. Although 802.1X does not meet all of Woodgrove's security requirements, it is still used for wireless security. Microsoft recommends 802.1X to secure wireless networks and to provide access control for wired networks where possible. For more information about the use of 802.1X, see Wireless Networking. IPsecIPsec is the IETF standard security protocol for the Internet Protocol. It provides a general, policy-based IP layer security mechanism that is ideal for providing host-by-host authentication. An IPsec policy is defined to have security rules and settings that control the flow of IP traffic inbound and outbound on a host. Policy can be managed centrally in Active Directory using Group Policy objects for policy assignment to domain members. IPsec provides that ability to establish secure communications between hosts. IPsec uses the Internet Key Exchange (IKE) negotiation protocol to negotiate options between two hosts for how to communicate securely by using IPsec. The agreements that two hosts make about how to communicate using IPsec and the various parameters that define this negotiation are called security associations or SAs. The IKE negotiation establishes a main mode SA (also called the ISAKMP SA) and a pair of quick mode SAs (called IPsec SAs—one for inbound traffic, the other for outbound traffic). IKE requires mutual authentication to establish the main mode SA. Windows IKE can use one of the following three methods:
The most common reason for not deploying IPsec is the misperception that it requires public key infrastructure (PKI) certificates, which are often difficult to deploy. To avoid the need for a PKI, Microsoft integrated Windows 2000 domain authentication (Kerberos) in the IKE negotiation protocol. Windows IKE negotiation can be configured to allow communication with a computer that does not respond to the IKE negotiation request. This capability is referred to as Fall back to clear and is a practical necessity during rollout of IPsec. It is useful in normal operations to allow trusted hosts to talk to untrusted computers and devices only when the trusted host initiates the connection request. IPsec uses the term soft security association to describe a communication that IPsec cannot protect with either Authentication Header (AH) or Encapsulating Security Payload (ESP) formats. IPsec logs this communication with a Security Log success audit containing the destination IP address and monitors the traffic flow activity. When traffic flow ceases after an idle time (5 minutes by default), a new attempt to negotiate security is required when new outbound connections are made. IPsec does not support stateful filtering of outbound traffic either for traffic within an AH or ESP security association or for plaintext traffic involved with a soft SA. Thus, when you use the IPsec policy designs presented here for server and domain isolation, the trusted host is able to receive inbound connections from the untrusted computer to any open port through the soft SA. This is a potential window of vulnerability to attack. But it is also a design that supports certain protocols that negotiate open ports to receive inbound connections. Stateful filtering for outbound connections can be added in addition to IPsec protection by using a host-based firewall product, such as Windows Firewall. Network traffic that is protected by IPsec AH or ESP without encryption is not considered to be in plaintext form because it is does have authentication and protection against spoofing and modification. Because IPsec encapsulates normal IP packets in a secure format, the packets no longer appear as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) packets when traversing the network. The attempt to deploy IPsec inside Woodgrove Bank identified that most network management tools assumed that applications can be readily identified by their TCP or UDP port numbers (for example, port 25 for e-mail traffic and port 80 for Web traffic). When you use IPsec, the traffic becomes opaque, and the routers and network intrusion detection system cannot distinguish which application is being used or inspect the data in the packet. This factor creates a network management issue, because it reduces the value of the tools currently used for traffic monitoring, security filtering, weighted fair queuing, and quality of service classification. Unfortunately, the assumption about traffic visibility is not entirely accurate, and it is becoming rapidly obsolete, even in the absence of IPsec. The relationship between port numbers and applications is becoming increasingly weak. It is possible, for example, to run a Web server at an arbitrary port number and to document the port number in the URL of the site. It is also possible to bypass the e-mail filtering efforts of some Internet service providers (ISPs) by running a mail service on an alternate port number. Many peer-to-peer (P2P) applications are port agile; that is, they use port numbers picked at random in an attempt to avoid detection. Applications based on remote procedure call (RPC) services are also port agile, because RPC services pick random ports in the ephemeral range (above 1024) for various services. The increasing use of Web services will likely accelerate traffic identification issues, because the traffic for these services runs on top of HTTP or HTTPS, using either port 80 or port 443. Clients and servers then use the HTTP URL to identify the traffic. All applications that move to a Web service architecture will appear as a single undifferentiated data stream to the routers, because the traffic for these Web services will run on a single port or a few ports instead of each application or service running on its own discrete port number. The use of SSL and TLS for HTTPS connections and RPC encryption decreases the value of network-based inspection as a defense against attacks. Because the network management applications could still analyze the addresses of the packets, and had visibility for all other traffic that was not IPsec-protected, Woodgrove decided that the loss of some network management functionality was not significant enough to affect the plans for the project. Additionally, some network management tool vendors were willing to modify their tools to inspect inside non-encrypted forms of IPsec packets. Most host-based applications do not need to be modified to work properly with IPsec securing all traffic between IP addresses. This solution does not attempt to use IPsec only for specific applications or protocols because of the risk of network attacks on other network services. If applications do not work properly with IPsec, the administrator may be able to choose to permit this traffic outside of IPsec protection based on the IP addresses used for servers. It is not recommended to permit applications based on a well-known port because doing so opens a static inbound hole for attackers to make inbound connections to any open port, defeating the purpose of isolation. Applications that use dynamically allocated ports cannot be permitted outside of IPsec protection. Applications that use multicast and broadcast IP addressing may have problems working with the IPsec design for server and domain isolation. Windows IPsec supports the ability to permit all multicast and broadcast traffic, but not certain types. If there are application compatibility problems, investigate with the vendor to determine whether or when a fix or upgrade will be available to address this issue. If the application cannot be upgraded or replaced with a compatible one, computers that must use this application might not be able to participate in the isolation domain or group. In addition to its authentication capabilities, IPsec can provide two other useful services for host communication: ensuring address integrity and encrypting network traffic:
Note ESP with encryption or using null encryption provides strong IPsec peering relationships with authentication, just like AH. It also provides replay protection and will properly traverse a NAT device. For these reasons, Woodgrove decided not to implement AH and instead uses only ESP/null and ESP with encryption on its corporate network. There are two modes in which IPsec can operate—tunnel mode or transport mode:
For more information about the technical details of both transport mode and tunnel mode in IPsec, see Determining Your IPSec Needs. Host AuthorizationAfter a host determines that the communication it is receiving is from a verifiable source, the host needs to determine whether to allow access to the source computer and user. This step is important, because the fact that a device is capable of authenticating is no guarantee that it is also allowed to access a given host. The approach that Microsoft recommends is to use standard Windows groups to limit the users' and computers' abilities to access the resources on other computers in the design. This method creates a new layer of authorization for both the computer accounts and the user accounts at the network and application level by using permissions on the user rights assignments of the local policy on the host being accessed. Using both the "Access this computer from the Network" (ALLOW) and the "Deny access to this computer from the network" (DENY) user right assignments, it is possible to restrict the ability of a computer and a user to access a resource even though they share common IPsec policy parameters and the logged-on user has the right to access the resource. This extra level of control is fundamental to the isolation approach that this solution describes. The group capabilities of Active Directory organize the computers and users in such a way as to allow the required authorization levels to be assigned in a manageable and scalable manner. To help differentiate the groups that were specifically created to achieve the host access permission from those of the standard share access permissions, this guide uses the term network access groups. The following figure illustrates the main steps in the overall host and user authorization process of the solution. Figure 2.2 shows a five-step process, as detailed in the following list, that is followed for all network communications after the isolation solution is in place.
The use of network access groups makes it possible to achieve an extremely high level of control in the solution. The following scenario provides a practical example of how the steps in the logical isolation solution work: During a meeting, a contractor plugs her mobile computer into a network connection point in a conference room to copy some data to a share on the HR server of an employee. Donna, a member of the HR department, provides the contractor with the path for the share on the HR server. Because the contractor's computer is not a known or trusted host, the IT department does not manage the computer, and the level of security precautions in place on the mobile computer is unknown. So, potentially, the files can contain malware that could infect internal computers. When the contractor's computer attempts to connect to the HR server, the computers fail at step 2 in the process. The computers cannot negotiate an IKE main mode SA because the mobile computer is unable to provide the required Kerberos ticket to allow the computer's credentials to be checked; it is not part of a trusted domain. The IPsec policy requirements of the isolation group that the HR server is a member of do not allow the server to communicate with a host that does not use IPsec, so all communication attempts are blocked from this untrusted computer. In summary, the logical isolation solution helps protect the IT infrastructure from the threat of untrusted and unmanaged computers even if those computers have physical access to the internal network. This example explains how isolation can be achieved on a host-by-host basis. Another important requirement of the solution is to provide isolation at reduced administrative costs. It is possible to group computers in the same manner as you do users and then assign those groups the ALLOW or DENY user rights assignment in each computer's local policy. However, this approach will be difficult to manage and does not scale well without using the centralization capability of Group Policy and Active Directory, and without a thorough understanding of the required communication paths. In addition, this approach alone does not provide strong authentication or the ability to encrypt data. When these host access permissions are coupled with IPsec and the hosts are organized into isolation groups, it is easier to understand the relationships between the groupings and simpler to define the communication paths (after the requirements have been clearly documented). For more information about the design and framework for isolation groups, see Chapter 4, "Designing and Planning Isolation Groups." What Does Server and Domain Isolation Protect Us From?Server and domain isolation are about placing limits on how computers communicate with each other and with devices that attempt to initiate communications. These limits or boundaries are used to restrict communications by depicting the level at which a device is trusted. Placing boundaries such as authentication, authorization, and network location around a host by using IPsec policy is an effective way to mitigate many threats. Although IPsec is not a complete security strategy, it does provide an additional layer of defense in an overall security strategy. The following section describes some typical threats and briefly discusses threat modeling. For more information about trusted devices within the Woodgrove Bank scenario and the design process that Woodgrove used to identify and classify computers as trustworthy, see the "Trust Determination" section of Chapter 3, "Determining the Current State of Your IT Infrastructure." Modeling and Categorizing ThreatsIn recent years, the frequency and complexity of attacks on network-based applications and servers have significantly increased. Interestingly, both the types and styles of attacks and the basic methods used to counter them have remained relatively static. However, some features and methods of implementing these defenses are different. Before you can begin to understand the planning that a server and domain isolation solution requires, your organization should conduct a detailed risk analysis of the threats that are present and how you can counter them by using various technologies and processes. Processes that can identify, categorize, and enumerate threats to an organization have been documented over the years. This documentation often presents a methodology that can be used for modeling common business, environmental, and technical threats to an organization. Microsoft uses the STRIDE method for threat modeling. STRIDE stands for categories of threats to guard against. These categories are: S spoofing T tampering R repudiation I information disclosure D denial-of-service E elevation-of-privilege It is essential that adequate time and resources be devoted to defining as detailed a threat model as possible to ensure protection for all assets that need to be protected. For an explanation of particular threats and attacks that server and domain isolation can help mitigate, see Appendix D, "IT Threat Categories," of this guide. For detailed discussions about threat models, see Securing Windows 2000 Server: Chapter 2, Defining the Security Landscape. How Can We Deploy Server and Domain Isolation?After you gain an understanding of the threats to your organization and realize how the solution mitigates these threats, the next thing to do is to examine the manner in which such a solution can be deployed. This section describes how this deployment process can take place. Information GatheringThe very first step, even before beginning the design process, is to ensure that you have an up-to-date and accurate picture of the current state of your organization's network that includes workstation and server configurations as well as communication paths. It is not possible to develop an effective logical isolation solution without knowing exactly what the solution is expected to protect. Chapter 3, "Determining the Current State of Your IT Infrastructure," provides a detailed explanation and rationale for obtaining information about the current state of your network and the devices on it. This process will provide all of the requisite information for the subsequent chapters of this solution in addition to providing value to other projects undertaken in the organization. Most importantly, it will enable the organization to closely analyze and scrutinize the required communication paths for its information systems and to make informed choices about the compromises that may exist among risk, communication requirements, and business requirements. IPsec Deployment Process OverviewAfter you have decided upon and created a design, the next priority is establishing a process for implementing the design into the organization in a manner that is both manageable and of minimal impact to users. Chapter 4, "Designing and Planning Isolation Groups," discusses in detail a number of different approaches that you can use to achieve this. However, the basic process can be summarized as follows:
Chapter 4, "Designing and Planning Isolation Groups," provides detailed information on the isolation domain design process and presents options for a phased roll out approach to the solution. SummaryThis chapter discussed the goals and processes behind the solution presented in this guide. Although IT professionals have well understood the benefits of IPsec for many years, the complex nature of the technology has led many people to avoid implementations. With IPsec implementation, potential exists for serious consequences if the solution does not have in place a solid design, a well-planned deployment, and a reliable test methodology. The guidance in this chapter should convey that logical isolation is an additional layer of security that uses server and domain isolation techniques with the capabilities of the Windows platform, IPsec, Group Policy, and Active Directory to provide a manageable and scalable enterprise solution that can minimize the risk to which data assets are exposed. The information presented in the remaining chapters focuses on the stages that are required to plan and implement this solution. Chapter 6, "Managing a Server and domain Isolation Environment," provides procedures that you can implement for the day-to-day running of an operational environment that is using server and domain isolation. Chapter 7, "Troubleshooting IPsec," provides supportability and troubleshooting information.
|
In This Article
|
