The Potent Union of Netsh and IPsec

In last month's column ("Netsh Tricks," InstantDoc ID 50425), I showed you three interesting ways to use the powerful Netsh command, and I suggested that the tool could do a lot more. One example of "a lot more" is the way Netsh tackles IPsec functionality in Windows Server 2003—a topic that everyone feels they should know better but haven't had the time to research. Now's the time to start remedying that situation. Let's start with a little IPsec background, then delve into an example of using Netsh and IPsec to block a specific TCP or UDP port.

IPsec Primer
Ipsec has been around since Windows 2000, but it's a new game for Netsh. Historically, Microsoft seems to have had some difficulty determining what kind of interface to give IPsec, particularly on the command line. Windows 2000 offers Ipsecpol (available in the Microsoft Windows 2000 Resource Kit), Windows XP 32-bit offers Ipseccmd (an XP Support Tools utility), and now Windows 2003 and XP Professional x64 Edition have moved IPsec command-line control to Netsh in the Netsh Ipsec command set.

Because IPsec can be complex and beyond the range of daily tasks that most administrators perform, let's start with a quick Ipsec primer. As its name suggests, IPsec adds security to the relatively low-level IP protocol. With IPsec, you can not only configure IP to pass packets from one system to another (IP's typical functionality), you can also set it to pass packets only if the sender and receiver encrypt or sign those packets, and you can set it to refuse to pass packets. The particularly nice aspect of IPsec is that, again, we're talking about IP—not any higher-level protocols. With IPsec, you can secure Web communications as easily as you might secure email or Microsoft SQL Server transactions, because those applications run on top of IP.

Unfortunately, however, IPsec is a jargon-rich environment. Understanding IPsec means understanding terms such as policy, rules, filter list, filter, filter action, and authentication.

Policy and rules. You secure some or all of your IP communications on a given system (or set of systems) by creating what IPsec calls a policy. The policy is nothing more than a container for one or more rules, so it's little more than a descriptive label, such as Protect my SQL Server system or Block port 80. In the SQL Server example, the policy might consist of two rules, such as Allow encrypted communications only on port TCP 1433 with the local subnet and Block any incoming communications to TCP 1433 from anywhere else. (TCP 1433 is the default network interface port for SQL Server.) In general, each rule has two mandatory parts and one optional part. The mandatory parts are the filter list and the filter action, and the optional part is authentication.

Filter list. A filter list is just a container for one or more filters. These filters determine when to activate IPsec rules. You specify the combination of IP addresses, protocols, and ports that must match before the filter action occurs. For example, in the Allow encrypted communications only on port TCP 1433 with the local subnet rule, the filter would say to enable the rule when the source address is any address on the local subnet, the destination address is the server's address, the source port is any port, the destination port is 1433, and the protocol is TCP. Note that the filter list contains just one filter—a fairly common scenario in IPsec filter lists.

