Reasons to Upgrade to the 2004 ISA Firewall

Reasons to Upgrade to the 2004 ISA Firewall

By Thomas W Shinder M.D., MVP

Got Questions?
Discuss this article at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=24;t=000292

You’ve been running an ISA Server 2000 firewall and it’s doing what you want it to do. Now Microsoft comes out with a brand new and improved firewall, ISA 2004 (ISA firewall). You might be thinking “My ISA Server 2000 firewall is doing just fine for me. Why should I go through the hassle of upgrading, which is going to include exporting and importing my old rules, learning how the new things works, and dealing with all the things that you have to deal with when a new Microsoft product comes out?”

Get the New Book!

Good question! I’m the same way. Why should I go through the stress and strain of upgrading my firewall when it’s doing exactly what I want it to do. There better be some very good reasons for upgrading, or else I’m going to keep things exactly as they are.

The good news is that there are a great number of reasons for upgrading. To support this premise, I’ve cherry picked a list of features that battled-hardened ISA Server 2000 firewall veterans will appreciate the most, and provide the most compelling reasons to upgrade:

  • One of a kind VPN Server
  • IPSec tunnel mode support for site to site VPN
  • Preserve the source IP address for Web Publishing Rules
  • Publish a PPTP VPN Server
  • HTTP filtering on a per rule basis, including Windows executable blocking, for inbound and outbound connections
  • Create Protocol Definitions with multiple Primary Connections
  • Firewall Groups
  • RADIUS Authentication for Web Proxy connections
  • Access Policy is an ordered list
  • Forms-based authentication with the ISA firewall generating the form
  • Port redirection for both Web and Server Publishing Rules (FTP too!)
  • NAT and Route relationships between networks
  • Real time log monitoring and filtering
  • Automatically save reports as HTML files
  • Real Firewall backup and restore
  • Real DMZ networking with multi-adapter ISA firewalls

Look good? Let’s take a closer look at each of these and see if any one or more of them might give you the urge to upgrade.

One of a Kind VPN Server

The VPN server included with the new ISA firewall is nothing like you’ve ever seen before. Unlike most VPN servers and gateways (including the ISA Server 2000 VPN server and gateway) the new ISA firewall’s VPN capabilities allow you very granular, user/group, protocol and site based access control. The ISA firewall applies both stateful filtering and stateful application layer inspection to all communications moving over the VPN link.

For example, suppose your users want to use the full Outlook MAPI client to access the corporate Exchange Server from remote locations. You could use secure Exchange RPC publishing, but there are a lot of dull-bulb ISPs who are blocking the RPC endpoint mapper (TCP 135), so your users might be blocked from using the very cool secure Exchange RPC publishing rule to connect Outlook to your corporate Exchange Server.

Your other option is to use VPN. Just about all hotels, convention centers and airports allow outbound PPTP, since even the most elementary stateful filtering hardware firewall includes a PPTP NAT editor. The problem with VPN is that once the user VPNs into the network, they can potentially hit any server or workstation on that network.

Sure, you could create RRAS packet filters and limit users to specific servers, but like a hardware firewall, those packet filters apply to everyone. Not everyone needs access to the Exchange Server when they VPN into the network. Rudimentary stateful filtering doesn’t provide the level of access control you require to provide the highest level of protection for your networks.

The new ISA firewall allows you to create a Firewall group, and then create a rule that allows members of this Firewall group access to the Exchange Server only. And when users in this group get to the Exchange Server, they can only use the protocols they require to access it via the full Outlook MAPI client.

If members of that group try to access the Exchange Server using any other protocol, they will be denied. If members of that group try to access any other server on the network, they will be denied. If you set a schedule and they try to access the server at a time outside of the scheduled times where connections are allowed, they will be denied. Best of all, the users name will be included in the firewall logs, along with the protocols and servers they tried to use and access.

This is just the tip of the iceberg for the new ISA firewall’s VPN server and VPN gateway. If you’re using the ISA Server 2000 VPN features, then you’ll want to check out the new ISA firewall’s VPN capabilities, I know you’ll be impressed.

