Objective 3.1: Designing Network Infrastructure Security | MCSE Designing Security for a Windows Server 2003 Network: Exam 70-298

Designing a secure TCP/IP-based network begins with thorough planning. Whether you re designing a new network or upgrading an existing network, the first step is to clearly map out the existing or desired network structure. By knowing where resources are located and what services they require, you ll be able to develop a more secure network infrastructure.

The network infrastructure is comprised of hardware and software elements and has both a physical and logical structure. Hardware clearly includes servers, hosts , and gateways, as well as printers, mobile devices, and even the network cabling specifications (grade, length, connection points). The software side includes operating systems, applications, and services such as Dynamic Host Configuration Protocol (DHCP) and other network protocols, and the NTFS file format, to name a few. The physical structure includes where servers are located in a building or at different locations, how locations are connected, cabling diagrams and the overall physical organization of network resources. The logical groupings include domains, organizational units (OUs), user and computer groups. Although this list is not exhaustive, it gives you an idea of the scope of the elements that should be clearly delineated, listed, inventoried, and mapped out. Once you understand how your network infrastructure is organized, you can begin the task of developing security policies and practices.

The high-level elements involved with designing a secure network infrastructure are:

Plan network security.
Create secure boundaries.
Deploy network security technologies.
Deploy server, application, and user security technologies.
Deploy network monitoring and auditing.

This chapter focuses specifically on how to design network security technologies, and in particular, the Internet Protocol Security protocol (IPSec) to create a secure network from end to end.

Your overall network security plan should include several elements. The first step is to create secure boundaries. This includes both internal and external boundaries in both physical and virtual groupings. Internally, you can place sensitive servers or users with higher security needs on isolated network segments. You can place vulnerable servers in access-controlled locations and strictly limit access to those servers. Externally, you must configure firewalls, perimeter networks, or demilitarized zones (DMZ) to protect your network from external threats. We ll discuss this in more detail when we look at securing wireless networks later in this chapter. The use of firewalls and proxy servers protects the network by physically isolating the corporate network resources from the external network. Through the use of filtering and security policies, access through the firewall is controlled and the chance of intrusion is much lower than without these precautions . With proxy servers, internal network addresses and configuration information is hidden from external view because all authorized traffic in to and out of the company flows through the proxy server. Proxy servers and firewalls serve different but related functions, so in some cases, one server can be configured to serve both functions. External access must be controlled, and monitoring and auditing should be used to keep watch over network security at all times. In addition to these strategies, securing the network includes these best practices:

Physically securing critical network servers, including access-controlled locations, using the NTFS file system format.
Using Encrypting File System (EFS) where appropriate.
Requiring user authentication, strong passwords, and other strong account policies.
Securing network service data traveling on the network.
Securing application and user data traveling on the network.
Securing network access points and network access.

After developing your overall security plan, you need to drill down to design the security for the network infrastructure. Network infrastructure includes those services and protocols used to run network services. This includes DHCP, Domain Naming System (DNS), Windows Internet Naming System (WINS), authentication traffic, and IP traffic, to name just a few. As you know, the Windows operating system uses the TCP/IP suite as the networking protocol. The introduction in Windows 2000 of the IPSec framework made a significant contribution toward securing the network infrastructure. IPSec can be used to secure data and network services traffic across the intranet and across the extranet, including across the Internet. It uses signing, encryption, or both to secure IP packets in a manner that prevents common security problems. Remote access can be secured through creating a virtual private network (VPN) using Layer 2 Tunneling Protocol (L2TP), which uses IPSec to provide secure data transmission across external connections such as the Internet. We ll look at IPSec in detail in this chapter.

As with any security model, you must find a workable balance between security and usability. Typically, the higher the security, the lower the usability. A network that is so secure that users cannot access resources is not particularly useful. By the same token, a network that is so accessible that it s constantly attached is not useful either. An unsecured network creates a significant liability for the firm in terms of exposing corporate or trade secrets, private corporate data, and even user privacy. Finding this balance requires that you take several logical steps to implement the best solution for your firm. These steps include:

Assess the risk to your network and system data and determine the appropriate level of security. Assessing risk means looking at your physical building and network location. Can anyone just walk into the office, or is access controlled? Do visitors have to sign in, or do they roam freely about? Are exterior doors kept locked, or is there a lot of traffic in and out? These are the kinds of assessments you ll need to make about the physical security of your network infrastructure. Another part of the risk assessment is to identify the risk or downside of your company s data being compromised. For example, if you deal with individual health records, compromising that data could have serious legal consequences. The same is true if you re dealing with financial data, human resources data, personal user data such as social security numbers , or even sensitive proprietary or confidential corporate data.
Identify valuable information. Even if your firm deals with sensitive data, it s likely that not all the data is critical and must be secured. It s important to assess what is valuable information and what is not. Certainly , usernames, passwords, and social security numbers would rank high on the list of valuable information that should be protected. Identifying valuable data is key to avoiding over- or under-protecting the network. To determine the need for security, consider the consequences of particular data being stolen by a hacker and published on the Internet. If it would have serious consequences (legal, financial, ethical, organizational), that data needs to be secured. In addition to a balance between security and usability, there is also a balance between securing data and network performance. Every time you choose to secure a particular class of network traffic, you add layers of overhead to the IP packet transmission process that can, in some cases, cause serious degradation of system performance.
Define security policies based on risk. Once you ve assessed risk and identified valuable data, you can define security policies based on that information. Typically, there are three levels of security defined for Windows Server 2003 and the IPSec framework:
- Minimal security There is no sensitive data exchanged and the risks to the system are low. IPSec is not implemented (default setting).
- Standard security Certain computers, including servers, store valuable data and should be secured. Windows XP and Windows Server 2003 use security policies that provide for data security but do not require the highest level of security. Two examples of secure policies that involve standard security are Client (Respond Only) and Server (Request Security). Each of these settings uses the highest security available between the two computers without requiring the highest security. These policies will be discussed in more detail later in this chapter.
- High security If servers store highly sensitive data such as financial data, medical records, or other highly sensitive information, high security should be implemented. This is especially true of data that is transmitted via remote access or via the Internet. The security policy Secure Server (Require Security), a default policy in the high security model, requires IPSec for all traffic being sent or received. Unsecured communication with any computer that cannot use IPSec is not allowed.
Determine how security policies can best be implemented in the enterprise . You can implement security in a number of ways in Windows Server 2003. The preferred method is via IPSec policies that consist of one or more IPSec rules. These rules include:
- Selected filter list
- Selected filter action
- Selected authentication method
- Selected connection type
- Selected tunnel setting
There are essentially two ways to configure IPSec policies. You can create a new policy and define rules for the policy, or you can create a set of filter lists and actions and then create policies. In either case, these policies must then be assigned to a computer, user group , domain, or OU, to name a few. We ll discuss this in more detail later in this chapter.
Ensure security management and technology requirements are available and in place. To create the most secure network infrastructure possible, you should implement Active Directory, which was first introduced in Windows 2000. In addition, you should upgrade as many servers and clients as possible to Windows 2000, at the very minimum, and Windows XP or Windows Server 2003 optimally. This will allow you to use the very latest technologies for implementing and managing security in your environment. In addition, your security management should include organizing computers in similar roles into OUs for better security and ease of administration. OUs are virtual groupings of computers for ease of management and appear as objects within a folder. For example, you can place all application servers into an OU. When designing and implementing security solutions such as security templates and IPSec policies, you can apply these to all computers in an OU, a much easier and more secure method than managing each computer individually.
Provide users with an easy and secure method of accessing the appropriate resources. As mentioned earlier, security is always a fine balance between keeping data secure and allowing legitimate users access to needed data. By implementing security methods such as smart cards, VPN, and IPSec, the security becomes almost entirely transparent to users and still maintains tight security where needed. Higher security almost always means slower response times, because security services require CPU cycles to be processed . Testing and evaluating security measures with realistic loads is an important part of security management. Automating tasks , such as enforcing security policies via group policies, will also reduce problems.

Common Types of Attacks

So far, we ve talked in general terms about what you should consider when reviewing securing network infrastructure. Let s take a moment here to review the common types of attacks. Understanding attacks clearly is the key to implementing needed security technologies for your network.

Many types of attacks can occur, and it seems someone is figuring out another way to attack a secure computer system almost every day. Some of the common methods are eavesdropping, data modification, IP address spoofing, password-based attacks, denial-of-service (DoS) attacks, man-in-the-middle attacks, compromised key attacks, sniffer attacks, and application-layer attacks.

Eavesdropping Eavesdropping occurs when an intruder is monitoring network data and can read any unprotected data that travels across the network.
Data modification An intruder can modify data in a packet without the sender or the receiver ever knowing it.
Identity spoofing (IP address spoofing) IP addresses are used to identify computers on a network. Attackers can assume another computer s IP address and the packet appears to originate from a valid address on the network. This is known as identity spoofing, IP address spoofing, or IP spoofing.
Password-based attack Gaining access to one or more legitimate passwords is like payday for a hacker. Older applications don t always protect password information, and it is sometimes transmitted in clear text.
Brute force attack Hackers can also run programs against user accounts in attempt to derive the password. This is called a brute force attack since the hacker will have to run through every conceivable combination of alpha, numeric, and special characters to find a combination that works with a given user account. One form of brute force attack is a dictionary attack where words from the dictionary are used as the basis for trying to guess legitimate passwords. This is one reason why policies requiring complex passwords prohibit the use of any contiguous combination of letters found in a dictionary.
Denial-of-service attack These attacks don t typically generate data for the hacker, but instead are intended to disrupt the services provided to legitimate users. DoS attacks can cause abnormal application behavior or termination. A DoS attack is sometimes used as a smoke screen to keep IT staff busy while a hacker gets into the network in some other way. Some DoS attacks can cause peculiar computer behavior that results in exposing protected data.
Man-in-the-middle attack This occurs when someone is monitoring, capturing, and controlling data between the sender and receiver. The danger is that each side assumes the other party is the intended party, and data can be exchanged with an interloper without either side s knowledge.
Compromised key attack A key is a secret code or number used to encrypt or decrypt information. If a hacker is able to obtain a key, the hacker can then use that key to compromise other data or network areas. A key that is obtained by a hacker is considered a compromised key.
Sniffer attack A sniffer is a device that can read, monitor, and capture network data as it crosses the wire. When packets are unencrypted, anyone who can monitor data on the network can compromise security.
Application-layer attack This attack targets application servers by deliberately causing the application or server to fail. When this occurs, the attacker might be able to bypass normal security or controls. Once compromised, the application server can be used to spread viruses, introduce a sniffer program to gain further data, disable other security controls for future attacks, or simply delete or modify data on the server, including the operating system, the applications, and data files that reside on the server.
Social engineering Ironically, one of the most common security breaches is caused by social engineering, which occurs when a legitimate user is duped into revealing usernames, passwords, IP addresses, credit card information, or other sensitive data. In recent years , almost everyone with an Internet e-mail account has received at least one e-mail that appears to be from a legitimate source asking for username and password, credit card information, and so forth. This is social engineering and poses one of the greatest security risks. However, in this chapter, we ll focus on the technology-based risks discussed. The best defense against social engineering is really not technology based. Educating users about the risks and the tricks they re likely to encounter is the very best way to protect the network from social engineering threats.

Assessing Risk for Network Services

Now that we ve reviewed the overall security practices and some of the common risks, let s look at some of the common network services that should be assessed for risk and the need for additional security. These are:

Dynamic Host Configuration Protocol (DHCP)
Domain Name Service (DNS)
Windows Internet Naming Service (WINS)
Internet Information Server (IIS)
Routing and Remote Access (RRAS)
Application and file sharing

Each of these services uses the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols for sending and receiving data across the network. It is this data moving along the medium (wire or wireless) that becomes an additional threat to network security, as intruders who gain access to this infrastructure data can compromise the network in a number of ways. When we think of data, we typically think of files or user data. However, network data such as usernames or IP addresses are more common targets of attack because gaining this information is ultimately far more useful in gaining further access to or control of the network. Thus, this data must be evaluated for risk and secured appropriately.

As we discussed earlier, by grouping servers that have similar functions or roles together into OUs, you can more effectively manage common threats. If all DNS servers are placed in an OU, you can apply security measures such as security templates or group policies on all of them. This reduces administration, error, and troubleshooting time. Since an OU is simply a logical grouping, using OUs is the easiest method for managing security for computers. Of course, the flip side is also true ”if you make an error in setting up security, it will affect all computers in that OU. Testing, monitoring, and auditing are the best ways to mitigate that risk.

DHCP is the method used in Windows Server 2003 to dynamically assign IP addresses for legitimate domain member computers. Malicious users conceivably could attempt to lease all the IP addresses from a DHCP server, which would result in the inability of legitimate computers to obtain an IP address. Without an IP address, those computers would be unable to join to the domain. In smaller companies, this is not usually a major threat, but in larger companies, this threat must be addressed. In Chapter 2, Securing Servers Based on Function, we discussed how to secure a DHCP server against these threats.

DNS is a very popular target for hackers, because access to this data provides the hacker with very valuable information about computer names , IP addresses, and the network structure. Protecting DNS data has become increasingly important, especially as contact with the Internet has increased. Using IPSec to secure DNS traffic is one part of the security solution for DNS, which we ll examine in detail later in this chapter.

WINS is still required for any computers running operating systems prior to Windows 2000. Computers running Windows 2000, Windows XP, or Windows Server 2003 use DNS for name resolution instead of the Microsoft proprietary WINS method. If your network has older clients, you will still need to provide WINS for NetBIOS name resolution services. The threat to WINS, however, is typically when WINS traffic is replicated across a wide area network (WAN). In these cases, replication can be set up to use IPSec or VPN tunnels to protect this traffic during replication. We ll discuss how to secure WINS traffic with IPSec.

IIS provides Web-related services, including File Transmission Protocol (FTP), HyperText Transport Protocol (HTTP), and Network News Transport Protocol (NNTP), among others. IIS is probably the most vulnerable and the most hacked application because of its exposure to the Internet. An entire chapter in this book is dedicated to securing IIS, so we won t go into too much detail here. However, there are a number of ways IIS can be secured, and some of the new features in Windows Server 2003 help address vulnerabilities of IIS. In Windows Server 2003, IIS is no longer installed by default, which improves security right out of the box. In addition, when IIS is installed, it is locked down by default. There are also several tools that can further analyze and lock down security to help mitigate risk.

RRAS is also a very vulnerable point in the network. It s become increasingly common in today s networking environment to have users working from locations other than the office. Remote access increases the user s range in terms of data access, but it certainly opens the door to intruders. RRAS must employ strong user authentication to ensure that only authenticated users gain access to network resources. In addition, the data that flows back and forth from a remote user to the corporate network must be secured, because in most cases, that data is traveling over a public network. This makes the data far more susceptible to capture, monitoring, modification, and attack. IPSec is an excellent part of the security solution for remote access, and we ll explore IPSec in just a moment.

Finally, application and file data is transmitted across the network via application servers (including Terminal Server) and file and print servers. Data can be secured via securing physical access to computers, using the NTFS file format to protect files and folders on system volumes , and using IPSec to secure sensitive data as it travels the network.

As you know, each of these server roles implements many different types of network and system protocols. Applications all use different methods to communicate with the user and with other network resources. The most effective security solution is one that:

Is transparent to the application and the user.
Will protect only sensitive data on the internal and external network.
Will be easy to administer and hard to crack.

The IPSec framework is just such a solution, so let s review IPSec now.

IPSec Overview

This book assumes you re already familiar with both Active Directory and IPSec. However, we will review IPSec here to refresh your memory, and then we ll look at how to use IPSec policies to secure the network infrastructure.

IPSec is a suite of protocols that provides protection of data integrity, and authentication. It can also provide optional privacy and replay protection. The IPSec protocols are defined by the Internet Engineering Task Force (IETF) Request for Comments (RFCs) 2401 through 2409 (or IETF RFCs 2401 “2409). This specification defines security protocols, security associations, key management, and algorithms for authentication and encryption.

IPSec provides security services at the transport layer of the TCP/IP stack . The IPSec driver interfaces with the TCP/UDP transport layer and the Internet layer, making it transparent to users and applications. It can receive network communication and, through the use of filters and rules, it can:

Select required security protocols.
Determine algorithms to use for a particular service.
Use cryptographic keys required by any of the services.

IPSec is used to secure the communication channel between computers and to secure the data flowing across that channel. IPSec can secure any path between a pair of computers, whether it s client to client, server to server, client to server, or between a security gateway and any host.

IPSec secures data by signing the packet and encrypting data. You can choose to use one or the other or both. Signing the packet involves using a hash value to make sure the packet has not been tampered with. Encrypting the data involves an encryption algorithm as well as keys for encrypting and decrypting the data.

Security Associations

IPSec begins creating a secure environment by securing the channel between two computers. Essentially, a security association is an agreement between two computers that includes how they will exchange and protect data that flows between them. This agreement is called a security association (SA), which is defined by IETF RFC 2408. This specification defines the Internet Security Association and Key Management Protocol (ISAKMP)/Oakley. There are two parts of this ”creating a security association and managing keys for data encryption. Oakley is a key generation protocol. Within Microsoft, the ISAKMP process is often referred to as the Internet Key Exchange (IKE). IKE specifies:

How security associations are created (Phase I).
How keys are exchanged (Phase II) once the SA is established.

Once a security association is formed and keys are exchanged, data can be sent back and forth in one of several secure states.

The first SA (Phase I SA) specifies how the two computers trust each other and it protects their security negotiation. IKE operates in main mode during this phase. The second SA (Phase II SA) specifies the actual security methods and keys for each direction of communication. IKE operates in quick mode in this phase and automatically creates and refreshes a shared, secret key for each SA. The secret key is then independently created by both computers so the key is not transmitted across the network. Both main mode and quick mode statistics can be viewed in the IP Security Monitor snap-in to the Microsoft Management Console (MMC).

Phase I Security Association

Both phases of establishing a security connection require policy negotiation. In Phase I, four mandatory parameters must be established via negotiation:

Encryption algorithm
Hash algorithm
Authentication method
The Diffie-Hellman (DH) group to be used for the base keying material

IPSec Encryption Algorithms

IPSec can be used to ensure data confidentiality via encryption. The encryption method used by IPSec is based on one of the algorithms shown in Table 5.1.

Table 5.1: IPSec Encryption Algorithms
Encryption Algorithm	Description
Data Encryption Standard (DES)	Standard DES uses 56-bit encryption. This is the default value used in Windows Server 2003.
Triple DEC (3DES)	3DES uses 56 bits times 3 making it far more difficult to crack than DES. With 3DEC, the data is encrypted with the first key, decrypted with the second key, and encrypted again with a third key, hence the term triple DES.
40-bit DES	As its name implies, a less secure encryption algorithm is 40-bit DES. This is sometimes used for down-level client support because earlier versions of Windows operating systems do not support DES or 3DES.
None	You can choose not to encrypt data at all. This might make sense in scenarios where either the down-level client cannot support any encryption (in which case you probably want to consider upgrading that client) or in situations where the data itself is not particularly sensitive.

Encryption is one of several components of Public Key Infrastructure (PKI), covered in detail elsewhere in this book.