Filter action. When the filter is satisfied, the filter action occurs. An IPsec filter action can either permit the communication and pass the packets along (the default behavior that's happening on most of your networks right now), block the communications (simply discard the IP packets), encrypt the data stream, or digitally sign the data stream. For example, the second rule in our policy, Block any incoming communications to port 1433, has a filter action of block.

Authentication. If the filter action is neither block nor permit but rather encrypt or digitally sign, the optional third component of a rule becomes necessary: an encryption and/or signing algorithm and a means to exchange cryptographic keys for that encryption and signing—in other words, an authentication mechanism. IPsec lets two parties authenticate either by knowing the same password (i.e., a shared secret), by exchanging certificates, or simply by being members of the same Active Directory (AD) forest—an option that IPsec calls Kerberos.

Port-Blocking Example
An easy task you can use IPsec to perform is to block a specific TCP or UDP port. Although blocking ports might not sound incredibly useful, I've used IPsec in this way to use a mere batch file to build an ad hoc firewall—even after Windows Firewall debuted. Unlike Windows Firewall, IPsec can block outgoing packets.

Suppose you've discovered that some employees are running secret Web servers that host questionable content. You would like to stop that activity by creating a set of commands that prevent anything going into or out of port 80. Let's make a policy that contains one rule: If a packet is on its way to a particular system through TCP port 80, or if a packet is on its way from that system's port 80 to any other system, IPsec needs to block that packet.

If you'd like to follow along in this example, just set up a Windows 2003 system with Microsoft IIS and use Notepad to create a simple file (e.g., "Hello from Windows 2003!") in C:inetpubwwwroot, and call the file default.htm. To ensure that you've got the Web server set up right, try accessing this Web page from another system. Then, go back to the new Web server and open a command prompt.

Creating the policy. Begin the process by creating the IPsec policy, which you might call Block Web serving. The Netsh syntax is simple:

netsh ipsec static add policy
name="Block Web serving" 
description="Stops people from 
running a Web server on their system" 

All our IPsec-related commands begin with Netsh Ipsec Static. After that, you'll see either Add, Delete, Set, or Show, followed by one of five options: policy, rule, filterlist, filter, or filteraction. Legal parameters for most of the five are name= and description=. If you're ever unclear about syntax—a common problem with Netsh—just type the command without parameters, as in

netsh ipsec static add policy 

Building the filter. The filter we want to build will tell IP to engage the specified rule if data enters or leaves at TCP port 80. In our example, we need to specify the source IP addresses (i.e., anywhere in the Internet), source port (i.e., any port), destination IP address (i.e., me, which is a meaningful value in IPsec), and destination port and protocol (TCP 80), as follows:

netsh ipsec static add filter  filterlist="80 in or out"  srcaddr=any srcport=0   dstaddr=me dstport=80  protocol=tcp mirrored=yes 

The filterlist=name parameter tells IPsec which filter list to put the filter into. But when did we create that filter list? Netsh does have a command for creating a filter list, but in our example, when the Add Filter component sees that the new filter is to be part of a filterlist that doesn't exist, the command creates that filter list. The words any and me are built-in keywords with selfexplanatory meanings. The dstport=80 parameter is also self explanatory (i.e., the destination port number), but the srcport=0 parameter might not be—it means any source port.

The mirrored=yes parameter means that we really want this filter to be a rule that specifies both incoming data to port 80 on this system as well as the reverse: any outgoing data from port 80. I could have created two separate filters in my filter list, but many IPsec filters cry out for pairs such as this— pairs that might be called "mirrors."

Creating the filter action. Now, let's create the filter action. All we need to do is define an action that will block data, as follows:

netsh ipsec static add filteraction name=blockit action=block 

This command creates a filter action with the name blockit, and clearly the action is to block data.

Assembling the policy. We now have a policy, a filter list, and a filter action; all that remains is to glue the filter list and filter action into a rule, as follows:

netsh ipsec static add rule

 name="Block 80"
 policy="Block Web serving"
 filterlist="80 in or out"
 filteraction=blockit
 desc="Makes Web servers on this system
 effectively impossible

That's a long command, but it's fairly straightforward. Recall that a rule consists of at least two things—a filter list and a filter action—and is part of a policy. The command's parameters give the rule a name (Block 80), the filter list to use (80 in or out), the action to take (blockit), and a description. The policy is now assembled.

Enabling the policy. All that remains is to enable the policy. To do that, you can use the command

netsh ipsec static set  policy name="Block Web serving"  assign=y

Finally, go to another system, fire up Microsoft Internet Explorer (IE) and try to open the home page on your Web server. IE will attempt the action for a while and finally give up. Try it again, run back to the Web server, and type

netsh ipsec static set  policy name="Block Web serving"  assign=n 

and you'll see the home page.

More to Come
This article's IPsec example is one of the simplest you can try, but really, the more difficult ones aren't much more complex, and they can accomplish some valuable things. Next month, I'll dive more deeply into the power of Netsh and IPsec by introducing encryption into the equation. Until then, keep playing with Netsh!