How to Make the ISA Firewall as Dumb as a Traditional Stateful Packet Inspection Firewall – Redux

How to Make the ISA Firewall as Dumb
as a Traditional Stateful Packet Inspection Firewall – Redux

by Thomas W Shinder MD, MVP

Got Questions? Go to:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=24;t=000462 and ask!

This article first appeared in the ISAserver.org newsletter a couple of months ago. Its was so popular that I decided to update and enhance it and bring it online on the main ISAserver.org articles site. As always, I welcome your observations and opinions on the stuff we put up here on www.isaserver.org and hope you’ll use the discussion link at the beginning and ending of their article to further expand on what’s discussed in this article.

One of the worst ways to start my day is to read a post like this:

“We want to install ISA Server 2004 in Web cache mode. We already have a hardware firewall so we don’t need ISA in firewall mode. How can I do that?”

What makes this a painful experience is that I can’t figure out what’s up with these people who want to dumb down their ISA firewalls. When you install the ISA firewall in single NIC configuration, you lose a significant amount of security the ISA firewall can provide you that complements and enhances the security your current stateful packet inspection firewall provides. While the ISA firewall will exquisitely protect itself in single NIC mode, you’re at the mercy of your stateful packet inspection firewall for network protection, which isn’t a place I’d want to be.

It’s like saying “My Ferrari goes too fast; can you give me instructions on how to remove three tires to slow it down? I already have a Yugo for going fast”.

The fact is that the ISA firewall is a state of the art, third generation firewall that provides both the stateful packet inspection any “hardware” firewall provides and adds to that the ISA firewall’s stateful application layer inspection that traditional hardware firewalls don’t provide.

When I ask these guys what the deal is with dumbing-down their ISA firewalls, I hear stuff like:

• “I feel more comfortable with a hardware firewall in front.”
• “I don’t trust Microsoft security.”
• “Isn’t ISA a Proxy Server?”

I feel more comfortable when I have my teddy bear in bed with me because I believe it will stop monsters from coming out of the closet, but just because it makes me comfortable doesn’t mean the teddy bear is going to prevent the monsters from coming out of the closet. They usually come out regardless of the status of my Teddy Bear.

Think about it. What firewall protects more hacked networks than any other? (hint: its not the ISA firewall)

If you don’t trust Microsoft security, why are you running any Microsoft software at all? Host security is as important, and arguably more important, than the network security provided by any firewall.

And no, Proxy Server 2.0 was retired years ago – the ISA firewall is a FIREWALL. And a darned good one at that.

However, it’s clear that many firewall “experts” and administrators are still concerned about monsters coming out of the closet, and the “hardware” firewalls are their teddy bears. While we can never turn the ISA firewall into a teddy bear, we can make it look like one for those die-hards who feel uncomfortable without a “hardware” firewall.

To this end, we’ll go over things you can do to make your ISA firewall as dumb (and insecure) as a hardware firewall.

• Install the ISA firewall in Unihomed Web Proxy Mode
• Create an “All Open” Outbound Access Rule
• Never Require Authentication for Outbound Access
• Don’t Install the Firewall Client
• Don’t Configure the Browsers as Web Proxy Clients
• Don’t Use the HTTP Security Filter
• Don’t Join the ISA Firewall to Your Active Directory Domain

When you install the ISA firewall in unihomed Web Proxy mode, the only host on your network that is fully firewalled by the ISA firewall is the ISA firewall itself. The unihomed ISA firewall in this configuration acts as only a forward and reverse Web proxy server. While the ISA firewall retains its firewall functionality to protect itself, you’re at the mercy of your stateful packet inspection firewall for protecting the rest of your network.

Ever wonder why the level 1 techs on the other side of the phone always tell you to “open a port” even though no firewall in the world has an “Open Port” button? The reason is that “hardware” firewalls assume that you’re going to let everything from everyone outbound to the Internet, so the only ports that need to be “opened” are those inbound from the Internet (there are some non-sensical assumptions about “open a port” but we’ll talk about those issues at another time).

