Microsoft’s Internet Security and Acceleration Server performs proxy and firewall services. This briefing educates you on its firewall capabilities.

The Network Protector

Microsoft’s Internet Security and Acceleration Server performs proxy and firewall services. This briefing educates you on its firewall capabilities.

• By Roberta Bragg
• November 01, 2000

Back in 1995 there was a lot of chatter about this new, cool, coming-out-“real soon” product with the code name of “Catapult.” It would be a Web proxy and save companies money by caching Web pages for later use. We know Catapult now as Proxy Server, and many of us use it. In Proxy 2.0, packet filtering—the ability to determine access via the protocol number or port used—was included and many of us used it instead of purchasing a firewall. Maybe it’s not your idea of the best firewall (read: it doesn’t work on Unix, doesn’t have all the bells and whistles, and doesn’t cost a lot), but then we don’t all have the extra moola to blow on a dedicated firewall product from one of the players in that industry.

At Microsoft TechEd this year, several break-out sessions focused on a new product, the Internet Security and Acceleration Server (ISA), which will eventually land in BackOffice 2000 (or whatever they call it when it arrives). I picked up a beta copy. ISA could be called “Proxy on steroids with wings,” and its program managers claim it’s a REAL firewall. Several sessions touted its caching capabilities and (yawn) many of us in the audience were looking at each other and whispering, “But I can do that with Proxy…” Eventually, the new, more sophisticated packet filtering, policy setting, and alerting and intrusion detection features were outlined and nap time was over.

ISA, it turns out, can be a proxy server (to cache Web pages and filter Web access with reporting), a firewall (to block access to your internal network from the Internet), or a combination of the two. To determine its role on your network, you choose a mode—Cache, Firewall, or Integrated—during installation. In the beta product, the mode can’t be changed after installation. Table 1 defines the services available with each mode.

Cache mode is, at least as far as this novice can tell, very much like Proxy server. So for this “first look” rundown, I’m going to tell you about the Firewall mode. Remember that I’m working from beta. By the time this column is published, the product could be out, which means your experience may vary. Note, too, that Windows 2000 is required for ISA. Proxy Server (as far as I can tell) will still be around for your Windows NT 4.0 installations.

First, I’ll cover features and implementation issues; then I’ll address those concerns you might have in entrusting your network protection to Microsoft.

Array Administration

One of the most impressive features of ISA is its potential to be managed both at a server level, as an independent array (a series of ISA servers treated and administered as a single logical entity) and as an enterprise array (an array of ISA member servers in a Win2K domain). An array doesn’t have to exist in a Win2K domain, but when it does, you accrue further benefits. To understand the difference, remember this: In an independent array, all servers will have the same configuration; at the enterprise level, they all share the same policy. Think Win2K local configuration vs. Group Policy and you’ve got the right idea. I’ll describe configuration and policy choices shortly.

If Win2K isn’t the predominant logical configuration for your network and you still want the advantages, you can establish a Win2K domain just for the ISA servers. By establishing a trust with an NT 4.0 domain, you can provide extended support for NT clients. Once you’ve determined appropriate security policies, you can more easily protect your enterprise since you can administer and maintain polices for the ISA server centrally. You can certainly install just one ISA server on a stand-alone Win2K server; but if you need to protect more than one access point or both sides of a DMZ, install an array and you won’t have to visit individual servers eternally to coordinate their settings. The administration console shows up in Figure 1.

Figure 1. The ISA Administration console lets you administer and maintain security policies across the enterprise. (Click on image to view larger version.)

The Firewall Client Concept

While it’s not necessary to install a “firewall client,” doing so gives you additional benefits. Firewall clients can run Winsock applications that use the firewall client service of the ISA server to access services on the public network. The firewall client intercepts an API call and decides whether to route it to an ISA server computer.

If a client doesn’t have the firewall client installed, the SecureNAT service of the ISA server provides normal and extended filtered access. Clients supported in this way are called SecureNAT clients. SecureNAT is network address translation provided by the firewall service, not by Win2K Routing and Remote Access Services. There’s no requirement for the installation of any software on the client system. SecureNAT provides address transparency and—for supported protocols—requires no client configuration.

ISA’s SecureNAT extends NAT, enforcing ISA server policy (server rules) for SecureNAT clients. Policies can cover protocol usage, destination, and content type. SecureNAT filters can handle complex protocolsæa feature similar to NAT editors. HTTP requests by clients are automatically forwarded to a Web proxy service that handles access rules and site and content rules and uses the proxy cache. SecureNAT clients can be of any type, not just Windows. Unix, Macintosh, and other OSs can access the Internet through ISA.

NAT vs. SecureNAT As you know, network address translation, or NAT, replaces the internal IP address of the client in a packet that crosses the NAT server boundary with a viable, external IP address. External hosts, those on the public network, can’t determine the internal host’s true IP address by examining captured packets. When an answer is returned, the NAT server replaces the IP address with the real, private network client IP address. The figure illustrates this action. SecureNAT performs a similar function but adds authentication, even for non-Windows clients, and the ability to support additional protocols. Each packet from the private network has its source address replaced by a valid public network address. Each returning packet is addressed to this address, and the ISA server removes that address and replaces it with the private network address.

