Lesson 2: Monitoring IPSec

 < Day Day Up > 



Monitoring IPSec is important for verifying that IPSec is working correctly in your organization. You will also need to closely monitor IPSec if you are having a problem implementing it or if you experience network connectivity problems that might be related to IPSec. This lesson will describe the various tools that you can use to monitor IPSec.

Tip 

Monitoring IPSec is also the single best way to learn how IPSec functions. If you don’t feel like you fully understand IPSec, spend some time establishing IPSec connections and monitoring them by using the various tools described in this lesson.

After this lesson, you will be able to

  • Describe the tools available to monitor IPSec.

  • List which tools can be used to identify specific IPSec statistics.

  • Capture and analyze IPSec network traffic to verify that it is being encrypted.

  • Enable auditing of IPSec negotiations and dropped packets to allow for careful analysis of IPSec communications.

  • Use the Performance console to gather and analyze IPSec statistics over a period of time.

Estimated lesson time: 45 minutes

IP Security Monitor Snap-In

IP Security Monitor is a Windows XP and Windows Server 2003 snap-in used to monitor and troubleshoot IPSec. If an IPSec policy is active, you can use this console to examine the policy and its operations.

Information in the IP Security Monitor snap-in is divided into three nodes: Active Policy, Main Mode, and Quick Mode. The Active Policy node, as shown in Figure 9.4, displays information about the currently assigned policy. This information includes the policy’s name, last modified date, and origin. If you are unsure about how a particular policy was applied to a computer, check this node to identify the GPO that assigned the policy.

click to expand
Figure 9.4: The Active Policy node of the IP Security Monitor

See Also 

For a description of the fundamentals of Main Mode and Quick Mode, refer to Chapter 8.

Main Mode

As you recall from Chapter 8, Main Mode negotiation is the first phase of establishing an IPSec connection. Main Mode establishes common security protocols shared by the two hosts, determines master key keying material that will be used for encrypting communications, and authenticates the computers themselves.

One of the most useful features of the IP Security Monitor snap-in is its ability to quickly view active SAs. To do this, expand Main Mode, and then click Security Associations. The right pane displays a list of active SAs, including the IP address of the IPSec peer. Double-click any SA to view the properties of the SA, as shown in Figure 9.5. The SA properties dialog box shows you the IP addresses of the two peers, the protocols used for encryption and integrity, the key lifetimes, and a list of Quick Mode SAs that were established from that Main Mode SA. The listing of Quick Mode SAs, in turn, reveals the negotiation policy used to establish each Quick Mode SA.

click to expand
Figure 9.5: Main Mode SA details

The most important node within the Main Mode node of the IP Security Monitor is the Statistics node. The Statistics node will be your primary tool for monitoring IPSec, because it contains statistics about Phase 1 of the IPSec negotiations, including the number of active IKE negotiations and the total number of successful and unsuccessful negotiations and authentications. Table 9.1 lists the most useful Main Mode statistics.

Table 9.1: Descriptions of Main Mode Statistics Parameters

Main Mode statistic

Description

Active Acquire

The number of queued IKE negotiation requests. Typically, the number of active acquires is 1. If IPSec cannot keep pace with the number of incoming requests that require IKE negotiation, this statistic will increase by the number of requests that are queued by IKE for processing. If you are troubleshooting performance problems that occur when clients establish connections to an IPSec-enabled server, monitor this parameter to determine whether Main Mode negotiations are the cause of the problem. If this number stays consistently high, use the Performance snap-in to monitor processor utilization on the server. If processor utilization is also high, consider upgrading the server’s processors or using a network card with integrated IPSec processing.

Acquire Failures

The total number of acquire outbound requests that have failed since the IPSec service was last started. It is not unusual to see this counter greater than zero when IPSec is functioning normally. However, if this number climbs, an IPSec peer is having trouble establishing a connection. You can use IKE tracing to identify the peer and the specific problem.

Receive Failures

The total number of errors that have occurred during the process of receiving IKE messages since the IPSec service was last started.

Send Failures

The total number of errors that have occurred during the process of sending IKE messages since the IPSec service was last started. The number of Send Failures typically increases for computers that establish SAs over temporary network connections, such as dial-up connections, virtual private network tunnels, and wireless connections. Therefore, it is not necessarily an indication of a problem that needs to be resolved.

Acquire Heap Size

The Active Acquire statistic measures the number of queued incoming connections; this statistic measures queued outbound connections. This number normally increases under a heavy load and then gradually decreases over time as the acquire heap is cleared. If it remains high, it is an indication that the computer is having problems establishing an IPSec connection to a remote computer.

