Why the ISA Firewall Client Rocks:
Lessons on the ISA Stateful Application Layer Inspection Firewall
by Thomas W Shinder MD, MVP
Got Questions?
Discuss this article at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=27;t=000130
There are many things that set the ISA firewall apart from other firewalls in widespread use. But the one thing that stands out is the ISA firewalls unique combination of stateful filtering (stateful packet inspection) and stateful application layer inspection. Combine these features with the ISA firewall’s one of a kind VPN server and Web Proxy/caching capabilities, and you have one powerhouse firewall that causes other firewalls to pale in comparison.
A key component of the ISA firewall’s security model is its ability to authenticate virtually any connection made through it. In contrast to the traditional stateful filtering firewall, the ISA firewall is able to transparently authenticate just about any TCP or UDP connection made through it. The allows you not only the strong inbound access control you require to protect your network from Internet criminals, but also strong user/group based access control over outbound requests.
Traditional firewall administrators who think in terms of “opening ports” often ignore strong outbound access control. In contrast, the ISA firewall administrator knows that logging user names and applications used by users to access resources via the ISA firewall is critical. You’ll need this information to baseline your network activity, to provide reports on user behavior, and you’ll also need this information to meet evolving federal requirements on documenting and reporting user Internet activity.
A key piece of your outbound access control plan is the ISA firewall’s Firewall client application. In this article we’ll explore some of the capabilities and features of the Firewall client. You’ll wonder why you hadn’t installed the Firewall client sooner once you understand what the Firewall client can do for you.
Understanding the ISA 2004 Firewall Client
The Firewall client software is an optional client component that can be installed on any supported Windows operating system to provide enhanced security and accessibility. The Firewall client software provides the following enhancements to Windows clients:
- Allows strong user/group-based authentication for all Winsock applications using the TCP and UDP protocols
- Allows user and application information to be recorded in the ISA firewall’s log files
- Provides enhanced support for network applications, including complex protocols requiring secondary connections
- Provides “proxy” DNS support for Firewall client machines
- Allows you to publish servers requiring complex protocols without the aid of an application filter (although not ‘officially’ supported in the new ISA firewall)
- Makes the network routing infrastructure transparent to the Firewall client machine
Allows Strong User/Group-Based Authentication for All Winsock Applications Using TCP and UDP Protocols
The Firewall client software transparently sends user information to the ISA firewall. This allows you to create Access Rules that apply to users and groups, and allow or deny access to any protocol, site, or content based on user account or group membership. This strong user/group-based outbound access control is extremely important. Not all users require the same level of access, and users should only be allowed access to protocols, sites, and content required to do their jobs.
ISA FIREWALL NOTE:
The concept of allowing users access to only the protocols, sites, and content they require is based on the principle of least privilege. The principle of least privilege applies to both inbound and outbound access. For inbound access scenarios, Server and Web Publishing rules allow traffic from external hosts to ISA firewall Protected Network resources in a highly controlled and monitored fashion. The same should be true for outbound access. However, in traditional network firewall environments, inbound access is tightly controlled, while at the same time users are allowed outbound access to virtually any resource they desire. This weak approach to outbound access control can put not only the corporate network at risk, but other networks as well, as Internet worms can easily traverse these conventional stateful filtering firewalls that do not restrict outbound access.
The Firewall client automatically sends user credentials (user name and password) to the ISA firewall. The user must be logged on with a user account that is either in the Windows Active Directory or NT domain, or the user account must be mirrored on the ISA firewall.
For example, if you have an Active Directory domain, users should log on to the domain, and the ISA firewall must be a member of the domain. The ISA firewall is able to authenticate the user and then allows or denies access based on the user’s domain credentials.
If you do not have a Windows domain, you can still use the Firewall client software to control outbound access based on user/group. In this case, you mirror accounts users log on to on their workstations to user accounts stored in the local Security Account Manager (SAM) on the ISA firewall.
For example, a small business does not use the Active Directory, but they do want strong outbound access control based on user/group membership. Users log on to their machines with local user accounts. You can enter the same user names and passwords on the ISA firewall, and the ISA firewall will be able to authenticate users based on the same account information used when users log on to their local machines.
Windows 9x clients can be configured to forward domain credentials if they have the Active Directory client software installed. You can obtain the client software and installation instructions at http://support.microsoft.com/default.aspx?kbid=288358
Allows User and Application Information to be Recorded in the ISA 2004 Firewall’s Log Files
A major benefit of using the Firewall client is that when the user name is sent to the ISA firewall, that user name is included in the ISA firewall’s Firewall Service log file. This allows you to easily query the log files for user names and obtain precise information on that user’s Internet activity.
In this context, the Firewall client provides not only a high level of security by allowing you to control outbound access based on user/group accounts, but also provides a high level of accountability. Users will be less enthusiastic about sharing their account information with other users when they know that their Internet activity is being tracked based on their account name and they are held responsible for network activity carried out using their credentials.
Provides Enhanced Support for Network Applications, Including Complex Protocols Requiring Secondary Connections
Unlike the SecureNAT client, which requires an application filter to support complex protocols requiring secondary connections, the Firewall client can support virtually any Winsock application using TCP or UDP protocols, regardless of the number of primary or secondary connections, without requiring an application filter.
The ISA 2004 firewall makes it easy for you to configure Protocol Definitions reflecting multiple primary or secondary connections and then create Access Rules based on these Protocol Definitions. This provides a significant advantage in terms of Total Cost of Ownership (TCO) because you do not need to purchase applications that are SOCKS proxy aware, and you do not need to incur the time and cost overhead involved with creating custom application filters to support “off-label” or “home grown” Internet-enable applications.
Provides “Proxy” DNS Support for Firewall Client Machines
In contrast to the SecureNAT client, the Firewall client machine does not need to be configured with a DNS server address that can resolve Internet host names. The ISA firewall can perform a “proxy” DNS function for Firewall clients.
For example, when a Firewall client sends a connection request for ftp://ftp.microsoft.com, the request is sent directly to the ISA firewall. The ISA firewall resolves the name for the Firewall client machine based on the DNS settings configured on the ISA firewall’s network interface cards.
The ISA firewall returns the resolved IP address to the Firewall client machine, and the Firewall client machine sends the FTP request to the IP address for the ftp.microsoft.com FTP site. The ISA firewall also caches the results of DNS queries it makes for Firewall clients. Unlike ISA Server 2000, which cached this information for a default period of 6 hours, the ISA firewall caches the entries for a period determined by the TTL on the DNS record returned by the DNS server. This speeds up name resolution for subsequent Firewall client connections to the same sites. The figure below shows the name resolution sequence for the Firewall client.
- The Firewall client sends a request for ftp.microsoft.com.
- The ISA firewall sends a DNS query to an Internal DNS server.
- The DNS server resolves the name ftp.microsoft.com to its IP address and returns the result to the ISA firewall.
- The ISA firewall returns the IP address of ftp.microsoft.com to the Firewall client that made the request.
- The Firewall client sends a request to the IP address for ftp.microsoft.com and the connection is complete.
- The Internet FTP server returns requested information to the Firewall client via the Firewall client connection made to the ISA firewall.
The Network Routing Infrastructure Is Transparent to the Firewall Client
Another major benefit conferred by the Firewall client is that the routing infrastructure is virtually transparent to the Firewall client machine. In contrast to the SecureNAT client, which depends on its default gateway configuration and the default gateway (gateway of last resort) settings on routers throughout the corporate network, the Firewall client machine only needs to know the route to the IP address on the local interface of the ISA 2004 firewall.
ISA FIREWALL ALERT:
Note that I say “local interface” when referring to the connection to the ISA firewall. Unlike ISA Server 2000, where there was one or more “Internal” interfaces, the new ISA firewall does not see the network as composed of “Internal” and “External” interfaces. While the new ISA firewall has a default external interface, which is the interface that has the default gateway configured on it, the new ISA firewall supports multiple internal, external and DMZ interfaces. Note that there is a default “Internal Network” (with a capital “I” and a capital “N”). The default Internal Network is defined during setup and has nothing to do with the concept of Internal network used by the ISA Server 2000 firewall. The “local interface” is the interface on the same ISA firewall Network (with a capital “N”) as the client requesting content through the ISA firewall.
The Firewall client machine “remotes” (or sends directly) requests directly to the IP address of the ISA firewall’s interface that is located on the same ISA firewall Network as the client. Since corporate routers are typically aware of all routes to all network IDs on the corporate network, there is no need to make changes to the routing infrastructure to support Firewall client connections to the Internet. The figure below depicts the “remoting” of these connections directly to the ISA firewall. The table below summarizes the advantages of the Firewall client application.
Table 1: Advantages of the Firewall Client
| Firewall Client Advantage | Implication |
| Strong user/group based authentication for Winsock TCP and UDP protocols | Strong user/group based authentication for Winsock applications using TCP and UDP allows you fine-tuned granular control over outbound access and makes it possible for you to implement the principle of least privilege, which protects not only your own network, but other corporations’ networks as well. |
| User name and application information is saved in the ISA 2004 firewall’s logs | While strong user/group-based access controls increase the security the firewall provides for your network, user name and application name information saved in the ISA 2004 firewall’s logs increases accountability and enables you to easily research what sites, protocols, and applications any user running the Firewall client software has accessed. |
| Enhanced support for network applications and protocols | The Firewall client can access virtually any TCP or UDP-based protocol, even those used by complex protocols that require multiple primary and/or secondary connections. In contrast, the SecureNAT client requires an application filter on the ISA 2004 firewall to support complex protocols. The overall effect is that the Firewall client reduces the TCO of the ISA 2004 firewall solution. |
| Proxy DNS support for Firewall clients | The ISA 2004 firewall can resolve names on behalf of Firewall clients. This offloads Internet host name resolution responsibility from the Firewall client computer and allows the ISA 2004 firewall to keep a DNS cache of recent name resolution requests. This DNS proxy feature also enhances the security configuration for Firewall clients because it eliminates the requirement that the Firewall client be configured to use a public DNS server to resolve Internet host names. |
| Enables publishing servers that require a complex networking protocol | Web and Server Publishing Rules support simple protocols, with the exception of those that have an application installed on the ISA 2004 firewall, such as the FTP Access application filter. You can install Firewall client software on a published server to support complex protocols, such as those that might be required if you wished to run a game server on your network. It is important to note the Microsoft no longer officially supports this configuration and they recommend that you have a C++ programmer code an application filter to support your application. |
| The network routing infrastructure is virtually transparent to the firewall client | Unlike the SecureNAT client, which relies on the organization’s routing infrastructure to use the ISA 2004 firewall as its Internet access firewall, the Firewall client only needs to know the route to the IP address on the Internal interface of the ISA 2004 firewall. This significantly reduces the administrative overhead required to support the Firewall client versus the SecureNAT client. |
How the Firewall Client Works
The details of how the Firewall client software actually works are not fully documented in the Microsoft literature. In fact, if you do a network trace of Firewall client communications using the Microsoft Network Monitor, you’ll see that the Network Monitor is unable to decode the Firewall client communications; however, Ethereal does have a rudimentary Firewall client filter you can use (www.ethereal.com). This was true for the ISA Server 2000 Firewall client communications. Things can be even more problematic with the new ISA firewall’s Firewall client app because its able to encrypt the control channel communications.
What we do know is that the ISA firewall’s Firewall client, unlike previous versions, uses only TCP 1745 for the Firewall client control channel. Over this control channel, the Firewall client communicates directly with the ISA firewall’s Firewall Service to perform name resolution and network application-specific commands (such as those used by FTP and Telnet). The Firewall Service uses information gained through the control channel to set up a connection between the Firewall client and the destination server. The ISA firewall proxies the connection between the Firewall client and the destination server.
ISA FIREWALL NOTE:
The Firewall client only establishes a control channel connection when connecting to resources not located on the same network from which the Firewall client machine establishes the connection from.
In ISA Server 2000, the Internal network was defined by the Local Address Table (LAT). The new ISA firewall does not use a LAT because of its enhanced multinetworking capabilities. Nevertheless, the Firewall client must have some mechanism in place to determine which communications should be sent to the Firewall Service on the ISA firewall and which should be sent directly to the destination host that is located on the same ISA Network as the Firewall client machine.
The Firewall client solves this problem using addresses defined by the Network on which the Firewall client is located on. The ISA Network for any specific Firewall client consists of all the addresses reachable from the network interface that is connected to the Firewall client’s own network.
This situation gets interesting on a multihomed ISA firewall that has multiple Networks associated with different network adapters. In general, all hosts located behind the same network adapter (regardless of network ID) are considered part of the same Network and all communications between hosts on the same Network should bypass the Firewall client and be sent directly to the destination host located on the same ISA Network.
ISA 2004 SECURITY ALERT:
You may have multiple interfaces on the same ISA firewall. However, only a single network may have the name Internal. The new ISA firewall’s “Internal Network” consists of a group of machines that have an implicit trust in each other (at least enough trust to not require a network firewall to control communications between them). You can have multiple internal networks, but additional internal networks cannot be included in the address range of another network.
This means you cannot use the centrally-configured network address range for the Internal Network and additional Networks with the goal of bypassing the Firewall client when communicating between these Networks connected to the ISA firewall via different network interfaces. However, the centralized configuration of the Firewall client can be done per Network, so you can control the Firewall client settings on a per network basis. This allows you a significant measure of control over how the Firewall client configuration settings are managed on each ISA Network. However, this solution does not help in the network within a network scenario, where there are multiple network IDs located behind the same network interface card.
The most significant improvement the new ISA firewall’s Firewall client has over previous versions of the Firewall client (Winsock Proxy Client 2.0 and ISA Server 2000 Firewall Client) is that you now have the option to use an encrypted channel between the Firewall client and the ISA 2004 firewall.
Its important to be able to encrypt the information moving over the Firewall client’s control channel because the Firewall client sends user credentials transparently to the ISA firewall. The ISA firewall’s Firewall client application encrypts the channel so that user credentials cannot be intercepted by someone “sniffing” the network with a network analyzer (such as Microsoft Network Monitor or Ethereal). Note that you do have the option of configuring the ISA firewall to allow both secure encrypted and non-encrypted control channel communications. You might want to allow unencrypted connections for a short period of time to support the ISA Server 2000 Firewall client while you’re in the processing of migrating machines to the new Firewall client application.
For a very thorough empirical study on how the Firewall client application works with the firewall service in ISA Server 2000, check out Stefaan Pouseele’s article Understanding the Firewall Client Control Channel at www.isaserver.org/articles/Understanding_the_Firewall_Client_Control_Channel.html. While this article covers the details of the ISA Server 2000 Firewall client, most of the details remain the same and I highly recommend this excellent article.
Conclusion
In this article we went through the details of why the Firewall client is a key piece of security infrastructure to bolster the already impressive level of security provided by the ISA firewall. The ISA firewall’s Firewall client application allows the ISA firewall to greatly exceed the level of security and accountability that could be achieved by using a conventional stateful filtering firewall by automatically and transparently sending user names, user application names and other detailed information to the ISA firewall so that this information can be recorded in log files for later analysis and reporting. The Firewall client also enhances the level of accessibility the ISA firewall can provide by greatly extending the protocol support for Firewall clients without requiring C++ coded application layer filters.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=27;t=000130 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.
