For many corporations, the Internet is becoming an important business tool, but with that tool comes the concern of security. To meet that concern, a networking industry sector has grown up around firewalls, proxy gateways, and related security products.
Microsoft is active in this market. In November 1996, Microsoft introduced Proxy Server 1.0 as a cost-effective Internet gateway. Proxy Server lets you control traffic between your corporate network and the Internet by acting as an intermediary between them. Through application and circuit layer gateways that are tightly integrated with ordinary Windows NT Server access control, the product lets users on a local network access Internet resources efficiently and transparently while keeping out traffic from the Internet. In addition, Proxy Server includes caching capabilities, improving performance for frequently accessed Web sites.
When Proxy Server 1.0 (then called the Internet Access Server, or Catapult) was in beta, Mark Joseph Edwards wrote a two-part overview of the product. Check out "Microsoft's Internet Access Server," September 1996, and "Configuring Microsoft's Internet Access Server," October 1996, for an excellent overview of Proxy Server 1.0.
Proxy Server 1.0 had two major shortcomings. First, although it provided application and circuit layer security, it lacked the packet filtering functions that would put it in the same class as firewall products. Second, Proxy Server 1.0 lacked the scalability to let multiple proxy servers work together to provide intelligent caching and access services to the end user.
In designing Proxy Server 2.0, Microsoft has addressed these problems and is positioning Proxy Server 2.0 as a combination firewall and cache server: one product that gives you secure and fast Internet access from your corporate network. I'll examine the new features that make Proxy Server 2.0 a more compelling product than its predecessor.
More Administration Choices
Proxy Server 2.0 gives the net manager a flexible set of administrative tools. As in the previous version, you can use the Internet Service Manager (ISM) to manage proxy services. ISM is the most complete method available; it gives you access to all administrative functions. The ISM main screen lists each of the installed Proxy services (Web Proxy, WinSock Proxy, and SOCKS Proxy) and any Internet Information Server (IIS) services you have installed.
Each proxy service has its own set of property sheets. Microsoft has reformatted the Web Proxy Service sheet, shown in Screen 1, to list functions that all three services share (with some exceptions for the SOCKS Proxy). Other property sheets are more specific to each service. New in the administrative toolbox is a command-line interface for querying and configuring Proxy Server. One great application of this tool is to use scripts to simultaneously configure multiple proxy servers. The two command-line utilities for configuring multiple servers are RemotMsp and WspProto. Table 1 lists the capabilities of each utility. The initial release doesn't support an HTML administrative tool, but Microsoft has promised that you'll be able to download the tool from the Microsoft Web site.
Configuration Backup and Restore
The new configuration backup function creates a text file (similar to an .ini file) that contains a complete list of all parameters defined for all installed proxy services. Click Server Backup on the Service property sheet of any of the proxy services, choose a directory, and away you go. This function is an easy way to get a manual dump of the configuration on the local machine, but you can't use it for remote machines. You can use the command-line utility RemotMsp for either local or remote backup.
Similarly, restoring a Proxy Server configuration is also a manual process, and just as simple. A neat feature is the ability to choose Partial Restore; you reach this option by clicking Server Restore on the Web Proxy Service Properties sheet, then choosing Restore Configuration. With Partial Restore, you can restore only noncomputer-specific parameters, such as user permissions. This capability is useful for setting up multiple proxy servers without having to code scripts. Just configure user permissions on one proxy server the way you want it, back up the configuration, and do a partial restore for each of the other servers.
Microsoft refers to Proxy Server 2.0 as a firewall primarily because of its new packet-filtering capability. This feature lets an administrator reject specific packet types at the IP level before they reach any of the higher-layer services (Web, WinSock or SOCKS). Enabling packet filtering causes Proxy Server to drop all packets sent to the external interface, except for those that match a default list of predefined packet filters. Note that you create a filter for the packet types you want the proxy server to accept. Screen 2 shows the Packet Filters tab.
By default, selecting packet filtering also enables dynamic packet filtering. This feature is an intelligent component that enables and disables filters based on the current state of a protocol sequence. For example, a Telnet client can request the proxy server to open a connection to a server on the Internet. The proxy chooses a source port, say 1500, creates a filter allowing Telnet traffic to and from port 1500, and then establishes a TCP connection to the server. When the Telnet session is complete, the proxy disables the filter and denies further access to port 1500 from the external interface.
You can disable dynamic filtering and rely on your ability to define the correct static filters for your needs. However, static filters can be difficult to code correctly. Thinking that you have adequate protection when you really don't is not a good security practice. If you must use static filtering, make sure that you check your configuration by scanning the ports on your external interface. Use a TCP port scanning tool (e.g., AGNet Tools from the AG Group) to check that only the ports you intended to expose are visible.
When you enable packet filtering, you also select IP fragment filtering, which you can use to prevent a FRAG denial-of-service attack. Fragmentation is a function of the IP protocol that routers perform to accommodate networks of varying maximum frame sizes. For instance, a router fragments a 1400 byte datagram received from an Ethernet segment if it is bound for an X.25 network, which has a maximum frame size of 576 bytes. Receiving hosts must reassemble these fragments. Sending multiple bogus fragments to a host will keep it busy tracking lots of fragments that never get reassembled back into a datagram, eventually causing a severe depletion of resources.
Intruders can exploit this aspect of the protocol to get through a packet filter. Because only the first fragment contains the port information (in the TCP header), the proxy server has no information to base a filtering decision on for subsequent fragments. The Enable filtering of IP fragments checkbox in Screen 2 lets Proxy Server filter out all fragmented IP datagrams. This action also filters out normal fragmented traffic. Leave this box checked for better security protection, but if you have problems communicating with a specific host or server through the Proxy Server, keep in mind that this filtering is occurring.
Microsoft has defined a set of default packet filters (shown in Screen 2), which at first glance look as though they are letting Internet Control Message Protocol (ICMP) and Domain Name System (DNS) traffic onto the internal network. However, proper operation of the proxy services requires these filters. Normal ICMP traffic between a host (in this case, the proxy service) and other hosts or routers includes protocol exchanges necessary for proper TCP/IP operation. Microsoft chose to open static holes in the wall to accommodate this traffic. Proxy Server doesn't send these packets to the internal network unless you explicitly configure the proxy service to let them pass. For example, the ping program uses ICMP packets. If I want to ping an external host from the internal network, I have to configure a WinSock Proxy service protocol definition for outbound echo and inbound echo reply in addition to the default ICMP packet filter. Similarly, Microsoft intends the DNS filter definition to let the proxy services talk to an external DNS.
Packet Alerts and Logging
In addition to filtering packets, Proxy Server 2.0 lets you keep a log of packet-level events. You can log to a text file or to an Open Database Connectivity (ODBC)-compliant database. By default, Proxy Server initiates logging only for packets that are dropped.
Useful packet-layer information kept in the logs in regular logging mode includes source and destination address, source and destination port, the protocol, and a time stamp. You can turn on verbose logging, which increases the size of the logged event to include the IP header and a portion of the data field from the packet, saved in hex notation. In the Registry, you can adjust the size of the captured data field. I don't know about you, but I get a headache from looking at hex packet dumps. I wish you could convert the hex dump portion of these logs to a Network Monitor format for easy decoding and viewing.
Logging is great for analysis, but what about situations that require your immediate attention? In conjunction with the logging function, Proxy Server 2.0 can alert you to suspicious activity at the packet level. If packet-logging is enabled, you can choose for Proxy Server to alert you via email or the NT Event Log if the event frequency exceeds a threshold that you set. For instance, if the proxy server rejects more than 20 packets in 1 second (the default), your network might be under attack. An example is someone attempting a denial-of-service attack via SYN flooding. This feature helps an administrator head off security threats.
The Web Proxy Service lets you cache objects retrieved via FTP. Note that Proxy Server doesn't cache all FTP traffic, only objects retrieved via FTP that your browser can display. For example, Proxy Server won't cache a downloaded executable or other file that your browser won't display, or files you download with a Winsock program for FTP (either the command-line FTP or a third-party GUI version).
Reverse Proxy and Reverse Hosting
If you want to share information on your local Web servers with Internet users, you'll be interested in reverse proxy and reverse hosting. Proxy Server 1.0 lets you publish to the Internet, but only if the Web server resides on the same machine as the Proxy Server. With reverse proxy, you can configure the Proxy Server 2.0 machine to listen for URL requests and forward them to a Web server on your local network, in effect impersonating the local Web server. An external client uses the URL of the external interface of the proxy server, but a different Web server on the local network returns the pages to the client. You can represent only one local server in this manner.
Reverse hosting (also called virtual hosting) offers a slightly different twist on this concept. With reverse hosting, you can specify multiple virtual paths from the main proxy server URL, much as you would for virtual servers on IIS. Then, you set up mapping between the virtual paths and actual URLs on the local network. When an external client tries to hit the virtual path, the proxy server forwards the pages from the real local URL.
Both these services take advantage of caching, which can deflect some external traffic from reaching your local network. If the proxy server has the requested URL in its cache, it won't request the URL from the local Web server. Of course, you have to make a good estimate of the expected traffic at your site to provide enough cache space. You also have to make sure that the proxy server hardware you're using can handle requests for multiple Web servers.
SOCKS 4.0 Support
As Microsoft gets deeper into the role of providing enterprisewide solutions, it is learning to deal with client platforms that don't come from Redmond. SOCKS is a proxy gateway with strong roots in the UNIX community. The SOCKS proxy service can provide access to a "socksified" client, whose TCP/IP stack can attach to a SOCKS server. Most UNIX platforms and Macintosh and Windows offer client support for SOCKS.
Microsoft describes the SOCKS Proxy Service as a cross-platform version of the WinSock proxy service. But it's closer to a plain vanilla proxy that supports only TCP (not User Datagram Protocol--UDP) and requires you to manually add permissions (by default, the SOCKS proxy denies all access). The SOCKS Proxy bases permissions on source address (individual IP address or Internet domain). Because the intended platforms are non-Windows, the SOCKS proxy performs no NT user authentication.
Incidentally, the Internet Engineering Task Force (IETF) has adopted as an Internet standard a later version of SOCKS (SOCKS 5) that adds several features, including authentication. If you plan to use the SOCKS proxy, make sure that the clients you are using are compatible with SOCKS 4.0, the version that Microsoft supports.
HTTP 1.1 Support
The most recent version of HTTP improves performance significantly over previous versions by supporting persistent connections. In the widely implemented HTTP 1.0, retrieving multiple objects on a Web page (e.g., text, graphics, audio clips) requires a separate TCP connection for each object. HTTP 1.1 improves on this activity through the use of persistent connections, in which you can retrieve multiple objects with one TCP connection. This reduced overhead can improve end-to-end performance dramatically (assuming that HTTP was a bottleneck). A proxy has two connections, one from the Web client to the proxy and another from the proxy to the Web server. Because the proxy is an active participant in mapping between the two connections, Proxy Server must support the new version of the protocol to reap the benefits.
Caching improves the performance the client sees, primarily by cutting down on the number of requests the client needs to generate to servers on the external network. Proxy Server 1.0 lets you run multiple proxies in an enterprise, but it has no mechanism for coordinating the caching between them. With multiple proxies, you often end up, over time, with multiple versions of the same cached objects on different proxies. Also, Proxy Server offers no way to intelligently share loading between the proxies. One proxy can be scrambling to keep up with client requests while others stand idle.
Microsoft has responded to these problems with the Cache Array Routing Protocol. CARP uses two types of intelligent routing--distributed and hierarchical--between proxy servers. Distributed routing occurs between members of a proxy server array; hierarchical routing occurs between proxy servers configured in a chain.
An array is a group of proxy servers that you administer as one logical entity. All members of the array keep an array membership list. Each proxy server updates the list regularly to account for proxies coming online or going down. Array members are peers and communicate with one another to cooperatively service requests from clients. Proxy Server uses a hash, a common algorithm in searching and sorting, to determine which member of the array services the request. (For a discussion of hash functions, see Mark Minasi, "Windows NT Logons," June 1997.)
Array members feed each combination of proxy server name and URL name into the hash algorithm to generate a score. The highest score determines which proxy server will service requests for that specific URL. Each proxy server runs the algorithm and keeps scores in a hash table. The algorithm is deterministic--the hash table entries are the same in all proxy servers, without their communicating with one another. This scheme addresses a drawback of an earlier cache routing scheme called the Internet Cache Protocol (ICP), which used a query protocol between proxies to find a specific URL. Besides minimizing protocol chatter between proxies, the hash scheme is good for load-balancing because it has positive scalability. The more members in the array list, the more evenly distributed the load.
A chain is a hierarchical grouping of proxies. A proxy server that is a member of a chain forwards client requests that it can't service to the next higher-level proxy in the chain. The downstream proxy in the chain is closest to the client; the furthest upstream proxy is closest to the Internet. Requests flow only upstream or among members of an array.
You can combine chains and arrays. In a chain, the upstream entity can be one proxy server or an array. Downstream proxies can obtain a copy of the upstream array list by polling. With the array list, downstream proxies can create a hash table for an array to determine which member of the array needs to respond to a request for a URL.
Figure 1 shows an example of proxies distributed between a branch office and a corporate site. Clients in the branch access the Internet through Proxy Server Z, over a leased line to the corporate net, then through the Proxy Array, following these steps:
- The client requests a URL from Proxy Z.
- Proxy Z does not find the URL in its cache so it uses the hash function to forward the request to Proxy A in the array CORP.
- Proxy A receives the URL request from Proxy Z. Proxy A checks its cache and does not find the URL.
- Proxy A runs the hash function and determines that Proxy C is the proper location for the URL. Proxy A then forwards the request to Proxy C.
- Proxy C finds the URL cached and returns a response to Proxy Z.
- Proxy Z returns the response to the client and caches the URL locally for future use.
I have two observations about this example. In step 4, if Proxy C does not have the URL cached, Proxy C looks for the URL on the Internet. Second, because Proxy Z caches the URL, two copies are cached. You gain a performance advantage because users in the branch now have a local copy cached, and they don't have to chew up any more leased-line bandwidth to retrieve it from the corporate net. If you implement chains properly, they can put the cache close to the users who need it.
You can add or remove array members via the Array property screen. Screen 3 shows two members of the CORP array, MSCPDC and WEBSTER. Although this example uses NetBIOS names, you also can use fully qualified domain names and the DNS. The system will propagate changes made here to other array members to keep them in sync.
To configure chains, use the Routing tab on the Web Proxy Service Properties screen, as shown in Screen 4. In the Upstream Routing section, the last upstream Proxy Server selects Use direct connection. Downstream proxies choose Use Web Proxy or array. Select Modify to get to Advanced routing options (shown in Screen 5), where you can add the name of the next upstream proxy. Note that an upstream proxy can be running Proxy Server 1.0 or a third-party proxy gateway, because the downstream proxy is acting as a client with respect to the upstream proxy. If the upstream proxy is an array, you can automatically poll for the array configuration. From this dialog box, you can also select proxy-to-proxy authentication for the chain; this choice requires an account with Administrator privileges on the upstream machine.
You can configure a backup route from the Enable backup route section of Screen 4. The fault-tolerance process is dynamic. The system uses the backup if the primary route is down; but the system periodically polls the primary and uses it again when it comes back up.
And That's Not All...
Proxy Server 2.0 has many improvements over the previous release. In addition to the features I've discussed, Proxy Server 2.0 includes client configuration scripts, server proxying, and domain filtering. You can also extend the product via third-party applications that use the Internet Server API (ISAPI). Some third-party enhancements already available are Trend Micro InterScan Web Protect for virus scanning, Cyber Patrol Proxy for content filtering, and Market Wave Hit List and TELEMATE.Net for reporting. Depending on your situation, Proxy Server could fulfill a significant part of your needs for secure Internet access.