Authentication Failures

The total number of identity authentication failures that have occurred during Main Mode negotiation since the IPSec service was last started. If you are having difficulty communicating securely, monitor this counter to determine if the problem is caused by a Main Mode negotiation failure. If it is, refer to Lesson 3 for information about troubleshooting authentication problems.

Negotiation Failures

The total number of negotiation failures that have occurred during Main Mode or Quick Mode negotiation since the IPSec service was last started. If this counter increases, check your authentication and security method settings for an unmatched authentication method, an incorrect authentication method configuration, or unmatched security methods or settings.

Total Acquire

The total number of requests that have been submitted to IKE since the IPSec service was last started to establish an SA. This number includes acquires that result in soft SAs that lack encryption.

IKE Main Mode

The total number of successful SAs that have been created during Main Mode negotiations since the IPSec service was last started.

IKE Quick Mode

The total number of successful SAs that have been created during Quick Mode negotiations since the IPSec service was last started.

Soft Associations

The total number of negotiations that resulted in unencrypted soft SAs. This typically reflects the number of associations formed with computers that did not respond to Main Mode negotiation attempts. This can include both non- IPSec-aware computers and IPSec-aware computers that did not have a suitable IPSec policy to successfully complete Main Mode negotiations. Although soft SAs are not the result of Main Mode and Quick Mode negotiations, they are still treated as Quick Mode SAs. Soft SAs are not secured by IPSec.

Invalid Packets Received

The number of received IKE messages that are invalid, including IKE messages with invalid header fields and incorrect payload lengths. Invalid IKE messages are commonly caused by unmatched preshared keys between the IPSec peers. It does not necessarily indicate a problem if this statistic is greater than zero, because invalid packets can be received during normal IPSec communications.

Quick Mode statistics

Quick Mode, also known as Phase 2 of IPSec negotiations, occurs after Main Mode and regularly while an IPSec connection is in use. The IP Security Monitor tool has a Quick Mode node that you can use to view current information about Quick Mode negotiations. The information contained in the Quick Mode node is similar to that of Main Mode, including the listing of active Quick Mode SAs.

The most useful information can be viewed from within the Quick Mode Statistics node. Quick Mode statistics provide more granular information than is available in Main Mode, including the total number of encrypted and authenticated bytes. Table 9.2 lists the most important parameters contained in the Quick Mode Statistics node.

Table 9.2: Descriptions of Quick Mode Statistics Parameters

Quick Mode statistic

Description

Active Security Associations

The number of active Quick Mode SAs.

Offloaded Security Associations

The number of active Quick Mode SAs offloaded to hardware. Certain network adapters can accelerate IPSec processing by performing hardware offload of IPSec cryptographic functions. If you are not using such a network adapter, this value will remain zero.

Pending Key Operations

The number of IPSec key exchange operations that are in progress but are not yet completed.

Key Additions and Key Deletions

The total number of keys for Quick Mode SA negotiations that have been successfully added or deleted since the computer was last started.

Rekeys

The total number of successful rekey operations for Quick Mode SAs since the computer was last started. Rekeying occurs on a regular basis after Main Mode negotiations. If you specify nondefault settings for rekeying, you should monitor this statistic to verify that rekeying is occurring at a realistic rate.

Active Tunnels

The number of active IPSec tunnels.

Bad SPI Packets

The total number of packets for which the Security Parameter Index (SPI) has been incorrect since the computer was last started. If the SPI is incorrect, it might mean that the inbound SA has expired and a packet using the old SPI has recently arrived. This number is likely to increase if rekey intervals are short and there are a large number of SAs. A large number of packets with bad SPIs that are received within a short amount of time might indicate a packet spoofing attack.

Packets Not Decrypted

The total number of packets that could not be decrypted since the computer was last started. A packet might not be decrypted if it fails a validation check.

Packets Not Authenticated

The total number of packets for which data could not be verified (for which the integrity hash verification failed) since the computer was last started. Increases in this number might indicate an IPSec packet spoofing or modification attack or packet corruption by network devices.

Packets With Replay Detection

The total number of packets that have contained an invalid sequence number since the computer was last started. Increases in this number might indicate a network problem or replay attack.

Confidential Bytes Sent and Confidential Bytes Received

The total number of encrypted bytes that have been sent or received by means of the Encapsulating Security Payload (ESP) protocol since the computer was last started.