Get the New Book!

IPSec Tunnel Mode Support for Site to Site VPN

One major barrier to adoption for the ISA Server 2000 firewall was its inability to establish an IPSec tunnel mode connection with a third party VPN gateway. Many organizations had to hamstring their ISA Server 2000 firewalls and relegate them to the role of a common Web Proxy server at the branch office, all because the ISA Server 2000 firewall could not establish an IPSec tunnel mode VPN connection to the main office VPN gateway.

The new ISA firewall can connect to third party VPN gateways using IPSec tunnel mode site to site links. Now you can drop in an ISA firewall in your branch offices, and use the complete ISA firewall feature set! No more pain from putting a simple stateful filtering “hardware” firewall in front of a Web Proxy only ISA Server 2000 firewall – the 2004 firewall can be your branch office’s complete VPN, Web caching and firewall solution right out of the box.

Preserve the Source IP address for Web Publishing Rules

One thing that drove ISA Server 2000 firewall admins nuts was the inability to preserve the source IP address of a remote client when it was connecting to a Web server via a Web Publishing Rule.

ISA Server 2000 firewall admins wanted to use Web Publishing Rule instead of Server Publishing Rules because the Web Publishing Rules provided the deep stateful application layer inspection they needed to secure their published Web servers. But the inability to preserve the source IP address of the remote host made it impossible to use the Web server logs for site analysis – all source IP addresses appeared as the IP address of the ISA Server 2000 firewall’s internal interface.

The new ISA firewall allows you to choose between using the IP address on the internal interface of the ISA firewall or the original remote host’s IP address. If you don’t want to make the Web server a SecureNAT client, then use the internal address for the remote hosts IP address that the Web server sees; if you want to keep the original source address for log analysis purposes, then you can configure the Web Publishing Rule to preserve the address. Cool!

Publish a PPTP VPN Server

Many ISA Server 2000 firewall administrators used a back to back ISA Server 2000 firewall configuration. This allowed them to put Internet-facing servers on the DMZ between the ISA firewalls.

While the back to back ISA Server 2000 firewall configuration served them well, inbound VPN connections to the Internal network were a bit problematic. You can use the “tunnel within a tunnel” method, with the users establishing a VPN link to the external ISA Server 2000 firewall and then creating a second VPN tunnel inside that tunnel to reach the back-end ISA Server 2000 firewall.

When you upgrade, the new ISA firewall will allow you to publish the back-end VPN server. The updated PPTP filter now supports outbound and inbound PPTP connections. Your users can create the VPN connection to the front-end ISA firewall and the Server Publishing Rule will forward the PPTP VPN connections to the back-end ISA firewall. No more “tunnel within a tunnel” requirement. Great!

HTTP Filtering on a Per Rule Basis (including Windows Executable Blocking) for Inbound and Outbound Connections

The ISA Server 2000 firewall performed a very thorough, deep stateful application layer inspection on published Web servers when you used URLScan and Web Publishing Rules.

However, if you wanted more detailed inspection for inbound connections, you needed to get a third party application to plug into the ISA firewall. The same was true for outbound Web connections; you got some basic stateful application layer inspection, but not the kind of granular HTTP communications-control you really want and need to prevent 21st century attacks from internal and external attackers.

The new ISA firewall has a very sophisticated HTTP Security Filter that can be enabled and configured on a per rule basis. For example, suppose you want to create a rule preventing a group from accessing Windows executable files. No problem. It’s a matter of putting a checkmark in a checkbox. And it doesn’t even matter what the file extension is; the ISA firewall will be able to determine if the file is a windows executable, even if the file extension is .mom 😉

The ISA firewall’s HTTP Security Filter can inspect just about every aspect of an HTTP communication and block the connection based on the parameters you set, and do this on a per rule basis. Want to block Kazaa using an Access Rule? It’s a no-brainer. If you limit the users to Web connections, its as simple as putting the Kazaa host header information in the HTTP Security filter. Wow!

