| Downloads |
|---|
| 41571.zip |
IP Security (IPSec) is a set of protocols that the Internet Engineering Task Force (IETF) developed to secure the exchange of network packets. Because IPSec works at the network layer, it's well suited to applications such as VPNs, and it also works well for general encryption of network application protocols. IPSec on Windows provides authentication and encryption of network traffic but also lets you restrict traffic based on source or destination IP address and port. Because of these capabilities, many administrators use IPSec as a simple packet filter for Windows-based servers.
IPSec has always been a cheap and simple packet filter for protecting standalone servers such as those running Microsoft IIS. (For information about setting up IPSec packet filtering to protect a Web server, see "IPSec Packet Filtering," September 2002, http://www.winnetmag.com, InstantDoc ID 25935.) However, the Windows 2000 IPSec implementation has limitations. For example, IPSec in Win2K doesn't filter all network traffic by default, and its rules lack flexibility. Microsoft introduced many security improvements in Windows Server 2003, including important new features in the OS's IPSec implementation. New management and monitoring tools improve, simplify, and speed up the deployment of packet- filtering capabilities through IPSec. These improvements make IPSec on Windows 2003 more adept than IPSec on Win2K at securing standalone servers. Although IPSec is far from a full-featured firewall, it has come a long way and is now an excellent firewall solution for standalone IIS servers.
What's New in IPSec?
With the new IPSec features in Windows 2003, you can easily script a reasonably secure IPSec packet-filtering configuration. IPSec's new features are as follows:
- Improved packet filtering permits IP addresses, DNS names, and server types (i.e., WINS, DNS, DHCP, and gateway) in source or destination fields. You also get new flexibility for specifying network masks.
- Network Address Translation (NAT)traversal support permits IPSec through a firewall or router.
- Netsh command-line scripting support improves flexibility.
- By not using default filtering exemptions for broadcast, multicast, Kerberos, and Resource Reservation Protocol (RSVP) traffic, IPSec eliminates security holes.
- Persistent IPSec policies permit protection during system startup.
- Strong 2048-bit Diffie-Hellman encryption keys improve security.
- Resultant Set of Policies (RSoP) support helps resolve conflicting Group Policy settings.
- A new Microsoft Management Console (MMC) IP Security Monitor snap-in displays detailed information about IPSec traffic.
IPSec and ICF
Why use IPSec when Windows 2003 has a built-in Internet Connection Firewall (ICF)? Actually, the best idea is to use both IPSec and ICF on your servers. Both IPSec and ICF have unique limitations but are extremely secure when you use them together. Having said that, however, IPSec does have more flexible rules than ICF for controlling both incoming and outgoing traffic.
ICF is a stateful firewall that blocks unsolicited incoming connections. ICF can permit incoming connections to various services but doesn't let you limit access to specific IP addresses. ICF is aware of incoming traffic that's in response to outgoing requests, such as Web page requests, but has no way of blocking outgoing traffic—a capability that can be useful for limiting damage from Trojan horses or worms.
IPSec, which isn't stateful, doesn't know which incoming traffic is in response to which outgoing traffic but rather permits or blocks traffic based on the port and source and destination IP addresses. IPSec, therefore, gives you specific control over which IP addresses have access to which ports, and you can use it to control outgoing traffic.
You might find that only a third-party firewall will meet your needs. For example, more advanced firewalls let you specify ranges of ports in a filter and let you filter on specific TCP flags. Advanced firewalls also have features such as the ability to create address groups and filter by time of day. If you don't need such features, though, IPSec and ICF are both free and effective at port filtering.
Plan for and Deploy IPSec
Many security experts recommend isolating IIS servers from the rest of your network rather than running them as members of your domain. One good argument for the isolation scenario is that it reduces the attack surface and greatly simplifies the server's firewall configuration. For example, suppose that your public IIS 6.0 server also uses FTP and Terminal Services, which are accessible only from your internal network. Table 1 shows your potential port-filtering strategy. The server will accept network connections from three applications: IIS Web Services, IIS FTP Services, and Terminal Services. The Web service will accept connections on TCP ports 80 and 443 from anyone, but FTP and Terminal Services will permit connections to their respective ports only from the internal network. For outgoing connections, the server will permit outgoing HTTP connections and DNS lookups, as Table 2 shows. You can browse the Web from your server to download product updates and patches. Table 2 shows that the server will permit DNS requests only to authorized DNS servers but will permit Web browsing to any IP address, although for increased security you can further limit privileges to permit Web browsing only to specific sites. Following the same strategy, you can plan for other incoming or outgoing traffic on the server.
You can rapidly deploy IPSec configurations several ways: You can run a Netsh script, import an IPSec policy file in the IP Security Monitor snap-in, or apply a Group Policy. On a standalone server, the most convenient of these methods is to run a Netsh script. Netsh is a command-line tool that you use to configure various network parameters, including IPSec's. The scripts are simply batch files that call the Netsh command in the IPSec context. Netsh scripts are useful because they ensure consistent configurations across multiple servers, and you can save them with a change-control system, if you use such a system in your organization.
Scripting IPSec
The process of scripting IPSec through Netsh is straightforward. First, to ensure that all your IPSec configurations will be consistent, clear the existing configuration. You can do so by using the following Netsh command:
netsh ipsec static delete all
This command ensures that you always start with a clean slate and eliminates any rules or filters that you no longer use.
Next, you have several configuration options to set. To ensure consistency across all servers, you'll set some of these options to the default Windows 2003 settings. First, set the IPSec logging level to one of the values that Table 3 shows. For example, to log all dropped incoming and outgoing packets, as well as any packet errors, use the command
netsh ipsec dynamic set config ipsecdiagnostics 7
By default, IPSec writes log events once per hour or when it reaches a certain maximum threshold. To reduce this threshold so that IPSec logs every minute, you can use the command
netsh ipsec dynamic set config ipsecloginterval 60
Next, to set IPSec exemptions, use one of the settings that Table 4 shows. IPSec in Windows XP and Win2K has packet-filtering exemptions for some types of network traffic, potentially creating security holes. IPSec in Windows 2003 is much more secure, permitting only Internet Security Association and Key Management Protocol (ISAKMP) traffic by default. To set the IPSec exemptions, use a command such as
netsh ipsec dynamic set config ipsecexempt 3
You should use setting 0 or 1 on an Internet-facing server only when you're using another firewall for packet filtering. Kerberos exemptions let attackers use source port 88 to completely bypass all other port restrictions. Doing so isn't always easy but isn't particularly difficult either. If you need to permit Kerberos traffic, use setting 3 but create individual filters for TCP and UDP ports 88.
IPSec in Windows 2003 lets you specify the level of server protection at startup. The possible settings are Permit, which allows all inbound and outbound traffic until Windows applies the persistent IPSec policy; Block, which blocks all inbound and outbound traffic except DHCP traffic; and Stateful, which permits only inbound traffic in response to outbound connections. The Stateful setting also permits DHCP traffic and other filters set with the Bootexemptions command. For most standalone servers, the best option is to simply block all traffic at startup, as follows:
netsh ipsec dynamic set config bootmode block
Policies, Filters, Actions, and Rules
One confusing aspect of IPSec is the relationship between objects (e.g., policies, filters, actions, rules). This relationship can be described as follows: A computer can have one active policy, which contains one or more rules. A rule contains one or more sets of filter lists and filter actions. A filter list contains one or more filters; the filter actions permit traffic, block traffic, or negotiate IP security for all traffic that matches the filters in the filter lists. A filter specifies the protocol, source, and destination of the traffic. Figure 1 shows a sample computer policy with one rule for incoming Web traffic. This rule has one action that permits any traffic that matches the rule's filters. One filter list is in place for HTTP, which contains two filters: one for HTTP traffic on TCP port 80 and one for HTTP Secure (HTTPS) traffic on TCP Port 443.
In your Netsh script, first use the following command to establish a policy:
netsh ipsec static add policy name="Web Server Policy" description="Packet filtering policy for a standalone Web server"
Next, define two basic actions that you might use in your policy:
netsh ipsec static add filteraction name= Permit action=permit netsh ipsec static add filteraction name= Block action=block
To add packet filters to your policy, you need to create a filter list, add filters to the filter list, then add a rule to map the filter list and the action to the policy. The code in Web Listing 1 (http://www.winnetmag.com/windowssecurity, InstantDoc ID 41571) creates a default rule that blocks all incoming traffic. With these commands, you create a new filter list that has the name "All Network Traffic" and add a rule that defines the traffic as coming from anywhere on any port going anywhere on any port. Finally, you create a rule for "Web Server Policy" that blocks all traffic matching the "All Network Traffic" filter list.
At this point, your IPSec configuration won't permit any incoming or outgoing network traffic, so you need to add a rule for each service you want to provide on the server or to access from the server. To do so, create a rule for HTTP server traffic, as the code in Web Listing 2 shows. This rule permits any incoming traffic on TCP ports 80 (HTTP) and 443 (HTTPS). Because the mirrored parameter is set to yes, the reverse of that traffic—any response to traffic on TCP ports 80 and 443—is also permitted.
You can now repeat this process for each service (e.g., FTP, Terminal Services) running on the Web server. For an example of a complete IPSec configuration script, see http://www.xato.net/files/ipsecfilters.zip.
Because the Web server needs to connect to external servers, you must create a rule for each type of service. Web Listing 3 shows a rule to permit the Web server to perform DNS lookups. Notice that these filters use the DNS setting for the dstaddr parameter. This setting causes IPSec to permit traffic to the currently assigned DNS servers on the system and prevents you from having to change these filters should your DNS server addresses change. Other values for this parameter are WINS, DHCP, and gateway. Another important rule is to permit outgoing HTTP requests so that you can use services such as Windows Update, as Web Listing 4 shows.
Customizing the Script
After you become comfortable with the basic IPSec scripting format, you might want to add more features. For example, you might want to encrypt traffic between certain hosts or create multiple policies for different tasks, such as working on the server or running the server locked down. You might also want to add filters to permit Internet Control Message Protocol (ICMP) traffic or other types of traffic.
One problem you'll notice is that the System event log entries aren't useful unless you click each event to see the event details. You might want to export the logs to a more readable format that's more compatible with your management software. To do so, I use the Microsoft LogParser tool, which is available as part of the IIS 6.0 Resource Kit Tools (http://www.microsoft.com/downloads/details.aspx?familyid=56fc92ee-a71a-4c73-b628-ade629c89499). To extract log files from the System event log, use the command
logparser "SELECT * FROM System TO ipsec.log WHERE SourceName='IPSec'"o:W3C
This command creates a text file that contains information about each field definition, similar to an IIS log file. You could easily customize this query to a more suitable format, perhaps to mimic Microsoft Internet Security and Acceleration (ISA) Server 2000 logs.
IPSec's new features make it a valuable host-based packet filter, especially if you use it in conjunction with ICF. With its enhanced scripting features, you can easily configure and deploy an IPSec policy across all your dedicated servers.
