You can also use the command-line utilities to apply dynamic policies, which stay in effect only as long as the system is running (they're lost when the policyagent service is restarted or the computer is rebooted). Dynamic policies are useful when you know you won't need a policy for a long time and want to use a reboot to clear it. The following two commands create a dynamic policy that does the same thing as the static policy I created above:
ipseccmd -f[*=0:1434:UDP]
ipseccmd -f[0=*:1434:UDP]
The square brackets that enclose the filter specification indicate that the filtered traffic will be blocked.
So far we've been exploring how to use IPsec to block traffic from and to known "bad" destination ports. You could be more restrictive with your IPsec policies—blocking all traffic in both directions and creating rules that permit certain traffic from and to certain ports. Think carefully about what kinds of traffic to allow, plan extensively, and thoroughly test your ideas before launching them into production.
Using IPsec to Protect Servers
One good use of a "block-all-except-for" policy is for server protection. Why should a Web server, for example, accept anything other than inbound Web traffic on its Internet-facing connection? You can use an IPsec policy to build a rudimentary packet filter that discards everything except whatever makes sense for the purpose of a particular server—in the case of a Web server, everything except traffic destined for TCP port 80 (and TCP port 443, if some pages use HTTP Secure—HTTPS).
You could also use a server-protection policy to buy time for testing and deploying patches. If someone discovers a vulnerability in the OS, you can assign a policy to deny access to the vulnerable service to give yourself additional time to test and deploy the patch during a scheduled outage, rather than violating a service-level agreement that might be in place.
Let's look at an IPsec policy for a Web server. The policy would have two rules:
Rule 1
- Filter list with one filter: from any-address:any-port to my-address:any-port
- Filter action: block
- Rule: link the list with the action; all interfaces; no tunnel; any authentication method
Rule 2
- Filter list with two filters: from <any-address>:<any-port> to <my-address>:80/tcp and from <any-address>:<any-port> to <my-address>:443/tcp
- Filter action: permit
- Rule: link the list with the action; all interfaces; no tunnel; any authentication method
To script this policy, use the following commands:
ipseccmd -w REG
-p "Web traffic packet filter"
-r "Block everything"
-f *+0 -n BLOCK -x
ipseccmd -w REG
-p "Web traffic packet filter"
-r "Permit web traffic"
-f *+0:80:TCP -f *+0:443:TCP
-n PASS
Note in these examples that a plus sign (+) replaces the equals sign (=) between the source and destination IP address:port:protocol specifications. The + tells the policy agent to build "mirror" rules, which are required for reply traffic to leave the Web server. Without the mirror, you'd need to write separate rules permitting outbound traffic from the server's TCP ports 80 and 443. When you create rules in the GUI, they're mirrored automatically. Figure 1 shows the filter list for Web traffic in the GUI. Figure 2 shows the Web packet filter policy with two rules, one to block all traffic and another to permit Web traffic.
Could you accomplish the same thing with a host-based firewall? Of course, and on a Windows 2003 server that's what I'd prefer. But for a Win2K server, using IPsec to filter packets is very effective at reducing your attack surface area. Think about the roles of various servers in your organization and start to develop IPsec policies that are appropriate for those roles. Use Group Policy to assign the IPsec policies based on organizational units (OUs) that reflect the roles. You can measurably increase the security of your environment simply by implementing a method to limit the traffic that enters a server.
Using IPsec for Domain Isolation
You know who your users are—they have to authenticate to a domain controller (DC) when they want to use network resources. But what about their computers? Sure, some of them are joined to your domain. Windows doesn't require that computers belong to the domain, though. So long as a user possesses valid credentials, he or she can access network resources from any computer on the network. And XP's credential manager makes it even easier for a client that isn't joined to your domain to access network resources.
The concept of domain isolation essentially prohibits rogue machines from accessing domain resources and permits only authorized domain-joined computers to communicate with other authorized computers. You can trust domain-joined computers at least somewhat, because they use security-related technologies that you can centrally control and manage, such as Group Policy, security templates, software restriction settings, IPsec policies, and Microsoft Systems Management Server (SMS). Computers whose configuration you control are computers that do only what you allow them to do. These computers are far less dangerous in your environment than rogue unmanaged machines whose existence or configuration is unknown to you. I urge you to start thinking about domain isolation soon.
Implementing domain isolation across your domain is easier than you might think. First, add the following IPsec policy to your default domain Group Policy Object (GPO):
- Filter list: Use the existing All IP Traffic sample filter list
- Filter action: Encapsulating Security Payload (ESP) only, null encryption, SHA-1 integrity; require security; don't communicate with non-IPsec machines
- Rule: link the list with the action; all interfaces; no tunnel; Kerberos authentication; no default response
Use ESP-null because you're interested in per-packet authentication, not encryption. Privacy isn't a requirement—only authentication and integrity, which SHA-1 hashes provide. You could use IPsec Authentication Header (AH) rather than ESP-null, but then your policy wouldn't work with devices that communicate over Network Address Translation (NAT) devices.
You also need to create a policy that exempts your DCs, because clients need to communicate with them to authenticate and get the Kerberos ticket that's used for all other communications:
- Filter list: filters with the addresses or address ranges of your DCs
- Filter action: permit
- Rule: link the list with the action; all interfaces; no tunnel; any authentication method
You'll need similar policies for machines that can't participate in IPsec, such as network printers.
After you test and deploy these policies, nondomain machines will be unable to communicate with any domain-joined machine because domain members require IPsec. Clients can't get the policy unless they join the domain. Clients outside the domain can't "roll their own" policy because the IPsec policy requires Kerberos, which works only if the client is in the domain. All domain members receive the policy and therefore can communicate with all other domain members.
The network edge is moving inward; indeed, it's becoming more difficult to identify the outside border of a network the way we once did. Instead of an egg with a hard perimeter and a gooey inside, we now view the network as more like an onion with nested layers. We're arriving at a time in which every layer—every computer—must be secured. IPsec is the right technology to help fortify every host in your network.
End of Article
