Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – The Totally Unofficial and Non-Authoritative Guide on ISA Firewall Installation on SBS 2003 SP1 (Part 1)

Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 –
The Totally Unofficial and Non-Authoritative Guide
on ISA Firewall Installation on SBS 2003 SP1

If you would like to read the other articles in this series please check out:

• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 2: The CEICW from the Welcome Page to the Route Configuration Page
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 3: The CEICW from the Network Connection Page to the E-mail Retrieval Method Page
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 4: E-mail Domain Name Page to Completion of the CEICW
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 5: Checking DNS and Certificate Settings and Installing the ISA Firewall

ISAServer.org is not known for being SBS friendly. Many times I’ve heard that someone from the newsgroups or mailing lists referred someone to the www.isaserver.org forums for advice and consent only to be rewarded with a critical chorus telling the plaintive SBS’er that he shouldn’t be running Exchange/DC/Web sites/etc on the same device as their network firewall. More humorous ISA firewall commentators might even come back with pithy aphorisms like “it’s a firewall, not a fire sale” or “don’t make the network firewall part of your server consolidation plan” or my favorite “the ISA firewall isn’t ZoneAlarm for Windows Servers”.

Part of the motivation for these sometime friendly, sometimes not so friendly retorts to SBS supplicants is that the ISAServer.org Web site has been oriented toward three groups of users:

• The hobbyist or home networker who is using an evaluation version of the ISA firewall to learn more about it before considering it for his production network
• The medium or large business network administrator interested in bringing in an ISA firewall for its unique security model which provides a superior level of network firewall security for Microsoft servers and services
• The established ISA firewall admin who has already read the books and comes to the ISAServer.org site for the advanced lessons covered in the site’s articles and the active discussion groups hosted on http://forums.isaserver.org

While this might at first glance look like a diverse collection of networking professionals, they all share one thing in common: they don’t know anything about Small Business Server (SBS).

ISA Firewall Admins Looking through SBS Glass Darkly

Because none of us knew anything about SBS, we figured SBS was just a standard issue Windows Server running stock editions of Microsoft Exchange Server, Microsoft SQL Server, and an IIS Web site. Since the ISAServer.org cadre of ISA firewall admins figure that the ISA firewall was designed from the ground up as a network firewall that should be dedicated to that purpose, we generalized our knowledge of good network security principles and with the best of intentions defiled and beguiled our SBS peers.

With the release of ISA Server 2004 (subsequently referred to as ISA firewall) and SBS SP1 (that included a free upgrade to the ISA firewall), came the realization that a large segment of the ISA firewall admin space is significantly underserved by our lack of coverage for ISA on SBS at www.isaserver.org. I hope that this, my first article about running ISA on SBS 2003 SP1 is the beginning of a long and continuing stream of information on how to get the most out of the ISA firewall when co-located on SBS.

Overview of this ISA Firewall on SBS 2003 SP1 Series

In this first series of articles about ISA on SBS 2003 SP1, I will share my experiences and observations on the CEICW and installing the ISA firewall on SBS 2003 SP1 as part of a clean install. What I mean by a clean install is that the SBS software with SP1 will be installed from beginning to end as a new SBS 2003 SP1 server. The server in the examples and procedures in this article series was not upgraded from an existing SBS installation that has already been in production.

While I realize that this probably isn’t the most common deployment scenario out there in SBS-land, it seemed like the only reasonable compromise. Upgrading an existing installation would require that I first install, configure and run SBS 2003 without SP1 for a period of time so that it simulates a production pre-SP1 SBS 2003 server that has been in production. The certificate (PKI) infrastructure would already be in place, a number of ISA Server 2000 rules would already in place, and an infinite number of permutations of customized configurations would need to be considered.

In spite of the fact that this might not be the most common deployment scenario, I still think there is much you can learn from my experiences with installing a clean SBS 2003 SP1 server, even if you already have an SBS 2003 machine in place that has been in production for some time and are thinking of upgrading to SP1 and including the new ISA firewall. I’ll discuss many principles and procedures that maybe you haven’t considered before and perhaps you’ll be able to use them to optimize your own configurations using this information.

