IPSec Packet Filtering

Activate and Test It
Now you need to activate your policy. Select the Packet Filters policy, right-click your policy, and select Assign. Open a command prompt and enter

secedit /refreshpolicy machine_policy

Your IPSec policy is now in effect. Test it; you should be able to browse the Web site from any computer. You shouldn't be able to connect through FTP from your workstation because only the application servers are permitted to connect through ports 20 and 21. Go to a workstation outside subnet 10.0.11.* and try to log on using Terminal Services; the attempt should fail.

If your Web server and the workstations your administrators use are part of the same Active Directory (AD) forest, you can require Kerberos authentication to tighten security on port 3389 for Terminal Services. Delete the filter for port 3389 from the permit rule. Create a new rule in which you select Kerberos as the authentication method. (Keep in mind, however, that if you use Kerberos authentication, you can't enable NoDefaultExempt, which then lets more-experienced intruders spoof the source port to TCP 88 to bypass your blocking rules.) Give the rule the same packet filter you specified earlier for subnet 10.0.11.* and port 3389, but—for this rule—specify Require Security as the rule's action. Next, configure your administrator workstations to support IPSec when they connect to the Web server. You don't need to create a new IPSec policy for these client computers because Win2K includes a Client (Respond Only) policy that automatically negotiates security when a client requests it. To assign this policy on your administrator workstations, either edit the Microsoft Management Console (MMC) Local Security Policy snap-in on each workstation by assigning the Client (Respond Only) policy or add those workstations to an organizational unit (OU) and link a Group Policy Object (GPO) to that OU. Assign the Client (Respond Only) policy to the GPO. Now you have further protection against intruders who connect to Terminal Services on your Web server, even if they succeed in spoofing their IP addresses to make it look as if they come from the 10.0.11.* subnet.

By default, IPSec doesn't block packets that appear to be related to Kerberos or Internet Key Exchange (IKE); it views any packet with a source or destination port of TCP port 88 (Kerberos) or UDP port 500 (IKE). Therefore, an experienced intruder might succeed in reaching a supposedly blocked destination port on your server by specifying TCP port 88 or UDP port 500 as the source port. In Win2K Service Pack 1 (SP1), Microsoft added NoDefaultExempt, a REG_DWORD value under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC registry subkey. When you set NoDefaultExempt to 1, Win2K won't let packets with source port 88 reach destination ports on a server you blocked with an IPSec policy. However, NoDefaultExempt doesn't address IKE packets, and Microsoft documentation doesn't explain why it doesn't.

Flexible Security
Good security is a combination of layers stacked to provide in-depth defense. Using IPSec packet blocking is a good, built-in second line of defense in case your firewall fails you. If you're interested in an independently developed packet-filtering utility, check out Jean-Baptiste Marchand's PktFltr.