Windows Server 2003 : Configuring a Windows IPSec Policy (part 3) - Setting Up the IPSec Monitor and Testing the Policy, Writing Policies Using netsh

6. Setting Up the IPSec Monitor and Testing the Policy

You could test the policy as you have previously, but you should use the IP Security Monitor tool to monitor IPSec activity. This tool can help you understand your policies, troubleshoot policy problems, and verify that encryption is taking place. To use the tool, create a new MMC on ComputerA. In this example, you'll monitor both computers from one console. However, you can create a console on each computer if you wish.

Open an MMC console on ComputerA and add the IPSec Monitor snap-in. ComputerA will be monitored automatically. Right-click on The IP Security Monitor and select "Add computer." Enter the IP address for ComputerB and click OK. Expand both computers and select the Active Policy node for one of the computers, as shown in Figure 11. The Active Policy node provides information on the active policy.

Figure 11. Display the active policy

On ComputerB, repeat the process so that you can monitor both computers from either computer. On ComputerA, in the IPSecurityPolicy1 console, right-click the Block TS policy and click Assign. On ComputerB, open the Remote Desktop Connection. If the IP address of ComputerA is not in the Computer window, use the drop-down arrow to select it, or use the Options button and then the Open button to open the ComputerA connection information saved earlier. Click the Connect button. The connection should succeed.

