Internet Security and Acceleration (ISA) Server is Microsoft’s enterprise-class firewall and proxy server. As its name implies, ISA Server is designed to make your Internet connection both more secure and more efficient. ISA can actually act as an independent firewall or a proxy server, or it can serve both functions at the same time, becoming an all-purpose border server on your network.
Content caching, also known as proxying, is designed to maximize the efficiency of your network’s Internet connection. For example, suppose that all 10,000 of your users have set Yahoo! to be their Web browser’s home page. Every time a user launches their Web browser, it heads straight for the home page, downloading both the text and the graphics over your Internet connection. Having 10,000 people download the exact same thing several times a day is very inefficient. When a proxy server is in use, users don’t access the Internet directly. Instead, they ask the proxy server to go out to the Internet and retrieve Web content. When the proxy server retrieves content, it caches, or saves, the content to its local hard disks. When another user requests the same content, the proxy server can then provide it without going over the Internet. Proxy servers include means of detecting when Internet-based content has changed, so that they know it’s time to go out and get a new copy, rather than using the cached copy.
The fact that proxy servers access the Internet on behalf of your users makes proxy servers valuable as content filters, too. Although most proxy servers—including ISA Server—don’t provide much in the way of built-in content filtering, almost all of them are extensible, enabling you to add in third-party content filters. These filters analyze users’ Web content requests before the proxy server goes out to retrieve the content. If the content is filtered—for example, if the URL of the Web site is on a list of adult Web sites—then the content filter instructs the proxy server to display a “restricted” error message page, rather than retrieving the page from the Internet. Filters can also analyze content after the proxy server retrieves it, scanning Web pages for unacceptable words or phrases. If the content doesn’t pass the filter’s settings, it can either censor the content (replacing unacceptable words with “xxx,” for example), or instruct the proxy server to disregard the page altogether and display the “restricted” error message page instead.
Note
A number of third-party companies make content filters that are compatible with ISA Server. These are usually sold on a subscription basis, which enables the manufacturer to provide constantly-updated lists of restricted Web sites in many different categories (adult, games, auction sites, and so forth).
ISA Server actually features three basic types of caching: forward caching, scheduled caching, and reverse caching. Forward caching is the regular type of caching I’ve discussed, where ISA Server retrieves content on behalf of users, and then saves the content to satisfy future requests without accessing the Internet. Scheduled caching enables ISA Server to proactively download specific content from the Internet, making that content available to users before they request it. Scheduled caching works a lot like a server-based version of the Channels feature in Internet Explorer 4.0: You configure a specific URL, and instruct ISA Server to download that URL, or to also download any pages linked from that URL. You configure a schedule, and ISA Server goes out and retrieves the specified content according to your schedule, preloading its cache. Finally, reverse caching enables ISA Server to provide outside (Internet-based) users with cached access to internal Web servers. For example, suppose that you have a Web server on your network that provides access to static product information pages. By placing that Web server behind your ISA Server, rather than directly on the Internet, you can protect it from Internet-based attackers. ISA Server’s reverse caching capability can also reduce the overhead on that server: When Internet users request a product page, ISA Server may have that page in its cache, meaning it can satisfy the request directly, rather than passing it on to the Web server. ISA Server can be used for both forward and reverse caching at the same time, as shown in Figure 12.1
ISA uses time-to-live (TTL) information to determine when content in the cache has expired and should be retrieved again. Many Web pages include TTL information encoded within them, and ISA Server always uses that encoded TTL information when it’s available. For example, a daily news Web page might include a TTL of 24 hours, ensuring that ISA Server will retrieve a fresh copy of the page at least once a day.
Note
TTL information can be expressed in relative terms, like “24 hours,” or in absolute terms, like Sunday, “April 28 2002 at 15:00 GMT.” Absolute TTLs are more accurate than relative TTLs. For example, suppose that ISA Server retrieves a daily news page for a user at 3:00 p.m. on Monday, and that the page has a 24-hour TTL. ISA Server will continue to serve other requests for the page from its cache until Tuesday at 3:00 p.m. That means ISA Server will be delivering Monday’s news until nearly the end of the day on Tuesday.
Of course, you have no control over the TTL information encoded into Web pages. You do need to be aware of how TTLs work, though, so that you can inform your users why they’re still seeing day-old content from the Internet.
You can also configure a TTL when you schedule a content download into the cache using scheduled caching, and you can manually apply a TTL to any of the content in ISA Server’s cache. In the event that an item being stored in the cache specifies multiple TTLs, ISA Server uses the TTL that expires soonest, erring on the side of caution to make sure the cache doesn’t include outdated content.
Note
ISA Server can be configured to deliver expired content if the Web server that should provide the content can’t be contacted. The theory is that expired content is better than no content at all. You can configure ISA Server’s behavior in this regard to meet your needs.
ISA Server also supports negative caching. When ISA Server tries to retrieve content from a Web server, but the server is unavailable, ISA Server will receive a “not available” response. Negative caching can save that response for a period of time, providing a quicker “not available” response for other users trying to reach the site. Negative caching can also be disabled, which will prevent ISA Server from caching that “not available” response, forcing ISA Server to try to retrieve content directly from the Web server until it can be successfully contacted.
You can configure a global caching behavior for ISA Server. For Web pages, you can instruct ISA Server to retrieve content frequently, less frequently, normally, or with a specific relative TTL. Your configuration affects ISA Server’s efficiency, as more frequent updates increase Internet connection utilization, and also affects the age of content in the cache, as less frequent updates obviously result in older content remaining in the cache longer. For FTP content, which doesn’t have the capability of including a TTL, you can either deactivate caching or specify a relative TTL (the default is one day). If specified, the FTP TTL applies to all cached FTP content.
There is some content caching that you have no control over. Web sites have the capability to send special cache-control headers along with Web pages, and ISA Server will not cache content that includes certain headers:
Cache-control: no-cache. This header indicates that the Web server does not want the content to be cached at all. Web servers often include this header for dynamically generated Web pages, such as an online shopping cart.
Cache-control: private. This header is usually included on Web pages that include private information. Caching the page would be useless, as a Web server would never return this page to anyone but the original user.
Pragma: no-cache. This header is similar in function to the “cache-control: no cache” header, although it is less-widely used on the Internet.
Www-authenticate. This header indicates that the page is an authentication page, and that caching it would be useless since it is unique to the user being authenticated.
Set-cookie. This header is included with any Web page that sets a cookie. Since cookies almost always contain user-specific information, there is no reason to cache the page, since it would be useless to other users.
In addition, ISA Server will not cache the responses to outgoing requests if the outgoing requests contains an “authorization” or “cache-control: no-store” header. Responses to these requests are generally private, and give the user’s Web browser control over whether or not ISA Server will cache the response to the request.
ISA Server’s caching capability is provided by its built-in Web Proxy service. This service has three primary design considerations: The server’s disk storage subsystem, performance, and cache configuration.
The disk subsystem is perhaps the most important component of an ISA Server that is acting as a proxy server. While ISA Server attempts to fulfill cache requests from the server’s RAM, the sheer amount of content cached by most ISA Server computers means that the majority of cache requests will be filled from disk. There are a number of requirements and design tips for designing a disk subsystem to support caching:
Try to use a single logical drive letter for the cache. While ISA Server itself doesn’t care, and enables you to spread the cache across multiple drives, I find that a single drive letter simplifies management. Keep in mind that each drive used in the cache must be formatted with the NTFS file system.
You should allocate at least 100MB of drive space to the cache, plus an additional .5MB for each client on your network. On large networks, you’ll quickly exceed the capacity of a single server, which means you may need to use a cache array. I’ll discuss those under “Enterprise Architecture,” later in this chapter.
Get as many physical disks involved in the cache as possible. Generally, that means using a RAID array of some kind, where several physical disks are configured to act as one giant logical disk. If a RAID array isn’t an option, spread the cache across multiple logical drives. Involving more physical disks will improve overall cache performance.
Many administrators are hesitant to allocate huge amounts of disk space, because disk space usually has to be backed up, and usually becomes a disaster recovery problem. With ISA Server’s cache, of course, disaster recovery is no problem. Simply don’t bother backing up the cache. If the cache fails completely, you can simply allow ISA Server to repopulate it as users make requests.
Tip
If you configure the cache on different disks than ISA Server and the operating system, you can just back up the disks containing Windows and ISA Server, and ignore the disks containing the cache. This technique makes disaster recovery a bit easier to manage.
If you are going to use a RAID array, consider using a RAID 4 array—disk striping—instead of the typical RAID 5 array—disk striping with parity. The difference is that a RAID 5 array can survive the failure of a single disk in the array, due to the parity information. RAID 5 arrays offer fast read performance, but somewhat slower writer performance than a RAID 4 array, due to the requirement of writing parity information in addition to regular data. RAID 4 arrays can’t survive a drive failure: If one disk fails, the whole array is useless, and must be reformatted. If you only have one ISA Server on your network, RAID 4 might not be a good idea, since one disk failure can take the whole server down. If you’re using cache arrays (which I’ll discuss under “Enterprise Architecture,” later in this chapter), losing one array member isn’t catastrophic, and RAID 4 offers somewhat faster performance. You should weigh the potential benefits and risks and decide which type of array works best for you.
Performance is an important consideration in any ISA Server design. At the hardware level, the server must simply have as much RAM and the fastest disk subsystem you can get, in order to achieve maximum ISA Server performance. From a workload level, be very careful when using ISA Server to perform reverse caching on a busy network. As shown in Figure 12.1, ISA Server can perform both forward and reverse caching at the same time. If you’ll be taking a lot of hits to your internal Web server, and if it delivers mostly static pages, then the Web server itself might not be all that busy. Instead, ISA Server will bear the brunt of the work, delivering content from its cache. That makes ISA Server less available for internal clients (or vice versa, if your internal clients are responsible for the bulk of ISA Server’s workload). If you need ISA Server to perform all of these functions, and a single server isn’t up to the task, consider using a cache array, which is essentially an ISA Server cluster. I’ll discuss cache arrays under “Enterprise Architecture,” later in this chapter.
Your final concern—one related to performance—is cache configuration. Ideally, your users would be happy with outdated content, enabling you to set really aggressive cache levels and minimizing your Internet bandwidth utilization. Unfortunately, users often need their content to be fairly fresh, so you’ll need to find an appropriate middle ground. Depending on your corporate culture, you can either start out with really aggressive cache settings, and then back off as necessary until your users stop complaining, or you can start with a looser cache, and then decrease cache update frequency until users start to complain, and then back off a notch.
ISA Server is a fully featured firewall that integrates well with a Windows-based network. ISA Server enables you to determine who can access your network from the Internet, as well as what types of traffic are allowed to pass from your network out to the Internet. ISA Server also provides intrusion detection capabilities, which help you identify attacks on your ISA Server computers. ISA Server provides more granular access functionality than less well-integrated firewalls, enabling you to create traffic rules not only based on types of traffic, but also based on individual user and group needs.
Before you can understand how ISA Server works as a firewall, you need to understand a little bit about how TCP/IP communications work. The data sent between computers using TCP/IP is organized into packets, which are simply small segments of data suitable for transmission over a network. A single Web page, for example, might be comprised of hundreds of packets, which are reassembled by the receiving computer into a single stream of incoming data. Each packet is marked with the sender’s IP address, known as the source address, and the recipient’s IP address, known as the destination address. These addresses are used by routers in between the sender and recipient to route the packets to the correct destination. Packets are also marked with source and destination port numbers, or ports. When the packet finally arrives at its destination, the recipient uses the destination port to determine which service—such as a Web server or an FTP server—will handle the packet. Replies are always directed back to the source port, which enables the original sender to associate the replies with the original request. Figure 12.2 illustrates this association of IP addresses and port numbers.
Note
Destination port numbers are usually taken from a list of well-known port numbers published by the Internet Assigned Numbers Authority (IANA). For example, Web servers usually listen to port 80 for incoming requests. Source port numbers are usually chosen at random by the sending computer, and are usually greater than 1024 (which is the upper end of IANA’s well-known port number list). Source port numbers are chosen based on nothing more than their uniqueness and availability at the time.
Each TCP/IP packet contains a payload, which is simply the contents of the packet. Payloads consist of data that’s formatted according to an application-level protocol, such as HTTP, FTP, SMTP, and so forth. Once a packet arrives at the destination IP address and port number, the receiving computer handled the payload appropriately. For example, packets directed to port 80 of a Web server should contain an HTTP payload, because the Web server wouldn’t know how to handle other payloads.
Firewalls such as ISA Server are capable of restricting traffic based on the information included in the TCP/IP packet or its type of payload. ISA Server, with its tight integration to the Windows operating system, is also capable of restricting traffic based on user or group permissions that you configure. When ISA Server receives traffic, it passes it through a series of filters to determine whether or not the traffic is allowed to go through the server:
The packet filter examines the IP addresses and port numbers of the packet, to determine whether the packet is permitted. The packet filter uses static rules, and attempts to match the packet to a rule that permits traffic (all traffic is denied unless a rule specifies otherwise). For example, you might configure a rule that allows all internal IP addresses on any source port to go through ISA Server to any Internet IP address on a destination port of 80. This rule would have the effect of allowing outbound Web traffic.
ISA Server also uses stateful inspection in its packet filter. If you did configure the previous rule to allow outbound Web traffic, the responses to the outbound requests wouldn’t be allowed unless you configured static rules to allow it. If you did configure static rules, though, you’d be opening up your network to inbound Web traffic, which might not be desirable. Stateful inspection solves the problem by automatically allowing replies to come in through ISA Server, provided the replies match up with a request that was sent out.
The protocol filter analyzes the payload of packets to determine whether or not they’re permitted. Protocol filters make it easier to configure common Internet protocols without knowing their port numbers, or allowing specific types of traffic—such as FTP—that are sent to nonstandard port numbers (such as to a custom-configured FTP server that uses a nonstandard port).
ISA Server also enables you to reverse-publish resources from your internal network. Reverse publishing causes ISA Server to accept incoming Internet traffic directed at specific IP addresses and ports. ISA Server then forwards that traffic to a designated internal server for handling. For example, you might configure ISA Server to accept incoming SMTP traffic and forward it to your email server. To the Internet, ISA Server would appear to be acting as an email server. In reality, though, ISA Server is simply forwarding traffic to your internal email server, thereby protecting it from attacks.
Note
ISA Server enables you to create some really complex, useful rules to determine what traffic can pass through the firewall. In addition to basic filtering for IP address and port number, ISA Server can, for example, limit the use of certain superfluous protocols when network utilization is already high. This feature integrates with Windows 2000’s network Quality of Service (QoS) rules, and enables ISA Server to determine which traffic is important in a pinch.
ISA Server also monitors all incoming traffic from the Internet to determine whether the traffic represents an attack on the ISA Server computer. ISA Server can detect the following types of attacks:
Port scanning, which is used by attackers to determine what ports a server is responsive to. Once a list of responsive ports is available, attackers can focus further attacks on those ports.
IP half scan, which means ISA Server attempted to connect to a destination computer, but that computer did not respond. This is usually the result of an attacker sending a request to the server, and then ignoring the response. This results in an open connection on the server, which can be exploited in future attacks.
Ping of death attack, which is where an attacker sends especially large Internet Control Message Protocol (ICMP) packets in an attempt to overwhelm the target’s TCP/IP handler.
UDP bomb attack, which is a User Datagram Protocol packet containing illegal values. Older TCP/IP implementations would crash when attempting to process the packet.
Windows out-of-band attack, which is where an attacker attempts to overwhelm a server by sending a huge number of packets to specific ports.
ISA Server includes other intrusion detection filters, which are described in the product’s documentation and can protect DNS, POP3, and other protocols, as well as protect against other common types of attacks.
ISA Server can be configured to alert an administrator if any of these events occurs. ISA Server can also be configured to alert an administrator for other types of events that you define.
In order for a firewall to be effective, it has to be hardened and exclusive. Hardening a server means removing all nonessential services, thereby limiting potential attack targets. ISA Server computers used as a firewall should never run other applications, such as a Web server, email server, and so forth. Firewalls should also be exclusive, meaning they represent the only way in or out of your network. If your firewall represents one of many ways that traffic can enter your network, then it’s not an effective barrier to attackers. If you have servers that need to be accessible to the general public, you can use ISA Server’s reverse-publishing feature to make those servers seem as if they are present on the Internet. Figure 12.3 shows an example of this configuration.
Note
Reverse-publishing is similar to reverse-caching, which I’ve already discussed. However, reverse-caching is only available for the content ISA Server can cache: Web and FTP. Reverse-publishing is appropriate for other resources, such as email servers.
You can also use multiple ISA Server computers to create a demilitarized zone, or DMZ, which contains and protects your publicly accessible servers. Figure 12.4 shows an example of a DMZ configuration. The idea with the DMZ is for the outermost firewall to allow traffic in from the Internet to reach the public servers, while the innermost firewall keeps that same traffic out of the more protected internal network. The outermost firewall only allows specific traffic—such as Web or FTP—to reach the DMZ, thereby helping to protect the DMZ servers from attacks on other ports.
ISA Server computers acting only as a firewall don’t need much disk space. What they do need is lots and lots of memory, and as much network throughput as you can give them. Keep in mind that ISA Server must inspect every incoming and outgoing packet, which requires fast processors and fast network adapters. ISA Server is, of course, limited in the amount of data it can send and receive on the Internet, since companies’ Internet connections are often a hundredth the speed of their internal networks.
ISA Server supports three types of clients, and provides different functionality for each. In today’s heterogeneous computing environments, understanding how ISA Server supports various types of clients will help you make better ISA Server design decisions.
Keep in mind that ISA Server really operates in two modes: proxy server and firewall (which can be combined, allowing a single server to provide the functionality of both modes). Each mode supports different client types. In proxy server mode, ISA Server supports any CERN-compliant Web browser, which is pretty much any Web browser you’ll find these days, from Netscape Navigator 4.x and higher to Internet Explorer 4.x and higher. So, unless you’re running some truly antiquated Web browsers, all of your users will be able to take advantage of ISA Server’s proxy server capabilities.
When acting as a firewall, ISA Server recognizes two types of clients: 32-bit Windows and everything else. ISA Server requires you to install special client software on 32-bit Windows operating systems. This client software intercepts the computers’ usual method of handling TCP/IP traffic: For all traffic sent to a local, internal address, the computer handles the traffic normally. For all outbound traffic, the ISA Server firewall client steps in, and sends the traffic directly to ISA Server along with authentication information. This client enables ISA Server to include user and group membership information in the firewall’s rules, allowing certain types of traffic only for certain users, for example.
Any client computer that isn’t running the ISA Server client software is considered a “SecureNAT” client. ISA Server still provides protected Internet access to these clients, but does not receive authentication information from them. That means they’ll be unable to access the Internet if the only way to do so is to provide user credentials. If you have clients running operating systems other than 32-bit Windows, or don’t want to deploy the Firewall Client, then you’ll need to configure your firewall rules to allow them to access the Internet without basing the rules on a user account or group membership.
From a design standpoint, working with 32-bit Windows clients is the easiest. You can easily deploy the ISA Server client software to these computers through a variety of methods, including logon scripts and Windows 2000 Group Policy objects. It’s very important that you configure ISA Server with the correct Local Address Table, or LAT, and that the LAT make its way to your firewall clients. The LAT tells the clients which addresses are local and which are external, and therefore must be handled by the firewall. If you have non-Windows firewall clients then you’ll need to plan your firewall rules to allow these clients to function properly. This simply means that your rules are limited to IP address and port filters, rather than filtering traffic by user or group.
You will need to perform some configuration on your users’ Web browsers so that they use your ISA Server proxy servers. While you can manually configure the proxy settings on each client computer, that’s time-consuming. ISA Server offers two more automated choices: a routing script and automatic discovery. Automatic discovery is by far the easiest method, since most Web browsers are configured to automatically detect proxy settings by default (if they’re not, you’ll have to at least configure them to do so; you may be able to use Group Policy or some other centralized means of configuring all of your browsers at once). Automatic discovery is actually implemented through DNS and DHCP. In your DNS server, create a new Alias (CNAME) record named WPAD with the fully qualified name of your ISA Server. In DHCP, configure a global or scope option named WPAD with a code of 252. The value of the option should be the full URL of the DNS CNAME record: http://wpad/wpad.dat. Once you complete those configuration steps, all Web browsers capable of automatic proxy discovery will be able to find your ISA Server correctly.
The sheer volume of Internet traffic created by large companies makes it impossible for one ISA Server to do the job. For that reason, ISA Server supports a number of enterprise-class architectural features that you can incorporate into your design. These features enable you to make ISA Server designs faster and more efficient, and able to handle much larger user populations than a single server could possible hope to do.
ISA Server offers three enterprise architecture features:
Cache arrays, which enable several ISA Server computers to work in a cluster, acting as a single gigantic proxy server.
Cache chains, which enable ISA Servers to send requests to other ISA Servers, creating a cache hierarchy.
Three server modes, which enable an ISA Server computer to be a proxy server, a firewall, or both. These modes enable you to dedicate ISA Server to a particular task, improving the server’s ability to keep up with demand.
Cache arrays are useful in any large organization where the volume of Web and FTP requests exceeds a single server’s capacity. A cache array is basically a group, or cluster, of ISA Server computers that distribute the overall caching load between them. The servers communicate using CARP, the Cache Array Routing Protocol, to determine which server will cache which URLs. When clients connect to the cache array, the appropriate ISA Server computer handles the request, based on the URL in the request. Cache arrays are only possible when ISA Server is installed on the members of an Active Directory domain, and when the domain has been pre-initialized with ISA Server’s Enterprise Initialization utility. Cache arrays are not available with the Standard Edition of ISA Server. Array configuration and policies are stored in Active Directory, enabling you to centrally manage all of your arrays in one place.
Cache chains are useful in large, distributed environments. Essentially, a cache chain creates a hierarchy of ISA Server computers or arrays. For example, suppose you have 10 branch offices which are connected directly to your main office by T1 lines. Your main office, in turn, is connected to the Internet by a T1 line. You can install an ISA Server array in each branch office, and chain them to an array in the main office. Users at the branch offices will contact their local array for Web content first; if the array doesn’t have the content in its cache, it will contact the main office array. The main office array can fulfill the request from its cache, or go to the Internet for the content. The result is less utilization of your interoffice and Internet connections for Web and FTP content.
Carefully selecting the correct mode for your ISA Server computers enables them to dedicate themselves to a task. For example, you might install three computers in an ISA Server cache array, and a fourth as a standalone firewall. This configuration helps each computer focus on a specific segment of your overall Internet access needs, making each computer individually more efficient.
The biggest downside to cache arrays, of course, is their utter reliance on Active Directory to store their configuration information. Of course, Active Directory does give you additional features, such as the ability to centrally configure Internet access policies, which are then applied to all ISA Server computers that are members of the domain.
| If you want to create a new array or add a new server to an existing array, you have to install ISA Server in what I call “Enterprise mode.” If ISA Server Setup won’t let you select this mode, see “Can’t Install ISA Server in Enterprise Mode” in the “Troubleshooting” section at the end of this chapter. |
You don’t have to have a production Active Directory domain in order to host ISA Server cache arrays. You can, for example, create a new domain for the express purpose of supporting ISA Server. That domain might then become the target for a future migration from an existing Windows NT domain, later on down the line. And you can use ISA Server in standalone mode—which means no arrays—without Active Directory in place. Standalone mode, however, reduces the scalability of ISA Server, because you’ll be limited to the amount of traffic that a single server can process.
One way to sort of cheat the system and create a more scalable ISA Server environment without Active Directory is to use cache chains. You might, for example, use a standalone ISA Server for each of your company’s departments, as well as for each branch office. This design will help distribute the content-caching load, although not as efficiently as a cache array would distribute the same load.
ISA Server’s only main supporting technology is Active Directory, and that is only required if you want to use centralized configuration and cache arrays. Prior versions of ISA Server (called Proxy Server) relied on IIS, as they were implemented as an IIS ISAPI filter. ISA Server, however, not only does not require IIS, but can actually conflict with IIS if it’s installed on the same computer.
| For more information on prior versions of ISA Server and the differences in the new version, see “Internet Security and Acceleration Server,” p. 708 |
ISA Server does, of course, rely completely on the TCP/IP protocol suite, but so do most of the other .NET Enterprise Servers. ISA Server simply utilizes TCP/IP at a very detailed level as part of its packet and protocol analysis and IP-based firewall rules.
ISA Server doesn’t exactly integrate with any of the other .NET Enterprise Servers. However, it does provide valuable services that enable some of the other .NET Enterprise Servers to operate more safely and efficiently. Any Web server, for example, can be protected from attack by using ISA Server’s reverse-publishing and reverse-caching features. Any of the .NET Enterprise Servers that utilize the Internet for communications—Exchange Server, BizTalk Server, Commerce Server, and so forth—can be protected from attack through ISA Server reverse publishing. ISA Server can provide the same protection for non-Microsoft server applications, too. Reverse-publishing is completely vendor-independent, as it relies only on IP address and port mapping information, and not on any particular application protocols.
You have a lot of options when incorporating ISA Server into your environment. Whether you choose to use the product as a firewall, proxy server, or both, and whether or not you choose to take advantage of ISA Server’s enterprise architecture features, ISA Server can be made to fit into just about any environment.
You can utilize ISA Server as a standalone firewall in a number of ways. Figure 12.5 shows a basic corporate configuration, with ISA Server acting only as a firewall, protecting the private network from attack and intrusion.
For corporations with branch offices, ISA Server’s VPN support enables it to act both as a firewall and as the endpoint for a VPN connecting branch offices to the main office. As shown in Figure 12.6, the central office might have one ISA Server dedicated to handling VPN connections, and another for Internet access. Each branch office might utilize a single ISA Server computer for both the VPN to the main office, as well as for Internet access.
Cache designs can be a lot of fun to put together. Figure 12.7, for example, shows a basic network using three ISA Servers in a cache array. This design improves caching performance by enabling each server to focus on a specific subset of the URLs that users access. The array also provides fault tolerance, since CARP automatically accommodates servers that fail or are taken out of service, rebalancing the cache workload across the remaining members of the array.
In larger environments, chaining ISA Server computers and arrays can reduce interoffice connections’ utilization and provide faster service to branch offices that rely on a main office’s Internet connection. Figure 12.8 shows an example, where the main office array is chained to branch offices. Larger branch offices use a cache array, while smaller offices with fewer users rely on a single ISA Server computer.
Using ISA Server as both a firewall and as a proxy server enables you to create the most efficient designs for your organization. In a very small office, for example, you might just use a single server as both a firewall and a proxy server. In larger environments, you might use ISA Server as a firewall to connect branch offices via VPN, and use ISA Server cache arrays to handle content caching. Using cache chains for directly connected offices, as shown in Figure 12.9, enables you to make the most efficient use of your network bandwidth.
Microsoft is a bit of a latecomer to the proxy server and firewall product markets. Although ISA Server’s predecessor, Proxy Server 2.0, was available more than five years ago, it didn’t provide the robust firewall features that ISA Server does today, and which many companies demand.
A number of companies produce firewall products that run on the Windows operating system, including Checkpoint’s Firewall-1, which is one of the most popular Windows-based software firewalls. Other firewall products, such as Cisco’s Pix firewall, are “black boxes” with their own internal operating systems. These boxes simply plug into your network and start working, enabling you to configure them from a Telnet session or a Web interface.
ISA Server’s biggest advantage over these firewall products is its integration with Active Directory for centralized management, built-in proxy server capabilities (making it more of an all-in-one solution), and its integration with the Windows operating system, enabling access rules based on user accounts and group memberships. ISA Server is also relatively easy to configure, in contrast with products such as the Pix firewall, which are much more complex and require a more intimate understanding of TCP/IP protocols.
Cache and proxy servers have become almost a commodity, and are available from a number of manufacturers in the form of plug-in “black boxes” that require little or no configuration. ISA Server operates in an enterprise class with its cache chaining and cache array capabilities, but these capabilities are by no means unique to ISA Server. What ISA Server has going for it is integrated firewall functionality, and a good selection of best-of-breed features. ISA Server is one of the few products that offers extensibility for third-party content filters, cache arrays, cache chains, centralized management, and more, all in one package.
I’ve been using Pete’s Big Beverages (PBB) as an example of how the various .NET Enterprise Servers can be implemented, and it’s a good case study for ISA Server, as well. PBB has a main office in Denver, with a number of regional offices throughout the world. Some of these regional offices have their own Internet connections, although they all rely on IT management from the Denver office for things such as network configuration. Offices in the continental U.S. have private connections to the Denver office, and utilize its Internet connection for Web access. Figure 12.10 shows how PBB might use ISA Server. This design includes a cache array at each regional office, all centrally stored in the company’s top-level Active Directory domain. The offices with their own Internet connections use ISA Server as both a firewall and a proxy server, and use ISA Server’s VPN support to create a VPN to the Denver office. The U.S. regional offices have cache arrays that chain to Denver’s array, maximizing the interoffice bandwidth efficiency.
When attempting to install ISA Server, Setup only allows me to install the server in Standalone mode.
This behavior is actually by design. Whenever you attempt to install ISA Server, Setup checks to see whether the local server is a member of an Active Directory domain, and whether that domain already has the ISA Server schema extensions in place. If either of those requirements are not met, Setup will only install ISA Server in Standalone mode, which prevents it from becoming a member of an array. To install ISA Server in Enterprise mode, which includes array support, you must first ensure that the Windows 2000 Server computer you are using belongs to an Active Directory domain (a Windows NT domain won’t do), and that you’ve run the ISA Server Enterprise Initialization in that domain. This latter step extends the Active Directory schema to include the additional attributes needed to support ISA Server array configuration.
Caution
Before running Enterprise Initialization and extending your Active Directory schema, make sure that you understand the ramifications of extending the schema. Every domain controller in your forest will be modified with the new schema, and all Global Catalog servers may have to rebuild their catalogs (unless your domain is 100% Windows .NET Server domain controllers). When you’re ready to extend the schema, just launch Enterprise Initialization from the ISA Server Setup menu, which runs automatically when you insert the ISA Server CD.
Keep in mind that Enterprise Mode is only available in the Enterprise Edition of ISA Server; if you’re using the Standard Edition then you won’t be able to use Enterprise Mode no matter what you do.
ISA Server provides a flexible solution for securing your network, and for making Internet access more efficient. In this chapter, you learned about ISA Server’s capabilities as a firewall and proxy server, as well as its architectural features, including cache chains and arrays. You also learned how ISA Server supports various Windows and non-Windows client computers, and how you can create network designs that include ISA Server to protect valuable network resources.