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.
||Yes, but only HTTP
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.
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. 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.
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
| 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.
|Table 2. ISA client types.
||32-bit Windows clients only
||All. HTTP supported if CERN-compatible browser.
An HTTP application filter allows support for any
client application that uses HTTP to access the Internet.
|Requires network settings
||Yes, default gateway, routers, etc.
|Requires application filters for multiple connections
||By user name or IP address
||By IP address
||Must configure mspcfg.ini
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
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
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
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
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,
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
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
- FT—Functional Testing
- ST—Security Testing
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
|Table 3. How ISA would stack
up in ICSA's certified firewall testing.
||Criteria from the ICSA Web site
||How does ISA stack up?
||Once the required Services Policy is configured,
it must be enforced. Allowed inbound and outbound
traffic to and from defined services is permitted
unless specifically denied. Defined inbound services
are FTP, HTTP, HTTPS, SMTP, and DNS. Defined outbound
services are TELNET, FTP, HTTP, HTTPS, SMTP, DNS.
||You can certainly configure the settings listed,
||No special or proprietary software or specific platforms
may be required for the clients or servers in the
private or services network, the exception being management
||The firewall client is proprietary "special" software,
but it's not required to support these services. The
firewall client merely adds functionality. You could
use ISA as specified without it.
||Once the firewall is configured for the required
services policy, it's required to log events including
each permitted inbound and outbound access and all
attempts to violate these rules. Unauthorized attempts
to access the firewall itself should also be logged.
||Logging must be configured, but then it'll occur.
||Required data for each event is: date and time,
protocol IP, source IP address, destination IP address,
destination port or message type, disposition of event
||Information required is captured. And, even more
information can be logged.
||Date and time must reflect the exact date and time
the event occurred in hours, minutes, and seconds
||Information required is captured.
||Log data must be human readable.
||I could read it. (All right, stop snickering.)
||Conditional: If the log is sent to a separate logging
server, then the Fully Qualified Domain Name (FQDN)
or IP address of the firewall needs to be captured
in the log.
||Time and resources prevented my installing an array
of ISA firewall servers to demonstrate central policies
and logging. Product documentation claims this ability.
||Conditional: If data from a single event exists
in multiple logs and the logs are linked to display
this event, then some correct and understandable relationship
between the logs must be defined.
||I didn't investigate this "conditional" requirement.
||Administration functions are available to configure
the required services security policy and enable logging
of required log events. If remote administration is
possible, then these functions must be available and
||Administration functions are installed or not installed
on the ISA server by choice. These functions can be
installed on a remote station.
||An administrative interface that includes the administration
functions is available with the product
||Administrative functions are in the administration
||Authentication is required in order to access the
administration interface. A valid password or some
stronger form of authentication is necessary.
||To use the functions, you must authenticate using
Windows authentication. By default, only administrators
are allowed access. I didn't test smart card access.
||Conditional: When remote administration is possible,
if it's from the private network, the IP address of
the remote station shouldn't be the only authentication
means. If remote administration is possible from the
public network, then an encrypted session, one time
password device, or other stronger authentication
method is necessary.
||Remote administration uses Windows authentication.
Encrypted sessions can be configured via VPN or IPSec.
||Demonstrate that services in security policy can
be used and no others can be used.
||Limitations on time and resources prevented me from
doing functional testing.
||Demonstrate that there is no unauthorized control
of administration functions.
||I attempted administration access via user-level
logon with no success. Available time and resources
didn't permit rigorous testing.
||Demonstrate that the firewall isn't susceptible
to an evolving set of vulnerabilities that are known
in Internet communities. Testing should be remote
as well as local. The firewall doesn't introduce vulnerability
to private or service network servers.
||I lacked the time and resources for vulnerability
testing. I'm sure there will be claims that Win2K
introduces vulnerabilities (as you could rightly claim
of any OS that was improperly secured). The server
should be secured before introducing ISA and continually
||No other traffic other than that defined and allowed
can enter the private network.
||Time and resources didn't permit rigorous testing.
||DoS demo: The firewall can't be rendered inoperative
by a trivial DoS type attack and fails closed if it's
rendered inoperable by a DoS for which no known defense
||Time and resources didn't permit rigorous testing.
||There are installation docs, either written or electronic.
||Installation docs included.
||There are administration docs. All documentation
||A wealth of administrative documentation included.
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