8. 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 targeted by the GPO.
These policies can be created by right-clicking on the IP Security
Policies on Active Directory node of the GPO, selecting Create IP
Security Policy, and following the wizard. Or, you can import a saved
policy into the IP Security node of the GPO. Keep the following in mind
when creating IPSec Group Policy-based policies:
Create and test the policy in a test network between two computers.
Assign
the policy to an OU in a test forest. The OU should contain computer
accounts from representative computers (for example, Windows 2000,
Windows XP, and Windows Server 2003, if all of these operating systems
will be assigned the policy in the production network).
When the policy is working as expected, add the policy to the production domain, but assign it (at first) to a small test OU.
After testing, assign the policy to larger groups of computers in the production domain.
To create an IPSec policy
directly in a GPO, begin by opening the GPO for editing. Expand the GPO
and drill down to the Windows Settings → Security Settings → IP Security
Policies on the Active Directory node, as shown in Figure 14.
Right-click on the node
and select Create IP Security Policy. Follow the wizard to implement
the desired policy. The wizard works the same way as it does for the
local IP Security Policy described earlier.
To import a saved IP
Security Policy into a GPO, begin by opening the GPO for editing. Expand
the GPO and drill down to the Windows Settings → Security Settings → IP
Security Policies on Active Directory node. Right-click on the node and
select All Tasks, then select Import Policies, as shown in Figure 15.
Browse to and select a saved IPSec policy and click Open.
9. Monitoring and Troubleshooting IPSec
When an IPSec
policy does not work, it is often a simple configuration error. Many of
these errors can be easily discovered by reviewing the policy
configuration. Common errors are IP addresses that are entered
incorrectly, mismatched encryption or integrity algorithms, and wrong
port numbers. However, because there are a large number of things to be
configured, knowing how to use monitoring
and diagnostic tools is important. In addition, it is easy to configure
a policy that does not work, but that you may think is working because
the systems are communicating. If you monitoring IPSec, you can confirm
that encryption is taking place.
Two Windows Server 2003 tools that can be used to monitor and troubleshoot IPSec on Windows Server 2003 are the netsh ipsec show command and the IP Security Monitor snap-in.
9.1. 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 graphical 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, or disabled, to level 7 for all logging:
ipsecdiagnostic value=7
Turn on or off IKE (Oakley) logging:
Ikelogging value=
Disable Certificate Revocation List (CRL) checking (0), fail certificate validation if the certificate is revoked (1), or fail if any CRL check error occurs (2):
strongcrlchecek value=
Several show commands provide useful troubleshooting information, including the following:
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
netdiag
is a command-line tool for Windows 2000 and Windows Server 2003. It can
be used to display IPSec information, as well as test and view network
configuration for Windows 2000 computers. The command can be used to
test and view network configuration of Windows Server 2003 computers,
but the netdiag /test:ipsec option is not available. The netsh command can be used to provide this information. |
|
9.2. Using the IP Security Monitor to monitor IPSec
In the section "Setting Up the IPSec Monitor and Testing the Policy,"
the IP Security Monitor was used to monitor the test of the security
negotiation policy. The tool is also available as an MMC snap-in for
Windows XP. It cannot be used to monitor Windows 2000 IPSec. Use the
tool to monitor the active Windows Server 2003 and/or Windows XP IPSec
policy. Policy configuration information, quick mode and main mode
statistics, as well as information on active SAs can be obtained.
Much of the information
the tool presents is straightforward. However, some of the information
on IPSec main mode and quick mode statistics is not. Some of this data
only makes sense when it is collected and monitored over time, and when
it is 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 easy to interpret. 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. Table 2 provides an explanation of main mode statistics, and Table 3 provides an explanation of Quick Mode statistics.
Table 2. Main Mode statistics in the IP Security Monitor
| Statistic | Explanation |
|---|
| Active Acquire | The number of pending requests for IKE negotiation between IPSec peers. |
| Active Receive | The number of IKE messages queued for processing. |
| Acquire Failures | The number of established outbound SA requests that have failed since the IPSec service started. |
| Receive Failures | The number of errors in received IKE messages since the IPSec service started. |
| Send Failures | The number of errors during IKE negotiation. |
| Acquire Heap Size | The number of successive outbound requests required to establish SAs. |
| Receive Heap Size | The number of IKE messages in IKE receive buffers. |
| Authentication failures | The
number of failed authentication failures since the start of the IPSec
service. When connections are failing, check to see if authentication
failures increase during connection attempts. If this is the case,
authentication is most likely the problem. Look for common errors
depending on the type of authentication used. If shared secrets are
used, check to see if they match. If the method is Kerberos, are IPSec
peers members of the domain? When the method is certificates, make sure
that are they available and correct. |
| Negotiation failures | The
number of main mode and quick mode negotiation failures. If connections
are failing and negotiation failures increase during connection
attempts, check to see if security methods (or possibly authentication)
are mismatched. . |
| Invalid cookies received | Cookies
are values in received IKE messages and are used to help identify the
corresponding main mode SA. (SPIs are used to identify quick mode SAs.)
If invalid cookies are received, then the failure is with IKE
negotiation. |
| Total acquire | The number of requests submitted to IKE. (Including those resulting from soft SAs). |
| Total get SPI | Requests to driver for the SPI. |
| Key addition | The number of outbound quick mode SA additions. |
| Key updates | The number of inbound quick mode SAs added by IKE. |
| Get SPI failures | The number of failed requests for a unique SPI. |
| Key addition failures | The number of failed outbound quick mode SA addition requests submitted by IKE. |
| Key update failures | A failed inbound quick mode SA addition request. |
| ISADB List Size | The
number of main mode state entries. This includes successful main modes,
main modes in negotiation, and those that have failed or expired, but
have not been deleted. |
| Connection list size | The number of quick mode negotiations in process. |
| IKE Main Mode | The number of successful SAs in main mode. |
| IKE quick mode | The total SAs in quick mode. |
| Soft associations | SAs that are not the result of an encrypted, main mode negotiation. |
| Invalid packets received | The
number of invalid IKE messages. This can be the result of invalid
header fields, payload lengths, and incorrect values. The preshared key
may be mismatched. It may also be the result of retransmitted IKE
messages. |
Table3. Quick Mode statistics
| Statistic | Explanation |
|---|
| ActiveSecurity Association | Number of quick mode SAs. (Though two SAs are used during quick mode, only one of them will be shown here.) |
| Offloaded Security Associations | Number of quick mode SAs offloaded to hardware. |
| Pending Key Operations | Number of key exchange operations. |
| Key Additions | Number of keys added for quick mode SAs since the computer started. |
| Key Deletions | Number of keys quick mode SAs that have been successfully deleted since computer started. |
| Rekeys | Number of successful rekey operations for quick mode. |
| Active Tunnels | Number of active tunnels. |
| Bad SPI Packets | Number
of packets with incorrect SPI. This may mean that the SPI expired and
an old packet just arrived. If rekeying is frequent and/or there are a
large number of SAs, this number may be higher than normal without being
indicative of anything wrong. It might also indicate a spoofing attack. |
| Packets Not Decrypted | Number of packets not decrypted. Packets are not decrypted if they fail a validation check. |
| Packets not authenticated | Might indicate IPSec packet spoofing or modification attack or corruption by network devices. |
| Packets with Replay detection | Number
of packets that contain an invalid sequence number. Watch for increase
because they might indicate a network problem or replay attack. |
| Confidential bytes sent | Number of encrypted bytes (those sent using ESP protocol). |
| Authenticated bytes sent | Number of bytes authenticated using AH or ESP. |
| Transport bytes sent | Number of received bytes using IPSec transport mode. |
| Bytes sent in Tunnels | Bytes sent using IPSec tunnel mode. |
| Bytes received in tunnels | Bytes received. |
| Offloaded bytes sent | Number of bytes sent that use the hardware offload. |
| Offloaded bytes received | Number of bytes received using hardware offload. |
To
learn the basics of configuring, testing and monitoring IPSec, you must
perform extensive preparation and practice. Once you have successfully
written a few policies with the wizard, monitored them using the IPSec
Monitor, and rewritten them using netsh,
you are ready to write and use all but the most complex IPSec policies.
While those policies may require more intensive study and testing, they
are built on the information you've learned. A few of these extended
operations are covered in the following discussion.