I need to point out that this article series is based on my experiences with Windows Server 2003, Microsoft Exchange Server 2003, and ISA Server 2004. Whatever I know about SBS 2003 SP1 I’ve learned from the installation wizard and the inline Help files included in the installation Wizard interface. Even though SBS 2003 SP1 does a lot of things most non-SBS admins would consider “off-label”, most of the SBS services configuration conforms to the basics of Windows networking and the Windows Server services that run on non-SBS boxes. And although the Microsoft SBS and ISA teams have done a wonderful job at working out the bugs and issues involved with running multiple co-located Windows Server System services, these service still comply with their original design specs and still lend themselves to the application of principles used by dedicated server deployments.

This all means that you should consider this article and those that follow, as it relates to SBS best practices and configuration, as totally unofficial and non-authoritative. There will be some things that I do outside of the Wizards and there will be some configuration options that the SBS team enforces on us that don’t agree with my own approach to doing things. I’ll tell you what I think, but you should always go with the official SBS documentation if you find that it collides with what I have to say. Of course, you can try things my way and if they work better for you, so much the better and everyone wins!

SBS 2003 SP1 / ISA Firewall Network Security Model and Considerations

Before I get started with the CEICW and installation of the ISA firewall components on a new SBS 2003 SP1 server, I’d like to start with a small rant regarding network placement of the SBS box and whether or not a “hardware firewall” should be placed in front of the SBS box. Note that I put “hardware” in quotes because I consider this an inane distinction. All firewalls run on both hardware and software. While the hardware and software implemented a bit differently, the fact is that all firewalls and all computing devices depend both on hardware and software components.

Of course, mistakes made in language occur all the time and if it were only a nosological issue I’d probably leave it alone. But the “hardware” firewall marketeers have been very effective in spreading the misconception that their wares are more secure than firewalls built on a general purpose operative system (which of course flies in the face of Check Point’s Firewall-1 dominance in the firewall market).

Don’t fall for the “hardware” firewall ruse – a dedicated ISA firewall is just as secure as any other dedicated firewall device, and in many cases, much more secure.

Unmasking the “Hardware Firewall” Fallacy

The SBS’ers problem for is that an ISA firewall co-located on an SBS box is not a dedicated ISA firewall. Its sort of a blend between a network firewall performing inbound and outbound access control to and from the corporate network and a host-based firewall protecting the Microsoft Server services running on the SBS 2003 SP1 computer . Because of this, there has been a lot of discussion about whether there should be a “hardware” firewall or a NAT device placed in front of the SBS box.

Even I have fallen victim to this type of lazy thinking, as it was part of my knee-jerk reaction to the increased attack surface presented on a co-located ISA firewall/SBS box. Conventional wisdom dictates that each non-firewall service loaded up on a firewall device significantly reduces the overall security provided by the firewall services because of the increase software “attack surface” exposed by the non-firewall components. The conventional wisdom is right, but I, and everyone else who considered placing a simple “hardware” firewall in front of the SBS device with the goal of increasing security, are wrong.

The security issue with SBS is not related to the ISA firewall being co-located on the directory server, Exchange Server, SQL server, and multifunctional Web server. The ISA firewall is a top of the line and in many ways, cutting edge stateful packet inspection and application layer inspection blended firewall that includes proxy firewall and packet inspection firewall features and capabilities. When properly configured, no one is going to “break through” the ISA firewall’s stateful packet inspection and application layer inspection components to own your SBS box.

NOTE:
The operating term here is properly configured. The ISA firewall’s firewall feature set enables it to be a network brick, or a fully porous sponge, depending on how you configured it. The default configuration created by the CEICW makes attacks coming from the outside very difficult, but leaves the internal interface almost entirely unsecured, using a security model similar to that employed in the ISA Server 2000 firewall. Note that I saw similar, because the situation is not exactly the same as that found in ISA Server 2000. The reason for this is that the stateful packet inspection feature set cannot be turned off on any interface. Unfortunately, stateful packet inspection provides only rudimentary protection and almost none against the attacks seen on modern networks.