Create Protocol Definitions with Multiple Primary Connections

It was virtually impossible with the ISA Server 2000 firewall to create a Protocol Definition that included a large number of primary connection ports. You had to create one Protocol Definition at a time and include all of them in your Protocol Rule.

The new ISA firewall solves this problem by allowing you to create a range of Primary connections when defining a Protocol Definition. No more long nights entering 500 primary connection ports one at a time. Fantastic!

Firewall Groups

The ISA Server 2000 firewall allowed you to control outbound and inbound access on a user/group basis by using local and domain global groups and users. If you wanted to create a custom group for outbound or inbound access control, you needed to create this group at the level of the Active Directory (or in the local SAM of the ISA Server 2000 firewall). This meant you had to be a domain admin to create these global groups, or worse, you had to beg a domain admin to create the groups for you.

The ISA firewall now allows you to create custom Firewall Groups that you can use in Access Rules. Instead of using domain global groups to control inbound and outbound access through the ISA firewall, all you need is the ability to read the group information in the domain. You can now create custom groups on the firewall, such as Web Only, and Exchange MAPI Group and RDP and Web Only and then populate these groups you created on the firewall with users and groups that are already in the Active Directory.

No more begging the domain admins to create your groups. Wh00t!

Get the New Book!

RADIUS Authentication for Web Proxy Connections

A lot of organizations wanted to take advantage of the advanced logging and reporting included with ISA Server 2000 firewall so that they could have a list of sites users on the internal network visited over a period of time. The problem was that the ISA Server 2000 firewall needed to be a member of the domain in order to authenticate users making outbound requests.

These organizations may only have a single firewall, and so the ISA Server 2000 firewall was located at the Internet edge. They were uncomfortable placing a domain member at the Internet edge and so they couldn’t avail themselves of the ISA Server 2000 ability to record user names and the sites these users visited. (This is in contrast to when there is another ISA Server 2000 firewall in front of the ISA Server 2000 firewall, where it would be perfectly acceptable to allow the back-end ISA Server 2000 firewall to be a domain member.)

The new ISA firewall solves this problem for organizations who wish to put the ISA firewall at the Internet edge by allowing RADIUS authentication for outbound and inbound Web Proxy connections. The ISA firewall can be configured to send credentials to a RADIUS server to authenticate users. This removes the requirement that the ISA firewall be a member of the domain for authenticating outgoing Web Proxy connections.

Note:

It is a very common misconception that the ISA firewall needs to be a member of the domain to publish resources requiring authentication. All versions of the ISA firewall supports delegation of basic authentication, where the ISA firewall freezes the connection while it forwards the user credentials to the Web site. The Web site then forwards the credentials to an authentication server (Active Directory DC) and then returns the result to the ISA firewall. If the user successfully authenticates, then the connection is passed to the published Web server. The ISA firewall, be it 2000 or 2004, does not need to be a member of the domain to support delegation of basic authentication!

Access Policy is an Ordered List

I would venture to say that the majority of ISA Server 2000 firewall admins were never really sure when a specific rule would be activated. They sort of knew that unauthenticated would usually be evaluated first, then authenticated and then there was some stuff that had to do with whether it was a Web Proxy connection or a Firewall client or SecureNAT connection.

At that point things got muddy and they hoped for the best by creating Deny rules, which they were fairly confident were evaluated before allow rules.

The new ISA firewall changes the entire Access Policy model. Now the ISA firewall uses a simple, unified and ordered list of rules. The rules are evaluated from the top down. The first rule to match the connection request is the one applied. It doesn’t matter if it’s a Web Proxy, Firewall or SecureNAT client and it doesn’t matter if it’s allow or deny. The first rule on the list that matches the connection parameters is applied. Easy!

Forms-based Authentication with the ISA Firewall Generating the Form

If you’ve ever used Outlook Web Access and turned on forms-based authentication on the Exchange 2003 Server, you’ve seen the form that allows you to log on to the OWA Web site. The problem with letting the OWA Web site generate the form is that in order to access the form, an unauthenticated connection is allowed directly to the OWA Web site. I don’t know about you, but I wouldn’t take too kindly to allowing unauthenticated connections anywhere near my OWA Web server!