Authenticated Bytes Sent and Authenticated Bytes Received

The total number of authenticated bytes that have been sent or received by means of the Authentication Header (AH) protocol or the ESP protocol since the computer was last started.

Transport Bytes Sent and Transport Bytes Received

The total number of bytes that have been sent or received by means of IPSec Transport Mode since the computer was last started.

Bytes Sent In Tunnels and Bytes Received In Tunnels

The total number of bytes that have been sent or received by means of IPSec Tunnel Mode since the computer was last started.

Offloaded Bytes Sent and Offloaded Bytes Received

The total number of bytes that have been sent or received by means of IPSec hardware offload since the computer was last started.

Event Viewer

As with many features of Windows Server 2003, you can configure IPSec to add events to the event logs. This is useful for verifying that IPSec is functioning correctly, for troubleshooting problems with IPSec, and for detecting successful or unsuccessful intrusion attempts. IPSec can generate events for two types of actions: successful and unsuccessful negotiations and dropped packets.

Off the Record 

I’m not a fan of using Event Viewer to troubleshoot IPSec problems. The fact is, the events don’t provide nearly enough information to be useful, and you have to weed through far too many events that don’t signal a problem condition. I’d rather use the IP Security Monitor snap-in, IKE tracing, and Network Monitor because they provide more detailed, useful troubleshooting information.

Auditing IPSec negotiations

The creation and deletion of IPSec SAs are audited as network logon events. To audit these events, enable success or failure auditing for the Audit Logon Events audit policy for your domain or local computer. IPSec records the success or failure of each Main Mode and Quick Mode negotiation and the establishment and termination of each negotiation as separate events. The IKE event category is also used for auditing user logon events in services other than IPSec, so you won’t see just IPSec events.

Planning 

On a busy server, enabling the auditing of logon events can cause the Security event log to fill with IKE events. Increase the size of the Security event log to prevent losing important information. If you need to enable the Audit Logon Events policy but do not want to see IKE events, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Audit\DisableIKEAudits registry value and set it to 1. You cannot disable auditing of IKE events on Windows 2000.

To add an event each time a user changes the IPSec policies, enable the Audit Policy Change policy. In Windows 2000, you must enable both the Audit Policy Change and the Audit Process Tracking settings to view the success or failure of IPSec policy change events. In Windows XP and Windows Server 2003, you only need to enable Audit Process Tracking to view the success or failure of IPSec policy change events. After these policies are enabled, the following events will be added to your Security event log:

  • Event ID 541, success audit. Recorded when IKE successfully negotiates either a Main Mode SA or an IPSec SA. The SA parameters are noted in the description of the event, as shown in Figure 9.6. The information recorded includes the details of the IP filter, security algorithms, and key exchange settings.

    click to expand
    Figure 9.6: Event ID 541 showing a successful IKE SA established

  • Event ID 542, success audit. Recorded when IKE successfully deletes an IPSec SA. An IPSec SA might be deleted because the SA lifetime expired, because a new SA was generated during Quick Mode rekey, because the IPSec peer sent a delete message, because the IPSec policy changed, or because the IPSec service was stopped.

  • Event ID 543, success audit. Recorded when IKE successfully deletes a Main Mode SA. An IKE Main Mode SA might be deleted because the SA lifetime expired, because the IPSec peer sent a delete message, because the IPSec policy changed, or because the IPSec service was stopped.

  • Event ID 544, failure audit. Recorded when the IKE negotiation is terminated because of a certificate trust failure and subsequent authentication failure. This failure might occur because a valid certificate chain could not be found on the IPSec peer, or because the certificate chain that was found could not be sent to a trusted root CA.

  • Event ID 545, failure audit. Recorded when the IKE negotiation is terminated because of the validation failure of a computer certificate signature. This event is rare because it indicates that the computer certificate on the IPSec peer has a mismatched RSA type public/private key pair.

  • Event ID 546, failure audit. Recorded when an SA cannot be established because of an invalid IKE proposal from the IPSec peer. This error typically occurs when an IPSec policy is incorrectly configured.

  • Event ID 547, failure audit. Recorded when the IKE negotiation fails. The causes of the failure are noted in the text of the event. Figure 9.7 shows an event generated when IKE negotiation failed during certificate authentication because a valid machine certificate was not located.

    click to expand
    Figure 9.7: Event ID 547 showing an IKE negotiation failure

    See Also 

    For information on how to enable auditing, refer to Chapter 3.

Logging dropped packets

