The third part of a rule contains the rule's authentication methods. For permit or block actions, you don't need to specify an authentication method. However, if your rule's action is to negotiate security, you'll need to ensure that at least one of the three authentication methods is configured. (If more than one authentication method is configured, the two computers compare the methods for which each one is configured until they find one they have in common.) The available authentication methods are Kerberos, preshared secret key, and certificate-based authentication.
Unlike router or firewall tables, the sequence of rules within a policy or filters within a filter list isn't important. You can specify a blocking or negotiate-security rule with a broad filter list, then open ports with a permit rule whose filter list specifies just the public ports. Win2K automatically applies what it considers the most specific rule to each packet. Although you might think that this approach could lead to some ambiguity, so far Win2K has always interpreted the policies I've created as I intended.
Protecting Your Private Ports
The simplest way to protect your Web server's private ports is to create a broad rule that requires negotiated security for all connections to the Web server from any source address. Then, create a more specific rule that permits connections to public ports such as 80 and 443 without any further IPSec involvement, as Figure 2, page 15, shows. For your broad rule that requires negotiated security, you'll need to choose an AH or ESP mode.
If you need to simply ensure that only trusted computers access the port and you don't care whether others can see the data in the packets, you can improve performance by using only AH. Some applications such as Terminal Services already encrypt some or all of the data they transmit. To ensure maximum confidentiality, use ESP. (When you use ESP, even the port numbers are encrypted.) Incidentally, my testing hasn't revealed that implementing IPSec imposes a significant performance penalty. (I transferred a file of at least 2GB without IPSec in about 45 minutes. With IPSec in ESP mode, the file transfer took only 3 minutes longer.)
With the flexibility of IPSec, you can define rules that help you stop worrying about attackers gaining access to your Web server through the private ports you use to administer or update your server. If you use the strategy I've described—of creating a broad rule that requires IPSec security for all ports—don't forget to create an exception rule to allow unsecured communication to public ports such as 80 and 443. Otherwise, you'll lock the public out of your Web server.
I discussed the overall pieces involved in limiting access to private ports on your Web server, but how does IPSec know it's communicating with a trusted computer? You'll need to determine which authentication methods to use.
Kerberos is the easiest authentication method to designate in your IPSec policy because you don't need to set up any additional key exchange or certificate requests. However, Kerberos isn't an option for computers that aren't part of trusted domains, which leaves preshared secret key or certificate-based authentication.
Next month, I'll consider the pros and cons of each authentication method for Web servers. I'll also set up a sample IIS server to show you how to use IPSec protection.
Register
