Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Use Internet Protocol Security Policies

The original TCP/IP standard had as its goal the development of a bulletproof protocol. TCP/IP's designers, however, did not add any requirements for confidentiality. They may not have been particularly interested in keeping people from reading the information contained in the communications packets because, at that time, it was difficult just to get computer systems to talk. Basic communication between diverse systems was difficult because many computer systems of the day had their own proprietary communications. In addition, few organizations, let alone individuals, had access to computer systems, and fewer had access to the network that was being built between governments and universities.Chapter 14, "Securing Remote Access." This chapter details IPSec's ability as a security protocol to block or permit communications with a server or to negotiate secure communications between two computers. IPSec can also be used to secure communications between a Windows 2003 Server and a device such as a Cisco router. This type of communication follows the same pattern as those described in the following section, though not all IPSec devices will be compatible with each other. You will need to determine interoperability and follow the instructions provided by the device manufacturer.

NOTE: FYI

The article "Simple Certificate Enrollment Protocol (SCEP) Add on for Certificate Services" (http://www.microsoft.com/downloads/details.aspx?FamilyID=9f306763-d036-41d8-8860-1636411b2d01&displaylang=en) provides information and a downloadable tool that can make it easy for a Cisco router to download a certificate from a Windows Server 2003 CA. "Windows Virtual Private Network Connectivity to a Cisco PIX Firewall" (http://support.microsoft.com/default.aspx?scid=kb;en-us;249576) and other articles provide interoperability information.

To use IPSec to secure communications between Windows computers, including Windows 2000, Windows XP, and Windows Server 2003, write IPSec policies. To do so, you must understand how the protocol works, as described in the section "How IPSec Works" and how to write the policy, as detailed in the section "Writing IPSec Policies." It is also important to be able to monitor and troubleshoot IPSec, as described in the section "Monitoring and Troubleshooting IPSec," after the policy is assigned.

IPSec Implementation in Windows Server 2003

IPSec is implemented as the IPSec driver within the TCP/IP protocol stack, and as a Windows service (IPSec services) in Windows Server 2003. Although the service is enabled by default, no IPSec protection is available until a policy is written and assigned. The protocol and the policies are complex, and the best way to understand IPSec is to write and test a few policies in a test environment. Windows Server 2003 IPSec components are illustrated in Figure 15-1 and described in Table 15-1. In Figure 15-1, the shaded rectangles represent the components, and those that are built into the TCP/IP protocol stack are illustrated as such. The unlabeled rectangles at the physical layer of the stack represent the capabilities of the IPSec driver to offload encryption to TCP/IP cards that are capable of doing so. The IPSec components can be broken down into parts, which are further defined in the process description in the section "How IPSec Works."

How IPSec Works

IPSec monitors inbound and outbound traffic. When IPSec policies are assigned (made active), they are used only when IP traffic, either inbound or outbound, meets the IPSec filter requirements. The IPSec filter is a combination of source and destination IP addresses, protocols, and ports defined in one of the policies' rules. Rules are a policy part composed of a list of filters, filter actions, and other settings. If a packet matches a filter, this triggers a filter action associated with the filter's rule. A filter action specifies what happens to the packet.

Three possible filter actions are as follows:

Block
Do not allow traffic to pass; packets are dropped.

Permit
Allow traffic to pass.

Negotiate
Agree on security protocols, key settings, and other secure configurations and securely exchange traffic if authenticated.

For example, if an IPSec policy filter identifies inbound port 23 traffic from any source address and the filter action is block, all inbound traffic to port 23 will be dropped. If, however, in addition to this filter and filter action, another rule in the policy has a filter that specifies that inbound port 23 traffic from a specific IP address is allowed (the filter action is Allow), only inbound port 23 traffic from that address will be allowed.

Here's how the IPSec components work together on inbound and outbound traffic:

The IPSec Policy Agent monitors for changes in policy and passes that information on to the IPSec driver.

The driver attempts to match every inbound and outbound packet against the filters in the active policy.

If a packet does not match any filter, or if it matches a filter with a Permit filter action, it is passed back to the TCP/IP driver.

If a packet matches a filter with the Block filter action, the packet is dropped.

If packets match a filter with the Negotiate filter action, the IPSec Policy Agent queues the packet, notifies IKE, and then IKE negotiates the inbound and outbound Security Association (SA). SA and IKE negotiation are detailed in the section "IKE Negotiation."

If negotiation fails, the packet is dropped.

If negotiation for outbound packet is successful, the IPSec Policy Agent does the following:

Receives SA with session key from IKE.

Inserts a Security Parameters Index (SPI) in the protocol header (either the ESP or AH protocol headersee the section, "IPSec Protocols").

Signs, encrypts if required.

Sends packet onto IP layer for forwarding.

Stores quick mode SA information in a database. (Quick mode is discussed in the section "IKE Negotiation.")

If an inbound secured packet matches the filter, the IPSec Policy Agent does the following:

Receives SPI, SA, and session key from IKE.

Uses the Security Parameters Index to match a packet with the SA in its database.

Decrypts if necessary.

Checks the signature.

Checks the packet against the filter to make sure that nothing but what was negotiated was received.

Sends the packet to the TCP/IP driver to pass on to the application.

If the unsecured packet is received, checks filters. If the packet should be secured, discards it.

IPSec Protocols

IPSec is composed of two protocols: Authentication Header (AH) and Encapsulated Security Protocol (ESP). An IPSec policy can specify the use of one or both of them. Both protocols provide authentication, integrity, and anti-replay; however, AH cannot provide confidentiality (encryption) but provides superior integrity protection. The AH packet is pictured in Figure 15-2. Note that the IP header, the AH header, and the IP payload are signed by AH. In contrast, the ESP packet, shown in Figure 15-3, signs only the ESP header and trailer and the IP payload. This means that the IP header, because it is not signed, is not necessarily protected from modification. The IP payload and ESP trailer are encrypted.

What Is an IPSec Policy?

The IPSec policy defines the elements that decide what traffic is allowed, blocked, or negotiated and, if negotiated, what protocols and what type of protection is used. An administrator can create an IPSec policy locally, distribute it via Group Policy, or copy it from one computer to another. A policy is not active until it is assigned. Only one policy can be active on a specific computer at a time. Policy parts are defined in Table 15-2.

Setup of policies that only specify block or allow filter actions is straightforward, and these policies act like simple gateways, either dropping or passing packets to the TCP/IP driver. Policies whose rule(s) specify a filter action of negotiation are more complex. In addition to filter lists, many other specifications must be defined. In order for negotiation to be successful between two IPSec Policy Agents on the respective computers, the specifications in both policies must be compatible. Table 15-3 lists and describes these specifications.

IKE Negotiation

Internet Key Exchange (IKE) negotiation is used to create the Security Agreement or Security Association (SA) between two computers (also known as IPSec peers). During the negotiation, an agreement is reached on how to exchange and protect information. Both sides must be able to agree, and neither side can agree on some configuration that is not present. Negotiations are divided into two phases: Phase I (main mode) and Phase II (quick mode).

During main mode:

A secure, authenticated channel is established.

Encryption (DES or 3DES), integrity (MD5 or SHA1), Diffie-Hellman group (1, 2, or 3) and authentication method (Kerberos, preshared key, or certificates) is negotiated.

Diffie-Hellman exchange of public values and master key generation. No actual keys are exchanged, just keying material that is required by the Diffie-Hellman key determination algorithm. Both computers generate the master key. The DH exchange must be authenticated or no communications can proceed.

The sender presents an SA to the receiver, who cannot modify it but can accept or reply with an alternative.

If main mode is successful, during quick mode, the negotiation process is protected by the main mode SA:

Policy negotiation of IPSec protocol (ESP or AH), hash algorithm for integrity (MD5 or SHA1), and encryption (DES or 3DES). If a common agreement can be reached, two quick mode SAs are established: one for inbound and one for outbound communication.

Session key material refreshes or is exchanged. IKE refreshes keying material, and new shared keys are generated for packet integrity, authentication, and encryption.

The IPSec Policy Agent generates a SPI.

SAs keys and SPI are passed to the driver.

Writing IPSec Policies

Policies may be written using either the GUI policy wizard or the command-line tool netsh. If the wizard is used, it can be initiated via a Group Policy Object (GPO) (IP Security Policy on Active Directory) linked to an Active Directory object via the IP Security Policies on the Local Computer in the Local Security Policy, or by adding the IP Security Policy Management snap-in to an MMC. The wizard works the same way no matter where it is started. Both options, GUI or command line, can produce the same policy, with the exception of the a special policy, which can be activated before the IPSec Policy Agent service is started during system boot. This type of policy must be created and assigned using netsh.

How to Write Policies Using the IPSec Policy Wizard

To understand how policies work, create policies and make them work. Do this on a test network between two servers. A good way to do so is to first work with one computer, creating a blocking rule and testing it. Then, in the same policy, create a permit rule and test it. Finally, change the permit rule to a negotiate rule, and create a policy with its counterpart at another server. Make the policy simple. For example, block a single protocol, then allow that protocolbut only if its source address is a single computer. Then, turn that rule into a negotiated policy.

By writing the policy bit by bit, you gain experience and find that troubleshooting is easier if something goes wrong. One area of policy definition that often causes problems is authentication. You can eliminate this as an initial problem:

Configure your test policies to use a preshared secret for authentication.

If the policy does not work (and you confirm that both IPSec computers are using the same preshared secret), the problem lies elsewhere (not with authentication), most likely in your protocol configuration.

When the policy works, you can change the authentication to Kerberos or certificates, whichever you require, and test the policy again.

If your goal is to use IPSec policies for many computers that are joined in an Active Directory domain, test the policy between two computers before including the policy in a GPO. Once tested between two computers, a policy should be tested in a test Active Directory domain and only then implemented in production.

To create and test a policy via the GUI, do the following:

Create a console by adding the IPSec Management snap-in to an MMC.

Write a blocking rule and test it.

Write and test a Permit rule.

Change the allow rule to a Negotiate rule and test it.

Create an MMC Console

The first step is to create a console:

Create and Test a Blocking Rule

Next, take the easy wayconfigure and test a blocking rule:

It is only necessary to create a blocking policy on one computer. To test the policy, follow these steps:

Create a Permit Rule

The blocking rule blocks all attempts at a telnet connection from any computer. However, if a more specific rule, such as one that identifies a specific computer, permits telnet traffic, the specifically identified computer will be able to make a telnet connection and use telnet in the normal manner. This is because the IPSec Policy Agent attempts to match packets against the more specific rules first, so packets from the specified computer are accepted because they match the Permit rule, while packets from all other computers won't match that rule, but will match the generic Block rule. You create the Permit rule in the same IPSec policy because only one IPSec policy can be active on the computer at a time:

To test the new rule, you first need to show that an attempt from the specified computer will be successful. However, you should also check that when the IP address does not match that identified in the policy, the telnet connection will be dropped.

Change the Allow Rule to Negotiated

If the traffic from the approved computer should also be protected, and it should, the rule should be given a Negotiate filter action, and the specifics for negotiation should be defined. The creation of a Permit rule first is not necessary. It is detailed only in this section to demonstrate the Permit function and make it easier for those new to IPSec to create rules. To change the rule, follow these steps:

To test the rule, the second computer must also have a policy assigned. This policy needs only one rule, a Negotiate rule, that matches the one written for the first computer. That is, it must have the same security methods and shared key that the other policy does for this rule:

TIP: Stop and Start IPSec Policy Agent Service

If IPSec policies are not working as you expected after you have made changes, you may want to force a policy refresh by starting and stopping the IPSec Policy Agent service. The agent does periodically poll the policy database to see if changes have been made, but stopping and starting the Policy Agent service quickly clears and resets any policy information.

If you have problems implementing this test IPSec policy, use the information included in the section "Using netsh to Monitor IPSec" as an aid in troubleshooting.

How to Write Policies Using netsh

IPSec policies for the local computer can be created by using netsh at the command line. The netsh command is a complex command that offers much more functionality than the GUI. The netsh IPSec commands described here are for Windows Server 2003.

NOTE: FYI

A complete list of netsh IPSec commands is in Windows Server 2003 help. You can locate them in the %system root%\Help\ntcmds.chm::/ netsh_ipsec file.

Another guide to the netsh commands that can be used to configure policies and manage IPSec can be found at "Netsh commands for Internet Protocol Security" (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/netsh_ipsec.asp).

Because many individual commands may be necessary, a more efficient method is to create the command lines in a batch file or script and then run the batch file or script. Using this method allows you to easily add a policy to another computer by simply placing a copy of the file on the computer and running it. You can also use this file as part of a boot script.

netsh IPSec commands can be executed in either static or dynamic mode. When you work in static mode, it's like creating policies using the GUI: nothing you do actually changes the use or non-use of IPSec on the computer because the IPSec Policy Agent is not aware of them. You must issue a command to assign the policy. Dynamic mode netsh IPSec allows you to make immediate changes to IPSec policy; however, if the Policy Agent service is stopped, the dynamic changes are discarded. Dynamic IPSec should be used only if you must make immediate changes to IPSec processing. Be careful, however, because you will have no warning and no opportunity to discover a mistake in your command. If you create a valid command that does not do what you want, it will still run.

Before creating IPSec policies or changing them, enter the IPSec context by entering netsh ipsec at the command line, and then enter the word static or dynamic to select the mode. Alternatively, you can enter all three words at the same time: netsh ipsec static.

To create and assign the policy, you follow steps similar to those outlined for the GUI interface. You add the information for IKE configuration and add rules that are composed of filter lists, filter actions, and other configuration parameters. You can create blocking, permitting, and negotiation rules and do things such as monitor IPSec and create special types of IPSec policies that cannot be created with the GUI.

To make the policy make more sense, we'll use the computer names Andy and Betty. To create your own policy, substitute your own computer names. The first netsh policy will create an IPSec policy that blocks telnet access from all computers except from computer Betty. Then, the Negotiate rule will be added. If you are creating your own policy, enter lines in a text file and save it as a batch file using the extension .bat. Using a text file helps when policies are longer, like this one. After you test the first step (the blocking policy), you can re-open the text file and add the commands for the second rule (the Negotiate rule). You run a .bat batch file by entering its name at the command line. You will also be able to use it on another computer with slight adjustments. You can also enter each line at the command line, and when you press the Enter key, it will be executed. If your syntax is correct, a new command prompt will be made available.

TIP: Erasing netsh Mistakes

If you make mistakes or need to remove the policy, do so by using the delete policy command. Here's an example using the policy name:

Delete policy name=telnet

To create policies, first create a policy for computer Andy that will block all telnet but negotiate telnet from computer Betty. In this example, the IP address of computers on a test network is used so that you can see the complete syntax of the command. When you create your test, substitute the actual IP address of the computer used in the test. Remember that the policy on Andy will require two rules. Table 15-4 lists and defines some of the netsh command parameters that are not obvious from their name.

netsh ipsec static

add policy name="telnet" description="block all telnet except Betty"
 activatedefaultrule=no mmsecmethods="3DES-MD5-3"

Add filter filterlist="telnet Betty" srcaddr=192.168.5.3 dstaaddr=Me description="Betty
 telnet to Andy" protocol=TCP mirrored=yes srcmask=24 dstmask=32 srcport=0 dstport=23

Add filteraction name="negotiate Betty telnet" qmpfs=no inpass=no soft=no action=negotiate
 qmsecmethods="ESP 3 DES,MD5

Add rule name="telnetN" policy="telnet" filterlist "telnet Betty" filteraction="negotiate
 Betty telnet" Kerberos=yes description="this rule negotiates telnet if the source address
 is computer B"

Add filter filterlist="blocktelnet" srcaddr=Any dstaddr=Me description="block all telnet
 to Andy" protocol=TCP mirrored=yes srcmask=24 dstmask=24 srcport=ANY dstport=23

Add filteraction name="block telnet" inpass=yes action=block

Add rule name="telnet Betty" policy="telnet" filterlist "blocktelnet" filteraction="block
 telnet" Kerberos=yes description="this rule blocks all telnet"

Next, create a policy on computer Betty. This policy only needs a single rule, the Negotiate rule. The easiest way is to copy the policy created for computer A and delete the block rule. Then, if necessary, you can adjust the statements. A copy of the policy written in the previous list is shown in the following code with the adjustment made to the filter. The change is necessary to switch the source and destination addresses:

netsh ipsec static
add policy name="telnet" description="block all telnet except computer Betty"
 activatedefaultrule=no mmsecmethods="3DES-MD5-3"
Add filter filterlist="telnet computer Betty" srcaddr=Me dstaddr=192.168.5.50
 description="computer Betty telnet to computer Andy" protocol=TCP mirrored=yes srcmask=32
 dstmask=24 srcport=0 dstport=23
Add filteraction name="negotiate computer Betty telnet" qmpfs=no inpass=no soft=no
 action=negotiate qmsecmethods="ESP 3 DES,MD5
Add rule name="telnetN" policy="telnet" filterlist "telnet computer Betty"
 filteraction="negotiate computer Betty telnet" Kerberos=yes description="this rule
 negotiates telnet if the source address is computer Betty"

The final step is to assign the policy. Remember to add this line to both batch files:

Set policy name=telnet assign=yes

Using Group Policy to Implement IPSec

IPSec policies can also be created as part of a Group Policy Object (GPO) and will be distributed to the computers whose accounts are impacted by the GPO. These policies can be created by right-clicking the IP Security Policies on Active Directory node of the GPO, selecting Create IP Security Policy and following the wizard, or by importing a saved policy into the IP Security node of the GPO. When creating IPSec Group Policy-based policies, be sure to do the following:

Always create and test the policy in a test network between two computers.

Use an OU in a test forest and create a new GPO for the test. The OU should contain computer accounts from representative computers, such as Windows 2000, Windows XP, and Windows Server 2003 if all these operating systems will be assigned the policy in the production network.

Test the policy using a shared key until it is working correctly.

Change the authentication method to Kerberos or certificates and test again.

When the policy is working as expected, add the policy to the production domain but assign it at first to a small test OU. Perhaps this OU can temporarily hold a few computers belonging to IT staff.

After testing, assign the policy to larger groups of computers in the production domain.

TIP: DCs and IPSec

Be careful when implementing IPSec policies that will impact domain controllers. It is easy to block communications between domain controllers or between domain controllers and member computers, and it is more difficult to reverse the effect.

Special IPSec Policy Operations

The netsh command can also be used to perform special IPSec operations, such as Oakley (IKE) logging (useful for diagnostic purposes), changing driver modes, creating persistent policies, and requiring strong CRL checking (ensures protection from the use of revoked certificates for computer authentication of IPSec policies). Driver modes and persistent policies are discussed in the following sections.

Even IPSec protected systems may be vulnerable to attack during times when the IPSec policy is not in affect. This may occur during boot (after the IPSec driver starts but before the IPSec Policy Agent service starts) or if polices are implemented through Group Policy and Group Policy is for some reason unable to distribute the policy. Group Policy IPSec policies are cached in the local computer registry and can be used when a domain controller is not available at computer boot; however, no changes to Group Policy and therefore to IPSec policy will be downloaded. To ensure protection for these potential gaps in coverage, use persistent policies and configure IPSec driver mode.

IPSec Driver Modes

The IPSec driver modes are computer startup, operational, and diagnostic. When the operating system boots, the IPSec driver is loaded in computer startup mode, which is used until the IPSec Policy Agent can set the IPSec driver into operational mode. (Diagnostic mode can be set using a netsh command.) There are three computer startup modes:

Permit
No IP packets are processed. When no IPSec policy has ever been assigned, Permit mode is the default computer startup mode. It is the default mode when the IPSec Policy Agent service is disabled or set to Manual startup mode and selected if the service is automatic but no IPSec policies have ever been assigned.

Block
All inbound and outbound IP packets are dropped unless they match filters configured to be used during Block mode, or they are DHCP traffic (so that a computer can obtain an IP address). To configure Block mode, use the netsh ipsec dynamic set config bootexemptions command.

Stateful
All outbound traffic is allowed, and inbound permit filters are created in response to outbound traffic. All other inbound traffic is dropped, including unicast, broadcast, and multicast. If an IPSec policy is assigned to a computer and the IPSec Policy Agent service is set to automatic startup, the computer startup mode of the IPSec driver will be stateful mode.

The computer startup mode can also be modified by using the netsh ipsec static set config bootmode command.

Once the IPSec Policy Agent service starts, the IPSec Policy Agent sets the IPSec driver to operational mode. Any computer startup mode filters are discarded. You cannot change operational mode via any commands. Operational modes are

Secure
IPSec policy filters are enforced. If a persistent policy is configured, it will be applied first, then the agent sets the driver into secure mode and then applies the Active Directory IPSec policy or local policy if one is assigned. If no persistent policy is assigned, Secure mode does not protect the computer until the Active Directory of the local policy can be applied.

Permit
No IP packets are processed, and no IPSec protection is provided. Permit operational mode is active when the IPSec service is manually stopped.

Block
All inbound and outbound traffic is dropped. If filters are configured for computer startup mode, they are not applied here. Block mode is active if a persistent policy is configured but cannot be applied.

Diagnostic mode is used to record all inbound and outbound dropped packets and other packet-processing errors in the System Event log. Diagnostic mode is disabled by default. To enable it, use the command netsh ipsec dynamic set config ipsecdiagnostics value=, where the value equals a number from 0 to 9, with 0 meaning disabled, which is the default.

Creating Protection for Computer Startup

During computer startup, three periods of time must be considered to ensure complete protection. The time periods, protection requirements, and solutions are listed in Table 15-5.

To set the computer operation mode to Block and apply a filter that will allow the use of the remote desktop connection during startup, use the netsh command:

netsh ipsec dynamic set config bootexemptions value=tcp:0:3389: inbound

Make a policy persistent by doing the following:

set policy name=telnet assign=yes

set store location=persistent

Monitoring and Troubleshooting IPSec

Many IPSec problems are due to configuration errors, and many of these can be easily discovered by reviewing the policy configuration. Common errors are IP addresses that are entered incorrectly, mismatched encryption or integrity algorithms, and so forth. However, the IPSec protocol and policy configuration are complex enough that additional troubleshooting may be required. In addition, by monitoring IPSec, you can confirm that encryption is taking place.

Two tools can be used to monitor and troubleshoot IPSec on Windows Server 2003: netsh show commands and the IP Security Monitor snap-in loaded in an MMC console.

Using netsh to Monitor IPSec

The netsh show command can be used to obtain policy information on the current IPSec session and to obtain diagnostics and logging information. If you can obtain the information using the GUI IP Security Monitor, you can obtain it using netsh.

To display the current IPSec policy, use the netsh ipsec static show all command. This will list all the information on the current policy. To narrow down the range of information displayed, you can use variations such as the following:

Show the filter list:
show filter list name=filterlist

Show a specific rule:
show rule name

Display a specific policy:
show policy name=policy name

To find diagnostic information, use the netsh ipsec dynamic set config commands, such as the following:

Set diagnostic logging from level 0 (disabled) to level 7 (for all logging):
ipsecdiagnostic value=

Turn on or off IKE (Oakley) logging:
Ikelogging value=

Disable CRL checking (0), fail certificate validation if the certificate is revoked (1), or fail if any CRL check error occurs (2):
strongcrlcheck value=

Diagnostic logging levels and IKE logging are two different things. IKE logging is enabled or disabled using a 1 or 0, respectively. When IKE logging is enabled, the information is added to the systemroot\ Debug\Oakley.log. Diagnostic logging results are added to the system log. Diagnostic levels are defined in Table 15-6.

Several show commands provide miscellaneous information:

Resolve DNS or NetBIOS computer names associated with an IP address (helpful in determining if the policy impacts the correct computers):
show all resolvedns=yes

Display information on the IPSec main mode SA:
show mmsas

Display quick mode SAs:
show qmsas

Display IKE main mode and/or IPSec quick mode statistics:
show stats

TIP: Use of Netdiag Differs for Windows Server 2003

Netdiag is a command-line tool that is used to display IPSec information and test and view network configuration for Windows 2000 computers. However, though the command can be used to test and view network configuration of Windows Server 2003 computers, the netdiag /test:ipsec option is not available. The netsh command provides this information.

Using the IP Security Monitor to Monitor IPSec

The IP Security Monitor is available as an MMC snap-in for Windows XP and Windows Server 2003 computers. It cannot be used to monitor Windows 2000 IPSec. Use the tool to monitor the active IPSec policy. Policy configuration information, quick mode and main mode statistics, and information on active SAs can be obtained. To use the monitor, add it to an MMC and expand its node when IPSec policies are active. You can add additional Windows Server 2003 computers to the console, which is useful for diagnosing problems or monitoring activity on communications between two computers. Although some policy information is straightforward, some of the information on IPSec main mode and quick mode statistics is not. Some of them will only make sense if they are collected and monitored over time because they must be considered in context. For example, whether the number of pending requests or messages queued represents a problem (perhaps few are being serviced) may depend on the amount of processing normally done on this computer. Other policy statistics are almost self-explanatory. For example, if there are a large number of authentication failures and failed connections, it probably means that authentication is misconfigured (or it could mean an attempt is being made from an unauthorized computer). An explanation of main mode statistics is listed in Table 15-7.

IPSec Quick Mode Statistics are listed in Table 15-8.