IPSec is capable of adding events to the System event log when packets are filtered, as shown in Figure 9.8. The types of packet processing errors that the IPSec driver records in the System event log depend on the level of logging that is provided. IPSec driver logs can record inbound and outbound per-packet drop events during computer startup mode and operational mode. IPSec driver event logging is disabled by default, and it should not be used for extended periods. Depending on the logging level that you set, many events might be generated that will fill the System event log very quickly.

click to expand
Figure 9.8: Event ID 4290 showing dropped packets

To record all inbound and outbound dropped packets and other packet processing errors in the System event log on a computer running Windows Server 2003, set the IPSec driver event logging level to 7. By default, the IPSec driver writes events to the System event log once an hour or after a threshold for the number of events has been reached. For troubleshooting, you should set this interval to the minimum value, 60 seconds. To enable IPSec diagnostics and set the log interval to 60 seconds, run the following commands at a command prompt, and then restart the computer:

 netsh ipsec dynamic set config ipsecdiagnostics 7 netsh ipsec dynamic set config ipsecloginterval 60 
Off the Record 

The minimum value for the IPSec log interval is 60 seconds, which should cause IPSec to add a group of events for dropped packets once per minute. Exercise 3 in this lesson will demonstrate that it doesn’t actually work that way, however. Instead, IPSec will add events once every two minutes. If you set the ipsecloginterval value to something over two minutes, it seems to work correctly. So I guess the actual minimum is 120 seconds. Since the Netsh developers seem to think it’s 60 seconds, you should remember that value for the exam, but remember the actual minimum of two minutes for the real world.

The preceding commands cannot be used on a computer running Windows XP, however. To add IPSec driver events to the System event log on a Windows XP computer, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSec\EnableDiagnostics registry value to 7. To change the diagnostic interval to the minimum of once per minute, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSec\LogInterval DWORD registry value on the computer running Windows XP to 60, in decimal units.

Note 

You have to restart your computer after making this change because the IPSec driver reads the diagnostic level only during startup.

By default, packet event logging for the IPSec driver is disabled, which is equivalent to setting the diagnostic level to 0. When you enable packet event logging for the IPSec driver, you can specify any of the following values to enable various levels of logging:

  1. Packets with an incorrect Security Parameters Index (SPI), IKE negotiation failures, IPSec processing failures, packets received with invalid packet syntax, and other errors are recorded in the System event log. Unauthenticated hashes (with the exception of the “Clear text received when should have been secured” event) are also logged.

  2. Inbound per-packet drop events are recorded in the System event log.

  3. Level 1 and level 2 logging are performed. In addition, unexpected clear text events (packets that are sent or received in plaintext) are also recorded.

  4. Outbound per-packet drop events are recorded in the System event log.

  5. Level 1 and level 4 logging are performed.

  6. Level 2 and level 4 logging are performed.

  7. All levels of logging are performed.

The IPSec driver records bad SPI events using Event ID 4283 in the System event log when it receives an IPSec-formatted packet that it cannot interpret. These events occur because of the way in which IKE processes the transition of IPSec SAs during rekeys. They can usually be safely ignored.

Note 

You cannot disable logging for bad SPI events in Windows 2000. By default, Windows XP and Windows Server 2003 do not log these events.

IKE Tracing

Some troubleshooting scenarios require a more detailed analysis than you can do by using Event Viewer. The IKE tracing log is a detailed log intended for troubleshooting IKE interoperability under controlled circumstances. Keep in mind that the details of this tracing log are not well documented and that advanced knowledge of ISAKMP RFC 2408 and IKE RFC 2409 is required to interpret this log. However, experienced IPSec administrators might find it useful. You can enable tracing for IKE negotiations if the audit failure events do not provide enough information.

To enable tracing on a computer running Windows 2000 or Windows XP, create the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley\ EnableLogging registry value and set it to 1. Then either restart the computer or run the net stop policyagent and net start policyagent commands at the command prompt.

In Windows Server 2003, you can enable or disable the IKE tracing log dynamically while the IPSec service is running by using the Netsh commands for IPSec. To do this, open a command prompt and run the command netsh ipsec dynamic set config ikelogging 1. Alternatively, you can disable IKE tracing by running the command netsh ipsec dynamic set config ikelogging 0.

The IKE tracing log appears as the %systemroot%\Debug\Oakley.log file. A new Oakley.log file is created each time the IPSec service is started, and the previous version of the Oakley.log file is saved with the file name Oakley.log.sav. The log is limited to 50,000 lines. When the Oakley.log file becomes full, the current file is saved as Oakley.log.bak, and a new Oakley.log file is created.