If you’re familiar with Proxy Server, SecureNAT is similar to the proxying of HTTP, which could be transparently arranged by pointing the Web browser at the proxy server. All Internet requests were redirected to the ISA server. If support for other protocols were necessary, you installed the Proxy client. SecureNAT, however allows transparent interception of packets if the ISA server lies between the client and destination. Policy is applied to all communication that passes through the server, whether or not a client is physically installed or the browser is configured on the host source. Table 2 summarizes the client types.

Security Services

ISA provides packet filtering, dynamic application-level policies, secure Web publishing, and intrusion detection and alerting. Let’s examine each.

Circuit-level and Application-level Protection

Circuit-level protection, or packet filtering, is based on service type, port number, source computer naming, and destination computer. Filters define inbound and outbound access, both allowed and denied. This filtering is static; the communication is either allowed or disallowed. Blocking filters always block. Non-blocking filters always allow all traffic through unconditionally at the port specified in the filter. However, filtering is dynamic. Ports aren’t left open, but opened according to client request. If a communication isn’t blocked or allowed (no filter exists), it’s passed to the application level.

You provide application-level protection by creating an ISA server policy. A policy is a set of rules that specifies which communication is allowed. Ports are opened for transmission or reception, then slammed shut after the ISA server closes the connection. Server rules can be configured to determine access policy, bandwidth, and publishing.

Internal Service Publishing

ISA publishing and server publishing rules determine if a service or application is listening for incoming traffic by binding the service or application to the ISA server external interface. An external port on the ISA server is delegated to be an external port used by an internal server. (Got that?) The service bound to the port becomes the only user of that port and the sole recipient of traffic on that port.

Two obvious uses of this facility is the protection of an internal mail server or Web server. For example, Exchange could be bound to port 25 for SMTP on the ISA server using server publishing rules. These rules determine which services may publish to the Internet. The ISA server will intercept the traffic. To the external users, the ISA server is assumed to be the Web server or mail server. If ISA is fronting a Web server, it can even cache the internal Web server pages and serve the external request from them. If the request can’t be fulfilled, it can be forwarded to the actual Web server that sits inside the network. Figure 2 illustrates secure Web publishing. Microsoft has licensed intrusion-detection software from Internet Security Systems. These components allow alerting and logging of specific attacks and possible automatic actions such as breaking the connection. Detected attack rules include those for port scans, land attack, ping of death, and udp bombs.

Figure 2. The process of secure Web publishing with ISA. (Click image to view larger version.)

Getting Up and Running

Like most Microsoft BackOffice products, ISA installation’s a snap. The server will need to be pre-installed with Win2K Server. Whether it’s a member or stand-alone server will depend on how you plan to implement ISA. The box will need two network interfaces, either two network interface cards or one card and a modem. One adapter is used to connect to the Internet (it’s up to you to arrange for Internet accessibility); the other to your internal network. If you plan to use ISA as a Web proxy behind another firewall, only one interface is necessary. Administration tools are MMC snap-ins, and an administration tool is available for Win2K Professional.

Prior to installation you’ll want to assure that the Win2K routing table contains all internal network addresses so that a correct LAT or local address table is built. (You can configure the LAT post-installation, but configuring the routing table after installation won’t adjust the LAT). Web requests for addresses in the LAT won’t be channeled outside the ISA server.

You may also install ISA on a server as part of an independent (non-domain-based) array or as part of an Enterprise domain array. If the ISA server is to be part of a domain-based array, then ISA Active Directory schema modifications need to be installed to the AD on a domain controller. ISA provides a utility to do this, as well as documentation at www.microsoft.com/isaserver/techinfo/productdoc/default.asp. You may install ISA as part of an independent array and then later join a domain array. After this joining, the server will receive and adopt all of the array’s enterprise settings, access policy and monitory configuration, and filter settings and configuration of other add-ins. (The add-ins—application filters, Web filters, and the like—must be individually installed on the server, though.) Domain arrays can include more than one member server for greater fault tolerance, improved performance, and enterprise-based policy.

You can configure alerts for a single server or for all servers in an array. Reports, while developed for all servers, are stored in a database on a computer you specify.

You can do an upgrade from Proxy Server 2.0, to upgrade most proxy server rules, network settings, and monitor and cache configuration. The new server will support current Winsock proxy clients.

While installation is easy, it’s disconcerting. We all know that an improperly configured firewall is sometimes worse than no firewall at all—like using the standard door lock in the big city, we’re lulled into a sense of security. Don’t be fooled! While some settings are in place, especially if you only select the firewall or integrated mode, they may not be the settings you deem appropriate.

