Securing Your Network Using IPsec - 01 Apr 2005

Last month I introduced you to IPsec, a wonderful but sometimes bewildering bit of technology. Now that you understand what it is and how it works, this month I'd like to highlight IPSec's ability to help solve three common security problems.

Using IPsec to stop worms
It might sound condescending, but the best way to stop worms is not to get them in the first place! Alas, because not all people understand or even care about the threats and risks associated with electronic mail and Web surfing, worms and other kind of malicious code are simply a fact of life right now. Given that, how can we reduce the damage that such code inflicts?

You can thwart malicious code in three different ways:

The most difficult way is to prevent the code from installing. Although host firewalls and virus/spyware scanning utilities can stop some malicious code, it often remains the responsibility of the user to decide whether to permit the code to install. Certain features in Microsoft Windows XP Service Pack 2 create additional barriers against malicious code but still rely on users either leaving the features enabled (which they are by default) or making correct decisions when the operating system raises prompts. But you can eliminate some of these decisions by configuring many of the features through Group Policy and by not allowing ordinary users to run as local administrators.

SRPs (software restriction policies) help prevent malicious code from executing. Using Group Policy, you can apply restrictions to a computer that will allow only authorized programs to run. Resist the urge to think in the other direction-that is, to allow everything to run except known bad stuff. How can you really know everything that's bad? If you combine an organization-wide allow-to-execute list with non-local administrator users, you have an environment in which malicious code that does manage to get on a computer will be unable to do anything dangerous-the SRP simply won't allow it to run. I'm a big fan of SRPs and encourage you to investigate using them in your organization.

In some instances, your only option might be to prevent malicious code from communicating. IPsec policies will help here both by limiting what kinds of traffic a computer will accept and what kinds of traffic a computer will generate. Rules with filter actions that specify simply to block or allow traffic-that is, create no security associations-can build effective basic packet filters on individual computers. You can use Group Policy to assign these rules to computers and reduce the amount of malicious traffic propagating throughout your network.

Your choice of IPsec policies depends on which operating system you're running. Windows XP or Windows Server 2003 operating systems include host-based firewalls that are more effective than IPsec for blocking inbound traffic, so your IPsec policies would block only outbound traffic. Windows 2000 doesn't include a host-based firewall so you should consider IPsec policies that block traffic both inbound and outbound.

Consider the "Slammer" worm. Slammer searched for computers running SQL Server or MSDE and therefore would have been listening on UDP port 1434. Patching all computers can take some time, so an excellent interim mitigation is using Group Policy to quickly assign an IPsec policy to all computers to block inbound traffic to the vulnerable port. To prevent a computer from getting infected by Slammer, you can assign a policy that blocks all inbound traffic from anywhere to the computer's own IP address with destination port 1434/UDP:

You can also script IPsec policies using command-line tools. There are three different tools that you can use depending on your operating system. For Windows 2000, the tool is ipsecpol.exe from the Resource Kit; for Windows XP, it's ipseccmd.exe from the support tools folder on the CD-ROM or through a download; for Windows Server 2003, it's netsh ipsec included with the operating system. You can apply the Slammer filter in Windows 2000 with this command:

ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Inbound UDP 1434 Rule" -f *=0:1434:UDP -n BLOCK -x 

(In Windows XP the command is ipseccmd with the same syntax.) This command creates and assigns a static policy called "Block UDP 1434 Filter" with a single rule called "Block Inbound UDP 1434 Rule" containing the same filter list as above linked to a "block" filter action. Static policies are stored in the registry and will persist between reboots. The policy won't apply until the next boot or restart of the IPsec policy agent. If you want the policy to apply immediately your script should also stop and restart the service called "policyagent."

In case a computer does get infected with Slammer, you can use a different IPsec rule to prevent the computer from infecting other computers by blocking outbound communications to destination port 1434/UDP:

Note the subtle difference here: in the first rule the filter list is from any-address:any-port to my-address:1434/udp; in the second rule the filter list is from my-address:any-port to any-address:1434/udp. The second rule blocks any outbound traffic that's destined for UDP port 1434 on any computer. Use this command to script that rule and add it to the same policy as the first:

ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Outbound UDP 1434 Rule" -f 0=*:1434:UDP -n BLOCK 

Omit the "-x" here since this command is adding another rule to the existing policy.