Because many IKE negotiations can occur simultaneously, you should minimize the number of negotiations and enable the IKE tracing log for as briefly as possible to capture a more easily interpreted log. Use the IP addresses, SPI, timestamps, and SA identifiers to identify messages related to one security negotiation or IPSec SA processing session.

The following is an example of an Oakley log file. At first glance, it looks confusing. However, most of the lines are self-explanatory after careful examination. The first two rows show the date and time, and the remainder of each row is a description of what IPSec is doing at that particular moment.

12-22: 16:57:29:383:73c Sending: SA = 0x02B08C60 to 192.168.1.211:Type 2.500 12-22: 16:57:29:383:73c ISAKMP Header: (V1.0), len = 500 12-22: 16:57:29:383:73c   I-COOKIE daa86678465cfcfb 12-22: 16:57:29:383:73c   R-COOKIE 0000000000000000 12-22: 16:57:29:383:73c   exchange: Oakley Main Mode 12-22: 16:57:29:383:73c   flags: 0 12-22: 16:57:29:383:73c   next payload: SA 12-22: 16:57:29:383:73c   message ID: 00000000 12-22: 16:57:29:383:73c Ports S:f401 D:f401 12-22: 16:57:45:406:73c retransmit: sa = 02B08C60 centry 00000000 , count = 5

Netsh

Netsh was first introduced in Chapter 8 as a tool for configuring IPSec policies at the command line. It can also be used to monitor and troubleshoot IPSec on computers running Windows Server 2003, however. It provides access to several key pieces of information that are not accessible by means of graphical tools. Monitoring consists of displaying policy information, getting diagnostics and logging IPSec information, or both. By running Netsh, you can find any information that you can find by running the IP Security Monitor snap-in.

To quickly get a detailed snapshot of IPSec information on a computer, run the following commands from a command prompt:

Netsh ipsec dynamic show all > ipsec.txt Notepad ipsec.txt

These two commands will output all dynamic IPSec information to a text file and then open it in Notepad. You can, of course, view the information at a command prompt. However, the output from the command is so long that it will quickly scroll off the default command prompt.

Tip 

I prefer to use the Netsh ipsec dynamic show all command so that I don’t have to remember each of the various Netsh ipsec dynamic show commands. However, if you want more granular control over the information you receive, there are many more specific Netsh parameters. To list them, run the command Netsh ipsec dynamic show ? at a command prompt.

Performance Console

The most flexible way to monitor IPSec is to use the Performance console. The Performance console has two snap-ins: System Monitor and Performance Logs And Alerts. System Monitor allows you to monitor the real-time statistics of a wide variety of system counters by using a bar graph, a test report, or a line graph, as shown in Figure 9.9. Performance Logs And Alerts stores specified performance counters in a log file and allows you to later analyze the history of those counters by using the System Monitor snap-in. Performance Logs And Alerts can also send an e-mail message or other kind of alert when a counter reaches a specified threshold.

click to expand
Figure 9.9: Graphing IPSec performance statistics

Both Performance console snap-ins provide the same set of counters. IPSec counters are contained in the IPSec v4 IKE performance object, which contains Main Mode statistics, and the IPSec v4 Driver performance object, which contains Quick Mode statistics. The counters in the performance objects correspond closely to the Statistics parameters provided in the IP Security Monitor snap-in, but the counters are named slightly differently. For example, IP Security Monitor’s Transport Bytes Sent parameter in the Quick Mode Statistics node should have the same value as the Total Transport Bytes Sent counter in the IPSec v4 Driver performance object. They can differ slightly, however, because the IP Security Monitor snap-in is updated less frequently.

Exam Tip 

Oddly, the exam objectives do not mention using the Performance snap-in to monitor IPSec. I think it’s much more useful than the IP Security Monitor, but, for the sake of the exam, you should focus your energy on familiarizing yourself with the IP Security Monitor snap-in.

Network Monitor

Network Monitor is a protocol analyzer—a type of tool more commonly referred to as a sniffer. Network Monitor is an optional component included with Windows 2000 Server and Windows Server 2003 that can capture and analyze network traffic as it is sent to and from a computer. The version of Network Monitor included for free with the Windows operating systems is a limited version of the Network Monitor tool included with Microsoft Systems Management Server (SMS). The primary limitation is that the version included with Windows will capture only traffic sent directly to and from the computer it runs on. To capture traffic sent to or from other computers, you must use SMS.