On ComputerA (or by opening the IP Security Monitor console on ComputerB's remote desktop of ComputerA), select the Quick Mode → Statistics node, as shown in Figure 12. You should see some numbers in the Confidential Bytes Sent and Authenticated Bytes Sent categories. Not shown in the figure, but available if Main Mode statistics are displayed is the Soft Associations category. You should not see any numbers except 0 in the Soft Associations category. Soft Associations are unsecured bytes, and this policy requires encryption.

Click the Security Associations node which includes a section for each SA. Double-click on a specific SA to display the information shown in Figure 13. This will provide you with information on which protocols are being used to secure the communication.

Spend some more time viewing the parts of the IP Security Monitor. Familiarity with this tool when things are normal and correct will help you whenever you need to troubleshoot your IPSec policies.

If the connection does not succeed, you may be able to use the IP Security Monitor feedback to troubleshoot the problem. For example, if there is no information in the Quick Mode → Statistics node, then the failure occurred during Main Mode. If the Main Mode → Statistics node shows authentication failures, check to ensure that the same authentication method is chosen. Check the spelling of the shared secret. If negotiation failures occur, then check the protocols that are being used, the ports that

Figure 12. The presence of Confidential Bytes indicates that encryption is taking place

Figure 13. View confidential and authentication bytes sent to verify security

should trigger the response and so forth. 

Once you have learned how to create and assign policies using the wizard, you should also explore how to create a policy using a script. The netsh command is used to do so. Not only is this a useful technique, but knowing how to use netsh is a good idea. You can only create persistent policies by using netsh, and netsh has some useful monitoring commands as well. The following section describes how to write a policy to do the same task described earlier by using the wizard.

7. Writing Policies Using netsh

You can use netsh at the command line to create IPSec policies for the local computer. If you use the netsh commands in a script, you can run it on as many computers as you wish. You will, however, have to adjust any computer-specific information in the script. The netsh command is a complex command that offers much more functionality than that used to create and assign IPSec policies.

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

IPSec netsh commands can be executed as either static or dynamic. Static mode is used to create policies for assignment later. Nothing you do actually changes the use or non-use of IPSec on the computer unless you include the assign command in the script, or execute it later at the command line. Otherwise, the IPSec Policy Agent is not aware of them. On the other hand, dynamic mode IPSec netsh allows you to make immediate changes to IPSec policy. If the Policy Agent service is stopped, however, the dynamic changes are discarded. Dynamic IPSec should be used only if you must make immediate changes to IPSec processing. There will be 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, then enter the word static or dynamic to select the mode. Alternatively, you can enter all three words at the same time (for example, netsh ipsec static).

To create and assign the policy, you'll follow steps similar to those outlined for the GUI interface of the wizard as described earlier. 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 security negotiation rules, and do other things such as monitor IPSec and create special types of IPSec policies that cannot be created with the GUI.

The following steps will create an IPSec policy that blocks Terminal Services (access to a Remote Desktop session, and/or access to a terminal server using either Remote Administration mode or Application mode) from all computers except from ComputerB. To test your script, be sure to unassign any polices assigned on ComputerA and ComputerB.

The easiest way to work is to add the lines to a text file and save it as a batch file using the extension .bat. You can then run the 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. If you make mistakes, or need to remove the policy, you do so by using the delete policy command. An example, using the Block TS policy name is shown here:

    Delete policy name="SecureTSBlock TS"

To create policies, first, create a policy for ComputerA that will block all Terminal Services, but negotiate security for Terminal Services from ComputerB. 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.

Enter IPSec static mode:

     netsh ipsec static

Create the policy on ComputerA. The parameters in the following statement below are fairly easy to interpret, except the mmsecmethods parameter. The mmsecmethods parameter is the main mode security methods information.

    add policy name="SecureTS" description="block all terminal services except
    connections from ComputerB" activatedefaultrule=no mmsecmethods="3DES-MD5-3"
				

					  

To block all terminal services except that from ComputerB, two rules must be written. Each rule needs a filter added to the rule's filter list, so create that first. Here is a filter to identify ComputerB. It adds the IP address of ComputerB in the policy written on ComputerA. Src and dst stand for source and destination, respectively (for example, srcaddr stands for source address, and dstaaddr stands for destination address).

    Add filter filterlist="TS computerB" srcaddr=10.10.0.2 dstaaddr=Me
    description="computerB terminal services to computerA" protocol=TCP mirrored=yes
    srcmask=24 dstmask=32 srcport=0 dstport=3389
				

					  

Next, add a negotiate filter action. The qmsecmethods parameter identifies the quick mode security method. The qmpfs=no parameter indicates perfect forward security is not used. Inpass=no indicates that insecure communication is not allowed.

    Add filteraction name="negotiate TS" qmpfs=no inpass=no soft=no action=negotiate
    qmsecmethods="ESP 3=DES-MD5"


					  

Add the rule for negotiation:

    Add rule name="SecureTS Rule" policy="SecureTS" filterlist "TS computerB"
    filteraction="negotiate TS" psk="secret" description="this rule negotiates a terminal
    services connection if the source address belongs to computerB"


					  

Note how the filteraction is identified by name, as is the policy and the filterlist. The rule statement ties these important parts together.

Create the second rule, the blocking rule. First, create a filter:

    Add filter filterlist="blockTS Filter" srcaddr=Any dstaddr=Me description="block all
    terminal services to ComptuerA" protocol=TCP mirrored=yes srcmask=24 dstmask=24
    srcport=ANY dstport=23
				

					  

Add the filter action:

    Add filteraction name="Block TS Action" inpass=yes action=block
				

Add the rule:

    Add rule name="BlockTS" policy="SecureTS" filterlist "blockTS filter"
    filteraction="Block TS Action" psk="secret" description="this rule blocks all
    terminal services"


					  

The shared secret is entered in clear text in the Add rule statement using the psk parameter. It is, therefore, visible to anyone who can obtain access to the script. In a production environment, always use alternative authentication methods to improve security. If you must use a shared secret, protect the secret. Do not leave scripts and notes lying around in hard copy, and do not store the script file where it can be opened and read. If a script is used to add a policy, remove the script file afterward.

Next, create a policy on ComputerB. This policy only needs a single rule, the negotiate rule. The easiest way is to copy the policy created for ComputerA, and delete the blocking rule. Then, if necessary, you can adjust the statements. A copy of the policy written previously is listed here with the adjustment made to the filter. The change is necessary to switch the source and destination addresses.

Enter IPSec static mode:

     netsh ipsec static

Create the policy on ComputerA. The mmsecmethods parameter is the main mode security methods information:

    add policy name="SecureTS" description="block all terminal services except
    connections from ComputerB" activatedefaultrule=no mmsecmethods="3DES-MD5-3"
				

					  

Add a filter to identify ComputerB:

    Add filter filterlist="TS computerB" srcaddr=10.10.0.1 dstaaddr=10.10.0.2
    description="computerB terminal services to computerA" protocol=TCP mirrored=yes
    srcmask=24 dstmask=32 srcport=0 dstport=3389
				

					  

Next, add a negotiate filter action. The qmsecmethods parameter identifies the quick mode security method. The qmpfs=no parameter indicates perfect forward security is not used. Inpass=no indicates that insecure communication is not allowed.

    Add filteraction name="negotiate TS" qmpfs=no inpass=no soft=no action=negotiate
    qmsecmethods="ESP 3=DES-MD5"


					  

Add the rule for negotiation:

    Add rule name="SecureTS Rule" policy="SecureTS" filterlist "TS computerB"
    filteraction="negotiate TS" psk="secret" description="this rule negotiates a terminal
    services connection if the source address belongs to computerB"


					  

The final step is to assign the policy. Remember to add this line to each batch file:

    Set policy name=SecureTS assign=yes