To encrypt and decrypt, you need keys. Public cryptographic systems use two keys ”a public key known to anyone and a private or secret key known only to the sender and receiver. This system was originally devised in 1976 by Whitman Diffie and Martin Hellman. For this reason, public key cryptography is sometimes referred to as Diffie-Hillman encryption or asymmetric encryption , because it requires two keys instead of one (which is called symmetric encryption).

IPSec Hash Algorithms

You can choose between two hash functions when implementing IPSec policy: Message Digest (MD5) and Secure Hash Algorithm 1 (SHA1). The hash function is also used by other security protocols, including the Challenge Handshake Authentication Protocol (CHAP) and the Extensible Authentication Protocol (EAP). Table 5.2 compares the two hash algorithm methods.

Table 5.2: IPSec Hash Algorithms
Hash Algorithm	Description
Message Digest (MD5)	MD5 is based on IETF RFC 1321 and completes four passes over the data blocks, using a different numeric constant for each word in the message on each pass. This process creates a message digest, which is the message converted into a fixed string of digits. It is a one-way hash function, meaning that it is virtually impossible to reverse engineer the string to derive the original text. The result of this process is a 128-bit hash that is used for the integrity check.
Secure Hash Algorithm 1 (SHA1)	The SHA1 was developed by the National Institute of Standards and Technology described in the Federal Information Processing Standard (FIPS) Publication 180-1. The computational process is similar to that used in the MD5 hash, but SHA1 results in a 160-bit hash being used instead of a 128-bit hash. The longer hash generated by SHA1 provides greater security than the MD5 hash.

Authentication Methods

The authentication methods that can be used by a security association include certificates, Kerberos v5, and pre-shared keys. Table 5.3 compares the three authentication methods that can be used and are discussed in order of most-to-least secure.

Table 5.3: IPSec Authentication Methods
Authentication Methods	Description
Certificates	Certificates are issued by certificate authorities (CAs). Some well-known organizations that provide certificates (act as CAs) are Microsoft, Entrust, VeriSign, and Netscape. An encrypted digital certificate contains the applicant s public key and other identification information. Certificates are the most secure form of authentication and are the most viable choice in environments that require high security.
Kerberos v5	Kerberos v5 is an authentication protocol and was established as the default authentication protocol in Windows 2000. If Kerberos v5 is used, the computer identity is *unencrypted* until encryption of the entire payload takes place during authentication. This creates a security hole that can be exploited. Authentication via Kerberos should not be implemented in highly secure settings. In those cases, use certificates.
Pre-shared keys	Pre-shared keys are fast and easy to use because they use a shared, secret key that is previously agreed upon by two users. It does not require the use of a public key certificate or the Kerberos v5 protocol. This key is used for authentication only and does not encrypt the data. Typically, pre-shared keys should be used only when certificates or Kerberos v5 cannot be used. Pre-shared keys store the authentication key in clear text in the IPSec policy, which means this method is not very secure.

Diffie-Hellman (DH) Groups

The fourth element in Phase I SA negotiations is the negotiation of the Diffie-Hellman (DH) group to be used for the base prime numbers, which are called the keying material . Each DH group defines the length of the keying material. These are summarized in Table 5.4.

Table 5.4: Diffie-Hellman Groups
Diffie-Hellman Group	Description
DH Group 2048 (high)	The highest setting, Group 2048, uses 2048 bits of keying material as the basis for encryption. This is a highly secure setting.
DH Group 2 (medium)	DH Group 2 (medium) is the default setting in Windows Server 2003 and provides medium protection by using 1024 bits of keying material.
DH Group 1 (low)	DH Group 1 (low) is defined by the use of 768 bits of keying material for encryption. This is considered the least secure and in most cases where security is a concern, it should not be used. This is sometimes used with down-level clients that do not support the use of more bits for encryption.

The strength of the DH group is directly proportional to the strength of the key. Clearly, the longer the key length, the more difficult it is to crack ”both in terms of the time and level of sophistication needed to do so.

Phase II Security Association

Phase II of the security association negotiation determines how data will be secured via:

The IPSec protocol to be used
The hash algorithm
The encryption algorithm

Remember, the hash and encryption algorithms in Phase I are used to negotiate communication between the two computers . The hash and encryption algorithms in Phase II are used on the data itself. Like Phase I, Phase II also uses hashing and keying algorithms for packet integrity (hashing) and data security (keying and encrypting). The third element is the IPSec protocol to be used. The IPSec protocols are the Authentication Header (AH) and the Encapsulating Security Payload (ESP) . Before we discuss the details of these two protocols, it s important to review the two modes for IPSec.

IPSec Modes

AH and ESP can be used in transport mode or tunnel mode. Essentially, transport mode secures only the IP payload while it s in transit. Tunnel mode secures the entire packet, including the original IP header, by signing (and/or encrypting) the entire contents of the packet, including the IP header.

Transport mode is the default mode in IPSec and is used for end-to-end communications between two computers. When transport mode is used, only the IP payload is encrypted via the use of AH or ESP.

In tunnel mode, IPSec encrypts the IP header and the IP payload. This contrasts with transport mode that encrypts only the IP payload. In tunnel mode, the entire IP packet is encapsulated with an AH or ESP header and with an additional IP header.

The IP addresses in the outer IP header are the tunnel endpoints (source and destination), such as a proxy server or gateway. The IP addresses in the encapsulated IP header are the ultimate source and destination for the packet. By encapsulating the ultimate source and destination, IP addresses are protected while the data travels from one tunnel endpoint to another. These endpoints typically connect via an unsecured medium such as the Internet. Now let s look at the protocols used in these two modes.

IPSec Protocols

IPSec uses either AH or ESP to protect packets from modification or viewing. The AH protocol, IP protocol 50, is used to sign a packet to ensure it is not modified in any way. AH protects the IP header from modification as well as the IP payload. ESP can sign and encrypt data in an IP packet. When using ESP, the original IP header is only protected when ESP is used in tunnel mode.

IPSec protects an IP packet using one of two methods (or both methods, if desired). The AH protocol uses various methods to protect the integrity of the packet. It is sometimes referred to as IP protocol 50 since that is the port is uses. IPSec using AH will attach an AH header to the IP packet. This AH header contains information about the packet that guarantees the packet will arrive at its destination without alteration. If the receiving computer receives an IPSec protected packet with the AH header information intact, it can be sure the packet is unaltered. If the packet has been altered , the receiving computer will reject the packet. The packet structure IPSec uses when protecting a packet with AH is shown in Figures 5.1 and 5.2. Two modes can be used with each protocol, transport mode or tunnel mode. Thus, there are two packet structures possible when using AH (and ESP). The shaded area is the original IP packet data, the area in white indicates the AH segment(s).

Figure 5.1: IPSec Transport Mode with Authentication Header

Figure 5.2: IPSec Tunnel Mode with Authentication Header

The second IPSec protocol is ESP, IP protocol 51, which is used to ensure not only that the packet will arrive intact but that the data within it is secure. Securing data is often referred to as data confidentiality or data privacy. ESP signs and encrypts data to make the packet and its payload secure. In the default mode (transport), ESP does not protect the IP header because it only signs the IP payload. Therefore, ESP can be used in conjunction with AH to protect the entire packet, although for practical purposes, this is used only where there is a very strong need for security. The additional overhead required to formulate a packet with both AH and ESP protection is generally more than most firms need, but can be implemented if the computers using it can handle the load generated. In tunnel mode, ESP encapsulates and secures the original packet, including the IP header, but does not secure the outer IP header. ESP uses an ESP header, ESP trailer, and an ESP authentication trailer to protect the data. Figures 5.3 and 5.4 show the two packet formats with ESP, again in transport or tunnel mode. Again, the gray areas show the original IP packet contents, and the areas shown in white are the ESP segments.

Figure 5.3: IPSec Transport Mode with ESP

Figure 5.4: IPSec Tunnel Mode with ESP

Now that you ve looked at the two protocols and how they protect the packet, let s compare the two to see how they re similar and different. Understanding these concepts will be important when you implement IPSec and on the exam. Table 5.5 delineates the similarities and differences between AH and ESP.

Table 5.5: Comparison of Authentication Header and Encapsulated Security Payload Protocol s
Requirement	Protocol	Description
Data and header must be protected from modification and replay, data remains readable.	A H	Use in situations where data does not need to be secret but must be authenticated. One common use of AH is where firewall filtering requires packet inspection; the packet must be authenticated but must remain readable.
Data must be protected but IP addressing does not require protection.	ESP	Use in situations where data must be kept secret such as database traffic or protocol data.
Both the IP header and the IP payload need to be protected.	Both AH and ESP	Use in situations that require the highest security. Typically, ESP is implemented alone for security because implementing AH and ESP creates tremendous overhead.

Typically, ESP provides adequate protection for secure situations because it protects everything except the IP header. The IP addresses for ESP-protected packets cannot be spoofed because ESP guarantees authentication of the data s origin. Therefore, the additional overhead required to protect an ESP packet with additional AH protection is generally not worthwhile.

Exam Warning

Although you re not likely to run into specific questions regarding the details of the IPSec format on the exam, it s always a good idea to at least be familiar with the information. Often on exams, the information, although tangential to the question, can help you discern the correct solution from among several similar incorrect answers.

Authentication Header

Using a hash function, the data in the authentication header is protected from tampering and in turn , it protects the data by signing the entire packet. Some data in the packet might not be included in this protection because data in some fields might legitimately change during transportation, such as the Time To Live (TTL) field. The packet format for AH in transport mode is shown in Figure 5.1.

Let s compare that to the IP packet using AH in tunnel mode, as shown in Figure 5.2. A new IP header and the AH header are placed in front of the original IP header. The new IP header is the address of the intermediary such as a gateway or router. The AH signs the entire packet, including the new IP header. Notice that the IP header in the middle is the IP header of the original packet and contains the ultimate source and destination addresses. The outer IP addresses are used to route the packet to intermediaries and to protect the ultimate source and destination addresses. An important note is that the intermediaries, such as gateways or proxy servers, need not be configured with IPSec because the packet appears to be a normal packet to these computers.

Clearly, using IPSec in tunnel mode makes sense when you want to protect traffic that has to pass through an unprotected area such as the Internet or some other untrusted source. Tunnel mode is often used for remote access and typically not used for local connections where transport mode is generally more appropriate. Keep in mind that if the data is being sent between two host computers using IPSec tunneling, the IP header on the outside of the encapsulated data is the same as the IP header on the inside.

A few notes of caution here. Tunnel mode secures IP traffic; it can t be used to secure non-IP traffic. Windows Server 2003 does not support protocol-specific or port-specific tunnels.

Tunnels can be configured via IP Security Policy Management and Group Policy to specify rules for inbound and outbound tunnel traffic. We ll explore IP Security Policy in depth later in this chapter.

Before we leave AH, it s helpful to understand what s actually in the AH segment. Without going into tremendous detail, let s look at the elements of the AH. Table 5.6 describes each element and its use.

Table 5.6: AH Header Description
Name of AH Header Field	Description of Field
Next Header	This field is used to describe the IP payload that follows the AH header by using the IP protocol ID.
Length	This field indicates the length of the AH header.
Security Parameters Index (SPI)	This field is used in combination with AH (or ESP) and the destination address to identify the correct security association to which the packet belongs.
Sequence Number	The sequence number is what provides anti-replay protection. This number is a 32-bit, incrementally increasing number that begins with the number 1. It indicates the packet number sent over the security association. The sequence number cannot repeat for the life of the quick mode security association, which is what protects the packet from replay. The receiver checks the sequence number against packets received from this security association. If it is a duplicate number, the packet is rejected.
Authentication Data	The authentication data is called the integrity check value (ICV), also known as the *message authentication code* . This value is used to verify the message integrity and authentication. The ICV is calculated over the packet. The receiver calculates the ICV and checks it against the one sent by the sender.

Encapsulated Security Payload

AH is fine to use for authentication and integrity, but it does not provide privacy. To keep the data in a packet confidential, it must be encrypted. That s where the second IPSec protocol comes in, Encapsulated Security Payload (ESP). Like AH, ESP works in transport or tunnel mode, and like AH, ESP provides authentication, integrity, and anti-replay protection. Where ESP differs is that it provides data encryption, which AH does not. In the default transport mode, only AH will protect the IP header, so you can see why you might want to use both AH and ESP to fully protect a packet. Figure 5.3 shows the format of a packet using ESP in transport mode.

The difference between AH and ESP becomes immediately apparent when you look at the packet format because ESP appends data to the IP packet itself. The signed portion of the packet is signed for integrity and authentication. The encrypted portion provides confidentiality of the payload. ESP is used in tunnel mode when packets will be sent over an unsecured link. The packet format for ESP in tunnel mode is shown in Figure 5.4.

Notice that a new header for tunneling is added to the packet. Everything that follows, then, is signed, except for the ESP authentication trailer. The entire packet is appended with an ESP authentication trailer and then the packet is encrypted. Thus, the original IP header is encrypted as part of the encapsulated data. The new tunnel header is only used to route the packet between endpoints. Both AH and ESP can be used singly or together in tunneling mode to provide integrity, authentication, and confidentiality.

As with AH, the fields used in the ESP header have specific functions that help understand how the packet is protected. Table 5.7 describes the elements found in the ESP header, ESP trailer, and ESP authentication trailer.

Table 5.7: Encapsulated Security Payload Header Descriptions
Name of ESP Field	Description of Field
Security Parameter Index (SPI) Used in ESP header	This field is used in combination with ESP (or AH) and the destination address to identify the correct security association to which the packet belongs.
Sequence Number Used in ESP Header	The sequence number is what provides antireplay protection. The sequence number cannot repeat for the life of the quick mode security association, which is what protects the packet from replay. The receiver checks the sequence number against packets received from this security association. If it is a duplicate number, the packet is rejected.
Padding Used in ESP trailer	Padding of 0 to 255 bytes is used to make sure the encrypted payload s data falls on byte boundaries required by encryption algorithms.
Padding Length Used in ESP trailer	Indicates the length of the padding used in the padding field. The receiver uses this information to remove the padding after the data has been decrypted.
Next Header Used in ESP trailer	Identifies the type of data in the payload.
Authentication Data Used in ESP authentication trailer	The authentication data is called the integrity check value (ICV) or message authentication code. This value is used to verify the message integrity and authentication. The receiver calculates the ICV and checks it against the one sent by the sender.

Although you might not see specific questions on the format of the AH or ESP protected packets, you might see questions that ask you to assess what type of IPSec formatting is best in a given environment. Understanding how AH and ESP work alone and in combination in transport and tunnel modes will certainly give you a great understanding of IPSec and how to best implement it in your organization.

Test Day Tip

An important differentiation between AH and ESP is that ESP provides confidentiality. When you are assessing questions and answers on the exam, pay particular attention to this detail. If confidentiality is required, you must use ESP either by itself or in combination with AH. Keep this in mind when assessing proposed answers or solutions on the exam.

The IPSec Process

The IPSec Policy Agent resides between the transport layer and the Internet in the TCP/IP stack. Its job is to monitor all inbound and outbound IP traffic and to grab any IP traffic that meets the requirements of the IPSec policies applied to that computer. When an IP packet that matches an IPSec policy is captured, it is secured in the manner specified by that policy. This security is performed by the IPSec driver . Once the packet is secured by the IPSec driver, it is sent up (transport layer) or down (Internet or network layer) the TCP/IP stack for delivery. At the receiving end, the computer s IPSec works in reverse to identify IPSec packets, verify packet integrity, and decrypt data (if needed). If the packet has been compromised, the receiving computer rejects the packet.

Note that when a secured packet reaches an intermediary computer such as a gateway, proxy, or firewall, the packet is simply passed along as any other packet would be. These intermediary computers do not have to have IPSec implemented for them to properly handle a secure packet.

IPSec can use several different methods for protecting data integrity and confidentiality. The protocols and methods that can be used are specified by IPSec policies on the computers. For example, although two computers will negotiate various security options, the negotiation is limited to the filters applied by both computers IPSec policies. If they have vastly different policies specified, they might not be able to create an SA at all. That s why it s important to understand your network configuration and test your security configurations thoroughly before rolling them out to your organization.

IPSec Policies Overview

Now that we ve reviewed IPSec, let s take a look at how IPSec is implemented in Windows Server 2003. IPSec policy consists of several elements: filter lists, filter actions, and rules. It s critical to understand how these work together to enforce security across the enterprise. It s important for you on the job and will certainly be one of the key topics on the exam.

Default IPSec Policies

In Chapter 2, you learned about predefined security templates provided in Windows Server 2003. Windows Server 2003 also provides predefined IPSec rules, filter lists, filter actions, and default policies. Unlike the predefined security templates, though, these predefined IPSec rules, filter lists, actions, and policies are intended to provide examples of how to implement IPSec policies. They cannot be used in organizations without modification. There are three default policies that each use a number of predefined rules, filter lists, and filter actions. We ll review these policies and the different elements here so you can become familiar with how IPSec policies work. The three default policies are Client (Respond Only), Server (Request Security), and Server (Require Security). Table 5.8 shows the description and the rules, filter lists, and filter actions used for each predefined IPSec policy.

IPSec Rules

IPSec policies are applied based on rules. A rule provides the ability to create secure communication based on the source, destination, and type of IP traffic. Each rule contains a list of IP filters and a set of security actions to take. Each policy can contain one or more rules, all of which can be active simultaneously . The <Dynamic> Default Response rule is discussed later in this section, as it is present in all IPSec policies and cannot be deleted, although it can be deactivated. Each IPSec rule consists of these elements:

A selected filter list
A selected filter action
Selected authentication methods
A selected connection type

A selected tunnel settings