Well, the ISA firewall team understood that unauthenticated connections to an OWA server was a very bad thing; allowing unauthenticated connections to the OWA Web site can provide a powerful portal of attack for the bad guys. That’s why they included with the new ISA firewall the ISA Forms-based Authentication (FBA) protocol.

When you publish an OWA Web site using the ISA FBA, the form is generated by the ISA firewall. The user enters his credentials in the form and sends them to the ISA firewall. The ISA firewall forwards the credentials to the OWA site and the OWA site validates them by sending them to a DC. The OWA site informs the ISA firewall of the authentication results. If the credentials are valid, then connection is then allowed to the OWA site, if they’re not good, then the connection is dropped.

In addition, the ISA firewall generates the form for all versions of OWA. Without the ISA firewall protecting the OWA site, you only have forms-based authentication Exchange 2003. With the ISA firewall firmly in place protecting your network, you have FBA for all version of OWA, include OWA 5.5 and OWA 2000. The ISA FBA not only generates the form to prevent unauthenticated connections to the OWA site, it also allows you to block attachments and automatically log off OWA users after a predefined period of time or if they leave the OWA site.

If you need remote access to OWA sites, then upgrading to the new ISA firewall is the best thing you can do for that OWA site’s health!

Port redirection for both Web and Server Publishing Rules (FTP too!)

One complaint we used to hear a lot about with the ISA Server 2000 firewall was that port redirection wasn’t possible for Server Publishing Rules. For example, with the ISA Server 2000 firewall, when you published a server on TCP port 25 on the external interface of the ISA firewall, that connection was redirected to the same port number on the published server on the Internal network. This was irritating because even a dumb packet filter hardware firewall could do this.

The new ISA firewall solves this problem and allows you to perform port redirection very easily within the Server Publishing Rule Wizard. For example, you can create a mail server publishing rules that allows the ISA firewall to accept incoming connections on TCP port 26 and then forward that connection to TCP port 25 on the mail server on the corporate network.

One big improvement with the new ISA firewall is that you can now publish FTP servers on alternate ports. The ISA firewall can listen for incoming FTP requests on alternate ports and forward the connection requests to alternate ports. The new and improved FTP Access Filter makes this possible.

In addition, the new ISA firewall allows you to redirect incoming Web requests in the same way the ISA Server 2000 firewall allowed you to do this. The Web listener can be configured to listen on any TCP port number and forward the HTTP or HTTPS requests to any port number on the Web server on the corporate network.

Set NAT or Route Relationships between Networks

The ISA Server 2000 firewall had a pretty simple approach to networking. There was the external network and the Internal network. Any host with an IP address on the Local Address Table (LAT) was considered an Internal network host and any host with an IP address not included in the LAT was considered an external network host. All communications between Internal and external hosts were NATed. All communications from Internal to Internal were routed and all communications between external to external were routed (as in the example of the ISA Server 2000 trihomed DMZ configuration).

All this has changed with the new ISA firewall. There is no more LAT. The LAT is completely gone from the new ISA firewall. The definition on the Internal network has completely changed and has nothing to do with the route relationship between itself and any other network. The default External network includes IP addresses that the ISA firewall doesn’t have defined for any other network it knows about. There are no assumptions regarding the NAT or Route relationship between the default External network and any other network.

You can now choose, with the new ISA firewall, to either NAT or Route between any two networks. You might want to Route between the Internet and the DMZ and NAT between the Internal and one of the internal networks. You might want to Route between one of your internal networks and one of your DMZs and NAT between another internal network and another DMZ (or even the same DMZ!). The choice is yours with the new ISA firewall.

Real Time Firewall Log Monitor

The ISA Server 2000 firewall had comprehensive logging for the Firewall and Web Proxy services, but it was hard to get the information you wanted out of those logs. Another big problem with the ISA Server 2000 firewall’s logging feature was that you had to use a third party tool to see the log entries in real time.

