Windows XP Professional supports two methods of securing and controlling the transmission of IP packets: Internet Protocol security (IPSec), an industry-defined set of standards that verifies, authenticates, and optionally encrypts data at the IP packet level; and TCP/IP filtering, which controls the ports and packet types for incoming local host data. Either or both of these methods can be implemented on the same Windows XP Professional based client.
IPSec might be enabled for the Windows XP Professional based computer by using local policies, or implemented by using Group Policy objects in Active Directory within an enterprise environment. If implemented locally, built-in or custom policies created by using the IP Security Policy Management snap-in can determine the rules required for secured communications with other hosts. For more information, see Configuring IPSec Policies later in this chapter.
You can also restrict the type of IP traffic that can be received by a Windows XP Professional based computer as the destination. TCP/IP packet filtering can be used to limit packet reception by TCP or UDP port, or by IP protocol. For more information, see TCP/IP Filtering later in this chapter.
The need for IP-based network security is almost universal in the interconnected business world of the Internet, intranets, branch offices, and remote access. Because sensitive information constantly crosses the networks, the challenge for network administrators and other information service professionals is to ensure that this traffic is:
Safe from data modification while in transit.
Safe from viewing.
Safe from being impersonated by unauthenticated parties.
Safe from being captured and replayed later to gain access to sensitive resources; typically, an encrypted password can be used in this manner.
These security services are known as data integrity, data confidentiality, data authentication, and replay protection.
IP does not have a default security mechanism and IP packets are easy to read, modify, replay, and forge. Without security, both public and private networks are susceptible to unauthorized monitoring and access. While internal attacks might be the result of minimal or nonexistent intranet security, risks from outside the private network stem from connections to both the Internet and extranets. Password-based, user access controls alone do not protect data transmitted across a network.
As a result, IPSec was designed by the Internet Engineering Task Force (IETF) to supports network-level data authentication, data integrity, data confidentiality, and replay protection. IPSec integrates with Windows 2000 and Windows XP Professional security to provide the ideal platform for safeguarding intranet and Internet communications. It uses industry-standard encryption algorithms and a comprehensive security management approach to provide security for all TCP/IP communications on both sides of an organization s firewall. The result is an end-to-end security strategy for Windows 2000 and Windows XP Professional that defends against both external and internal attacks.
IP security is deployed below the transport layer, sparing network managers the difficulty and expense of trying to deploy and coordinate security one application at a time. By deploying Windows XP Professional and Windows 2000 IPSec, network managers provide a strong layer of protection for the entire network, with applications automatically inheriting security from IPSec-enabled servers and clients.
Without security measures in place, data might be subjected to an attack. Some attacks are passive; that is, the information is simply monitored. Others are active, meaning that the information is used or altered with intent to corrupt or destroy the data or the network itself. Table 21-3 shows some common security risks found in networks and prevention methods using IPSec.
Attack Type | Description | IPSec Prevention Method |
---|---|---|
Eavesdropping (also known as sniffing or snooping) | Monitoring of plaintext or unencrypted packets. | Data is encrypted before transmission, preventing access to the original data even when the packet is monitored or intercepted. Only the peers have knowledge of the encryption key. |
Data modification | Alteration and transmission of modified packets. | Data hashing attaches a cryptographic checksum to each packet, which is checked by the receiving computer to detect modification. |
Identity spoofing | Use of constructed or captured packets to falsely assume the identity of a valid address. | The Kerberos V5 authentication protocol, public key certificates, or preshared keys authenticate peers before secure communication begins. |
Denial-of-service | Preventing access to a network server by valid users. An example is to flood the network or server with traffic. | Ports or protocols can be blocked. |
Man-in-the-middle | Diversion of IP packets to an unintended third party, to be monitored and possibly altered. | Authentication of peers. |
Known-key | Used to decrypt or modify data. | In Windows XP Professional, cryptographic keys are periodically refreshed, reducing the possibility that a captured key can be used to gain access to secure information. |
Application layer | Mainly directed at application servers, this attack is used to cause a fault in a network s operating system or applications, or to introduce viruses into the network. | Because IPSec is implemented at the network layer, packets that do not meet the security filters at this level are never passed to applications, protecting applications and operating systems. |
IPSec prevents attacks, described in Table 21-3, by using cryptography-based mechanisms. Cryptography allows information to be transmitted securely by hashing and encrypting the information.
A combination of an algorithm and a key is used to secure information:
The algorithm is the mathematical process by which the information is secured.
A key is the secret code or number required to read, modify, or verify secured data.
IPSec uses a policy-based mechanism to determine the level of security required during a communications session. Policies can be distributed throughout a network by means of Windows 2000 based domain controllers, or created and stored locally within the registry of a Windows XP Professional based computer.
Before the transmission of any data, an IPSec-enabled computer negotiates the level of security to be maintained during the communications session. During the negotiation process, the authentication method is determined, a hashing method is determined, a tunneling method is chosen (optional), and an encryption method is determined (also optional). The secret authentication keys are determined locally at each computer by using information that is exchanged at this time. No actual keys are ever transmitted. After the keys are generated, identities are authenticated, and secured data exchange can begin.
The resulting level of security can either be low or high, dependent upon the IP security policy of the sending or receiving computer. For example, a communications session between a Windows XP Professional based computer and a non-IPSec-aware host might not require a secure transmission channel. Conversely, a communications session between a Windows 2000 based server containing sensitive information and an intranet host might require high security.
These seven steps, as shown in Figure 21-3, demonstrate a typical implementation of IPSec.
An application on Computer A generates outbound packets to send to Computer B across the network.
The IPSec driver on Computer A determines that communications with Computer B must be secured.
Computer A begins security negotiations with Computer B. The two computers negotiate the use of a shared, secret key, using the Internet Key Exchange (IKE) protocol. The same shared cryptographic key is determined independently at both ends without being transmitted across the network.
The IKE negotiation establishes two types of agreements, called security associations (SA), between the two computers. One type specifies how the two computers trust each other and protects their ongoing negotiation. The other type specifies how to protect a particular type of application communication.
After the IKE negotiation is complete, the cryptographic key is passed by IKE to the IPSec driver. The IPSec driver on Computer A hashes the outgoing packets for integrity, and optionally, encrypts them for confidentially. It transmits the packets to Computer B.
Routers and servers along the network path from Computer A to Computer B do not require IPSec. They pass along the packets in the usual manner.
The IPSec driver on Computer B checks the packets for integrity and decrypts their content if necessary. It then transfers the packets to the receiving application.
Figure 21-3: Establishing an IPSec session
IPSec provides encryption of outgoing IP packets, but at the cost of local computer performance. The encryption and decryption of packets is a processor-intensive task. Consequently, the encryption and decryption of a large amount of IP packets can place significant demands on the workstation.
Alternately, you can offload cryptographic processing to the network adapter. Many network adapters include onboard processors that can perform tasks otherwise performed by the computer s central processor, including packet encryption. Consult the product documentation for your network adapter to see if it supports encryption-processing offload.
IPSec policies, rather than applications, are used to configure IPSec services. The policies provide variable levels of protection for most traffic types in most existing networks.
There are two storage locations for IPSec policies:
Active Directory
The registry on a local computer.
A network security administrator can configure IPSec policies to meet the security requirements of a domain, site, or organizational unit for an Active Directory domain. IPSec policy can also be implemented in a non-Active Directory domain environment by using local IPSec policies.
IPSec policies are based on your organization s guidelines for secure operations. For more information about planning, creating, and implementing IPSec policies on a Windows 2000 based domain controller, see Windows 2000 Server Help.
For an organization that chooses to implement IP security, creating and assigning IP security policies at the domain level provide the most efficient method of controlling enterprise security policy. Windows 2000 Server and Windows XP Professional offer an administrative interface, the IP Security Policy Management snap-in, to create and administer security policies. An IP security administrator can create security policies at varying levels of granularity from the site, domain, or organizational unit.
After an IPSec policy is created, it can be assigned to a specific container. For example, if Computer A is a member of an organizational unit (OU) that has a IPSec policy applied to it, the IPSec policy for the OU is automatically applied at startup. No user intervention is required. By using domain-based policies, you ensure that the proper security is always implemented at user s computer, overriding the local IPSec policies.
When a computer that is normally a member of a Windows 2000 domain is temporarily disconnected, the domain-based IPSec policy information is cached in the local registry.
IPSec policy precedence is identical with that of other Group Policy settings. In a domain, Group Policy is applied hierarchically from the least restrictive object, such as a site, to the most restrictive object, such as an organizational unit (OU).
For more information about Active Directory and Group Policy, see Active Directory and Desktop Configuration Management in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit.
Local IPSec policies can be selected and stored locally on a Windows XP Professional based computer. This can be done to implement local IP security in the following situations:
The computer is a member of a Windows 2000 domain that does not implement IPSec policies.
The computer is a member of a Windows NT 4.0 domain.
The computer is part of a workgroup.
The computer is not a member of a local domain or workgroup, but is connected to other hosts by means of an enterprise intranet or the Internet.
By implementing local IP security, the Windows XP Professional based computer can secure IP packets based on the security policy stored in its registry. Three preconfigured local IPSec policies are provided at system installation: Client (Respond Only), Server (Request Security), and Secure Server (Require Security). Table 21-4 describes the attributes of each of these default security policies.
Policy Name | Security Requirements | Attributes |
---|---|---|
Client (Respond Only) | Low | Enables a Windows XP Professional based computer to respond to requests for secured communications. Unsecured communications can be used with non-IPSec hosts. |
Server (Request Security) | Moderate | Enables a Windows XP Professional based computer to accept unsecured communications, but attempts to establish a secure channel by requesting security from the sending host. Communications are unsecured if the requesting host is not IPSec-enabled. |
Secure Server (Require Security) | High | Requires that all communications with Windows XP Professional based computers are secure. All unsecured incoming communications are discarded, with the exception of an initial incoming communication request, and all outgoing communications are secured. |
The default security policies are intended to provide an example. They are not designed for operational use without modification. A knowledgeable IPSec network administrator or advanced user should design new, custom polices for operational use. You must have administrative privileges to assign or change IPSec policies.
By default, no local IPSec policies are assigned. To assign one of the default local IPSec policies, right-click the policy in the IP Security Policy Management snap-in, and then click Assign.
The IP Security Policy Management snap-in allows you to perform the following tasks:
Create and manage local and domain-based IPSec policies.
Manage IP filter lists and filter actions.
Restore default IPSec policies.
Import and export IPSec policies.
To create a console with the IP Security Policy Management snap-in, perform the following steps while logged on to an account with administrative rights.
To install the IP Security Policy Management snap-in
Click Start, and then click Run.
In the Run dialog box, type mmc, and then click OK.
On the File menu, click Add/Remove Snap-in.
Using the Standalone tab of the Add/Remove Snap-In dialog box, click Add.
In the Available Standalone Snap-ins box, select IP Security Policy Management, and then click Add.
In the Select which computer or domain this snap-in will manage dialog box, select the option that matches the security policy environment to be managed by your computer.
You can manage the security policy of a computer (as stored in its registry), the IP security policy of the local domain or another domain (if appropriate permissions are granted), or manage the local security policy of another computer, as stored in the registry of that computer.
Click Finish, click Close, and then click OK.
New IPSec policies can be created by selecting Create IP Security Policy from the Actions menu of the IP Security Policy Management snap-in, or by right-clicking the IP Security Policies on Local Computer in the console tree, and then selecting Create IP Security Policy. This action starts the IP Security Policy Wizard.
The IP Security Policy Wizard prompts you for the information needed to configure the new policy. The following information is required:
Policy name and description
Application of default response rule
A security rule determines how IPSec policy secures communication. Selecting this option ensures responses to requests for secure communications. Additional rules can be created by editing the IPSec policy.
Authentication method for default response rule
An authentication method for the two computers must be determined before secure communications can begin. Use this option to select the method of authentication for the default response rule, if chosen:
Kerberos V5
Certificate-based
Preshared key
For more information about IPSec policy and rule creation, see Windows XP Professional Help and Support Center.
Windows XP Professional includes support for TCP/IP filtering. TCP/IP filtering allows you to specify exactly which types of incoming IP traffic are processed as the destination for each IP interface. This feature is designed to isolate the traffic being processed by Internet and intranet clients in the absence of other TCP/IP filtering provided by IPSec, the Routing and Remote Access service, or other TCP/IP applications or services. TCP/IP filtering is disabled by default.
TCP/IP filtering is a set of input filters for non-transit TCP/IP traffic (traffic destined for the local host). Non-transit traffic is traffic that is processed by the host because the destination IP address of inbound IP datagrams is directed to an assigned interface address, appropriate subnet broadcast address, or multicast address. TCP/IP filtering does not apply to transit or routed traffic that is forwarded between interfaces.
A packet is accepted for processing if it meets one of the following criteria:
The destination TCP port matches the list of TCP ports. By default, all TCP ports are permitted.
The destination UDP port matches the list of UDP ports. By default, all UDP ports are permitted.
The IP protocol matches the list of IP protocols. By default, all IP protocols are permitted.
It is an ICMP packet.
You cannot filter ICMP traffic by using TCP/IP filtering. If you need ICMP filtering, configure IP packet filters by using Routing and Remote Access. For more information, see Unicast IP Routing in the Internetworking Guide of the Microsoft Windows 2000 Server Resource Kit.
Note | Protocols that are members of the TCP/IP protocol suite are frequently referred to simply as IP Protocols. |
To configure TCP/IP filtering
In Control Panel (default view), click Network and Internet Connections.
Click Network Connections.
In Network Connections, right-click the local area connection you want to modify, and then click Properties.
On the General tab, click Internet Protocol (TCP/IP) in the list of components, and then click Properties.
Click Advanced.
Click the Options tab, click TCP/IP filtering, and then click Properties.
In the TCP/IP Filtering dialog box, select the Enable TCP/IP Filtering check box and then add the numbers of all TCP and UDP ports and all IP protocols for which you want filtering enabled.
Click OK.
TCP/IP filtering can be enabled and disabled for all adapters by selecting a single check box. This helps troubleshoot connectivity problems that might be related to filtering. Filters that are too restrictive might unnecessarily limit connectivity options. For example, if you decide to allow only specific types of UDP traffic and do not include RIP (UDP port 520), then the RIP Listener service does not function.