Netsh Adds Security to IPsec

In "The Potent Union of Netsh and IPsec" (September 2006, InstantDoc ID 92767), I walked you through the process of using a command-line IPsec setup to block any incoming or outgoing traffic on port 80. Blocking and permitting traffic are two of the simplest uses of IPsec—but they're not the only ones. IPsec can also digitally sign or encrypt traffic, and signing and encrypting require a bit more information. So, this month, let's modify last month's task: Let's create an IPsec rule that allows a Web server to offer traffic on TCP port 80, but only if it's encrypted with Triple DES (3DES) and signed with the Secure Hash Algorithm-1 (SHA-1).

Creating the Policy
As we did last month, we'll create an IPsec policy that applies to a Web server or group of Web servers. The policy will consist of just one rule, which must have a filter list and a filter action (as well as an authentication method, but we'll cover that later). The filter action will activate the rule if data arrives at a particular system through TCP port 80 or if data leaves from that system's TCP port 80 to anywhere. Should the filter list be satisfied, the action that the rule will take is to require 3DES encryption and SHA-1 signing.

With Windows Server 2003 commands, we'll create the policy, then the filter list, then the filter action, and finally the IPsec rule. Here's how to render the policy:

All our IPsec-related commands begin with Netsh Ipsec Static. The Add Policy option creates a policy, and the command proceeds to name and describe the policy.

Creating the Filter and Filter List
The filter we want to build will tell IP to engage the specified rule if data enters or leaves at TCP port 80; therefore, the filter recalls the one we created last month:

In situations involving only one filter, Netsh lets you create both the filter list and the filter by simply naming the filter list after the add filter parameter. When Netsh tries to add this filter to a filter list named "80 in or out" and can't find a filter list by that name, it creates that filter list. The command says that this rule applies when the data originates from anywhere (srcaddr=any) and any port (srcport=0), and is destined for the system to which this policy is applied (dstaddr=me) on TCP port 80 (dstport=80 protocol=tcp). The mirrored=yes parameter specifies that two filters are actually in place: one from anywhere to this system on TCP port 80, and one from this system on TCP port 80 to anywhere.

Creating the Filter Action
Instead of last month's action, which was to block the transmission if the filter is satisfied, this month's action is to encrypt and sign the transmission if the filter is satisfied. That code looks like

The Add Filteraction option adds a filter action, and the command proceeds to name and describe the action. Note the inclusion of the action=negotiate parameter, rather than action=block or action=permit. You use the action=negotiate parameter whether you want digital signing or encryption and signing. But which shall it be?

The next parameter, qmsecmethods="ESP\[3DES, SHA1\]", answers that question. This parameter has many possible parameters, but essentially you specify either ESP\[\] or AH\[\] and enter your preferred encryption or hashing algorithm inside the square brackets. For example, "AH\[SHA1\]" will use SHA-1 to digitally sign traffic. ESP requires the names of two cryptographic algorithms—for encryption and hashing—because it both encrypts and signs traffic. Thus, "ESP\[3DES,SHA1\]" encrypts with triple 3DES and signs with SHA-1.

The final three parameters correspond to three check boxes in the GUI of an IPsec filter action. The first check box is Accept unsecured communication, but always respond using IPSec. Suppose you have an XP box with a basic IPsec rule in place: This computer sends encrypted responses when it's asked to do so, but it never initiates encryption. If that XP system tries to retrieve Web content on your secured Web server, the Web server will accept the HTTP request but respond in encrypted IPsec. At this point, the client either doesn't understand IPsec and simply stops communicating, or it does understand and starts replying via IPsec. Selecting this check box isn't necessarily a bad idea—in fact, if you intend to equip your client systems with only the built-in IPsec policy named Client (Respond Only), you'll have to select it—but I don't like it. Plenty of Web applications stuff authentication details into the initial HTTP request, so I'm uncomfortable with the possibility that even the first communication to a secure Web server might travel in clear text. The inpass=no parameter clears that check box and avoids any chance of clear text occurring on the introductory communication.

The Allow unsecured communications with non-IPSec-aware computers check box is a terribly bad idea. Essentially, it requests encrypted communications from clients, but if they're unable to accommodate that request, the unsecure communications are permitted anyway. Remember, folks, malicious users don't need all your passwords; they need only one. The soft=no parameter clears that check box.

Finally, the qmpfs=yes parameter modifies the way IPsec changes its encryption/ signing keys. To thwart malicious users, IPsec regularly changes cryptographic keys. (You can configure IPsec to rekey as often as you want.) The new keys are mathematically related to the previous keys; therefore, if a key is compromised, an intruder might be able to figure out the subsequent keys. If you don't mind a slight performance slowdown, enable the Use session key perfect forward secrecy check box. By doing so, you enable a different approach to generating new keys. Instead of generating a key based on the previous key, IPsec reauthenticates the two parties and lets the authentication mechanism—Kerberos, in our case—generate a new key that's completely unrelated to the previous keys.

Choosing qmpfs=yes reauthenticates with every key.

What's the Rule?
To create the rule, we'll combine the filter list, the filter action, and the third item that we didn't need last month: authentication. IPsec supports three approaches: a shared secret password (a terrible idea except in testing situations), the built-in Kerberos infrastructure that connects every system in an Active Directory (AD) forest, or an X.509 certificate exchange. Windows IPsec uses Kerberos by default, and I'll use that for this example. The Netsh command to build the rule looks like

The Add Rule parameter is present because we're adding a rule. Next, the command names the rule and names the policy that includes this rule. (You can't use rules in more than one policy.) Then, the command names the filter list and filter action. The Kerberos=yes parameter specifies Kerberos authentication, and the command ends with a description. Now, you need only enable the policy, as we did last month, or go to the GUI to get it going.