Netsh Adds Security to IPsec

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.

End of Article

   Previous  1  [2]  Next