The actual security issue as it relates to SBS 2003 SP1 is that the SBS 2003 SP1 with the ISA firewall installed is an Internet facing device. Internet facing devices are by definition part of a security zone separate and distinct from the security zone where a company’s core assets are located. While it can be argued that most network based compromises take place from within the corporate network, the fact that the attacker [sic] surface for Internet facing hosts is many orders of magnitude greater than that presented by corporate network hosts.

With the fact that the SBS box is an Internet facing host in mind, it should be clear that it doesn’t matter if there is a “hardware” firewall in front of the SBS 2003 SP1/ISA firewall device, since the connections are still terminated at the SBS box. The SBS 2003 SP1/ISA firewall box with a “hardware” firewall or NAT device in front of it is no more secure than the SBS 2003 SP1 box without the “hardware” firewall or NAT device in front of it.

The Security Implications of Anonymous versus Authenticated Connections

Why? Because the “hardware” firewall or NAT device allows unauthenticated connections to reach the SBS 2003 SP1 computer. This creates an anonymous access DMZ in front of the SBS 2003 SP1/ISA firewall computer and provides a direct inroad to the directory services, DNS services, Exchange Server services, SQL services and Web servers located on the SBS computer. The simple stateful packet inspection firewall or NAT device in front of the SBS 2003 SP1/ISA firewall computer doesn’t change the fact that Internet sourced connections terminate on the company’s core information and financial assets.

The major risk for Internet facing devices is the shear number of anonymous connections made to it. You can realistically argue that if all connections were authenticated before reaching the SBS 2003 SP1/ISA firewall box, then a major portion of the risk is mitigated and can it can be reasonably argued that such traffic is no different then the type of traffic you see coming from corporate network clients located behind the SBS 2003/ISA firewall machine, since the internal network clients are almost exclusively authenticated users and machines.

The Valued Propositions for Front-end Stateful Packet Filter/NAT Devices and Co-located ISA Firewalls

This is not to say that there are no advantages at all to having a “hardware” firewall or NAT device in front of the SBS 2003 SP1/ISA firewall computer. When a NAT device or simple stateful packet inspection firewall is in front of the SBS 2003 SP1/ISA firewall computer, that device can be configured to allow inbound (albeit unauthenticated) connections only to the services that you want to provide remote access.

All other traffic, affectionately known as garbage traffic, is dropped by the NAT device or simple stateful packet inspection firewall. This offloads processing from the ISA firewall’s stateful packet inspection and application layer inspection mechanisms, which would otherwise take valuable processor cycles required to run the multiplicity of services running on the SBS 2003 SP1/ISA firewall device.

I also certainly do not want to give the impression that the ISA firewall added to the SBS SP1 computer provides no value. The ISA firewall component adds multiple levels of stateful packet inspection and application layer inspection to the connections moving to and through the SBS SP1/ISA firewall device. The ISA firewall’s feature set enables you to stop network layer attacks that wouldn’t be possible without the ISA firewall component, and it enables you to stop a large array of application layer attacks that are far beyond the capabilities of a simple stateful packet inspection firewall.

The bottom line: if you don’t authenticate users before they reach the SBS 2003 SP1/ISA firewall machine, then there is little to gain from a security point of view by putting a “hardware” firewall or NAT device in front of the SBS 2003 SP1/ISA firewall device. However, if you already own one, there’s no reason not to take advantage of its ability to filter out the garbage traffic.

In the follow four sections I go over some of the high level details of what I consider to be the most viable SBS 2003 SP1 network deployment options.

Scenario 1

The first scenario is the most simple of the four. The SBS 2003 SP1/ISA firewall computer has two network interfaces: an internal interface connected to the internal network and an external interface connected to a cable or DSL “modem”. The external interface receives its IP addressing information either the ISP’s DHCP server or the ISP may have assigned a dedicated (permanent) IP address for you to use on the external interface. The “modem” itself is transparent at the network level (the level where IP addressing takes place) since its works as a bridge between different communications infrastructures (e.g., Ethernet and DSL signaling).