You can reduce your overall level of security by the ISA firewall to that you get with a hardware firewall by creating an “All Open” Access Rule on the ISA firewall. This will give all users access to all protocols when connecting to the Internet and they can remain anonymous while doing it.

Speaking of anonymous connections, most hardware firewall admins will agree that authentication is such a bother. Users complain that they’re not allowed to get to certain sites when using certain protocols, while other users seemed to be allowed to do so.

That isn’t fair, is it? Everyone was able to do whatever they wanted on the Internet when you had only the “hardware” firewall. This is clear evidence that there’s something wrong with the ISA firewall, right? If all users can’t get to everything, then ISA must have broke something.

Fix this by making your ISA firewall like your hardware firewall, and do not force authentication on any of your ISA firewall’s Access Rules.

The Firewall client allows network client systems protected by the ISA firewall to transparently send user credentials over an encrypted channel to the ISA firewall for authentication purposes. This enables the ISA firewall to enforce strong user/group based access control over connections made to and through the ISA firewall.

The problem is that the hardware firewall doesn’t require user/group based access control. So clearly there’s no reason to install the Firewall client. And if you do have a hardware firewall that allows authentication for outbound access, then install the Firewall client but don’t require encryption of the channel. This will dumb the ISA firewall down so that it acts like your hardware firewall’s unencrypted channel for sending usernames and passwords.

This will make things easier for everyone.

The Web Proxy client configuration enables the Web browser to automatically send user credentials to the ISA firewall and communicate directly with the ISA firewall’s Web proxy component. This enables you to obtain user/group based access control over all Web access, and at the same time, as well as benefit from the ISA firewall’s Web caching feature and squeeze out the best performance.

However, since the hardware stateful packet inspection firewall doesn’t have a Web proxy component and doesn’t authenticate users, there’s no reason to enable the Web proxy configuration. You also don’t want Web access to be too fast due to the Web proxy components since your hardware firewall isn’t able to cache Web pages to speed up Internet access.

The ISA firewall is a powerhouse stateful packet and application layer inspection firewall. One of the key stateful application layer inspection features of the ISA firewall is its HTTP Security Filter.

The HTTP Security Filter allows the ISA firewall to fully inspect virtually any aspect of an HTTP communication and block it based on the parameters of your choice. The great thing is that the block decisions are applied to allow rules, so even if you allow HTTP communications for that particular connection, if there are suspicious components of the communication, the ISA firewall will block it.

The hardware firewall doesn’t have the smarts to fully inspect communications moving through it, so you want to make sure you don’t configure the HTTP Security Filter on the ISA firewall. The further enables the ISA firewall to be as dumb as your stateful packet inspection-only hardware firewall.

One last thing, do NOT join the ISA firewall to your Active Directory domain.

If you joined the ISA firewall to your domain, you would be able to use the Firewall client, you would be able to use integrated authentication for outbound access to transparently send user credentials to the ISA firewall for authenticated Web access, you’d be able to record applications that users use to connect to the Internet through the ISA firewall, you’d be able to simplify VPN remote access client and gateway configuration, you’d be able to use user certificate mapping, you’d be able to simplify pre-authentication of incoming Web requests — you’d be able do these things and a lot more.

Your hardware firewall can’t do any of these things, so be sure your ISA firewall is just as clueless as your “hardware” firewall and don’t join the ISA firewall to the domain!

There you have it. Your ISA firewall is now just like your hardware firewall. Do you feel more secure? Do you feel like you have more control over inbound and outbound access through the ISA firewall? Do you feel that you’ve made the most of your investment in the ISA firewall software and that you’ve performed the requisite due diligence required for best network security practices and regulatory compliance?

Hopefully, all this has put in context the “security” you believe the “hardware” firewall allegedly provides your organization. While you can certainly keep your current hardware firewall and put it in front of the ISA firewall (the more layers bad guys have to go through, the better), don’t fool yourself that just because you paid five times more for the “hardware” firewall, that means it’s even half as secure as your ISA firewall.

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=000462 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