Teaching Security to Non-ISA Firewall Administrators

By Thomas W Shinder MD, MVP

I often get to work with non-ISA firewall administrators who are in the position of introducing an ISA firewall into their corporate networks. These non-ISA firewall admins are typically part of the network infrastructure team, and they manage not only the firewalls, but also network devices such as routers and switches. Because of this, it's often difficult to communicate with these people that there is no magic protection provided by hardware devices and that all computing devices depend on both hardware and software.

My conversations with these people are often extremely interesting and I learn much more from them than they might ever learn from me. One thing I've learned from these folks is that many of them don't really understand that the role firewalls play when protecting network perimeters have changed since the mid to late 1990s, which is when most of these people began their networking education and joined the community of IP networkers.

Since you're reading this newsletter, you either have an ISA firewall on your network, or you want to bring one onboard. In both these cases, there's a good chance that you'll have to interface with people who'll give you some push-back on introducing or integrating the ISA firewall to the corporate network's security infrastructure.

To help you deal with these people more effectively, I'll share with you some of the content of an e-mail I had a chance to read last week from someone who manages a non-ISA firewall network infrastructure. As you'll see when reading through this interaction, this fellow felt (note I say felt, not thought, because none of the opinions expressed we're backed up with facts) that introducing the ISA firewall into his network would reduce his overall security posture.

What he didn't realize is that by taking a stance based on ignorance of modern network security principles, he was actually trying to come up with arguments that would reduce the overall security of his company's Exchange organization.

We'll take a look at what this non-ISA firewall administrator had to say and comment on it, so that you can come back with some effective arguments when you run into similar people. The sections in quotation marks are those of the non-ISA firewall admin.

"Our Microsoft administrator wants to multihome an ISA firewall on our web DMZ with the other NIC connected to our internal network to allow the ISA firewall to communicate to the internal Microsoft Outlook Web Access (OWA) front end Exchange Server, which then communicates with the back-end Exchange Servers. All this to allow users on the Internet to access Exchange via a web browser."

No problem here. The ISA firewall provides a unique level of protection for remote access to all the Exchange Server services. The "Microsoft admin" probably has performed due diligence and learned that the ISA firewall is a true network firewall that performs both stateful packet inspection (stateful packet filtering) and stateful application layer inspection (application layer filtering) and that is has several technologies included in it, right out of the box, to provide secure remote access solution to Exchange. The "Microsoft admin" probably is very security conscious and realizes that heterogeneous firewall environments are more secure than a single firewall solution.

"I've read a lot of the documentation on the whole Windows2003 Exchange web pages solution and I think Microsoft is trying to bad mouth other firewalls while touting their own proxy/packet firewall as good as or better than "the rest of the world". Problem is, Checkpoint/Nokia is a far better technical solution compared to MS ISA (MS bigots take a deep breath and count to ten)."

I've heard a few non-ISA firewall admins state something similar to this. If we pin down this non-ISA firewall admin, you'll see that there is no information anywhere on the Microsoft Web site that "bad mouths" other firewalls or that implies that it's better than any other firewall in the world.

What is on the Microsoft Web site is information on how the ISA firewall provides a unique level of protection for remote access connections to Microsoft Exchange Servers and services, and that the ISA firewall is a stateful packet inspection and stateful application layer inspection firewall.

The statement that Checkpoint/Nokia or any other firewall represents a better technical solution shows that the non-ISA firewall admin has definite knowledge issues. This is one of the biggest problems you'll run into with the non-ISA firewall admin. They typically know nothing about the ISA firewall, and assume that it's just a "proxy" server.

The problem is, they don't really understand what firewalls are, what proxy servers are, and the types of security conferred by firewalls and proxies. They get into even more trouble when confronted with a blended packet filter/proxy firewall like the ISA firewall. You can counter these guys by asking them for specifics:

• How is the current firewall a better "technical" solution? How is it a better technical solution when it comes to providing specialized protection for the servers and servers the firewall is protecting?
• What specific technologies does the current non-ISA firewall have to provide unique network and application layer protection for the service require protection? Make sure to have him provide the specific application layer inspection and protection features. Any firewall on the market today performs layer 3 and 4 protection, so stateful packet inspection alone doesn't differentiate any firewall from another (in general).
• Where are the specific documents on the Microsoft site that say that the ISA firewall is categorically better than any other firewall?

These are easy questions to ask, and when the non-ISA firewall admin comes up empty, it softens him up for the rest of your interaction.

"I asked the Microsoft admin to single home his ISA firewall or forget about the ISA firewall altogether and just run a front end server in the web DMZ. The idea of breaking our Checkpoint architecture with an multihomed ISA firewall that interfaces with the internal network and our web DMZ is just too much to ask a decent security admin don't you think. Now I need ammunition to press the point home."

There are some profound security problems with the non-ISA firewall admin's requirements.

Right now, all we have is a single vendor firewall solution, which is Checkpoint in this example. A more secure configuration is to have multiple firewalls, from multiple vendors, interposed between the Internet and the protected services. A single NIC ISA firewall can't provide firewall protection for the Exchange Servers, because it needs to be in the path between the source and destination and connections must be forced through the ISA firewall. A single NIC configuration is easy to bypass because the ISA firewall can't be put in the path.

So, we see that the non-ISA firewall admin is actually attempting to reduce the overall security of his corporate network. This is a dangerous situation for this company's Exchange organization.

The next concern is that the non-ISA firewall admin in this example is concerned about the ISA firewall somehow "breaking" his Checkpoint solution. How could the ISA firewall break an existing firewall infrastructure? We have to read between the lines here. Its could be that the non-ISA firewall admin doesn't really understand how to configure the Checkpoint firewall and is concerned having to learn more to make minimal configuration changes on the non-ISA firewall to support the enhanced security solution provided by bringing the ISA firewall into the mix. It could be that the non-ISA firewall is too busy to make the required changes. Or, it could be that the non-ISA firewall admin is trying to justify the premium prices he's asked the company to pay for their current hardware firewall solution and would be embarrassed that the ISA firewall provides the same protection at a fraction of the price.

A blanket statement like "a multihomed ISA firewall is too much to ask of a decent security admin" sounds more like a canard than something a serious network professional would say.

Probably the best way to approach this problem is to query the non-ISA firewall admin on what he knows about the ISA firewall's security model. If he says "it's just a proxy server" or "it's just a software firewall" or "it runs on Windows" then you know that you're dealing with someone with a significant knowledge gap and you can help educate this person by pointing him to ISA firewall technical resources.

"A few questions:
1. If any of you run an ISA firewall for tunneling for the front end server I'd like to hear if you were able to do it using single homing (the documents say it's possible but not recommended and our Microsoft admin says he can't get it to work)."

Bingo! We now have the answer to the level of sophistication the non-ISA firewall admin has regarding what network security is all about. SSL tunneling is a dangerous situation, because the perimeter devices, like the firewalls, are typically not able to inspect data inside the SSL tunnel. The typical firewall admin is just concerned about "opening ports" and blocking network layer attacks against the firewall device itself.

This non-ISA firewall admin wants to tunnel an SSL connection to the Exchange Server, which prevents any stateful application layer inspection from taking place at the perimeter and leaves the entire responsibility for protecting the front-end Exchange Server to the front-end Exchange Server itself.

The ISA firewall performs SSL to SSL bridging, so that the ISA firewall can perform stateful application layer inspection on the commands and data moving inside the SSL tunnel between the Web client and the front-end Exchange Server. Their current firewall solution can't do this, so it's quite easy for any attacker to tunnel through the Checkpoint device to attack the front-end Exchange Server. In contrast, the ISA firewall's SSL to SSL bridging feature set makes it easy to stop out of bounds HTTP commands and data at the ISA firewall itself and prevents exploits from ever getting near the front-end Exchange Server.

In addition, the ISA firewall can pre-authenticate users and leverage forms-based authentication to further secure the connection. So, not only does the ISA firewall prevent attacks from hiding in an SSL tunnel through the firewall, you can prevent any unauthenticated and unauthorized connection to the front-end Exchange Server.

"2. Scrap the ISA server, I think the front end server should be on the web DMZ. Does everyone agree with this? Yes, I know I have to open up all those nasty MS ports but at least I can restrict it to talking to the DC's and a few other boxes - those would be hardened machines anyways."

This is really bad. Placing only a basic stateful packet inspection firewall in front of the front-end Exchange Server allows non-authenticated, non-authorized and non-inspected (at the application layer) connections to the Exchange Server's Web services.

This also shows a lack of concern over the overall security infrastructure, if he's willing to open the ports for intradomain communications instead of providing a good security solution, which is the ISA firewall. He ignores the advantages conferred by putting the ISA firewall behind the Checkpoint firewall, between the front-end Exchange Server and the Checkpoint firewall, not only for strong inbound access control and protocol inspection, but also for strong user/group based access control for all protocols by using the ISA firewall on the back-end.

"3. I think the Microsoft admin should just run a front end server internally and also another front end server on the web DMZ. That way, you can harden the web DMZ machine properly but don't have to worry about the one that's only for internal use (ok not too much worry). Make sense?"

No, it doesn't make sense.

Notice the pattern of thinking and rationalizing here. This actually isn't that unusual. What we have here is someone who doesn't understand the ISA firewall, and doesn't want to understand it. So, rather than making a due diligence attempt to understand the ISA firewall and the technologies used by the ISA firewall to provide a very secure remote access solution to Microsoft Exchange, he comes up with a bunch of low security options.

In and of itself, this doesn't make sense. But if you look at this in the context of someone who has a bias against Microsoft security technologies, perhaps an knowledge deficit regarding how firewalls and proxy works, and perhaps even a knowledge challenge regarding how to configure his current firewall solution, it all begins to make sense.

The key to getting your way with these non-ISA firewall admins is to be patient with them. While many of them might have an anti-Microsoft bias, this isn't always the case. Some of them just don't understand the importance of application layer inspection and they don't understand what the ISA firewall brings to the table when it comes to a strong defense in depth posture when providing secure remote access to Microsoft Exchange Servers and services.

If you find yourself in a similar situation where you want to bring an ISA firewall in to protect Microsoft Exchange, some things you can bring up are:

• The ISA firewall's Secure Exchange RPC filter that enforces protocol compliance on RPC communications between Outlook clients and Microsoft Exchange
• SSL to SSL bridging, which provides a secure end to end SSL connection, but also prevents attackers from hiding exploits in an SSL tunnel through the firewall
• Forms based authentication, which allows the ISA firewall to generate the form. The removes the requirement for allowing anonymous connections to the Exchange Server, and also allows you to enforce security policy on the OWA client
• The HTTP Security filter. You can configure the HTTP Security filter on the ISA firewall to block methods, headers, bodies and other aspects of an HTTP communications that are inappropriate when connecting to Exchange Server's Web services. Only known good commands and data are allowed to and from the Exchange Server
• Pre-authentication and authorization. The ISA firewall can authenticate users, and then authorize them before a connection to an Exchange Server's services is allowed. This prevents attacks from anonymous users, or users that authenticate but should not be accessing the Exchange Server from remote locations. RADIUS authentication can be used for ISA firewalls that aren't part of a Windows domain.
• Built in support for SecurID two-factor authentication. If you SecurID in place, you can take advantage of SecurID two-factor authentication to authenticate incoming connections to the OWA Web site.

Once the non-ISA firewall admin gets in tune with the security advantages conferred by these technologies, you'll find that not only will they be less resistant but they might even want to take over the management of the ISA firewall!