Immediately after installation you should check the default settings. Default settings on packet filters are enabled in firewall and integrated modes, but disabled in cache mode. Define site access control rules. By-default access to all sites is allowed to internal clients. Since no publishing (no internal servers are accessible to the outside world) is configured, if you wish to provide access, you’ll have to configure it. All alerts are active, with the exception of these: port scan attack (someone is merely seeing what ports are open); dropped packets (some packets aren’t being allowed to enter or leave the network and so are dropped); protocol violation (a request is made to use a particular protocol but the packet is improperly defined); and udp bomb attacks (udp ports are being attacked).

To secure your ISA server, use the system security wizard—and spend some time to understand what each choice means. Three choices are available: default (use this if the server is also an IIS, database, or SMTP server); moderate (the server is also a cache server); or high security (a dedicated firewall). Many complaints about using NT or Win2K as the OS for a firewall come out of the fact that they’re relatively open systems (as in unprotected and insecure, not as in source code freely available and modifiable). You must harden your server before installing ISA and continually maintain it while monitoring for new security issues.

But Is It a Real Firewall?

What’s a “real” firewall? Some would tell you that a real firewall doesn’t run on Windows. Others would say only a hardware-based solution is proper. Still others insist on using a product running on an OS stripped to its bare essentials; in other words, no GUI, no services or daemons—just the essentials. If you listen to the “security” consultants, those with large vested interest in selling you one of the major players in the firewall industry, there’s only one product to choose (Which one? Theirs, of course).

Another criteria often used to judge the real-world readiness of a firewall is ICSA certification. ICSA(www.icsa.net) is a provider of security assurance services for Internet-connected companies. It supports the Certified Information Systems Security Professional (CISSP) examination (although it’s not the author) and runs ICSA labs, which provide product research and certification facilities. Test categories include virus protection, network firewalls, intrusion detection, cryptography, and IPSec products; results are published on the Web. (Go to www.icsa.net/html/communities/
firewalls/certification/vendors/index.shtml for a list of certified firewalls.) If you’re considering the purchase of a firewall, these certification pages are a good place to start.

At TechEd I heard that ISA would be submitted for certification testing; from what I’ve seen, there doesn’t seem to be any reason not to. Microsoft has everything to gain and nothing to lose. To give you an idea of what ISA will go through if submitted to ICSA, I’ve summarized the exam criteria. A more elaborate specification is available on the ICSA Web site. Get yourself an evaluation copy of ISA and do your own test. This examination of the product is no substitute for certification testing, but it will give you an idea on how to answer the question: Is ISA a real firewall?

As the specification states, “There is no required default behavior.” The product doesn’t have to block certain ports from the get-go or be difficult or easy to configure. But it does have to perform flawlessly if configured with a standard “Required Services Policy,” allowing identified communications to pass the firewall boundary and blocking others. The RSP is simply a security policy that ICSA uses to configure the system. Remember, a security policy is simply a high-level description of services explicitly permitted to traverse the firewall and of those that are denied. The firewall can implement these requirements in different ways. ICSA makes no restrictions. Submitted products can be hardware; application software; software, plus the underlying OS and utilities; management station hardware and software; documentation; and/or a one-time authentication device.

ICSA Firewall Criteria

The criteria used by ICSA in its testing labs are listed, along with comments on specific features of ISA, in Table 3. Mind you, ISA hadn’t been certified at the time of this writing; I just believe it would pass the exam from what I’ve seen. The discussion is meant to give you an idea of the rigorous testing required for certification. However, you should visit the ICSA Web site for a fuller explanation and to review the complete list of certified products. Some firewalls that operate with NT and that are certified using these criteria include:

• CyberGuard NT from CyberGuard Corp.
• Firewall-1 NT from Check Point Software
• Raptor NT from Axent Technologies
• FireWall for NT from Novell
• Gauntlet NT from Network Associates
• SecureWay NT from IBM

For purposes of the listing below, public network is defined as an unprotected or external network that the product can’t protect or make claims about (perhaps a public network is the Internet). A private network is the protected or internal network; it’s this network that the firewall should protect and/or monitor traffic on. In addition, a services network or DMZ is another private network that may consist of public access servers.

An administrative interface is the way that an administrator will access the firewall, through a Web browser, via a dedicated management station, local console, or something else. None of this should surprise you, but pay attention here: Remote administration is administration not done through direct connection with the firewall (serial cable perhaps or local console). Remote doesn’t mean, as in the traditional aspect, across an unprotected network, WAN, or dial up connection. Instead, remote in this context can mean an additional computer on the LAN. Inbound traffic is traffic from the public network to the private network, while outbound traffic is traffic from the private network to the public.

ICSA criteria are separated into six areas:

• RS—Required Services Policy
• LO—Logging
• AD—Administration
• FT—Functional Testing
• ST—Security Testing
• DO—Documentation

So How Does ISA Stack Up?

While I lack the resources of Microsoft, I can speculate on some of the criteria. You’ll find my comments in Table 3.

I’ll leave the heavy testing to the professionals. Remember, my comments are just that, speculation from observation of and use of a beta product. Time and resources prevent me from doing rigorous (or even elementary controlled) testing. I make no claims as to the suitability for your network of this product. That said, I think it’ll make a fine firewall for many of the security jobs on which I consult.