The Network Monitor parser in Windows 2000 cannot interpret ESP traffic. In Windows Server 2003, the parser can interpret ESP traffic if an IPSec hardware acceleration adapter performs encryption or decryption of this traffic, or if you use ESP without encryption. Otherwise, as shown in Figure 9.10, you will only be able to see that ESP traffic is being exchanged with a remote computer. You cannot interpret the Application layer data within the ESP header because it is encrypted.

click to expand
Figure 9.10: Network Monitoring displaying ESP-encrypted packets

To install Network Monitor, open Control Panel, and then open Add Or Remove Programs. Click Add/Remove Windows Components. Click Management And Monitoring Tools, and then click Details. Select the Network Monitor Tools check box, and then click OK. Click Next, and respond to the prompts provided by the wizard. When installation has completed, click Finish.

See Also 

For information about SMS, see the Systems Management Server Web site at http://www.microsoft.com/sms/.

Netcap

Netcap.exe is a command-line utility that you can use to capture network traffic to a capture file. You can then load the file in Network Monitor to view the captured traffic. You do not have to install the Network Monitor tool on the computer running Windows Server 2003 to use Netcap. You can also use Netcap on computers running Windows XP, which makes it an extremely attractive way to capture traffic for later review. The tool is available after the Windows Server 2003 Support Tools have been installed. When you first run the command, the Network Monitor driver is automatically installed.

Ping

The favorite tool for troubleshooting network connectivity, ping, might or might not be useful for troubleshooting IPSec. First, if you use IPSec filters to block Internet Control Message Protocol (ICMP) traffic, neither ping nor Tracert will work because IPSec will filter the incoming requests. Second, ping requests do not initiate a security negotiation if you are using the default security policies. Both Server (Request Security) and Server (Require Security) explicitly permit ICMP traffic, but neither require ICMP traffic to negotiate security, as shown in Figure 9.11.

click to expand
Figure 9.11: Ping permitted, but not secured

If you create an IP security rule with the All ICMP Traffic filter list that uses a filter action set to Negotiate Security, and ICMP traffic is not being blocked by Internet Connection Firewall (ICF) or a firewall, ping can be a useful tool. In these cases, the ping client will show “Negotiating IP Security” during the IKE negotiation process. After negotiation succeeds, you will see the standard ping reply messages, and the successful negotiation will be reflected in the IPSec monitoring tools.

IPSecMon

Computers running Windows 2000 do not include the IP Security Monitor snap-in. Instead, there is a graphical tool named IP Security Monitor. To start this tool on a computer running Windows 2000, click Start, click Run, type ipsecmon, and then click OK. The Windows 2000 IP Security Monitor tool shows much of the same information as the IP Security Monitor snap-in, including a list of active SAs, and statistics such as confidential and authenticated bytes sent and the total number of bad SPI packets.

IPSecCmd

As mentioned in Lesson 1, IPSecCmd can be used to display IPSec information at the command line on computers running Windows XP. The syntax used to view all available IPSec information is simply Ipseccmd show all. IPSecPol lacks IPSecCmd’s query mode, and, as a result, you cannot display IPSec information from the Windows 2000 command line.

Netdiag

Netdiag.exe is a command-line tool that you can use to display IPSec information on computers running Windows 2000 and Windows XP. Netdiag is also available for Windows Server 2003, but the IPSec capabilities of Netdiag have been disabled. For Windows 2000, Netdiag is included with the Windows 2000 Support Tools that you can also download from the Internet. It is also available on the Windows XP Installation CD-ROM. You can install it by running  Setup.exe from the Support\Tools folder and choosing the complete installation.

To display information about the current IPSec policy from the command line on a computer running Windows 2000 or Windows XP, run the command Netdiag /test:ipsec. The output will resemble the following:

IP Security test . . . . . . . . . : Passed     Service status  is: Started     Service startup is: Automatic     Local IPSec Policy Active: 'Client (Respond Only)'     Description: 'Communicate normally (unsecured). Use the default response  rule to  negotiate with servers that request security. Only the requested protocol and  port  traffic with that server is secured.'     Last Change (Timestamp): Thu Dec 25 21:45:33 2003     Policy Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\ipsecPolicy {72385236-70fa-11d1-864c-14a300000000}     Note: run "ipseccmd /?" for more detailed information 

Practice: Monitoring IPSec

In this practice, you will use several techniques to monitor IPSec traffic on Computer1 and Computer2.

