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:
netsh ipsec static add policy name="Require encryption
on Web" description="Force any Web visitors to
encrypt communications and Kerberos to
authenticate" activatedefaultrule=no
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:
netsh ipsec static add filter filter-list="80 in or
out" srcaddr=any srcport=0
dstaddr=me dstport=80
protocol=tcp mirrored=yes
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
netsh ipsec static add filteraction name="force encryption"
esc="Forces communications using encryption"
action=negotiate qmsecmethods="ESP\[3DES,
SHA1]" inpass=no soft=no qmpfs=yes
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.