This configuration enables the ISA firewall to provide strong stateful packet and application layer inspection protection for the services running on the SBS 2003 SP1 computer and for the hosts located on the internal network behind the SBS 2003 SP1/ISA firewall computer. The primary drawbacks to this configuration is that garbage traffic must be handled by the ISA firewall’s firewall services and that unauthenticated connections are allowed to terminate at the SBS 2003 SP1/ISA firewall computer, which can provide a potentially tasty attack surface for Internet intruders.

Figure 1 provides a high level depiction of scenario 1.

Figure 1

Scenario 2

Scenario 2 includes a simple stateful packet inspection firewall or NAT device in front of the SBS 2003 SP1/ISA firewall computer. In this scenario, the device in front of the SBS 2003 SP1/ISA firewall computer is a network layer device, which means that it will require IP addressing information on its internal and external interfaces.

The simple stateful packet inspection or NAT device in front of the SBS 2003 SP1 computer has an external interface that is assigned a public address (an address that is routable over the Internet). The external interface could have its IP addressing information assigned via the ISP’s DHCP server, or the ISP may assign you a static (permanent) address that you configure on the devices external interface.

The internal interface can use any private (non-Internet routable) address you like. The key requirement is that the IP address on the internal interface of the simple stateful packet inspection firewall or NAT device in front of the SBS 2003 SP1/ISA firewall must be on the same network ID as the external interface of the SBS 2003 SP1/ISA firewall computer. For example, you could assign the IP address 192.168.1.1/24 to the internal interface of the NAT device and assign the IP address 192.168.1.2/24 to the external interface of the SBS 2003 SP1/ISA firewall.

Note that another key requirement is that the internal and external interfaces on the SBS 2003 SP1/ISA firewall computer must be on different network IDs. By default, the installation Wizard on the SBS 2003 SP1 computer will assign the internal interface to network ID 192.168.16.0/24. You can use any private network ID you like on the external interface of the SBS 2003 SP1/ISA firewall computer as long as that address is not on network ID 192.168.16.0/24.

The internal interface of the NAT or simple firewall device and the external interface of the SBS 2003 SP1/ISA firewall computer are typically connected to the same hub or switch. All devices plugged into this hub or switch are part of an anonymous access DMZ. You could put public access Web servers or FTP servers or any other servers you like in the DMZ by plugging them into this switch. However, given that they are protected only by a simple NAT or stateful packet inspection firewall, you should be careful not to place mission critical resources in this DMZ.

The device in front of the SBS 2003 SP1/ISA firewall computer is configured to perform “port forwarding” or “reverse NAT” or “firewalling” or whatever the term the vendor chooses to use to describe allowing incoming connections to a specific port and have them forwarded to the external interface of the SBS 2003 SP1/ISA firewall device.

For example, in order to reach the Outlook Web Access (OWA) site on the SBS 2003 SP1/ISA firewall computer, you will need to configure the front-end device to allow incoming connections to TCP port 443 to the IP address bound to the external interface of the SBS 2003 SP1/ISA firewall computer. You would configure similar port forwarding for other services available on the SBS box.

The major disadvantage of this configuration is that incoming connections terminating at the SBS 2003 SP1/ISA firewall computer are unauthenticated. Attackers can leverage these unauthenticated connections to compromise your SBS computer through the services that you have configured to accept incoming connections. Anonymous attackers don’t even need to “sneak” through the front-end packet filter firewall or NAT device – they leverage the connection forwarding rules you configured to reach the SBS box. The primary advantage of this configuration is that you can filter out the garbage traffic using the front-end packet filter/NAT device.

Figure 2 provides a high level overview of scenario 2.

Figure 2

Scenario 3

Scenario 3 is a more advanced scenario that I’ve tried to promulgate in the SBS community with little success because of the cost of ISA firewalls. In this scenario, an ISA firewall replaces the simple stateful packet inspection firewall or NAT device used in scenario 2 and the IP addressing assignments are made in the same way as they are made in scenario 2.

