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
netsh ipsec static add rule name="Encrypt 80"
policy="Require encryption on Web
"filterlist="80 in or out" filteraction="
force triple DES" Kerberos=yes desc="Secures Web traffic"
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.