The new ISA firewall solves these problems. The new ISA firewall is able to log to SQL, to text files or to the new and improved MSDE database. If you choose the new ISA firewall’s Advanced Logging feature, you’ll be able to see log file entries written in real time, and you can filter the log file entries you see appear in the real time. Or, you can query log file entries that have already been written. The built-in log file query mechanism is powerful and very easy to use and we’ve found it to be a tremendous boon in troubleshooting and traffic analysis.

Automatically Save Reports as HTML Files

The new ISA firewall has the same comprehensive reporting functionality included with the ISA Server 2000 firewall. However, one question we used to see at least once a day was “how do I automatically save my reports to HTML on my Web server?” The answer for the ISA Server 2000 firewall was you can’t, so stop asking.

With the new ISA firewall, you can configure reports to be automatically saved in HTML format to the local hard disk on the ISA firewall, or you can write the report files to your Web server automatically. You can also configure the ISA firewall to send you an e-mail message informing you that the report was created and include a link to the report. Neat!

Real Firewall Backup and Restore

A big issue with the ISA Server 2000 firewall was the desultory backup and restore feature. With the ISA Server 2000 firewall, you could back up the firewall configuration and restore the configuration to the same machine, and only the current installation on the same machine. If you had to reinstall Windows and the ISA on the same machine, or if you wanted to move the ISA Server 2000 firewall configuration to another machine, restoring the backup file wouldn’t work.

In contrast, the new ISA firewall allows you to backup the entire ISA firewall configuration and restore it to any other ISA 2004 firewall machine. The new ISA firewall’s backup feature can back up the entire ISA firewall configuration to an .xml file. That .xml file can be used to restore the ISA firewall configuration to the same machine, to the same machine with a new installation of Windows and the ISA firewall software, or to an entirely different machine with the ISA firewall software installed.

In addition to performing a full backup and restore of the ISA firewall configuration, you can backup and restore components of the ISA firewall policy. You might want to just backup the Firewall Rules you created on the ISA firewall and copy those rules to another ISA firewall. Or, you might want to just backup two or three rules, such as your OWA and RPC over HTTP Web Publishing Rules. With the new ISA firewall it’s a no-brainer to backup the entire ISA firewall configuration or just parts of it.

Real DMZ Networking with Multi-adapter ISA Firewalls

With the ISA Server 2000 firewall, DMZ networking was severely limited because DMZs had to use public addresses and only stateful packet filtering was done on communications between the Internet and the DMZ network. This meant that DMZ networking for the ISA Server 2000 firewall was similar to the simple stateful packet filtering available with any hardware firewall. This wasn’t good because you couldn’t take advantage of the ISA Server 2000 firewall’s ability to take advantage of stateful application layer inspection on communications moving between the public address DMZ segment and the Internet.

The new ISA firewall supports full DMZ networking for multihomed ISA firewalls. The DMZ segments on the new ISA firewall and use public address or private addresses. You can choose to NAT or Route between the DMZ segment and the Internet and you can choose to NAT or Route between any other Network and the DMZ segment. You can configure one DMZ segment or 20 DMZ segments, and you can choose to NAT or Route between any network and the DMZ segments. Most importantly, all communications between the DMZ segment and any other network are subjected to both stateful filtering (like any conventional hardware firewall) and stateful application layer inspection.

The full DMZ network capabilities allow you powerful access control between the Internet and corporate networks and your DMZs, allowing you to create powerful and sophisticated DMZ scenarios. It’s a breeze to create partner extranets, authenticated DMZ segments and anonymous access DMZ segments.

Get the New Book!

Summary

The new ISA firewall is a complete remark of the ISA Server 2000 firewall. Now you have all the features provided by traditional stateful filtering firewalls, but with the new ISA firewall’s stateful application layer inspection feature set and ease of use. The new ISA firewall promises to make a major dent in the firewall market in the next few years because traditional packet filter firewalls just can’t protect networks against modern day attacks.

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=24;t=000292 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.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top