The major advantage to this scenario is that you can take full advantage of the ISA firewall’s full stateful packet and application layer inspection feature sets to block dangerous communications from ever getting near the SBS 2003 SP1/ISA firewall computer. In addition, you can configure the front-end ISA firewall to pre-authenticate connections before allowing them to the SBS computer. In this way you can block all anonymous connections and significantly reduce the attacker [sic] surface to which the SBS 2003 SP1/ISA firewall computer is exposed.

Figure 3 provides a high level view of this configuration.

Figure 3

Scenario 4

Unfortunately, I don’t think I’ll be very successful in getting a significant number of SBS shops to adopt a dedicated ISA firewall in front of their SBS server. Whatever the reason for this dismal state of affairs, there is still a way these organizations can protect themselves in a way that is similar, but a bit less transparent, than the level of protection they would achieve if they had an ISA firewall in front of their SBS 2003 SP1/ISA firewall computer. This solution requires that the simple stateful packet filtering firewall or NAT device in front of the SBS computer support incoming VPN connections.

A VPN connection is an authenticated connection. The user much successfully authenticate with the VPN server before the VPN link is established. Once the VPN connection is established, the VPN user can access resources contained in both the authenticated access DMZ between VPN server and the SBS 2003 SP1/ISA firewall computer. We can also configure the ISA firewall on the SBS computer to allow incoming connections from the VPN clients to the internal network behind the SBS 2003 SP1/ISA firewall computer. And, if we do it smartly, we can also require that users authenticate at the SBS 2003 SP1/ISA firewall computer before allowing them access to any resources on the internal network behind the ISA firewall.

The key to this solution is to define an ISA firewall Network for the DMZ between the SBS 2003 SP1/ISA firewall and the internal interface of the front-end simple packet filter firewall or NAT device. Once that ISA firewall Network is defined, you can create a Network Rule that establishes a ROUTE relationship between the authenticated access DMZ and the internal network behind the SBS 2003 SP1/ISA firewall computer. This design also enables you to completely leverage the Firewall and Web proxy client configurations on the VPN client to access the internal network resources in a secure and authenticated manner.

Note that the network security model for this configuration is not the same as that achieved by enabling VPN connections to the SBS 2003 SP1/ISA firewall computer itself. They key security issue here is that no connections are allowed to resources to or through the SBS 2003 SP1/ISA firewall without pre-authenticating. The simple stateful packet inspection firewall or NAT device in front of the SBS 2003 SP1/ISA firewall performs the pre-authentication using a VPN solution. Ideally, the device in front of the SBS 2003 SP1/ISA firewall will support RADIUS or LDAP authentication with the Active Directory rather than keeping a simple on-box user database that is easily cracked.

Figure 4 provides a high level overview of this configuration.

Figure 4

What’s Up Next?

This article series will be about my experiences and observations on the CEICW process and subsequent installation and configuration of the ISA firewall. A couple of scenarios will be covered, as I didn’t quite understand what I was getting into the first time around. However, I found the attempt at the CIECW an interesting experience and learned some valuable information about how the ISA firewall component is configured in that scenario. I’m not going to tell you the details now; you’re going to have to wait until the next article in the series comes out.

I hope that we end up with some lively discussion on the CEICW experience and that SBS gurus and neophytes alike come out of the woodwork to explain the things that don’t make sense to me, the rationale for what the CIECW does things the way it does, and then on the meat of the ISA firewall configuration. If everything works out the way I hope it does, I’ll learn more from all you than you’ll learn from me.

In the long term I’ll go through several article on how the ISA firewall performs access controls and go over special topics that focus on the ISA on SBS configuration. Most of the ideas for these articles will come from your comments and questions on the SBS section of the ISAServer.org messages boards, so post early and post often!

If you would like to read the other articles in this series please check out:

• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 2: The CEICW from the Welcome Page to the Route Configuration Page
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 3: The CEICW from the Network Connection Page to the E-mail Retrieval Method Page
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 4: E-mail Domain Name Page to Completion of the CEICW
• Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 5: Checking DNS and Certificate Settings and Installing the ISA Firewall