You can also use the command-line utilities to apply dynamic policies-these stay in effect only so long as the system is running. They're lost if the policy agent is restarted or the computer is rebooted. These two commands will create a dynamic policy that does the same thing as the static policy above:

ipsecpol -f[*=0:1434:UDP] ipsecpol -f[0=*:1434:UDP] 

The square brackets around the filter specification indicate that this is traffic the policy engine should block.

So far we've been exploring how to use IPsec to block traffic from and to known "bad" destinations. You could be more restrictive with your IPsec policies and block all traffic, and then create rules that permit certain traffic to certain locations. You will need to think very carefully about what kinds of traffic should be allowed where, plan extensively, and thoroughly test your ideas before launching into production. Expect stuff to break at first!

Using IPsec to protect servers
One very good use of a block-all-except policy is for server protection. Say you're building a Web server. Why should that server accept any inbound traffic that isn't Web traffic, at least on its Internet-facing connection (if dual-homed)? You can use an IPsec policy to build a rudimentary packet filter that discards everything except that which makes sense for the purpose of your servers-in the Web server example here, everything except traffic destined for TCP port 80 (and 443 if some pages use HTTPS).

Such policies buy you time to test and deploy patches. If someone discovers a vulnerability in the operating system but an IPsec policy isn't permitting access to the vulnerable service, you can deploy these policies to allow you additional time to test and deploy the patch according to your outage schedules.

Let's continue the Web server example. Your IPsec policy would have two rules:

Rule 1

Rule 2

To script this, use these commands:

ipsecpol -w REG -p "Allow Web Traffic" -r "Block Everything" -f *+0 -n BLOCK -x ipsecpol -w REG -p "Allow Web Traffic" -r "Permit Inbound TCP 80" -f *+0:80:TCP -f *+0:443:TCP -n PASS 

Note in these examples that a "+" replaces the "=" between the source and destination address/port/protocol specifications. This tells the policy agent to build "mirror" rules that are required for reply traffic to leave the Web server. Without the mirror, you'd need separate rules permitting outbound traffic from the server's ports 80 and 443. When you create rules in the GUI they're mirrored automatically.

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 that reflect each role. These policies can help measurably increase the security of your environment simply by implementing a method to limit the traffic that can enter a server.

Using IPsec for domain isolation
If you're using Active Directory, you know who your users are: they have to authenticate when they want to use network resources. But what about the computers? Sure, some of the computers are joined to your domain. The architecture of Windows doesn't require this, though. As long as a user possesses valid credentials, he or she can access network resources from any computer on the network. And Windows XP's credential manager makes it even easier to live with a non-domain-joined computer!

The concept of "domain isolation" is becoming increasingly popular. We first started mentioning it in late 2001; it's now running across all of Microsoft's corporate network and on the networks of many customers. If you haven't considered it yet, we encourage you to think about it now.

Domain isolation is important for many reasons. Domain-joined computers are computers that you can trust, at least somewhat, because you can take advantage of things like Group Policy, security templates, software restriction settings, IPsec policies, Microsoft Systems Management Server (SMS), and any other security-related technologies that you can centrally control and manage. Computers whose configuration you control are computers that do only what you allow them to do. These are computers that will be far less dangerous in your environment than rogue unmanaged machines of which you have no knowledge either of their existence or their configurations.

Here you're essentially saying that no user can bring up a rogue machine and access domain resources-only authorized computers can communicate with other authorized computers. It's easier than you might think to implement this across your domain. First add this IPsec policy to your default domain Group Policy:

You could use AH rather than ESP null, but then your policy wouldn't work with devices that must communicate over network address translators. You also need to create a rule that exempts your domain controllers because you need to communicate with them to authenticate and get the Kerberos ticket that's used for all other communications:

Once you test and deploy these policies, non-domain machines will be unable to communicate with any domain-joined machine. Why? Domain members will require IPsec. You can't get the policy unless you join the domain. You can't "roll your own" policy and try to remain outside the domain because the policy requires Kerberos, which works only if you're in the domain. All domain members will receive the policy and will therefore be able to communicate with all other domain members. Remember that if you allow users to add and remove their own machines from your domain, you won't be able to control who does and who doesn't receive the policy. Note that this isn't necessarily a problem so long as joining the domain applies other security controls like SMS, anti-virus, anti-spyware, a firewall, and so on.