Exercise 1: Monitor IPSec with the IP Security Monitor

In this exercise, you will monitor IPSec by using the IP Security Monitor snap-in.

  1. Log on to the cohowinery.com domain on Computer2 using the Administrator account.

  2. Open a blank MMC console, and then add the IP Security Policy Management snap- in. When prompted to select the computer or domain, select Local Computer.

  3. In the right pane, right-click Client (Respond Only), and then click Un-Assign.

    This ensures that Computer2 does not have an active SA with Computer1. Later, you will re-assign the Client (Respond Only) policy to demonstrate that you can see the difference by using the IP Security Monitor snap-in.

  4. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  5. Open a blank MMC console, and then add the IP Security Monitor snap-in.

  6. Expand IP Security Monitor, expand Computer1, and then click Active Policy. In the left pane, verify that the Server (Request Security) policy is listed for the Policy Name item.

    If it is not still active from the exercise in Chapter 8, add the IP Security Policy Management tool and assign the Server (Request Security) policy.

  7. In the IP Security Monitor snap-in, expand Main Mode, and then click Statistics.

    Examine the Main Mode statistics, and make note of the Total Acquire, Total Get SPI, Key Additions, Key Updates, IKE Main Mode, IKE Quick Mode, and Soft Associations parameters.

  8. In the IP Security Monitor snap-in, expand Quick Mode, and then click Statistics.

    Examine the Quick Mode statistics, and make note of the Active Security Associations, Key Additions, Active Tunnels, Confidential Bytes Sent, Authenticated Bytes Sent, Transport Bytes Sent, and Bytes Sent In Tunnels parameters.

  9. Return to Computer2. In the right pane of the IP Security Management snap-in, right-click Client (Respond Only), and then click Assign.

  10. Start Windows Explorer. On the Tools menu, click Map Network Drive. In the Folder box, type \\computer1\c$, and then click Finish. If prompted, provide Administrator credentials for Computer1. Browse through the files on Computer1 to generate network traffic.

    The purpose of this step is simply to communicate with Computer1.

  11. Return to Computer1. In the IP Security Monitor snap-in, expand Main Mode, and then click Statistics.

    Examine the Main Mode statistics. As a result of Computer2’s incoming connection, all of the parameters you noted in step 7 should have incremented except for the Soft Associations parameter. Soft Associations measures sessions that could not be encrypted, but this session should have been successfully encrypted.

  12. In the IP Security Monitor snap-in, expand Quick Mode, and then click Statistics.

    Examine the Quick Mode statistics. As a result of Computer2’s incoming connection, all of the parameters you noted in step 8 should have incremented except for the Active Tunnels and Bytes Sent In Tunnels parameters. These parameters measure traffic used with IPSec tunnel mode. However, the connection between Computer1 and Computer2 is using IPSec transport mode.

    See Also 

    For more information about tunnel mode and transport mode, refer to Chapter 8.

Exercise 2: Monitor IPSec with Network Monitor

In this exercise, you will use Network Monitor to verify that traffic between Computer1 and Computer2 is encrypted.

  1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  2. Click Start, click Control Panel, and then click Add Or Remove Programs.

  3. Click Add/Remove Windows Components.

  4. Click Management And Monitoring Tools, and then click Details. Select the Network Monitor Tools check box, and then click OK.

  5. Click Next, and then respond to the prompts provided by the wizard. When the installation has completed, click Finish.

    Network Monitor has now been installed. It can be used to monitor traffic on Computer1.

  6. Click Start, point to Administrative Tools, and then click Network Monitor.

  7. If prompted to select a network connection, expand Local Computer, click Local Area Connection, and then click OK.

  8. Click the Capture menu, and then click Start.

  9. Log on to the cohowinery.com domain on Computer2 using the Administrator account.

  10. Start Windows Explorer. On the Tools menu, click Map Network Drive. In the Folder box, type \\computer1\c$, and then click Finish. If prompted, provide Administrator credentials for Computer1. Browse through the files on Computer1 to generate network traffic.

    The purpose of this step is simply to communicate with Computer1. When we later analyze the traffic by using Network Monitor, it will be obvious if the communications are protected by IPSec.

  11. Return to Computer1. On the Capture menu, select Stop And View.

    Network Monitor displays a list of all captured frames. If the two computers are connected to a private network with no other hosts, you will see ESP shown in the Protocol box for all frames. This proves that ESP is being used.

  12. Double-click one of the frames to view the details of the frame. In the middle pane, expand ESP and examine the information Network Monitor provides about the frame.

    Network Monitor can show you the SPI and the sequence number, but it won’t show you anything else of use. The data contained in the packet is encrypted and therefore cannot be analyzed, regardless of whether the capture is performed by a legitimate administrator or an attacker.