Table 5.8: Predefined IPSec Policies
Policy Name	Description	Rules, Filter Lists, Filter Actions
Client (Respond Only)	This policy can be used (once modified) to allow client computers to respond to security requests but not to initiate them. For example, you might have a DHCP server or Application server set to require security, and the client can respond to these requests. The policy contains the default response rule , which creates dynamic IPSec filters for inbound and outbound traffic based on the requested port and protocol being secured. If a server is locked down (discussed later in this section), the default response rule will not allow the client to communicate with that locked-down server. The default response rule is present in all IPSec policies by default. It cannot be removed, but it can be deactivated.	Rule 1 (default response rule) “ IPFilterlist <Dynamic> “ Filter Action: Default Response “ Authentication: Kerberos “ Tunnel Setting: None “ Connection Type: All
Server (Request Security	This predefined policy is an example of a policy that could be used on computers that would prefer secure communication but would allow fallback to unsecured communication. For servers dealing with mixed clients (including down-level clients), this option provides the best balance between security and connectivity for down-level clients. There are three rules in place. The first looks at all IP traffic and requests security negotiations. If the client computer supports IPSec, a negotiation will take place. Rule 2 allows all Internet Control Message Protocol (ICMP), used to report errors and exchange limited control and status information for IP-based communications on the network. Rule 3 is the default response rule and is used to ensure a computer responds to security requests.	Rule 1 “ IP Filter List : All IP Traffic “ Filter Action: Request Security (Optional) “ Authentication: Kerberos “ Tunnel Setting: None Connection Type: All Rule 2 “ IP Filter List: All ICMP Traffic “ Filter Action: Permit “ Authentication: N/A “ Tunnel Setting: None “ Connection Type:All Rule 3 Default Response Rule “ IP Filter List: <Dynamic> “ Filter Action: Default Response “ Authentication: Kerberos “ Tunnel Setting: None “ Connection Type: All
Server (Require Security)	Servers that transmit highly sensitive data should require secure communications. This predefined policy is an example of how such a policy can be designed. It contains three rules: Rule 1 requires secure communication, Rule 2 allows ICMP traffic, and Rule 3 is the default response rule. Computers running Windows 2000 require the High En- cryption Pack or Service Pack 2 (or higher) to be installed in order to communicate using the 3DES algorithm. If the Windows 2000 computer does not have the High Encryption Pack or SP2 installed, it will fall back to the less secure DES. Windows XP and Windows Server 2003 support 3DES, and no mod- ification or additional configur- ation is required.	Rule 1 “ IP Filter List: All IP Traffic “ Filter Action: Require Security “ Authentication: N/A “ Tunnel Setting: None “ Connection Type: All Rule 2 “ IP Filter List: All ICMP Traffic “ Filter Action: Permit “ Authentication: Kerberos “ Tunnel Setting: None “ Connection Type: All Rule 3 Default Response Rule “ IP Filter List: <Dynamic> “ Filter Action: Default Response “ Authentication: Kerberos “ Tunnel Setting: None “ Connection Type: All

Exercise 5.01: View Predefined IPSec Policy “ Server (Request Security)

Click Start , select Run , type mmc in the Open text box, click OK or press Enter .
The Microsoft Management Console opens a new console. Click File , select Add/Remove Snap-in .
In the Add/Remove snap-in dialog with the Standalone tab selected (default setting), click Add .
In the Add Standalone Snap-in, scroll down and select Group Policy Object Editor . Click Add and then accept the default select of Local Computer for the Group Policy Object . Click Finish and then click Close .
Local Computer Policy should be displayed in the box in the Add/Remove snap-in dialog. Click OK to close the dialog.
In the left pane of the MMC console, click the + to expand the Local Computer Policy node.
Click the + to expand the Computer Configuration node.
Click the + to expand the Windows Settings node.
Click the + to expand the Security Settings node.
Click the IP Security Policies on the Local Computer node .
In the right pane, the three default IPSec policies are displayed. In the right pane, click the Server (Request Security) , which should be the first policy listed.
On the menu, click Action and then select Properties . Alternately, you can right-click the policy and select Properties from the menu, or simply double-click the policy name to display the Properties .
The Rules tab is selected by default. Click the General tab to select it.
The General tab shows the policy name and description as well as the setting for how often it should check for policy changes.
Click the Settings button to display Key Exchange Settings . You can change settings for the authentication and generation of new keys based on time length or sessions. You can also specify methods. If you want to use Master Key Perfect Forward Secrecy (PFS), click the check box to select that setting. If you enable this setting, the session key limit is not used. If both a master key lifetime and a session limit are specified, whichever limit comes first causes a new main mode negotiation to take place. By default, IPSec policy does not specify a session limit. Clicking this box will disable the Sessions option.
Click the Methods button. Figure 5.5 show the Key Exchange Security Methods dialog that is displayed. Notice that the settings are for IKE and specify the security method preferences, in order. To modify a setting, click the setting and then click Edit . To add a new setting, click Add . To remove a setting, click Remove . You can also use the Move up or Move down buttons to change the order of preference. Notice as you use the horizontal scrollbar that you can modify encryption, integrity (hash), and Diffie-Hellman Group settings here.

Figure 5.5: Key Exchange Security Methods Dialog
Click Cancel to exit the Key Exchange Security Methods dialog without accepting changes.
Click Cancel to exit the Key Exchange Settings dialog without accepting changes.
You should now be back to the Server (Request Security) Properties dialog. Click the Rules tab.
With the Rules tab selected, you can see the three IP Security rules defined. These match the information in Table 5.8.
Select the first IP Security rule, All IP Traffic , and use the horizontal scroll bar to view the various settings: IP Filter list, Filter Action, Authentication, Tunnel Endpoint, and Connection Type.
Click Edit to view the options on this first rule.
The Edit Rule Properties dialog gives you access to all the modifiable parameters. The tabs in this dialog are IP Filter List , Filter Action , Authentication Methods , Tunnel Setting , and Connection Type . If desired, look at the various options on the tabs to become familiar with the options on each.
Click Cancel to exit without saving changes.
Click Cancel to exit the Server (Request Security) Properties dialog without saving changes.
Close the MMC console by clicking File , then selecting Exit and clicking No when prompted to save the console.

As you can see, you can create intricate IPSec policies using the parameters and options we just explored in Exercise 5.01. Later, we ll create a policy so you can get some hands-on experience with creating IPSec policies.

The IPSec policy we just reviewed, Server (Request Security), contains three predefined rules, shown previously in Table 5.8. The first is to filter All IP Traffic and request security, the second is to filter All ICMP Traffic and to permit it, and the third is the <Dynamic> Default Response Rule. Let s discuss these rules in more detail.

Predefined Filter Lists

There are two predefined filter lists ”one that looks for All IP Traffic and one that look for All Internet Control Message Protocol (ICMP) Traffic.

The All IP Traffic filter list looks for all IP traffic sent or received by the computer on which the filter list (via the IPSec policy) is applied. By default, the Internet Key Exchange (IKE) traffic is excluded. Other traffic types are matched against IPSec filters. IPSec does not negotiate security associations for multicasts and broadcasts, although you can configure, block, or permit filter actions specifically for these.

The All ICMP Traffic filter list looks for all ICMP traffic (IP protocol 1) sent and received by the computer. Since this traffic is used for low-level IP communication and error reporting, it is permitted in even the most secure predefined IPSec policy.

The <Dynamic> Default Response is created automatically every time a new IPSec policy is created. It cannot be created manually. It is called the default response rule because it is used to respond to security requests when no other rules apply. You can disable this rule in the Rules tab (see Exercise 5.01 step 19). You can also modify the authentication method or the security method used by the default response rule, if needed. The <Dynamic> tag indicates that the filter list is generated automatically based on the receipt of IKE negotiation packets. The filter action of Default Response cannot be configured with the typical filter actions ( Permit , Block , or Negotiate ) . Unlike the other predefined rules, when you select a rule and click Edit (Exercise 5.01, step 23), you will only have two tabs (not five): Security Methods and Authentication Methods. To deactivate the default response, click the check box to the left of <Dynamic> to clear the check box, as shown in Figure 5.6.

Figure 5.6: Disabling Default Response Rule

Predefined Filter Actions

Microsoft provides three predefined filter actions as examples: Permit , Request Security (Optional) , and Require Security .

Permit When the filter action is set to permit, traffic is permitted.

Request Security (Optional) This filter action requests security when it can be negotiated and is set to Negotiate Security . There are two exceptions to negotiated security when using this setting.

Incoming initial traffic is allowed, and if negotiation fails after three seconds, communication is allowed with a non-IPSec-aware computer. This is also known as inbound passthrough .

If security negotiation fails after three seconds, negotiation is halted and unsecured communication with a non-IPSec computer is allowed. This secures traffic to all IPSec-aware computers but allows unsecured communication for non-IPSec-aware computers. This is known as fallback to clear.

This filter action should not be used for traffic that goes through the Internet. Using this filter on Internet traffic could result in a DoS attack. If you request security and spend three seconds per negotiation, an attacker could send repeated requests that would virtually halt all other traffic.

This setting uses a preset list of security methods during the negotiation process. The first method uses the highest security and the last uses the lowest security, as shown in Table 5.9

Table 5.9: Security Negotiation Order of Preference
Key Lifetimes Type	AH	ESP Encryption	ESP Integrity	(KB/sec)
Custom	None	3DES	SHA1	100000/900
Custom	None	DES	SHA1	100000/900
Custom	SHA1	None	None	100000/300
Custom	MD5	None	None	100000/300

Require Security This filter action applies to all IP traffic and requires security using Kerberos trust. It does allow initial incoming unsecured communication (inbound passthrough ). The fallback to clear function is disabled so that no unsecured communication with untrusted clients is allowed. Traffic is secured via the Negotiate security mode in which both computers negotiate the most secure communication possible. However, if negotiation fails, a connection will not be established. This filter action should not be used on the Internet as it is vulnerable to DoS attacks since it will attempt negotiation with all incoming traffic. Table 5.10 shows the security methods used with this setting, in order of preference from highest to lowest. To create the most secure setting possible, known as lockdown , you can disable the inbound passthrough, thus disabling the ability of any unsecured traffic from being accepted. In this state, the client computer must be forced to negotiate security with the server to initiate communication. The client computers must be configured with an IPSec policy that will do this. If the client computer is configured to only use the default response rule, it will not be able to communicate with the locked-down server.

Table 5.10: Security Methods for the Require Security Setting
Type	AH	ESP Encryption	ESP Integrity	Key Lifetimes (KB/sec)
Custom	None	3DES	SHA1	100000/900
Custom	None	3DES	MD5	100000/900
Custom	None	DES	SHA1	100000/900
Custom	None	DES	MD5	100000/900

IP Packet Filtering

IP addresses are either local or remote addresses, meaning they originated on your network or they came from elsewhere. As you know, each IP address contains two sections ”the network ID and the host ID. IP packet filtering is used to provide a way to define exactly what IP traffic is passed through (not secured), secured, or blocked.

Each filter within the filter list describes a particular set of network traffic to be secured. The list identifies both inbound and outbound filters. Rules must always have filters to cover the traffic to which it applies. For example, if you have two computers, Black and White, and Black always wants to exchange data in a secure manner with White, the following must be set up:

Black s IPSec policy has a filter for any outbound packets going to White.
White s IPSec policy has a filter for any inbound packets coming from Black.

A filter contains the source and destination address of the IP packet. This setting can be set wide or narrow ”you can filter an entire network, subnet, or just a single IP address. A filter also contains the protocol being used to send the packet. The default is TCP/IP, but the filter can be modified to specify other protocols within the TCP/IP suite such as ICMP and UDP. A filter also contains the source and destination port of the protocol for TCP and UDP. The default covers all ports, but this can be modified to suit your organization s needs.

netsh Commands

The netsh.exe command can be used to work with IPSec policies and it is referred to throughout this chapter. Let s take a minute to review the netsh.exe command. netsh.exe is a command-line utility that can be used instead of the console-based management provided by the IP Security Policy Management and IP Security Monitor snap-ins in the MMC.

The netsh command has many different uses in Windows Server 2003. Each type of use is called a context . For example, you can use the DHCP context to manage DHCP, or you can use the IPSec context to manage IPSec. For more information on using the various contexts with the netsh.exe command, you can refer to the Windows Server 2003 help files. We re going to limit our discussion to the IPSec context. Support for this context was added to Windows Server 2003, providing another method of managing IPSec policy for admins more familiar or comfortable using the command-line utility. Using netsh.exe , you can configure and view dynamic or static IPSec main mode settings, quick mode settings, rules, and configuration parameters. This command-line utility is particularly useful when you want to use scripts to configure IPSec or to extend features not available via the snap-ins. These features include IKE (Oakley) logging, logging intervals, computer startup security, computer startup traffic exemptions, IPSec diagnostics, default traffic exemptions, and strong certificate revocation list (CRL) checking. To use the netsh.exe command, open a command prompt ( Start Run type in cmd OK ) and type netsh ipsec . This establishes the context for the netsh.exe command.

The command structure begins with static or dynamic mode, meaning that the syntax of the command begins in this way: netsh ipsec static or netsh ipsec dynamic . Both modes have many options. For example, in the static mode, you can add, delete, or modify a filter; add, delete, or modify a filter list; or add, delete, or modify a policy. Dynamic mode also has a long list of options you can set.

You can use the netsh ipsec static mode to create, modify, and assign IPSec policies without immediately affecting the configuration of the active IPSec policy. Using the netsh ipsec dynamic mode, you can display the active state of IPSec and immediately affect the configuration of the active IPSec policy. Dynamic commands immediately configure the security policy database (SPD) but take effect only when the IPSec service is running. If the IPSec service is stopped , the dynamic settings are discarded. A few of the dynamic commands do not take effect immediately and require that the computer or the IPSec service be restarted. It s important to note that the IPSec policy agent does not interpret netsh ipsec dynamic commands, so you need to understand the IKE main and quick mode policies to use these commands effectively. Another caution is that because almost all of these commands are executed immediately, you can create invalid IPSec policy configurations on the fly.

One important note here is that the netsh.exe commands for IPSec can only be used to work with IPSec policies on computers running Windows Server 2003. The command line to configure IPSec policies for computers running Windows XP is ipseccmd.exe . Windows 2000 computers use the command-line ipsecpol.exe

How IPSec Policy Is Applied

IPSec policies are retrieved at the time the computer starts up (system start time) and at a specified interval in the IPSec policy, if the computer is joined to a domain. IPSec policy is stored in Active Directory and cached in the local Registry of the computer to which a policy is applied. This occurs for all computers joined to the domain. If the computer is temporarily not connected to the domain, the cached policy information will be used. When the computer reconnects to the domain, new policy is applied that overrides the cached policy data. If a computer is a stand-alone computer or is part of a domain that is not using Active Directory, the policy data is stored in the local Registry.

Policy is applied to a computer because the IPSec Policy Agent Service starts automatically every time the computer starts. The IPSec Policy Agent is a service that resides on each Windows 2000, Windows XP, and Windows Server 2003 computer. Its function is to retrieve the appropriate IPSec policies from Active Directory (or the Registry if the computer is not connected to or not a member of a domain) and to send the IPSec policy information to the IPSec driver .

The IPSec driver uses the IP Filter List from the active IPSec policy to determine which outbound packets match the criteria set in the policy. Any packet that meets those criteria must be secured via IPSec as defined by the policy. For example, if a policy requires that all data from the Finance department be authenticated but not encrypted, the IPSec driver will make sure all finance packets use the authentication method listed in the IPSec policy. Figure 5.7 shows the interaction of Active Directory, IPSec policy, the policy agent, and the IPSec driver.

Figure 5.7: Interaction of IPSec Components

The IKE negotiates security between the computers as well as the methods to be used to secure the data. The IPSec driver monitors inbound and outbound traffic and compares it to the IPSec rules within the applied policies. When they match, the IPSec driver determines the proper action to take based on the filter list and filter actions. The packet is secured in the manner specified by the policy and sent to the receiving computer. On the other end, the receiving computer s IPSec driver receives the session key, SA, and SPI from the IKE. (Recall that the SPI is the Security Parameters Index (discussed in the Head of the Class sidebar earlier), which indicates to which SA the packet belongs.) The IPSec driver checks the signature, ensures the packet is intact, and decrypts it, if necessary. It sends the original IP packet up the stack to the appropriate application. Figure 5.8 depicts this process.

Figure 5.8: IPSec Process

Assigning Domain-Based IPSec Policy

After you ve created your overall security plan and created IPSec policies to protect the data you want to secure, you ll need to apply the policies. In this section and the following two sections, we ll discuss, at a high level, how to apply these policies to three specific objects: domains, OUs, and local computers.

When you define IPSec via Group Policy and link the Group Policy Object (GPO) to the domain, the IPSec policy will propagate throughout the domain when the GPO is propagated. Like GPO, IPSec policy is applied from lowest to highest priority: local, site, domain, OU, persistent policy (if used). Unlike GPOs, IPSec policies from different OUs are never merged. Domain-based IPSec policies are limited to 10 rules, although Windows Server 2003 supports over 1500 rules per policy. It is recommended that you set broad IPSec policies at the domain level to reduce configuration issues and administrative overhead required to manage IPSec policy.

During the rollout phase of IPSec security, you should set your domain-based IPSec policy to Negotiate security, which allows unsecured communication with untrusted computers. This way, no computer will be blocked as you re rolling out policy. Once you re sure that all IPSec policies are being applied as expected, you can modify the security to require only secured communications. Of course, testing the policy on a single computer and monitoring results is recommended before rolling out any policies.

IPSec policies should first be applied to the domain to provide baseline security settings. Tighter IPSec filtering can be done on specific OUs that might require additional security.

Exporting and Importing IPSec Policy

Once you ve defined domain-based IPSec policy, you might want to import or export them. In order to back up or restore IPSec policy objects in the IP Security Policies container in Active Directory, you need to use the IP Security Policy Management snap-in in the MMC. You can also use the netsh.exe command-line utility with the IPSec context to perform these actions. As shown in Figure 5.9, you can import or export IPSec policy for the local computer for the domain. In this case, the IP Security Policies on Active Directory (domain) is selected. To export the policy, right-click, select All Tasks , and then select Export Policies . Notice this is also where you can create new IP security policy or manage IP filter lists and actions. If you want to create a new domain-based IP security policy, you would select Create IP Security Policy from the menu, as shown in Figure 5.9.

Figure 5.9: Export IPSec Policy via IP Security Policy Management Snap-In

When you use the Export Policies command, all IPSec policy objects are stored in one file given an extension of .ipsec. When you import policies, you can import .ipsec files into the destination policy stores. If you import IPSec policy into Active Directory (as you would do if you were to have the Active Directory level open, as is the case in Figure 5.9), you would overwrite existing IPSec policy objects. This can be good if you believe your Active Directory IPSec policy is corrupted or incorrect and you want to restore from a known good file. However, if you do not want to overwrite existing values, do not import into Active Directory. If you suspect your IPSec policies in Active Directory are corrupted, you can import the .ipsec file via the snap-in or via the netsh ipsec static importpolicy command. It s important that you leave either the snap-in or the command-line utility (depending on your method) open long enough to complete the import or export. Closing either before all IPSec policy data has been written could result in corruption.

Exam Warning

If IPSec policy is corrupted, you must delete IPSec policy objects so new IPSec policy can be successfully imported. If you are managing IPSec over slow WAN links, transfer the IPSec policies in .ipsec export files by copying the file to the remote computer first. Then, use Remote Desktop Connection to connect to the remote computer and perform the operation.

Assigning OU-Based IPSec Policy

By default, the policies applied at the OU level override the baseline domain policies. For example, you can group all client computers into one OU and apply appropriate client-type IPSec policies to the OU. You can keep sensitive servers in another OU and apply more secure IPSec policies to this OU. You could also place sensitive client computers, such as those in Finance, Research, or Human Resources, into separate OUs and apply varying degrees of security to those OUs.

When you assign an IPSec policy within a GPO such as an OU, a pointer is recorded that points to the IPSec policy within the GPO. If you make changes to the IPSec policy, the GPO is not aware of those changes. The GPO is only aware of changes to the IPSec policy itself. The IPSec service detects changes related to the IPSec policy, and this detection interval can be specified in the General tab of the properties of the policy via the IP Security Policy Management snap-in. This interval is known as the IPSec polling interval.

Assigning Local IPSec Policy

Local GPOs can be overridden by GPOs assigned to sites, domains, and OUs when operating in an Active Directory framework. On a network without Active Directory, you can use the local policy to apply IPSec policies (and group policies) to individual computers. Every computer running Windows Server 2003 has one local GPO called local computer policy . When this is used, Group Policy settings can be stored on the local computer regardless of whether they are joined to an Active Directory domain. However, if they are joined to an Active Directory domain, local policy will be overridden by any policies with higher precedence.

Persistent policies are used on local computers as a way to secure the computer during the startup process. This policy adds or overrides the local or Active Directory policy and remains in effect regardless of whether other policies have been applied. Persistent IPSec policies provide a more secure framework because they provide a secure transition from computer startup to the application of IPSec policy. Persistent policy can also be used as a failsafe mechanism in case of corruption or errors during the application of higher precedence IPSec policy. Persistent policy can cause problems if it is the only policy applied and you are trying to diagnose a problem remotely, as the diagnostic traffic might be blocked. Persistent policies can be configured via the netsh commands. Persistent policies are stored in the computer s local Registry and are loaded by the IPSec policy agent during computer startup. The IPSec driver is set to secure mode (discussed later in this chapter) if the persistent policy is successfully applied. Although you can make changes to persistent policy at any time, changes are not implemented until the IPSec service is restarted.

Test Day Tip

To provide maximum protection for a computer during startup, you should configure and apply a persistent policy. For many systems, this might not be needed, but if you re applying IPSec security, you most likely want to also apply persistent policy to prevent security holes during startup. Be sure to review policies before the exam and look for this type of question on the exam.

IPSec Driver Modes

In understanding how policies work, it s important to understand that the IPSec driver operates in three modes: computer startup , operational , and diagnostic . Computer startup mode is used when the computer is starting up. Operational mode is used when the computer is up and running in normal operational mode. Diagnostic mode is used for troubleshooting.

Computer Startup Mode

The IPSec driver is loaded at startup along with other system services and drivers. Computer startup mode is used until the IPSec Policy Agent put the driver into operational mode. At startup, the IPSec driver can perform any one of the following actions:

Permit In permit mode, no IP packets are filtered (all are permitted) and no IPSec security is used. Permit mode is the default state of the IPSec driver if no IPSec policy has been applied to the computer.
Stateful In stateful mode, all outbound traffic is allowed and it creates inbound traffic filters based on the outgoing traffic. Inbound unicast, broadcast, and multicast packets are dropped. The stateful mode is the default mode of the IPSec driver if an IPSec policy has been assigned to the computer.
Block In block mode, all packets are discarded except for those that match specific filters configured to be used in block mode. All inbound and outbound DHCP traffic is permitted by default, to allow the computer to obtain an IP address.

The default state of the driver can be modified using the command-line utility netsh.exe . To modify the state, use the netsh ipsec static set config bootmode command.

Depending on the startup type of the IPSec service, the IPSec driver will start in one of three modes: disabled , manual , or automatic . In disabled mode, the IPSec driver loads in permit mode, no IPSec security is applied, and the IPSec driver does not filter any packets. In manual mode, the IPSec driver also starts in permit mode and no packet security filtering occurs. Automatic mode starts the IPSec driver in a startup mode specified by the IPSec policy agent. If no IPSec policy is applied, the IPSec driver will start in permit mode. If IPSec policy is applied, the IPSec driver will load in the stateful mode.

Once the IPSec service starts, persistent policy (if any) is applied and the IPSec driver is set to secure mode, which is the default configuration.

Operational Mode

Once the IPSec service starts on a computer, the IPSec policy agent sets the IPSec driver to one of three operational modes: secure , permit , or block .

Secure In secure mode, the IPSec policy filters are enforced for standard IPSec operations. The IPSec policy agent puts the driver into secure mode after it applies any persistent policies present (persistent policies are discussed in the next section) and before it applies the Active Directory policies or local policies. If no persistent policies are defined, IPSec security does not begin until either the Active Directory or local policy has been applied. If no IPSec policy is assigned, no IPSec protection is provided in this mode.
Permit When the IPSec driver is set to permit in the operational mode, it does not filter IP packets, and no IPSec security is enforced or applied. If the IPSec service is manually stopped on a computer, the operational mode will be set to permit.
Block In block mode, any exemptions that might apply at startup are not applied and all inbound and outbound traffic is blocked. This mode is used to increase security in case the IPSec policy agent fails to apply persistent policy. Persistent policy, as the name implies, remains on the computer. It is applied via netsh.exe commands. We ll explore persistent policies in just a moment.

It s important to note here that you cannot set these modes via the netsh command. The operational mode can only be configured by the IPSec policy agent.

Diagnostic Mode

You can use the diagnostic mode for troubleshooting to log events and errors. The IPSec driver logs can record inbound and outbound drop events on a per-packet basis during both startup mode and operational mode. Logging is disabled by default, and care should be used when enabling logging. It should not be used for extended periods of time. Depending on the level of logging you configure, your System log file can fill very quickly.

Test Day Tip

A few days before the test, review the overall process of how all the IPSec components interact, and pay special attention to the startup and operational modes of the IPSec driver. Also remember that the netsh commands for IPSec can only be used to configure IPSec policies for computers running Windows Server 2003.

Designing & Planning
What s New in IP Security in Windows Server 2003

There are changes to the implementation of IP Security in Windows Server 2003 that can impact how IPSec works with computers running earlier versions of Windows, including Windows 2000 and Windows XP. Since you re likely to see this kind of information included in questions on the exam and run into these issues on the job, it s important to review the changes related to deploying IPSec in Windows Server 2003. These are summarized in Table 5.11.

Table 5.11: New IPSec Features in Windows Server 2003
New IPSec Feature	Description and Use Guidelines
Default exemptions have been removed.	Windows 2000 and Windows XP contained default exemptions for IPSec filtering. Specifically, these operating systems exempted broadcast, multicast ISAKMP,Kerberos, and Resource Reservation Protocol (RSVP) traffic. In Windows Server 2003, only ISAKMP traffic is exempt by default.
netsh enables command-line support for IPSec.	The netsh.exe command-line utility now has an IPSec context, which allows you to run IPSec-related commands from within this utility. Previous versions of Windows used different commands, Ipsecpol.exe and Ipseccmd.exe .
IPSec filters update IP configurations of partners .	The source or destination address fields that a computer interprets as the DHCP server, DNS server, WINS server, or default gateway can be configured using the IP Security Policy Management snap-in or the netsh.exe command. IPSec policies can now automatically manage changes in the IP configuration of the source or the destination by using DHCP or static IP configurations.
Network Address Translation traversal (NAT-T) support added.	IPSec in Windows Server 2003 now supports ESP-protected IPSec traffic passing through a NAT. Some applications might not work if their traffic is protected with IPSec ESP and passed through a NAT. IKE detects NATs and uses EDP ESP encapsulation to send all user data via UDP port 4500. The use of the AH protocol through a NAT is not supported.
Resultant Set of Policy (RSoP) now supported for IPSec.	The RSoP snap-in is used to view the results of various policies applied to a computer to address unanticipated results. Support of IPSec policies has been added in Windows Server 2003.
Support for Diffie-Hellman Group 2048.	The DH Group 2048 provides high security via the use of 2048-bit keying material to create security algorithms. Previous operating systems only supported DH Groups 1 and 2.
Persistent IPSec policy is supported.	Persistent IPSec policy is policy that is present during computer startup, before other policies are applied. Persistent IPSec policy can be used to protect the computer during the startup process. Admins can also force local IPSec policy to be applied when Active Directory policy is applied. Typically, Active Directory policy would override any local policy.
Stateful filtering of network traffic during startup.	IPSec in Windows Server 2003 now supports stateful filtering during startup. It permits only outbound traffic the computer initiates during startup and the inbound traffic sent as a response.
IP Security Monitor snap-in added.	This provides more detail about IPSec than the previous utility Ipsecmon.exe .

IPSec Best Practices

Microsoft outlines several best practices related to implementing IPSec.

Establish an IPSec deployment plan As we discussed earlier, planning is a critical part of the process in developing security plans.
Create and test IPSec policies for each deployment scenario Before deploying IPSec, all scenarios should be tested in a lab environment.
Do not use pre-shared keys These are stored in plain text and provide relatively weak authentication. Pre-shared keys should be used only for testing. In a live environment, certificates or Kerberos v5 should be used.
Do not use Diffie-Hellman Group 1 (low) DH Group 1 only provides 768 bits of keying strength. In today s demanding environment, use Group 2 (medium) for interoperability with Windows 2000 and Windows XP, or Group 2048 (high) for strong security using 2048 bits of keying strength. DH Group 2048 is only provided in Windows Server 2003.
Use Triple Data Encryption Standard (3DES) This uses a stronger encryption algorithm than does DES. Use 3DES for enhanced security. Windows 2000 computers must have the High Encryption Pack or Service Pack 2 installed in order to use 3DES. If the High Encryption Pack or Service Pack 2 is not installed, the security is set to the weaker DES. If not all computers support 3DES, use DES. Windows XP and Windows Server 2003 computers support 3DES by default.
For computers connected to the Internet, do not send the name of the Certification Authority (CA) along with the certificate request For computers connected to the Internet, enable the option to exclude the name of the CA from the certificate request to protect sensitive information about trust relationships from intruders.
For computers connected to the Internet, do not Kerberos v5 as an authentication method The computer identity is sent unencrypted until encryption of the entire payload occurs. This leaves the computer identity exposed during the authentication process. To secure computers connected to the Internet, use certificate authentication instead.
For computers connected to the Internet, do not allow unsecured communication You should disable the option to accept unsecured communication but respond with IPSec . Disabling this will prevent DoS attacks. Also disable the option to allow unsecured communication with non-IPSec-aware computers . If this option is not disabled, you are allowing unsecured communication. This is appropriate only in environments where IPSec is not needed.
Restrict the use of administrative credentials Administrative credentials can be used to attack the system, so these credentials should be restricted and monitored .
Test IPSec policy thoroughly when working with different versions of the Windows operating system Not all IPSec features are supported in all versions of Windows; thorough testing will prevent problems for users and problems with security.
Use the IPSec Policy Management console in Windows Server 2003 to manage IPSec policies This console provides for streamlined IPSec policy management. Be sure to use the console in Windows Server 2003, since earlier consoles lack features found in Windows Server 2003 and will not support newer IPSec features.

Use Terminal Server to remotely manage and monitor IPSec on computers running different versions of Windows Remote management and monitoring of IPSec is only supported on computers running the same versions of the Windows operating system. To remotely manage IPSec on computers running a different operating system, use Terminal Server.

Exam Warning

As with other details of IPSec, the exam won t test you directly on your knowledge of these individual elements. However, whenever Microsoft publishes best practices, you can be sure you ll see questions on the exam that test your understanding of these best practices in scenario questions. Make sure you re familiar with these recommendations and keep them in mind when answering exam questions.

Objective 3.1.3: Designing IPSec Policies

We ve reviewed IPSec, how it works, how it s implemented and when. Now, let s delve into the actual design and implementation of IPSec policies. Remember, the policies you apply on your systems should reflect the security plan you ve delineated for your network infrastructure.

Earlier, we discussed placing computers with similar security needs into OUs to simplify the application and management of IPSec policy. These can be placed in three general security groups ” minimal , standard , and high . Minimal security should be used with computers that do not exchange sensitive data. This group could include client computers and perhaps some file or print servers. IPSec is not active by default so no action is required to disable IPSec on these computers. Standard security should be applied to computers that store valuable data. This could include file servers and perhaps some application servers. Both Windows XP and Windows Server 2003 provide examples of standard security policies that secure data but do not require the highest level of security. Remember, there s always a balance between security and usability, so you don t want to lock down servers with IPSec policies when there s no clear need. The standard security settings typically provide this balance. These predefined standard security policies include Client (Respond Only) and Server (Request Security) . These should be used as the basis for your standard security to balance the need for security with the need to optimize usability and system efficiency. High security should be applied to computers that contain highly sensitive data that puts them at risk for attack, data theft, or system disruption. Any computer on the public network that provides remote access or vital system services should be secured with the high security level. The high security default policy Server (Require Security) requires IPSec protection for all traffic being sent and received except for initial inbound communication. Unsecured communication with a non-IPSec-aware computer is not allowed at all. Figure 5.10 shows these default policies for the domain.

Figure 5.10: Default Policies in Active Directory

Configuring IPSec Policy

You can configure IPSec policy in one of two ways. You can create a new policy, define rules, and then add filter lists and filter actions. You can also create filter lists and filter actions and then create policies and add rules that combine the filter lists and actions. Use whatever method makes the most sense for your particular needs. Using the first method, you ll add filter lists and filter actions during the rule creation. Using the second method, IPSec policies are created and rules are added that combine the desired filter list with desired filter action. Once IPSec policies are configured, they must be assigned.

IPSec policies can be configured via the IP Security Policy Management snap-in in the MMC or via the netsh command-line.

Assigning IPSec Policy

Once IPSec policies have been created, the list is available to assign to any level of the Active Directory hierarchy, but only one policy can be assigned at any given level in Active Directory. IPSec policy applied to an OU takes precedence over domain-level policy for members of the OU, which is why servers should be placed into OUs. You should also apply IPSec policy to the highest OU possible to avoid dealing with potential IPSec policy conflict and to ease security administration. A child OU will inherit the IPSec policies from its parent OU unless policy inheritance is explicitly blocked or explicitly assigned. Before assigning an IPSec policy to a GPO, make sure the GPO meets the requirements of the IPSec policy. For example, if your IPSec policy requires the use of a computer certificate, make sure the computer has a certificate. Finally, since an IPSec policy might remain active even after a GPO to which it is assigned is deleted, you should get in the habit of unassigning the IPSec policy first and then delete the GPO. Typically, you should wait 24 hours before removing the GPO to make sure changes have been propagated successfully.

Keep in mind that when policies are changed, the IPSec service might be forced to delete an existing Security Association (SA) and re-establish the SA. In this case, communication between the two computers will be terminated until a new SA is negotiated based on the new IPSec policy.

Exercise 5.02: Exploring the IP Security Policies snap-in

Before you create specific IPSec policies, rules, filter lists, and filter actions, you ll need to be familiar with the IP Security Policies snap-in in the MMC. This exercise will help familiarize you with this snap-in.

Click Start , select Run , and in the Open box, type in mmc , and then press Enter or click OK to open the MMC.
A new console is opened by default. Click File and then select Add/Remove Snap-in .
In the Add/Remove Snap-in dialog, click the Add button.
In the Add Standalone Snap-in dialog, scroll down to locate and select the IP Security Policy Management snap-in. Click Add to add the snap-in.
The Select Computer or Domain dialog will open. This allows you to select which computer or domain the snap-in will manage. You can manage policies on the local computer (the default setting) or you can select the Active Directory domain the computer belongs to, a different Active Directory, domain or another computer. Accept the default ( Local computer ) and click Finish. The Select Computer or Domain dialog closes , returning you to the Add Standalone Snap-in dialog.
The active dialog is the Add Standalone Snap-in dialog. Click Close to return to the Add/Remove Snap-in dialog. Click OK to close this dialog and return to the MMC.
Click IP Security Policies on Local Computer in the left pane to select this snap-in. By clicking it, you cause the default policies to be displayed in the right pane. You should see Server (Request Security) , Client (Respond Only) , and Secure Server (Require Security) . Following each is a description. You can adjust column widths by positioning your mouse over the vertical line separating labels in the gray header area (Name, Description, Policy Assigned, etc.) and left-clicking and pulling to the left or right.
Locate Server (Request Security) and double-click that policy to display the properties. Alternately, you can select the policy, right-click, and then select Properties from the menu.
The tab selected by default is the Rules tab, which displays the IP Security rules that are part of this policy. Each rule contains several elements: IP Filter List, Filter Action, Authentication, Tunnel Endpoint, and Connection Type.
Select the General tab by clicking it. This tab displays the policy name, description, and how often it will check for policy changes. The default value is 180 minutes, or every three hours.
You can configure additional settings for the key exchange by clicking the Settings button. Click the Settings button to display Key Exchange Settings .
You can change settings for the Key Exchange in this dialog. Click the Methods button to display the IKE security methods options.
In the Key Exchange Security Methods dialog, you can set the preference order for key exchange. The default settings are shown in Figure 5.11.

Figure 5.11: Default Settings for Key Exchange Security Methods for Default IPSec Policy
Use the horizontal scroll bar to view all the fields, which include Type, Encryption, Integrity, and Diffie-Hellman Group. Individual algorithms can be modified by double-clicking the desired algorithm or by clicking the Edit button. Each drop-down list shows choices we ve discussed earlier in this chapter. Take a moment to click each drop-down arrow and view the choices. Test your recall of each of these elements by reciting to yourself the definition and use of each element. The choices you should see are Integrity Algorithm “ MD5 or SHA1, Encryption Algorithm “ 3DES or DES, Diffie-Hellman group “ Low (1), Medium (2), or High (2048).
To avoid making any changes, click Cancel to exit. Click Cancel to exit the Key Exchange Security Methods dialog. Also click Cancel to exit the Key Exchange Settings dialog.
You should now have just the Server (Request Security) Properties dialog open. Click the Rules tab to select that tab.
The IP Security rules list contains three rules. Double-click the first rule All IP Traffic to display the properties for editing. Alternately, you can click the first rule then click the Edit button below.
The Edit Rule Properties dialog is displayed. There are five tabs in this dialog: IP Filter List is selected by default. The other tabs are Filter Action, Authentication Methods, Tunnel Setting and Connection Type, all the fields shown in the Rules dialog. The IP Filter List, Filter Action, and Authentication Methods tabs have options that you can drill down through to view the many different options you can set. Click Cancel to exit these without changing settings. Click Cancel to exit the Edit Rules Properties dialog and return to the Server (Request Security) Properties dialog.
Before we close this dialog, notice the check box in the lower-right corner labeled Use Add Wizard . When this box is selected, the Security Rule Wizard will be opened when you click the Add button. If you deselect this check box, a New Rule Properties dialog will be displayed. This has the same options as the Edit Rule Properties we just explored. You can select the options you want and then click OK to accept or Cancel to exit without saving the rule. When first working with IPSec policies and rules, you might want to use the Security Rule Wizard to step you through creating a new rule. Click Cancel to exit any open dialogs and return to the MMC.
To access the various options within the console related to the IP Security Policies on the Local Computer, right-click the selection (IP Security Policies on Local Computer) or click Action from the menu.
Click Action and select All Tasks .
Notice the actions you can take ”you can create a policy, manage filter lists and actions, restore defaults, and import and export policies.
Exit the MMC by clicking File and then selecting Exit . Click No when prompted to save the console.

As you can see, many levels of options can be configured within the IPSec policies. To keep things simple and make configuring, managing, and troubleshooting IPSec policy easier, make sure you define the fewest possible number of IPSec policies to meet your security needs, apply them at the highest possible level, and apply them to computers in similar roles via the use of OUs. Now you re ready to begin configuring IPSec policy for computers.

Objective 3.1.2: Designing IP Filtering

When designing IP filtering, there are a few design suggestions that will make your task easier. These are delineated in Table 5.12 and describe recommendations for both filter lists and filter actions.

Table 5.12: Filter List and Filter Actions Recommendations
IP Filter Lists	IP Filter Actions
Use general filters if you want to cover many computers with one list. Use Any IP Address or a subnet IP rather than using specific computers IP addresses.	For remote communications, consider using high security levels including 3DES, short key lifetimes, and Perfect Forward Secrecy (PFS) to prevent attacks based on known keys.
Segment your network and define filters that allow you to group and secure traffic by segment.	When using custom security methods, only set ESP confidentiality to None when a higher layer protocol will encrypt the data. Using None can create security holes.
The order in which filters is applied is from most specific to least specific. The order is not indicated comby the order in which they are displayed when viewing IPSec policy. As a result, you might see odd communication behavior during computer startup that should clear up after all filters have been processed.	Do not enable security for nonessential data or when computers are not IPSec aware. To prevent communication with rogue computers, use Filter Actions including blocking or pass-through policies.

Table 5.13: Commonly Used TCP and UDP Ports
Port Number (TCP or UDP)	TCP Description	UDP Description
20	File Transfer [default data]	File Transfer [default data]
21	File Transfer [control]	File Transfer [control]
22	SSH Remote Login Protocol	SSH Remote Login Protocol
23	Telnet	Telnet
25	Simple Mail Transfer Protocol	Simple Mail Transfer Protocol
38	Route Access Protocol	Route Access Protocol
42	Host Name Server	Host Name Server
53	Domain Name Server	Domain Name Server
80	World Wide Web HTTP	World Wide Web HTTP
88	Kerberos	Kerberos
101	NIC Host Name Server	NIC Host Name Server
109	Post Office Protocol ”Version 2	Post Office Protocol ”Version 2
110	Post Office Protocol ”Version 3	Post Office Protocol ”Version 3
113	Authentication Service	Authentication Service
115	Simple File Transfer Protocol	Simple File Transfer Protocol
118	SQL Services	SQL Services
119	Network News Transfer Protocol	Network News Transfer Protocol
137	NetBIOS Name Service	NetBIOS Name Service
138	NetBIOS Datagram Service	NetBIOS Datagram Service
139	NetBIOS Session Service	NetBIOS Session Service
143	Internet Message Access Protocol	Internet Message Access Protocol
156	SQL Service	SQL Service
161	SNMP	SNMP
162	SNMPTRAP	SNMPTRAP
179	Border Gateway Protocol	Border Gateway Protocol
389	Lightweight Directory Access Protocol	Lightweight Directory Access Protocol
443	HTTP protocol over TLS/SSL	HTTP protocol over TLS/SSL
989	FTP protocol, data, over TLS/SSL	FTP protocol, data, over TLS/SSL
990	FTP protocol, control, over TLS/SSL	FTP protocol, control, over TLS/SSL
995	POP3 protocol over TLS/SSL (was SPOP3)	POP3 protocol over TLS/SSL (was SPOP3)

As you can see, there are many TCP and UDP ports defined. The list in Table 5.13 is just a small portion of the entire list maintained by IANA. However, it s helpful to know what TCP and UDP ports are used for which common network functions so you can properly block or permit that traffic. It s also important to understand that TCP and UDP ports can be reserved (port numbers above 1000), and the highest number defined is 65535. Individual companies such as Cisco, Microsoft, and Hewlett-Packard (and hundreds of others) can reserve TCP and UDP port numbers for specific applications. This is also important to know as a network administrator. For example, suppose the director of the Research department comes to you and asks to install an instant messaging (IM) program for the researchers to use in her department. You do some research and find this program uses UDP port 334 for communicating. You could permit UDP port 334 traffic on the research segment but could block it at the gateway or router to keep IM local to that segment. This is an example of a UDP port being used for a particular application and one that might not be one of the more well-known ports.

Objective 3.1.1: Configuring a Firewall Configuration

Firewalls can be used between segments of a network or, more commonly, to protect the corporate network from the Internet. Since the firewall by definition provides a security boundary, configuring IPSec for a firewall makes sense. First, let s look at the firewall function in Windows Server 2003.

Windows 2000, Windows XP, and Windows Server 2003 all included a host-based firewall, often referred to as distributed firewall software or personal firewalls , called Internet Connection Firewall (ICF). Originally designed for home users, businesses found it useful to employ the ICF to provide an additional layer of protection against attack. ICF is a basic firewall program designed to prevent basic intrusion, but it does not include the robust features of full firewall applications. Most third-party firewall applications protect computers from software that could violate user privacy (including spyware, Trojan horses, etc.) or allow an attacker to misuse the target computer. ICF does not provide these features.

Most businesses separate their internal network from the Internet as a common sense security measure. This is typically done using firewalls that block traffic sent to specific ports or protocols. However, corporate networks have gained a level of complexity that often makes it difficult to protect sensitive data at all times. This is especially true because it s difficult, if not impossible, to know every single port that is carrying important information or that needs to be secured. IPSec allows you to provide broader coverage than a firewall might by allowing you to permit, block, or negotiate security for unicast IP traffic.

The difference between IPSec and ICF is that IPSec provides complex static filtering based on IP addresses, and ICF provides stateful filtering for all addresses on a network interface. IPSec is often used in intranets to secure communication between two trusted computers using the Kerberos service or for specific paths across the Internet where PKI can be used. To secure communication via remote access, you would more likely use L2TP/IPSec for VPN connections. This configuration does not require the creation and deployment of IPSec policies. We ll discuss this to some extent later in this chapter when you learn about securing a wireless network.

Exam Warning

It s important to understand the difference between ICF and IPSec in terms of securing the perimeter. Use ICF when you want to implement a firewall for a network interface that can be accessed via the Internet. Use IPSec when you want to secure traffic on the network or when you need to allow access only to a group of trusted computers.

By default, Windows Server 2003 only exempts IKE traffic from filtering. IKE traffic is needed to establish secure communication channels between two computers so secure data can be exchanged. However, you can modify this to remove the exemption and require all traffic to be secured. If you do this, you must configure a IPSec policy on client computers in order for secure communications to be successfully negotiated. The < Dynamic > Default Response rule will not allow a successful negotiation when the server is locked down. For firewalls and servers sitting on the Internet, removing this exemption is the most secure configuration. Leaving this setting as is can expose the server to a DoS attack. For servers not on the Internet or not acting as firewalls, it is acceptable to allow IKE traffic to be unsecured but to require all other data be secured by IPSec.

To configure a firewall between IPSec computers, it must be configured to:

Forward inbound and outbound IPSec traffic on UDP source and destination port 500. This allows ISAKMP traffic to be forwarded.
Forward inbound and outbound IP protocol 50 (ESP).
Forward inbound and outbound IP protocol 51 (AH).
Forward inbound and outbound UDP source and destination port 4500.

Although we re not specifically discussing NAT in this section, it should be noted that if you re using NAT-Traversal (NAT-T), you must also configure forwarding on UDP source and destination port 4500.

IPSec can be routed as normal IP traffic, although the forwarders do not have the ability to examine the packet if it is encrypted with ESP. When there is a firewall or gateway in the path of the IPSec traffic, IP forwarding must be enabled at the firewall as described. L2TP/IPSec traffic looks like IPSec traffic. The firewall forwarding L2TP/IPSec traffic should be configured to allow IKE (UDP port 500) traffic as well as IP protocol 50 (ESP).

In some cases, it might be necessary to allow Kerberos traffic through the firewall as well. In this case, permitting forwarding of UDP and TCP port 88 should also be configured.

Objective 3.1.4: Securing DNS

DNS is the method of resolving IP addresses to domain names or domain names to IP addresses. This vital network service is a target of interest to hackers because access to this data provides valuable data for attacking the network and gaining unauthorized access. Let s review the common threats to a DNS server and then we ll discuss ways to harden security for DNS traffic on the network.

Common Threats to DNS

There are a number of common threats to DNS that must be considered and mitigated when planning security for the enterprise. Table 5.14 shows the common threats and how hackers can exploit these threats. We ll look at ways to mitigate these threats in a moment.

Table 5.14: Common Threats to DNS
Common DNS Threats	Description of Threat
Footprinting	Footprinting is a process where DNS zone information is obtained by a hacker. Once the hacker has the zone data, that person can gather DNS domain names, computer names, and IP addresses for any resource. The hacker can then target servers with sensitive network functions or data. The attacker typically begins the attack by mapping out, or footprinting, the network structure based on captured DNS data. From this information, the attacker can use the structure to determine sensitive servers.
Denial-of-service (DoS)	A DoS attack occurs when an attacker attempts to deny availability of network services to legitimate users by flooding the DNS server(s) with recursive queries. As the server is flooded with queries, CPU processing will spike and eventually users will be unable to get DNS services because the server(s) will be busy trying to respond to this flood of queries.
Data modification or	Once an attacker has successfully footprinted the IP spoofing domain structure, he or she will likely then attempt data modification using valid IP addresses in packets the attacker created in an attempt to pass these packets off as legitimate. This is also called IP spoofing. With a valid IP address and an address that is within the address range of a desired subnet, the attacker can then access network resources including sensitive data.
Redirection	Redirection is an attack that occurs when the hacker is able to redirect DNS name queries to servers under the attacker s control. Redirection can be accomplished in several ways. One common way is to pollute the DNS cache with erroneous data that will cause the DNS server to forward DNS queries and data to the attacker s computer. Redirection can occur anytime a hacker has write access to the DNS server records, which can occur during unsecured dynamic updates.

To properly protect the DNS server service on your network, you must address security at these levels: DNS namespace, DNS server service, DNS zones, DNS resource records (RR), and DNS clients. Let s look at each of these in more detail.

DNS Namespace

The DNS namespace is a hierarchical naming structure that identifies network resources and that resource s place within the space. In contrast, WINS is a flat naming structure that identifies resources but does not indicate that resource s place within that structure. The DNS namespace at the top level is regulated by the Internet naming authority, ICANN (Internet Corporation for Assigned Names and Numbers). If your company does not and will not ever connect to the Internet, you can choose whatever namespace you choose. However, most companies do connect to the Internet and must register a unique namespace via the ICANN process.

The namespace is typically designated by a name followed by an extension, somecompany.com, thiscompany.biz, bigcompany.us, and so forth. The namespace can be divided for administration and security purposed. Let s look at how namespaces can be divided.

Single Namespace

A single domain namespace is what you are assigned if your company registered for a domain name. Even in a small company, if you are connected to the Internet, you should separate your namespace into one or more namespaces to designate internal and external names.

Delegated Namespace

You can divide the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. The decision to delegate the namespace is typically dependent on whether you need to delegate management of part of the namespace for administrative ease, whether you need to divide a large zone for better DNS service (response time, replication time, etc.), or whether you want to extend your namespace with subdomains to accommodate organizational needs.

Internal Namespace

An internal namespace is the namespace you define for your private corporate network. Companies configure these differently, but one common example is to create separate namespaces for separate segments of the business. This can be a fairly flat system or a deeper hierarchy, depending on your organization s needs. For example, your external namespace, as regulated by ICANN, might be somecompany.com. You might choose to create a subdomain (internal namespace) for each division: Finance, Sales, Human Resources, Service, and Manufacturing. Within each of those subdomain namespaces, you can create additional namespaces. For example, you might have na.sales.somecompany.com for North American sales, eu.sales.somecompany.com for European sales, and so forth. All of these are internal namespaces and must be protected. This is exactly the kind of information a hacker would seek to learn via footprinting.

Segmented Namespace

You can split your namespace between internal and external DNS servers. Your external DNS is the root domain, and your internal space is a subdomain of the external space. For example, if your external namespace is somecompany.com, your internal namespace can be defined as corp.somecompany.com. The internal namespace is managed by internal DNS servers behind a firewall, and resolution from external DNS servers to a corporate address occurs from the external DNS server to the internal DNS server via queries.

Securing the Namespace

To secure the DNS namespace, you should separate DNS servers that must resolve names on the Internet from those that do not. By separating internal and external DNS servers, you can restrict external contact to the internal DNS servers. Hosting your internal name space on internal servers and your external name space on external servers will create a first line of defense. To resolve queries for external names made internally, you configure internal DNS servers to forward external queries to external DNS servers for resolution. External hosts use only external DNS servers for name resolution.

For example, by using a segmented namespace, you can create these namespaces: somecompany.com, corporate.somecompany.com, and operations.somecompany.com. The somecompany.com namespace could be on an external DNS server and could resolve external Internet queries. The corporate and operations subdomains would be hosted on internal DNS servers. One DNS server would be the primary master for corporate.somecompany.com, and another would be the secondary server for the subdomain namespace. A second DNS server (perhaps the secondary just described) would be the primary master for the operations.somecompany.com, and the other DNS server would be the secondary for this subdomain. However, in no case does either DNS server resolve Internet name queries ”these are all forwarded to the external DNS server.

For external queries for internal namespace resolution, you should configure the external DNS server to send those queries to only one internal DNS server designated for this role. Configure a packet-filtering firewall to allow only UDP and TCP port 53 communications between your external DNS server and a single internal DNS server. This allows external queries for internal resources but prevents other external computers from gaining access to the DNS namespace.

DNS Server Service

There are a number of ways the DNS Server Service can be configured to reduce the risk of and exposure to attack. The first step is to examine the configuration of the DNS Server Service to review settings that affect security. The second step is to manage the discretionary access lists (DACLs) on DNS servers that are running on domain controllers (DCs). Finally, implementing the NTFS file system on DNS servers running any operating system that supports NTFS protects the files on the server. Let s look at these steps in more detail.

Table 5.15: Securing the DNS Server Service
DNS Security Area	Recommendation	Comments
Interfaces	Some DNS servers are multi- homed computers (multiple network interface cards). The default setting is for each interface to listen for DNS queries using all its IP addresses (all IP addresses assigned to all network interfaces). Limit the IP addresses that the DNS Server Service listens on. The only IP address it should be configured to listen on is the IP address used by its DNS clients ”those clients that use it as their preferred DNS server.	This can be configured via the DNS console by selecting Action Properties Interfaces and select Only the following IP addresses . This will create a static setting that will need to be managed manually in case of change to the IP configuration information. This is an effective security measure because only hosts on the same network or network segment will have access to the DNS server, reducing the exposure to attack.
Secure cache against pollution	We discussed briefly that cache on a DNS server might be corrupted, allowing the attacker to redirect DNS traffic to a computer the attacker controls. By default, the DNS Server Service is secured from cache pollution via the Secure cache against pollution option, which is enabled by default. This prevents cache from being corrupted with records that were not requested by the DNS server, which is typically the only way DNS records get into cache.	In the DNS console, click Action Properties Advanced tab. In Server options, select Secure cache against pollution , and then click OK . This is set by default but can be verified . This prevents entries in cache the DNS server did not specifically request.
Disable recursion	Recursion can be used to attack a DNS server by causing a DoS attack. By default, recursion is enabled . A DNS server may perform recursive queries on behalf of DNS clients and DNS servers that have forwarded DNS client queries to it. If your network does not need this functionality, it should be disabled.	In the DNS console, choose the DNS server, and select the Action Properties Advanced tab. In Server options , place a check mark in the Disable recursion check box and then click OK . If you disable recursion on a particular server, you will be unable to use forwarders on that server.
Root hints	Root hints are stored in the file cache.dns in the systemroot\System32\Dns folder and contains the DNS data stored on the server that identifies the authoritative DNS servers for the root zone of the namespace. The root hints file for internal servers should point only to DNS servers hosting the root domain and NOT to DNS servers hosting the Internet root domain.	To update the root hints on the DNS server, open the DNS console. Select the desired DNS server and select the Action Properties Root hints tab. Select Add, Edit , or Remove as appropriate to modify your root hints file. This prevents internal DNS servers from sending private DNS information over the Internet when responding to name resolution requests.

Examine DNS server configuration to review security settings There are four primary areas to examine and configure for security. Table 5.15 shows these four areas along with recommendations for securing these settings.

The first step in securing the DNS Server Service is to review security settings related to the service, as we ve just done. The next step is to manage access.

Manage DACLs on DNS servers running as DCs DNS servers configured as DCs use DACLs. The DACL allows you to control permissions for Active Directory users and groups that control the DNS Server Service. Table 5.16 lists the default users and groups as well as the permissions for the DNS Server Service when running on a DC. When a DNS server is running as a DC, its DACL can be managed using the Active Directory object or via the DNS console. It s important that administrators don t inadvertently undo each other s security settings via Active Directory and the DNS console, which operate independently but ultimately set the same settings. Although these default settings might be acceptable, best practices for assigning permissions suggests that removing and reducing rights that are not needed and restricting membership to groups with wide power (Administrators, Enterprise Administrators, etc.) will reduce the risk of abuse of credentials.

Table 5.16: Default Users, Groups, and Permissions for the DNS Server Service on a Domain Controller
User or Group	Default Permissions
Administrators	Read, Write, Create All Child objects, Special Permissions
Authenticated Users	Read, Special Permissions
Creator Owner	Special Permissions
DnsAdmins	Full Control. Read, Write, Create All Child objects, Delete Child objects
Domain Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers	Special Permissions
Pre-Windows 2000 Compatible Access	Special Permissions
System	Full Control, Read, Write, Create All Child objects, Delete Child objects

Implement NTFS file system on all DNS servers The third step in securing the DNS Server Service is implementing the NTFS file system format on all system volumes. NTFS allows you to control access to files and folders on a very granular level and integrates with Active Directory, which provides security features not available on volumes running FAT or FAT32.

DNS Zones

DNS zone data can be secured by using secure dynamic updates and security features found in Active Directory when DNS is integrated with Active Directory. There are four major components to securing DNS zones: configure secure dynamic updates, manage DACLs on DNS zones stored in Active Directory, restrict zone transfers, and understand the pros and cons of zone delegation.

Configure secure dynamic updates DNS in Windows Server 2003 is configured not to use dynamic updates, by default. While this is the most secure setting, it also prevents you from using the dynamic update feature that provides significant benefit to administration of zones data. For security, you can implement dynamic updates by storing DNS zones in Active Directory. This is called Active Directory-Integrated zones and allows you to use the secure dynamic update feature in Active Directory to provide both secure and dynamic updates to DNS zone data. Secure dynamic update restricts DNS zone updates to those computers that are authenticated and joined to the Active Directory domain where the DNS server is located. It also forces the secure dynamic update to adhere to the security settings defined in the ACLs for the DNS zone.

Manage DACLs on DNS zones stored in Active Directory Just as the DACLs in the DNS Server Service must be reviewed and modified, as needed, so too must the DACLs for the DNS zones stored in Active Directory. Table 5.17 summarizes the users, groups, and permissions set by default.

Table 5.17: Default Users, Groups, and Permissions for DACLs in Active Directory-Integrated Zones
Default Users and Groups	Default Permissions
Administrators	Read, Write, Create All Child objects, Special Permissions
Authenticated Users	Create All Child objects
Creator Owner	Special Permissions
DnsAdmins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Domain Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers	Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone	Read, Special Permissions
Pre-Windows 2000 Compatible Access	Special Permissions
System	Full Control, Read, Write, Create All Child objects, Delete Child objects

Restrict zone transfers. Typically, zones are transferred only to DNS servers listed in the name server (NS) resource records of a zone. This is the default behavior of DNS in Windows Server 2003. However, to increase security, this setting can be changed to allow zone transfers to specified IP addresses of the DNS servers. This can help prevent redirection attacks by allowing zone transfers to occur only between specific computers with specific IP addresses.

To modify DNS zone transfer settings, open the DNS console, select the DNS zone and select Action Properties Zone Transfer tab. To disable zone transfers, clear the check box labeled Allow zone transfers . To allow zone transfers, select the check box labeled Allow zone transfers . If you allow zone transfers, you can specify one of the following:
- Allow zone transfer To any server . This is not a recommended setting, as it exposes your DNS data to attack. This setting provides virtually no security.
- Allow zone transfer to servers listed on the Name Servers tab. Select Only to servers listed on the Name Servers tab . This is the default setting, which provides medium security.
- Allow zone transfer Only to the following servers . If you select this option, you can enter the IP address of any DNS servers to which you want to transfer zones. This is the most secure setting because it specifies the exact IP address.
Understand the pros and cons of zone delegation. Zone delegation is the process whereby zone administration is separated for ease of administration. The downside to this is that you have more people involved with securing your vital network resources. The more people with the ability to administer your data, the less secure your overall network is. There is a tradeoff between delegation and security, and you must assess the risk for your organization. DNS zones are more secure when there is a single authoritative DNS server but are more difficult to administer. Conversely, delegating zones for various namespaces to different administrators eases administration but reduces security. This is an especially important consideration for the company s top-level domain namespace or any namespace that contains very sensitive data.

DNS Resource Records

A DNS RR contains information about resources in the domain. There are different types of RRs that provide names, IP addresses, and other information related to hostnames. Default settings for DNS RR might be adequate for your organization. To harden security, DNS can be integrated with Active Directory to use Active Directory security features when hosted on a DC. If DNS is integrated with Active Directory, managing the DACLs on the DNS RRs will provide additional security. Again, work with user and group permissions set to the minimum to allow proper functioning. Table 5.18 lists the default permissions for DNS RRs in Active Directory.

Table 5.18: Default DNS Resource Record Permissions for Users and Groups in Active Directory
Default Users and Groups	Default Permissions
Administrators	Read, Write, Create All Child objects, Special Permissions
Authenticated Users	Create All Child Objects
Creator Owner	Special Permissions
DnsAdmins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Domain Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins	Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers	Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone	Read, Special Permissions
Pre-Windows 2000 Compatible Access	Special Permissions
System	Full Control, Read, Write, Create All Child objects, Delete Child objects

DNS Clients

The last of the five areas for securing DNS data is controlling the DNS server IP addresses used by DNS clients. When possible, use static IP addresses for the preferred and alternate DNS servers used by the client. By default, DNS server data is included in dynamic DHCP configuration data, which is fairly secure. However, if the DHCP server is compromised, the DNS server IP address can be modified in DHCP (by an attacker), and DNS clients could be redirected to a bogus DNS server controlled by the attacker. After assessing your organization s risk, you might choose to statically assign the IP address of the preferred and alternate DNS server on DNS clients. In addition, you can control which DNS clients have access to a DNS server. As discussed earlier, you can configure a DNS server to only listen on specific IP addresses. If DNS servers are configured in this way, only DNS clients configured with the IP addresses as preferred or alternate DNS servers will contact the DNS server.

Objective 3.1.5: Designing Security for Data Transmission

Thus far, we ve reviewed IPSec to understand how IP traffic can be secured. We ve also looked at securing DNS, a vital service on most networks today. Now, let s look at the specifics of designing security for the transmission of data. After that, we ll look at the specific needs of securing data for wireless networks.

There are a number of other methods for securing data being transmitted in a number of different scenarios. IPSec works well in some instances, but other options are more viable and appropriate in other instances. In this section, we ll review these options and discuss what they are, how they re used, and how they protect data and privacy on the network.

SSL/TLS

The Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol is typically used to secure HTTP/HTTPS traffic on Web sites. However, SSL/TLS works below the application layer in the TCP/IP stack and can be used transparently by applications that require security for application layer protocols such as FTP, LDAP, or SMTP. SSL/TLS provides server authentication, optional client authentication, data encryption, and data integrity. SSL/TLS can be used to protect against masquerade attacks, man-in-the-middle attacks (sometimes called bucket brigade attacks), and rollback and replay attacks.

SSL was originally developed by Netscape Communications Corporation to secure transaction over the Web. The current version is SSL 3.0. An earlier version, SSL 2.0, is still in use. After SSL was devised, the IETF created a standard for similar functionality called the Transport Layer Security protocol. Although there are subtle differences between SSL 3.0 and TLS 1.0, they are often referred to as SSL/TSL. TLS uses a keyed-hashing for Message Authentication Code, referred to as HMAC. SSL 3.0 uses the Message Authenticate Code (MAC) algorithm. The HMAC s keyed hashing makes it harder to break because the hash algorithm is used in combination with a shared secret key, and both parties must have the same shared secret key to prove the data is authentic .

SSL/TLS works between the application layer and the transport layer and includes two layers of its own: the handshake layer and the record layer. The handshake layer is responsible for setting up the secure connection, and the record layer contains the data. The handshake layer manages the authentication, encryption, and hash algorithms.

Authentication via SSL/TLS is accomplished using an X.509 certificate issued by a CA. Both symmetric and asymmetric keys are used for encryption in SSL/TLS. Symmetric keys, known also as shared secret keys, use the same key to encrypt and decrypt the message. Asymmetric keys use different keys to encrypt and decrypt the message. Typically, one of the keys is a public key and the other key is known only to the owner of that key (private key).

The hash algorithm used is either Message Digest 5 (MD5) or the Standard Hash Algorithm 1 (SHA1). MD5, as you recall, generates a 128-bit hash value, and SHA1 generates the stronger 160-bit hash value. In addition, the SSL/TLS hash algorithm includes a value that checks integrity of the data. TLS uses HMAC and SSL uses MAC. Although HMAC is stronger, both are acceptable hash algorithms to use. Windows Server 2003 supports using SSL and MAC.

Test Day Tip

Although they are similar, SSL and TLS do not interoperate . Both parties must use either SSL or TLS. If the other party cannot use the same protocol, communication will not occur. SSL uses MAC and TLS uses HMAC. Don t be fooled by the common use of SSL/TLS ”they are two separate but similar protocols that cannot be used interchangeably.

Using SSL/TSL provides several important benefits that might make it an appropriate security technology in your organization.

Strong authentication, message integrity, and privacy SSL/TLS provides the ability to transmit secure data using encryption. It also provides server authentication and optional client authentication to prove that the parties involved in the communication are who they say they are. This is accomplished through the use of digital certificates. Data integrity is provides through an integrity check function, similar to that used in the IPSec AH or ESP protocols.
Algorithm flexibility SSL/TLS provides the ability to select authentication methods, encryption algorithms, and hashing algorithms to be used during the secure session.
Easy to deploy and use Deploying SSL for secure browsing in Windows Server 2003 requires that you check a check box to enable this security feature via IIS. Since SSL/TLS resides below the application layer, it is transparent to applications and users and requires no user interaction to enable the secure communication. Although it can be used with various applications and application layer protocols, those applications must be written to use SSL/TLS.

However, there are two notable drawbacks to using SSL/TLS:

Increased CPU utilization As with any encryption system using public keys, the use of SSL/TLS requires additional CPU processor cycles creating overhead that must be anticipated and managed. The increased processor time to manage SSL/TLS is greatest when connections are being set up.
Administrative overhead SSL/TLS uses certificates and certificate-based systems require regular maintenance to configure the system and manage certificates.

Configuring SSL/TLS

You can configure SSL on your Web server but must first obtain a valid certificate. You can use the Web Server Certificate Wizard in Windows Server 2003, or use a third-party company to obtain a certificate. After you ve obtained and installed your certificate, you can enable SSL in IIS.

Exercise 5.03: Objective 3.3: Configuring IIS to Use SSL

Follow these steps to configure your Web server to use SSL in IIS. If you do not have your server configured as an IIS server or if you do not have a valid certificate, you will be unable to perform all of these steps. Review them even if you cannot perform them on your system, as you will likely need to know this information for the exam.

Click Start Administrative Tools Internet Information Services (IIS) Manager .
Expand the IIS node in the left pane to display the three subnodes: Application Pools , Web Sites , and Default Web Site .
Click the + to expand Web Sites, and select the Web site to which you want to add SSL. Right-click on that Web site and select Properties .
The [Name] Web Site Properties dialog is displayed. In the Web site identification section on the Web Site tab, click Advanced , as shown in Figure 5.12.

Figure 5.12: Web Site Properties Dialog
In the Advanced Web site identification box, under Multiple identities for this Web site, verify the address for the IP address is assigned to port 443, the default port for secure communications. Click OK .
To configure additional SSL ports for this Web site, click Add under Multiple Identities of this Web site . Configure additional ports, and then click OK .
On Directory Security , under Secure Communications , click Edit .
Click to select the check box labeled Require secure channel (SSL) in the Secure Communications box, as shown in Figure 5.13.

Figure 5.13: Require Secure Channel (SSL) Configuration
To enable SSL client Certificate authentication and mapping, click the check box for Enable client certificate mapping and click Edit .
If you click the check box labeled Required 128-bit encryption , the browser must support 12-bit encryption.
On the Secure Communications dialog, you can also specify how to handle client certificates: ignore , accept , or require . Requiring client certificates provides the most secure solution and is appropriate for limiting access to the site.
You can enable client certificate mapping, which allows access control to resources using client certificates that can be mapped to user accounts.
You can enable a trust certificate list by clicking the check box labeled Enable certificate trust list . A certificate trust list is a signed list of root certificate authorities that have been deemed reputable by the administrator.
Click OK to accept changes or Cancel to discard changes in the Secure Communications dialog.
Click OK to accept or Cancel to discard changes to the [Name] Web Site Properties dialog.
Click File Exit to close the IIS Manager console.

There are a number of different scenarios in which you might elect to implement SSL/TLS. For example, it s fairly common to see SSL/TLS implemented on Web sites (HTTPS) to provide secure communications with a Web site, particularly when securing an e-commerce transaction. Today, almost all e-commerce servers use SSL/TLS to secure username, password, and credit card transaction information. Although e-commerce is the most predominant and visible application of SSL/TLS, there are other scenarios in which using this security protocol makes sense.

Authenticated client access to a secure site You can provide access to authenticated clients to a secure site by requiring both client and server certificates and by mapping those certificates. Client certificates can be mapped on a one-to-one basis or a many-to-one basis via Active Directory Users and Computers. You can create a group of designated users, map the users certificates to the group, and give the group permission to access the secure site.
Remote access SSL/TLS provides authentication and data protection for remote users logged in to Windows-based systems. E-mail and other applications that use SSL/TLS provide security by requiring authentication and data encryption.
SQL access SQL Server administrators can require client authentication when clients attempt to connect to SQL Server. Either the client or the server can also be configured to require encryption of the data transferred. This is an important feature for SQL databases that contain sensitive information such as payroll, financial, or medical records.
E-mail Microsoft Exchange servers can use SSL/TLS to protect data between servers on the Internet or on the internal intranet. End-to-end security is best accomplished with Secure/Multipurpose Internet Mail Extensions (S/MIME) , discussed in the next section. However, data between servers can be secured via SSL/TSL regardless of whether S/MIME is implemented.

Firewalls and SSL/TLS

If you re using firewalls, SSL/TLS provides an interesting challenge. You have essentially two options. You can open the firewall to allow HTTPS traffic on port 443, which is the typical port for secured HTTP traffic with SSL. However, this means the firewall must allow the traffic based on the apparent source and destination of the packet because the packet is encrypted.

The alternative is to configure the firewall as a proxy server. The problem is that the proxy server must transmit the authenticated identity of the original user to the internal system, which might or might not be secured, exposing this information. You ll have to choose which is the better solution for your firm and monitor it carefully .

S/MIME

S/MIME is used to secure e-mail traffic from one end to the other. As mentioned earlier, SSL can be used to secure server-to-server traffic, but S/MIME is best suited for end-to-end security.

S/MIME is an extension of MIME that supports secure e-mail by enabling the e-mail originator to digitally sign an e-mail to provide proof of both origin and message integrity. It also enables e-mail to be encrypted to provide confidential communication via the Internet. Microsoft Exchange Server 2000 and Exchange Server 2003 both support S/MIME. However, one notable change from Exchange Server 2000 to Exchange Server 2003 is that Key Management is replaced by Certificate Services. Another significant change in Exchange Server 2003 is that it extends the scope of client support by the Microsoft Office Outlook Web Access S/MIME ActiveX Control. This enables Internet Explorer 6 SP1 and later Web clients to send and receive secure S/MIME e-mail. Discussing Exchange Server is outside the scope of this chapter, but it s important that you understand what S/MIME is and in what scenarios it makes sense to use it since you will undoubtedly run into questions related to or involving S/MIME on the exam.

SMB Signing

The Server Message Block (SMB) protocol provides the basis for file and print sharing and remote Windows administration. SMB signing can be implemented to prevent man-in-the-middle attacks because the data in transit is protected. SMB support the digital signing of SMB packets to prevent modification while SMB packets are in transit. As with most security measures, there is a balance between requiring SMB security and system performance.

If you think back to Chapter 2, you ll recall that Server Message Block Signing is negotiated in the secure*.inf predefined security template and is required in the hisec*.inf predefined security template. These settings can be implemented via the predefined security templates, security templates you create, or via Group Policy. It is recommended that you configure these settings inside a security template or group policy to make managing security more streamlined and consistent. To configure these settings via security templates, use the Security Template snap-in in the MMC. To configure these settings via group policy, open the appropriate policy via the Group Policy Editor snap-in in the MMC and expand the console tree in this manner: Computer Configuration Windows Settings Security Settings Local Policies Security Options .

There are four settings related to Server Message Block Signing, as shown in Figure 5.14. By viewing these settings within the predefined security template, securews.inf, you can see exactly how these settings relate. Each of these policy settings can be Enabled, Disabled, or Not Defined. When Enabled, the setting is enforced via the template or group policy. When Disabled, the setting is not enforced. When Not Defined, the check box for that policy has been cleared and that policy is no longer defined in the security database.

Microsoft network client Digitally sign communications (always)
Microsoft network client Digitally sign communications (if server agrees)
Microsoft network server Digitally sign communications (always)
Microsoft network server Digitally sign communications (if client agrees)

These settings must be used in certain combinations for communication to be successful. Table 5.19 outlines these combinations and the results. The if server agrees or if client agrees option essentially enables SMB signing on that computer. If this setting for either the client or server is disabled, SMB signing is disabled on the computer. This is the default setting (SMB disabled) for member servers.

Figure 5.14: Server Message Block Signing Options

Table 5.19: Server Message Block Signing Options
Server Setting*	Client Setting**	Result
Always	Always	SMB signing is required by both client and server. Communication without SMB signing is not allowed.
Always	If server agrees	SMB signing will occur because the client will use SMB signing if the server agrees to it. Since the server requires it, SMB signing will be required and used.
Always	Not defined	The client will not be able to communicate with that server because the server requires SMB signing, which the client is not configured to use.
If client agrees	Always	SMB signing will occur because the server side supports it and the client side requires it.
If client agrees	If server agrees	Both the client and server are able to negotiate the use of SMB signing; therefore, SMB signing will occur.
If client agrees	Not defined.	SMB signing will not occur. The server side will request SMB signing but the client is not configured to support SMB signing. None used.
Not defined	Always	SMB signing will not be implemented because the server is not configured to support it and the client requires it.
Not defined	If server agrees	SMB signing will not be implemented because the server does not support it. The client will attempt to use SMB signing until it finds that the server does not support SMB.
Not defined	None	SMB signing will not occur because neither the client nor the server is configured to use it.

* The Microsoft network server: Digitally sign communications node is implied .

** The Microsoft network client: Digitally sign communications node is implied.

By default, client-side SMB signing is enabled on workstations, servers, and DCs. This means the default setting for the client side is Microsoft network client: Digitally sign communications (if server agrees) . By default, server-side SMB signing is only enabled on DCs, and is disabled by default for member servers. This means the default setting for DCs is Microsoft network server: Digitally sign communications (if client agrees) is enabled and the default setting for member servers is Microsoft network server: Digitally sign communications (if client agrees) is disabled .

What this means is that essentially, all computers (running Windows NT or later) can sign SMB packets, if requested, without further configuration. DCs, by default, are the only servers that are configured to use (enabled) SMB signing. Other computers can be configured to use SMB signing, either as an option or as a requirement. An example of a use for this is a member server that stores sensitive research data. You can configure this server to always require SMB signing. You can either use the default client-side setting, which will use SMB because SMB signing is enabled by default, or you can require SMB signing on the client side as well.

Port Authentication for Switches

Network switches are commonly used to filter network traffic, reducing traffic to segments by filtering or blocking traffic that is not addressed for a particular network segment attached to the switch. Switches effectively segment a network. However, most switches send and received packets to and from any node (computer) attached to the switch. In less secure locations within a corporation, unauthorized users could gain access to the network via a switch. For example, conference rooms, lobbies , or shipping/receiving docks are all places a switch might be located to which outsiders have easy, often unchecked access. In these cases, securing the switch traffic can help secure the network.

Newer switches can be configured to require switch node authentication and authorization before data is transmitted from the network to the node attached to the switch. To accomplish this, each switch is required to have a user account database, but this becomes an administrative nightmare pretty quickly. Newer switches can now be RADIUS clients (in Microsoft, those are IAS clients), using the RADIUS protocol to send connection requests and accounting messages to the RADIUS server. RADIUS servers have access to user account databases and can better manage this data. The RADIUS server can then receive and process the switch s request for a connection and accept or reject it based on stored credentials.

IAS supports switch access authentication via Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Ethernet port type, or virtual local area network (VLAN).

EAP-TLS is used to provide certificate-based authentication for either the computer or the user.
Ethernet port type is typically used when configuring remote access policies. Using this port type, you can create various remote access policies that contain connection parameters specifically designed for switch nodes.

The use of VLAN switching is determined by whether or not the switch access client is authenticated.

Objective 1.2.3: Using Segmented Networks

One of the most common methods of securing network data is to segment the network into smaller sections. Switches, routers, gateways, or firewalls can be configured in between these network segments to manage traffic between and among various network segments. This can be especially helpful for computers in a particular department that require additional security. By placing these computers on a network segment, traffic to and from that segment can be filtered via the gateway.

When traffic for a host on another network or network segment is sent from a host, the packet goes to the host s default gateway. The IP address of a packet is compared to the host s IP address and subnet mask. If the network ID matches, the packet is destined for a computer on the local segment and is not passed on to the gateway. If the network ID does not match, the packet is forwarded to the default gateway for routing to the intended host.

Segmenting a network also improves the efficiency of the network because multicast and broadcast traffic is kept on the local segment, preventing it from being transmitted across the entire network. By segmenting a network, local traffic stays local and remote traffic is forwarded to the gateway. The gateway can be configured to block or permit different types of traffic to protect network segments from either receiving or sending data to unauthorized networks, segments, or hosts.

Objective 3.2: Design Security for Wireless Networks

We ve covered a lot of ground so far in this chapter. We ve covered different ways to protect data across the network. However, we haven t discussed how to protect the wireless network. As you know, wireless technologies are proliferating, and as standards and technologies continue to mature, wireless will no doubt continue to grow in popularity.

Critics of wireless networks point to inherent weaknesses in wireless technologies that create security holes. However, with recent improvements in wireless standards and technologies incorporated into Windows Server 2003 (and Windows XP), many of these issues are adequately addressed. Every networking method has some inherent weaknesses. As with all security planning, you must find an acceptable balance between the need for security and the need for the network to be a useful business tool accessible to and for the people that use its resources. In this section, we ll describe the most secure implementation of wireless networking within the Windows Server 2003 framework as well as touch on some of the less secure methods that you might have seen or read about. Although this chapter assumes your understanding of PKI and RADIUS, we ll review these briefly to refresh your understanding of these technologies.

Types of Wireless Networks

There are essentially four types of wireless networks, based on their range or scope:

Wireless personal area networks (WPANs)
Wireless local area networks (WLANs)
Wireless metropolitan area networks (WMANs)
Wireless wide area networks (WWANs)

A WPAN connects wireless personal devices such as cellular phones, personal digital assistants (PDAs), laptops, or wireless printers. WPANs operate using either infrared or radio frequency (RF). Bluetooth is one example of a radio-frequency-based WPAN and is defined by the IEEE 802.15 specification. Most WPANs provide connectivity up to about 30 feet and, because it uses RF, it can penetrate walls, pockets, and briefcases. Infrared WPANs are limited to line-of-sight and at a distance generally not greater than about three feet. Wireless keyboards and mice often use infrared.

WLANs are designed to provide connectivity to a local area, typically defined as a building or office. WLANs are based on the 802.11 standard. IEEE 802.11 WLANs original throughput was about 1 “2Mbps. Current throughput via the802.11g standard is about 54 Mbps and the range is about 300 feet. Special antennae can be used that boost the range up to five kilometers. A WLAN is implemented by attaching wireless access points (WAPs) to the wired LAN. Wireless users connect via a WAP to the LAN. Some implementations can be peer-to-peer WLANs. Wireless bridges can also be used to connect devices to the wireless network or to connect two wireless networks together.

WMANs connect buildings within a campus or city through infrared or radio frequency. The infrared implementation has limitations due to the requirement to have line-of-site for connectivity. RF is subject to interference from other devices that might operate at the same or nearby frequencies. RF WMANs include multichannel multipoint distribution services (MMDS) and local multipoint distribution services (LMDS), al though a standard for this has not yet been finalized.

WWANs have existed for a while and are most commonly implemented via cell phones. The current technology is not standardized and there are several companies and/or technologies vying for their place in the standard. These technologies are all referred to as second generation (2G), and the International Telecommunication Union is working on a third generation standard known as 3G. Current technologies include Cellular Digital Packet Data (CDPD and Code Division Multiple Access (CDMA).

Brief Wireless History

It will be helpful to begin with a brief history of wireless networking to help you understand the challenges inherent in this type of solution as well as the growing need to implement this type of solution in many organizations.

The Institute of Electrical and Electronic Engineers (IEEE) devised the wireless standard, 802.11, when wireless technology was in its infancy. As you know, the 802.X standards define various standards related to Ethernet networking. At the time of the development of 802.11 standards, there were significant governmental restrictions (U.S. government) on the use of high-strength encryption. Network security was also not a high priority at the time. Thus, the 802.11 standard was developed with relatively weak security by today s security standards (and facing today s security threats).

In today s environment, commonly available network audit tools are available that make breaking into an unsecured wireless network quite simple. The word audit is in quotes because some of these programs are very legitimate network tools and others are nothing more than ill-disguised hacker tools. One such tool describes itself as a tool that cracks encryption keys on 802.11b WEP networks.

You ve probably heard stories of people driving around cities trying to gain access to wireless networks. This practice, called wardriving , brought to the forefront the inherent weakness of some of the wireless networking technologies and also served to point out how many wireless networks were implemented with no security at all.

The IEEE 802.11 standard allows for two wireless network types: ad hoc and infrastructure . In the ad hoc type of wireless network, computers are brought together on the fly and each computer can communicate with all other computers in this ad hoc network. Several different algorithms can be used to control data flow on this network. One such algorithm is called the Spokesman Election Algorithm (SEA), which assigns the master role to one computer to manages this network. Another algorithm uses a broadcast and flooding method to establish order on the ad hoc network. This can be selected via Wireless Network (IEEE 802.11) Policies via the Group Policy Editor snap-in in Windows Server 2003.

An infrastructure-based wireless network is just as the name implies ”it relies on network infrastructure to establish and maintain order. This type of network uses fixed wireless access points (AP or WAP) with which mobile devices can communicate. These WAPs access the LAN and provide a variety of services to the mobile client. These services can (and should) include authentication, access control, and data encryption.

The 802.11 standard for wireless networks has evolved. The progression has been 802.11b, 802.11a, and 802.11g. The 802.11 standard supports operation in the 2.4 through 2.5 GHz range (radio frequency) and has a maximum bit rate of 2 megabits per second (Mbps). The next standard to be implemented was 802.11b (often referred to simply as Wi-Fi), which supports two additional speeds ”5.5 Mbps and 11 Mbps, still within the 2.4 to 2.5 GHz range. The next standard to emerge was the 802.11a standard, which operates in a different frequency range than does 802.11 or 802.11b. The range for 802.11a is 5.725 through 5.875 GHz and the maximum throughput is 54 Mbps. Finally, the 802.11g specification was announced in June 2003 and essentially doubles the throughput for 802.11b from 11 Mbps to 54 Mbps. Thus, 802.11g uses the 2.4 to 2.5 GHz range with maximum throughput of 54 Mbps. 802.11g is essentially an extension of 802.11b and is therefore backward compatible. Devices that use 802.11g can co-exist with 802.11b devices, and if needed, 802.11g devices can fall back to the slower 11 Mbps throughput speed. 802.11b devices are not forward compatible, meaning they cannot be boosted to run 54 Mbps throughput, although they can co-exist with the faster 802.11g devices.

You might wonder why the frequency (GHz) specification is given or specified, but this is an important element in understanding wireless networks. This range is within the radio frequency range, and as the wireless network range expands, there might be cases where the wireless network range overlaps with other commercial uses of radio frequency, causing interference for both uses. Radio frequency can also be used as an attack method by using the wireless frequency to disrupt communication between a wireless network and wireless device.

The 802.11 standard includes a protocol called Wired Equivalent Privacy (WEP). WEP provides some level of security, but, as the previous paragraph points out, there are tools readily available that can crack WEP encryption. An extension of WEP is called Wi-Fi Protected Access (WPA) and is just beginning to be available on the market. Both WEP and WPA provide methods for encrypting wireless traffic between wireless clients and wireless access points (APs or WAPs).

WEP and WPA provide secure communication, but some method must be used to authenticate users. Different 802.1X-based WLANs offer different solutions to this need. The preferred solution within the Windows Server 2003 environment is the use of the IETF standard called Extensible Authentication Protocol (EAP). EAP can use various authentication methods that are based on passwords, public key certificates, or other credentials.

The IEEE has also defined standards for authenticating access to a network and, optionally , for managing keys to protect traffic. Although this framework, called 802.1X, can be implemented in wired LANs, its applicability to wireless access is clear.

Although there is a wealth of information available on these standards and many more, our focus will be on these technologies.

Note

For more information on the IEEE, visit their Web site at www.ieee.org. Additional information on the IETF can be found at www.ietf.org. Understanding standards and reading about changes to standards is a good way to keep up to date on changing technologies that might become important to your network and your organization.

Threats to Wireless Networks

Before going into the technologies any further, let s look at some of the threats to wireless networks. Clearly, some of the threats are the same as on a wired network, but there are threats that are specific to wireless networks. We ll look at each threat and point out the best current solution for mitigating that threat. Table 5.20 lists the threats and descriptions and defines whether the threat is a wired/wireless threat or just a wireless threat.

Table 5.20: Common Threats to Wireless Networks
Threat	Description	Type of Threat
Eavesdropping	The unauthorized capturing of transmitted data for malicious purposes.	Both (wired and wireless)
Data modification	The interception and modification of data transmitted between to parties by a third party.	Both
Spoofing	The modification of data to appear as though data came from the sender or receiver when it was from a third party.	Both
Free-loading	When an unauthorized party uses your network bandwidth.	Wireless
Denial of service (DoS)	When a server is flooded with service requests that cause legitimate users to be denied use of that service because it is busy or overloaded.	Both, although different on wireless
Accidental network access	When a user with a wireless connection on his or her device accesses the network accidentally .	Wireless
Rogue wireless networks	When legitimate users within a company establish an unauthorized wireless LAN that is connected to the corporate network.	Both

As you can see, many of the threats to wireless networks are the same as for wired networks, although the methods of attack and mitigation might be slightly different. An interesting note about DoS attacks is that a wireless DoS can be caused by something as innocuous as a nearby microwave oven. More sophisticated DoS attacks target the wireless protocols, and less sophisticated attacks typically generate a DoS attack by flooding the WLAN with random traffic.

In addition to these threats, there are widely reported problems with WLAN technologies that are leveraged by attackers. Some of these problems that cause companies to delay or reject wireless networking include:

Confusion over wireless security standards
Management concern about the ability to control and manage wireless networks
Regulatory concerns about privacy, including finance and health care (HIPAA)

Early adopters of wireless technologies discovered that the security measures outlined in the 802.11 specification were flawed. There have been a number of attempts to address these flaws, which might have caused further confusion. Emerging standards provide better security, but there are still companies that are resistant to adopting a wireless model of any kind because of these concerns, both real and perceived.

Another major concern for some companies is the perceived inability to manage wireless LANs effectively. When someone actually taps into a wired network, intrusion can be detected and the intruder must find a way to physically connect to the network. With wireless networking, intrusion is virtually undetectable so it s difficult (or impossible) to determine who s connected to your wireless network. According to Les Vadasz, retired executive vice president of Intel, who spoke at the Wi-Fi Planet Conference & Expo (December 2003), over two- thirds of network architects at large enterprises fear that adding wireless will compromise their network security, and more than half of executives see rogue access points as a serious problem. There are methods for mitigating this, which we ll discuss in this section.

There is a growing body of legislation, both at the U.S. national and state level, to protect electronic data in cases where that data is sensitive. Two examples are data from the finance sector, whether it s a record of your online brokerage account or a record of corporate finances, and health care data. In 1996, the U.S. government established the Health Insurance Portability and Accountability Act of 1996 (HIPAA), which among other things, requires specific and secure handling of personal health care data.

These concerns are quite legitimate and, coupled with the growing list of attacks discussed earlier, are rational reasons why companies might elect to wait on implementing wireless networks. However, as we ll discuss shortly, there are effective technologies available today to eliminate or mitigate many of the risks, much as there are with wired networks. It might take a bit more planning on the front end to design and implement a secure wireless network. However, the cost savings and other tangible and intangible benefits will offset that additional work in many instances.

Quick Review of PKI and RADIUS/IAS

There are several considerations when designing and implementing a wireless network. You must:

Design a secure wireless network strategy as part of your overall security strategy.
Design a secure wireless architecture to implement the most secure technologies and architectures.
Evaluate (and/or implement) PKI.
Evaluate (and/or implement) RADIUS/IAS.
Design securing around the 802.1X standard.

Before we go into the design of the wireless network, let s take few minutes to review both PKI and RADIUS, which is implemented as Internet Authentication Service (IAS) in the Windows platform. Although familiarity with PKI and RADIUS/IAS is assumed, both topics are covered in detail in this book, so our review here will be brief.

Public Key Infrastructure

A PKI consists of certificates, CAs, and other registration authorities (RAs). Together, these verify and authenticate the identity of each party. Standards for PKI are evolving, but support for PKI is implemented in Windows Server 2003 and Windows XP. Although earlier versions of Windows supported elements of PKI, Windows Server 2003 and Windows XP use the latest features in PKI technology.

PKI is used in a number of different ways in Windows Server 2003. For example, it can be used to secure a wireless network, as we re discussing. It is also used to implement secure e-mail via S/MIME and to secure Web traffic via SSL and TLS, all discussed earlier. You can use PKI to implement smart cards for strong authentication as well as to implement EFS and IPSec.

Certificate

A certificate is a digital statement issued by a CA verifying and vouching for the identity of the certificate holder. The certificate binds a public key to the identity of the certificate holder, who holds the corresponding private key. Windows Server 2003 certificate-based processes use the X.509v3 format, which includes information about the certificate holder (person or entity), information about the certificate, and optional information about the CA.

Certificate Authority

A CA is an entity responsible for establishing and vouching for authenticity of the public keys issued to the certificate holder or other CAs. CA activities including binding the public key to the identity of the certificate holder, managing certificate serial numbers, and certificate revocation.

Certificate Revocation List

A CRL is used by both CAs and certificate verifiers to verify that a certificate is still good. In cases where a certificate is stolen or is otherwise considered invalid, a certificate can be revoked by the CA. When a certificate holder uses a certificate for authentication, that certificate is verified against the CRL. If it matches, the authentication is denied and the user is denied access. If it does not match (meaning it is not on the CRL), the user is authenticated and the authentication process continues.

Certificate Services

Windows Server 2003 (Standard, Enterprise, and Datacenter Editions only) includes functionality to set up and maintain your own CA via Certificate Services. You can issue, manage, and revoke certificates using Certificate Services.

Remote Authentication Dial-In User Service and Internet Authentication Service

RADIUS is a protocol defined by IETF RFCs 3865 and 2866. RADIUS is implemented in Windows Server 2003 as IAS, which is why you often seem them referred to together. RADIUS is used to provide centralized authentication, authorization, and accounting for dial-up access, VPNs, authenticating Ethernet switches, Digital Subscriber Line (DSL) access, wireless network access, and other network access methods.

RADIUS is implemented in a client/server model. The RADIUS server provides the authentication, authorization, and accounting services to RADIUS clients. RADIUS clients are typically remote access servers (RAS), VPN servers, or wireless access points (WAP). When a user wants to access the network, the user connects to the RADIUS client (again, RAS, VPN, WAP, etc.) and the authentication credentials and connection information are sent to the RADIUS server for verification. The RADIUS server authenticates and authorizes the user and sends a RADIUS message back to the RADIUS client. The user is then permitted access as defined by access policies and user permissions. The RADIUS messages from the client to the server and from the server to the client are never transmitted back to the user or user machine.

For point-to-point (PPP) authentication protocols, the results of authentication between the access server/RADIUS client (RAS, VPN server, WAP) and the user s computer are then forwarded to the RADIUS server for verification. PPP protocols include:

Password Authentication Protocol (PAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
MS-CHAP version 2 (MS-CHAP v2)

RADIUS supports the use of RADIUS proxies, which forward traffic back and forth between RADIUS clients, RADIUS servers, and other RADIUS proxies. RADIUS traffic between RADIUS clients, servers, and proxies is secured using a common shared secret, commonly configured as a text string at both ends.

Designing Wireless LANs

Designing a secure wireless network takes planning and integration with existing infrastructure. Some industry analysts believe that wireless networking will become the de facto standard, so understanding how to design a wireless network will help you both on the job and on the exam.

Exam Warning

You should expect to see strong emphasis on wireless networking on this exam. Wireless networking is a hot topic these days, and the improvements to the Windows Server 2003 wireless networking capabilities will certainly warrant several questions on the topic. Make sure you re very comfortable with PKI, RADIUS/IAS, and wireless topics for this exam.

The elements of designing a wireless network include:

Designing WLAN network infrastructure
Designing wireless authentication
Designing wireless access infrastructure

Objective 3.2.1: Designing WLAN Network Infrastructure

Although there are many ways to design and implement a wireless network, we re only going to consider methods that provide a secure wireless solution using technologies in Windows Server 2003. The following network infrastructure elements must be in place in order to implement a secure WLAN. These are summarized in Table 5.21.

Table 5.21: WLAN Network Infrastructure Requirements
Infrastructure Requirement	Function
Active Directory	Stores user and computer accounts, validates credentials.
DHCP	Provides automatic IP configuration for wireless devices.
DNS	Provides name resolution.
PKI	Provides certificates for authentication and authorization. Used by EAP-TLS, PEAP-TLS. TLS can use smart cards or Registry-based certificates.
RADIUS/IAS	Provides centralized authentication, authorization, and accounting for remote connections, including WLAN.

Let s take a look at each of these in more detail.

Active Directory

You ll need to determine which users and groups should have wireless access. Then, via groups and group policy, you can enforce those selections. With Active Directory, these settings are enforced across the domain to ensure consistent application of access and security policies for all users, including wireless users.

Several group policy settings are related to wireless connections, including data installed on wireless clients regarding user and computer certificate auto-enrollment, Wireless Network Policy settings that specify the preferred networks, 802.1X settings, and WEP settings. These can be specified in group policy.

Exercise 5.04: Create a Wireless Network Policy

To create a wireless network policy via group policy, use the following steps.

Open the Microsoft Management Console by clicking Start Run and then typing mmc in the Open: box. Click OK or press Enter .
Click File Add/Remove Snap-in . In the Add/Remove Snap-in dialog, click Add .
In the Add Standalone Snap-in dialog, scroll down to select the Group Policy Editor snap-in. Click Add . When prompted to select the Group Policy Object :, click Browse .
Locate the Default Domain Policy in the Browse for a Group Policy Object , click to select it, and then click OK .
Click Finish to select the Default Domain Policy as the GPO.
Click Close on the Add Standalone Snap-in dialog to return to the Add/Remove Snap-in dialog. Click OK to return to the MMC.
In the MMC s left pane, click the + to expand the Default Domain Policy.
Click + to expand the Computer Configuration node.
Click + to expand the Windows Settings node.
Click + to expand the Security Settings node.
Click + to expand the Wireless Network (IEEE 802.11) Policies node. If there is nothing beneath the node, the + will not be displayed and the tree will not expand.
Right-click Wireless Network (IEEE 802.11) Policies or click Action on the menu and select Create Wireless Network Policy . This launches the Wireless Network Policy Wizard. Click Next to continue.
Type a name for the wireless policy in the Name: box. Type a description for the policy that will help you identify this policy and describe what it does. Click Next .
The next screen is the completion screen. Leave the check box labeled Edit Properties selected and click Finish .
The policy properties will be displayed, as shown in Figure 5.15.

Figure 5.15: Sample Domain Wireless Policy Properties Dialog
If you want to modify how often Active Directory polls for changes, you can change the value in the Check for policy changes every: setting, which defaults to 180 minutes.
Specify the type of wireless network the clients can access by selecting a network type in the Networks to access drop-down box as shown in Figure 5.15. For this exercise, select the default Any available network (access point preferred) . This setting allows the wireless user to connect to any available network but will attempt to connect to the Preferred Network first. Using this setting does allow users to participate in an ad hoc network and, depending on your corporate environment, this might pose a security problem. If it does, select the second choice, Access point (infrastructure) networks only . There might be reasons to only allow the computers to connect to only via an ad hoc network. If so, select the third option, Computer-to-computer (ad hoc) networks only .
To allow clients to configure their own wireless settings, leave the Use Windows to configure wireless network settings for clients check box selected. To prevent users from doing this, clear the check box.
To allow users to connect to networks that do not appear in the Preferred Networks tab, check this box. To ensure clients connect only to networks that appear on the Preferred Networks tab, clear the check box for Automatically connect to non-preferred networks . This option is cleared by default for security. When this is not selected, Windows XP users will be notified of available wireless networks but will not be automatically connected. If the user chooses to connect to the nonpreferred network, they must take an action to do so. This choice strikes a balance between security and usability.
Preferred Networks are configured on the Preferred Networks tab of the Properties dialog. Click to select this tab. To add a network, click Add . The New Preferred Settings Properties dialog opens, as shown in Figure 5.16.

Figure 5.16: Adding a New Preferred Network
Enter a unique name for the new preferred network and enter a description in the description box that will help you to identify this network.
In the Wireless network key (WEP) section, there are three check boxes: Data encryption (WEP enabled) , Network authentication (Shared mode) , and The key is provided automatically .
- Selecting the Data encryption (WEP enabled) setting will require a network key to be used for encryption. Select this to ensure encryption is used to provide security on the wireless network. This is selected by default.
- Selecting the Network authentication (Shared mode) setting will require that a network key be used for authentication. If this is not selected, the network will operate in open system authentication mode, which is more secure. This setting should be cleared. A shared key strategy uses a static WEP key, which can be easily cracked and requires a fair amount of administrative work to change or update. Due to the administrative burden , shared keys are rarely changed, which leads to security holes. This is not selected by default.
- Selecting The key is provided automatically setting determines whether a network key is automatically provided for clients. This option should be selected so that the policy uses 802.1X to provide dynamic WEP session keys for encryption traffic. This is a more secure solution than using static WEP keys. This is selected by default.
The last option in the New Preferred Setting Properties dialog is a check box labeled This is a computer-to-computer (ad hoc) network; wireless access points are not used . This box is not selected by default, indicating the network is an infrastructure-based wireless network (uses wireless access points).
The second tab in the New Preferred Setting Properties dialog is the IEEE 802.1X tab, which allows you to set parameters for 802.1X, a port-based network access control. We ll discuss this later in this section. For now, accept the default options and click OK .
Click OK to close the Sample Domain Wireless Policy Properties dialog.
You should now be in the MMC and should have a Wireless Network (IEEE 802.11) Policies policy, as shown in Figure 5.17.

Figure 5.17: Wireless Policy Defined in Default Domain

DHCP Configuration

DHCP scopes and leases are configured differently for wireless networks than they are for wired networks. Typically, scopes are defined by network segments, a collection of related IP addresses. To configure a secure wireless solution, create a separate scope for wireless clients. By using a separate scope, you can configure lease requirements differently for wired and wireless clients.

Wireless users connect and disconnect from the network far more often than do computers that are connected to a wired network. The default lease period for an IP address is eight days. Your organization might use a slightly different default, but typically, leases are not renewed more often than every few days to once a week. Wireless users do not release their IP address when they disconnect from the network. This means that if you use the default (or standard) lease period, the unused IP addresses held by the disconnected wireless users will be unavailable for long periods of time. For the scope that contains the wireless users, reduce the lease time significantly. The preferred setting will depend on a number of factors, most notably the typical behavior of wireless users on your network and the tolerance to the additional load on the DHCP server(s). For example, if most of your wireless users connect and disconnect throughout the day but remain at one location, you might use a lease period of 18 hours. However,, if you have a lot of wireless users connecting, disconnecting, and leaving the network for several weeks at a time, you might elect to create shorter lease periods of several hours. You might also choose to create more than one scope for wireless users if your users wireless connection behaviors are dramatically different.

DNS Configuration

To configure DNS for secure wireless networking, it s recommended that you integrate DNS with Active Directory to support secure dynamic updates. This is a recommended configuration for wired and wireless networks. In DNS, you should identify the DNS zones in which wireless computers will register DNS address records. If you re not using Active Directory-Integrated zones, then you should ensure that DNS zones are configured for dynamic updates, since wireless computers DNS settings might change more often than computers connected via the wired LAN. As discussed in the DHCP section, if you set your IP lease time to a lower value, your DNS records might change more often. Using secure dynamic updates provides the most secure configuration and reduces administrative overhead.

Public Key Infrastructure

PKI is discussed at length elsewhere in this book. As we discussed earlier, PKI relies on certificates to provide strong authentication credentials. You will need to set up a CA in Windows Server 2003 to create certificates for PKI, or obtain your certificates from a third-party provider. Once the certificates are created, they must be properly installed on the servers and clients that will use them.

Although it is possible to implement a wireless network without the use of PKI and RADIUS/IAS (discussed next), it is highly recommended that you use the Windows Server 2003 features to design and build a secure wireless network.

RADIUS/IAS

A discussion of how to design and implement RADIUS/IAS is outside the scope of this chapter. However, you should use RADIUS/IAS to manage remote connection authentication for better security and ease of administration. You should verify that the Internet Authentication Server (IAS), Microsoft s implementation of the RADIUS standard, can use the Extensible Authentication Protocol ”Transport Layer Security (EAP-TLS). This requires the installation of a certificate on the IAS server. This topic is covered in additional detail in various other chapters in the book.

If you use Active Directory as the directory service and IAS as the RADIUS server, you can provide a single logon solution for users. This way, users can log on the same way whether they re connecting to the wired network or the wireless network. If you implement certificates, you can use smart cards for user logon authentication. The IAS server must also support Protected Extensible Authentication Protocol (PEAP)-Microsoft Handshake Challenge Authentication Protocol version 2 (MS-CHAPv2). This is used for password-based security environments.

Objective 3.2.2: Designing Authentication for Wireless Networks

The security mechanisms available for securing a wireless network are:

802.11 identity verification and authentication
802.11 Wired Equivalency Privacy (WEP) encryption
802.1X authentication
IAS support for 802.1X authentication

We ll discuss each of these in detail so you can see how security differs among these security solutions.

802.11 Identity Verification and Authentication

This is the least secure method because it uses open system authentication and shared key authentication . Open system authentication is not true authentication because it performs only identity verification between the wireless client and the wireless access point. Shared key authentication is even less secure than open system authentication. Shared key authentication provides authentication by verifying that the wireless client has the shared key. Under the 802.11 standard, it is assumed the shared key was provided to the wireless client via a secured method such as over a secure wired network or via floppy disk.

For better security, do not use the shared key authentication method because it requires the exchange of a secret key that is shared by all wireless access points and wireless clients, making it more vulnerable to attack.

802.11 Wired Equivalency Privacy (WEP) Encryption

The 802.11 specification also defines an encryption algorithm, Wired Equivalency Privacy (WEP). It provides data confidentiality by encrypting data sent between the wireless access point and wireless clients. The encryption used by WEP is the RC4 stream cipher that uses either 40-bit or 104-bit encryption key. The integrity of the data frame itself is provided by an integrity check value (ICV) in the encrypted portion of the frame so it cannot be tampered with or viewed.

Recent studies have shown that there are flaws within the WEP encryption method, and there are now several software products available that can easily crack WEP encryption, so this method is less secure that it was even three or five years ago.

Although there are known issues with this method, it is widely used in wireless networks that are configured today. It might be appropriate for smaller organizations that do not have the infrastructure or IT capabilities to implement and manage a more complex solution requiring certificates and other encryption methods, as described next. The balance between security and ease of implementation and management might make sense for some organizations where the risk of intrusion is low or where the cost of recovering from intrusion is low. However, in organizations where security of network data is critical, this is no longer a viable solution.

802.1X Authentication

802.1X is the IEEE standard for authenticated access to Ethernet-based networks and wireless 802.11 networks. This standard supports centralized user identification, authentication, dynamic key management, and accounting, all features that can be provided by a RADIUS server. The 802.1X standard improves security because both the wireless client and the network authenticate to each other. A unique per-user/ per-session key is used to encrypt data over the wireless connection and keys are dynamically generated, reducing administrative overhead and eliminating the ability to crack a key because the key is generally not used long enough for a hacker to capture enough data to then determine the key and crack it.

The 802.1X authentication method is supported in Windows XP (requires Service Pack 1) and Windows Server 2003. 802.1X authentication is only available for the access point (infrastructure) network type that requires the use of a network key (WEP). The most secure solution uses 802.1X, and connecting to a wireless network using anything less secure exposes your data to potential capture, modification, and malicious packet injection.

802.1X and Extensible Authentication Protocol

The 802.1X standard uses EAP for message exchange during the authentication process, to protect the contents of the authentication process. Remember that EAP is an extension of the PPP protocol that provides arbitrary authentication mechanisms to be used for the validation of a connection. Thus, with EAP, arbitrary authentication mechanisms such as certificates, smart cards, or passwords can be used to authenticate the wireless connection.

There are three authentication methods available using EAP, and you can use any of the following:

EAP-TLS EAP-TLS uses certificates for server authentication. Client and computer authentication is provided by either certificates or smart cards.
PEAP with EAP-MS-CHAPv2 Protected EAP (PEAP) with EAP-MS-CHAPv2 uses certificates for server authentication. User authentication is via username and password (also called password-based authentication).

PEAP with EAP-TLS PEAP with EAP-TLS uses certificates for server authentication and either certificates or smart cards for user and computer authentication. PEAP is supported for wireless user and computer authentication, but is not supported for VPN or remote access clients. PEAP with EAP-TLS provides an encrypted channel for EAP-TLS authentication traffic.

Exam Warning

If you deploy both PEAP and EAP unprotected by PEAP , don t use the same EAP authentication type for both. For example, if you deploy PEAP with EAP-TLS, don t use EAP-TLS without PEAP. Using authentication methods with the same type (in this case, EAP-TLS), one with PEAP and the other without PEAP, creates a security vulnerability. If you see exam scenarios or solutions that use the same authentication method with and without PEAP, you ll know that solution causes a security hole (which might be the right answer, depending on how the question is presented).

To use EAP-TLS, you ll need to verify that the certificate infrastructure is in place. Windows Server 2003 supports Certificate Servers, so you can issue certificates to the users, computers, and IAS servers involved in wireless networking. EAP-TL is not supported if the IAS or remote access server is not a member of the domain.

To use PEAP-MS-CHAPv2, you ll need to verify your IAS servers have computer certificates installed. On the other end, you ll need to verify that all wireless computers have the root CA certificates of the issuer of the computer certificates that the IAS servers have installed. You can use third-party CAs to issue certificates as long as the certificates meet the requirements for TLS authentication.

IAS Support for 802.1X Authentication

As stated earlier in this chapter, IAS is the Microsoft implementation of RADIUS, another IEEE standard . Thus, a Microsoft IAS server is a RADIUS server. As such, it can be used to enhance security and deployment of wireless networks. Although configuration of an IAS is outside the scope of this chapter, you should be familiar with configuring IAS on Windows Server 2003 computers.

When you use RADIUS/IAS, wireless access points are configured as RADIUS clients and use the RADIUS protocol to send connection requests to the RADIUS/IAS server. The RADIUS server uses a user account database to verify the user against the database (authentication) and then verifies that user has appropriate permissions to connect to the LAN via the wireless access point (access). Once the RADIUS server compares the request with the user database information, it either issues permission for the user to connect or rejects the request. This information is passed back to the wireless access point using the RADIUS protocol.

This configuration, using IAS with wireless access points, is the most secure solution for wireless networking in the Windows Server 2003 environment.

802.1X Group Policy Settings

Now that we ve discussed 802.1X and earlier stepped through creating a wireless network policy, let s look the range of settings available on the IEEE 802.1X tab.

Briefly, this is accessed with the Group Policy Object Editor snap-in in the MMC.

Right-click the Wireless Access Policy (or whatever name you gave it).
Click the Preferred Networks tab, click the Network Name shown in the Networks: box, then click Edit .
In the Edit [Network Name] properties , click the IEEE 802.1X tab.
Figure 5.18 shows this dialog with the associated options. We ll walk through each of them now.

Figure 5.18: IEEE 802.1X Properties in the Selected Preferred Network
- Enable network access control using IEEE 802.1X This check box must be selected to use 802.1X capabilities on this wireless network.
- EAPOL-Start message Your three options are: Do not transmit, Transmit, and Transmit per IEEE 802.1x. This message tells the client to begin the authentication process. It specifies whether to transmit EAP over LAN (EAPOL)-Start message packets and if so, how to transmit them. The default setting of Transmit is typically acceptable.
  - Parameters (seconds) These parameters are used to define the EAPOL-Start message packet. The default settings are usually the best settings unless you have clear reasons for changing them.
  - Max Start (default 3) Determines the number of successive EAP over LAN-Start messages the client will transmit when not receiving a response.
  - Held Period (default 60) Determines the amount of time the client will wait before re-attempting a failed 802.1X authentication.
  - Start Period (default 60) Determines the amount of time between EAPOL-Start messages when resending.
  - Authentication Period (default 30) Determines the amount of time between 802.1X request messages resent upon not receiving a response.
- EAP type
  - Smart card or other certificate Smart card or other certificate is the default option for EAP type. This specifies EAP-TLS as the EAP type.
  - Protected EAP (PEAP) You can select this option as your EAP type to use Protected EAP.
- EAP type Settings Both EAP types have various options that can be configured via the Settings button. Figure 5.19 shows the Smart Card or other Certificate Properties, and Figure 5.20 shows the PEAP settings available.
  
  Figure 5.19: Smart Card or Other Certificate Properties Options
  
  Figure 5.20: Protected EAP Properties Options
  - Authenticate as guest when user or computer information is unavailable This check box is cleared by default. If you want to provide public wireless access for visitors to connect to the Internet, for example, you can check this box to allow guest authentication. Unless the wireless network is for public use and is not connected to the internal corporate network, do not use this setting.
  - Authenticate as computer when computer information is available This setting uses computer-based authentication, discussed in more detail in the next section. It is recommended that you check this box, which is checked by default, for the best security and most convenient network configuration. If this box is not checked, the next option, computer authentication, is disabled.
  - Computer authentication There are three options to choose from in this final IEEE 802.1X parameter.
  - With user authentication If this setting is selected, when users are not logged on, the computer credentials are used. However, when a user logs on, the authentication established by the computer credentials is maintained.
  - With user re-authentication This is the default (and recommended) option and ensures that the users credentials are used whenever possible. When user credentials are not available, computer credentials will be used. Computer credentials are used until a user logs on. Then, the user credentials are used. When the user logs off, the computer credentials are again used.
  - Computer only This options specifies that user credentials will not be used and that only computer credentials will be used. User credentials are never checked with this option selected.

Selecting User or Computer-Based Authentication

For the most secure wireless network, you should consider using both user- and computer-based authentication. Although user authentication is a natural choice, there are instances when computer-based authentication also makes sense. The default choices in Windows XP Professional 802.1X client allow for computer-based authentication when users are not logged on and user authentication when users are logged on. This ensures user authentication is always used when a user is connected but also allows various Windows features to work properly when the user is logged off. Table 5.22 delineates the computer-based authentication scenarios.

Table 5.22: Computer-Based Authentication Scenarios
Windows Feature	Scenario
Active Directory Computer Group	Recall that computer group policy is applied Policy during computer startup and at regularly scheduled intervals. Computer-based authentication provides this capability because no user is logged on during startup.
Remote Desktop Connection	A computer that is on but not logged in to by a user can be accessed via the RDC if computer-based authentication is used.
Systems management agents	Microsoft System Management Server and other system agents can access the computer without user intervention with computer-based authentication.
Network logon scripts	Network logon scripts are run during user logon. Computer-based authentication is required because the user is not yet logged on and has not yet received user authentication.
Shared folders	If the computer is on but not logged in to, shared files and folders on the wireless device are still available if computer-based authentication is used.

Head of the Class
Understanding WEP Flaws, Threats, and Countermeasures

There are ever-evolving threats to WEP encryption. As mentioned earlier, there are programs available today that will crack WEP encryption. However, WEP can still be used effectively, and the emerging WPA standard will address some of the security flaws in WEP. It is anticipated that throughout 2004, WPA-based hardware and software solutions will become more widely available. However, let s take a look at the WEP encryption vulnerability.

Even with 802.1X dynamic key management and WEP, a determined hacker could still leverage flaws within the WEP encryption scheme. This flaw is well documented and if you want to understand the mathematical basis for this flaw, you can read about it in great detail in a draft document located at www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf entitled Intercepting Mobile Communications: The Insecurity of 802.11 DRAFT. Suffice it to say that the flaw can be leveraged but it requires two things: a certain amount of network traffic to be captured by the attacker, and a sufficient amount of time (or computer power) for the hacker to perform the crack.

The primary strategy, then, for keeping WEP secure, is to limit the amount of time a key is used. This prevents adequate network data from being captured before the key is changed and prevents the hacker from having time to crack the code before a new key is used. This is accomplished via the key refresh functionality present in wireless access points or by setting IAS RADIUS options to enforce automatic client-re-authentication including WEP key refresh. By forcing the re-authentication every 10 minutes, the hacker does not have time to both capture sufficient data and crack the key. Let s look at the math.

We know the theoretical maximum throughput rate for 802.11a is 54 Mbps. We also know that the actual throughput is about 60 percent of that, or 32Mbps. This is the equivalent of 4MB/second (a byte is eight bits, so 32 megabits divided by 8 bits is 4 megabytes). WEP only encrypts data packets, and data packets average 80 bytes. 4MB divided by 80 bytes equals 50,000 packets per second. Based on attacks known at this time, a maximum of 10 minutes (or the rough equivalent of 30,000,000 packets) is the recommended time for using a single WEP key.

It s important to understand several things, though. First, computing power continues to increase as do the sophistication of cracking programs. Second, there is additional network overhead used every time a key is re-established. When users frequently have to be re-authenticated, it can cause increased loads on IAS servers, WAPs, and client computers, which could have a negative impact on usability.

Look closely at your business model, your corporate computing needs, and your infrastructure to determine the threat level of wireless attack. Moreover, although it s hard to do at times, you ll have to assess the cost of prevention versus the cost of remediation . It s difficult to assess the cost of stolen data, but it must be assessed in order to understand the cost/benefit of implementing the security solutions for both your wired and wireless network.

Designing and Testing Wireless Access Infrastructure

The third major step is to design and test the wireless access infrastructure. Now that you ve either created or prepared your network infrastructure for wireless network access and defined authentication and access, you must put it all together.

The recommended configuration is to have:

Two IAS servers for fault tolerance of the RADIUS-based authentication.
Active Directory integration for better security and a single logon for wireless users.
Certificate infrastructure for strong authentication to protect wireless access.
Wireless access policies to protect the network by controlling who can access the wireless network and in what manner.
Sufficient WAPs so enabled wireless clients can obtain network connectivity throughout the approved wireless area.
WAPs configured as RADIUS clients in order to manage secure connections and data with the IAS/RADIUS server.

The functional diagram shown in Figure 5.21 delineates these components and the process of secure wireless client authentication and authorization. How this is implemented in your organization will differ based on different variables , including building layout and configuration, desired/required wireless network availability, and more. However, if you configure your wireless network access to use these components, you will have the most secure wireless network configuration currently available.

Figure 5.21: Functional Diagram of Wireless Access Infrastructure

The wireless client establishes credentials with the CA before wireless access is attempted. Often, this is done on a secure wired network or via removable media (floppy disk, CD-ROM, etc.).
The wireless client initiates contact with the wireless network by passing its credentials to the wireless access point. The WAP passes these credentials on to the IAS (RADIUS server) for verification. The IAS is integrated with Active Directory and can verify the legitimacy of the credentials as well as the access policies for the user.
Based on the IAS results, access to the network is either granted or denied. If access is granted, encryption keys are generated and exchanged over a secure channel with the WAP.
The encryption keys are exchanged securely between the WAP and the wireless client.

The wireless client and WAP create a secure connection and the wireless client begins exchanging data with the internal network.

Test Day Tip

You are practically guaranteed to get questions on designing a secure wireless network, so be sure to review the functional diagram and understand each component thoroughly before the exam.