Exercise 3: Log dropped packets

In this exercise, you will configure Computer1 to log dropped packets and to filter ICMP packets by using IPSec. You will then ping Computer1 from Computer2 and analyze the events added to the System event log.

  1. Log on to the cohowinery.com domain on Computer2 using the Administrator account.

  2. Open a command prompt, and run the following command:

    Note 

    Ping –t computer1

    At this point, Computer1 will respond to the ping requests.

  3. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  4. Open a command prompt, and run the following commands:

    Note 

    netsh ipsec dynamic set config ipsecdiagnostics 7
    netsh ipsec dynamic set config ipsecloginterval 60

  5. Open a blank MMC console, and then add the IP Security Policy Management snap- in. When prompted to select the computer or domain, select Local Computer.

  6. Right-click IP Security Policies On Local Computer, and then click Create IP Security Policy.

  7. In the IP Security Policy Wizard, click Next.

  8. In the Name box, type Drop ICMP. Click Next.

  9. Clear Activate The Default Response Rule, and then click Next.

  10. Click Finish.

  11. In the Drop ICMP Properties dialog box, click Add.

  12. In the Security Rule Wizard, click Next three times.

  13. On the IP Filter List page, click All ICMP Traffic. Click Next.

  14. On the Filter Action page, click Deny. Click Next.

  15. Clear the Edit Properties check box, and then click Finish.

  16. In the Drop IMCP Properties dialog box, click OK.

  17. In the IP Security Policies On Local Computer snap-in, right-click Drop ICMP, and then click Assign.

    Within a few seconds, Computer2 will show Request Timed Out because Computer1 is now dropping ICMP traffic.

  18. On Computer1, start Event Viewer, and then click the System node in the left pane.

  19. In the right pane, double-click an event with the Type value set to Information and a Source of IPSec. If no such events have appeared yet, wait two minutes, and then press F5 to refresh the display.

    The Event Properties dialog box appears, as shown in Figure 9.12. The description shows that an ICMP packet from Computer2’s IP address was dropped.

    click to expand
    Figure 9.12: Event Viewer details about a dropped ICMP request

  20. Click OK. Wait two minutes, and then press F5 to refresh the display. You should see another group of IPSec events added. Note that the event time is two minutes after the last sent events, even though you configured the events to be added every 60 seconds.

  21. Close all open windows on both Computer1 and Computer2.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

  1. Which of the following parameters can be found in IP Security Monitor’s Main Mode Statistics? (Choose all that apply.)

    1. IKE Main Mode

    2. Bytes Sent In Tunnels

    3. Transport Bytes Sent

    4. IKE Quick Mode

    5. Total Acquire

    6. Soft Associations

    7. Active Tunnels

  2. Which of the following tools can be used to verify that network traffic to a specific host is being encrypted on a computer running Windows Server 2003? (Choose all that apply.)

    1. IP Security Monitor

    2. Event Viewer

    3. Netsh

    4. Netdiag

    5. Network Monitor

    6. IPSecMon

    7. Performance console

  3. Which of the following tools can display the total cumulative number of successful Main Mode negotiations on a computer running Windows Server 2003? (Choose all that apply.)

    1. IP Security Monitor

    2. Event Viewer

    3. Netsh

    4. Netdiag

    5. Network Monitor

    6. IPSecMon

    7. Performance console

Lesson Summary

  • Use the IP Security Monitor snap-in to examine Main Mode and Quick Mode IPSec statistics.

  • To audit IPSec negotiations, first enable success or failure auditing for Audit Policy Change and possibly for Audit Process Tracking. Then use Event Viewer to examine the Security event log.

  • To analyze packets that are dropped, enable IPSec driver event logging by using the Netsh command on Windows Server 2003. (Other versions of Windows require that you add a registry value to enable IPSec driver event logging.) Then use Event Viewer to examine the System event log.

  • When you need detailed troubleshooting information, enable IKE tracing by using Netsh. Then examine the %systemroot%\Debug\Oakley.log file.



 < Day Day Up > 



MCSA(s)MCSE Self-Paced Training Kit Exam 70-299 (c) Implementing and Administering Security in a M[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)
ISBN: 073562061X
EAN: 2147483647
Year: 2004
Pages: 217

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net