Exchange Deployment and ISA Firewall Nightmare Scenarios — Getting to Know the "Nightmare on Exchange Street" and "Hork Mode Sandwich" Scenarios
If there were an award for putting together the worst possible security design for an Exchange Server organization, which topology do you think would win? In my experience, something I call the Exchange Publishing Nightmare Scenarios because they represent the worst case scenarios for network security when deploying an ISA Firewall to secure Exchange Web services. The figure below shows the topology for one version the Exchange Publishing Nightmare scenario. We’ll call this the Nightmare on Exchange Street scenario.
Figure 2
In the Exchange Publishing Nightmare Scenario the ISA Firewall is separated from the internal network by a third party firewall and from the external network by another third party firewall. As seen in the figure above, there are two “hardware” firewalls deployed, one on the edge of the corporate network and a backend firewall in front of the corpnet. A DMZ segment is seen on the back end “hardware” firewall where a single NIC “hork mode” ISA Firewall is deployed. There are several serious defects in this design:
- The back-end “hardware” firewall represents unnecessary point of failure
- The back-end “hardware” firewall represents another opportunity for firewall misconfiguration – the most common cause of firewall related security issues
- The ISA Firewall is subjected to the security weaknesses of the back-end “hardware” firewall. A quick look at www.secunia.com shows that the ISA Firewall (2004 and 2006) have no active security issues. Compare this with any “hardware” firewall and you will see that the ISA Firewall is more secure than just about any hardware firewall
A variant of this Exchange Publishing Nightmare Scenario places a hork mode ISA Firewall in the DMZ between the “hardware” firewalls, something that I refer to as the Hork Mode Sandwich scenario.
The problem with the Hork Mode Sandwich and the Nightmare on Exchange Street scenarios is that the full firewall feature set is gutted from the ISA Firewall when deployed in hork mode. There is no technical reason for this type of deployment. The only reasons for such a deployment would be political or ignorance. If you need or want to use a back to back Firewall deployment, then place the ISA Firewall closest to the resources that need protection, as the most secure firewall should be nearest the protected resource, and the ISA Firewall is most likely the most secure firewall in this scenario.
I’ve heard excuses that “the customer wants to do it this way”. That is not an acceptable excuse. Would you give a child a loaded gun to play with just because he wanted it? Would you hand a kid a stick of dynamite and a match because he likes to blow things up? Of course not. You use your superior knowledge of guns and explosives (at least compared to the child’s understanding) to protect the child.
In the area of Exchange security using the ISA Firewall, you are the expert and it is your responsibility to protect the customer from poor security designs, regardless of what the customer “thinks” he wants.
I’m fortunate because I can turn down customers who want to harpoon their network security due to their lack of understand of strong network security principles and the ISA Firewall. If you’re not as lucky as me, and you are forced to deploy desultory security designs such as the Nightmare on Exchange Street and Hork Mode Sandwich scenarios, then protect yourself from both a moral and potentially legal front by having the customer sign a release statement that releases you from responsibility for security breaches due to the poor security design demanded by the customer. You’ll be glad you did.
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)
Chris Says:
August 30th, 2007 at 12:04 pm
If only the world was as simple as Tom explains. I am in a scenario where the ISA servers are performing the role of the original ISA product, Proxy Services. While the firewall capabilities of ISA are in fact fantastic, the Proxy capabilities are just as excellent. In my scenario the customer wanted a proxy server that could provide reverse proxy services. The customer already has an established FE/BE firewall solution in place and would not want to re-engineer the firewall solution to simply provide proxy services.
So in this instance a “Hork Mode” ISA server works exceptionally well ( not to mention that the ISA firewall capabilities still apply to the localhost ). Unless Microsoft releases a dedicated Proxy Server in addition to ISA Server then the unihomed ISA server will still have a place in the enterprise.
Cheers!
the capslock assassin » Blog Archive » Tom Shinder on "hardware" firewalls Says:
August 30th, 2007 at 10:19 pm
[…] Tom Shinder of ISAServer.org takes an amusing shot at the myth in some circles that a “hardware” firewall or “firewall appliance” offers more security than a Microsoft ISA Server firewall. […]
Mylo Says:
September 7th, 2007 at 4:22 pm
Chris,
I’ve seen the FE/BE scenarios you describe as well, and it may be often more politically expedient in allowing the uni-homed solution allowing to pass. The point is though, simply using the ISA as a reverse proxy either as a stand-alone server or a domain member in the DMZ does it and security a disservice twofold:
(a) if it’s a stand-alone ISA server in a DMZ it’s not capitalising on the “real” proxy capabilities that come about via domain membership with ISA “fronting” the connection in the BE role; constrained delegation etc.
(b) if it is a domain member in the DMZ, chances are you’re making swiss cheese out of your BE firewall anyway by passing all the Windows protocols out of the DMZ from ISA just to sustain that model.
The irony is that this sort of setup ends up diluting security and it’s quite common in large organisations, sustained by the belief that hardware/appliance firewalls are safer. Both FE and BE need to do ALF and fork the traffic according to what it is. If it’s MS traffic use ISA as the BE.
Cheers,
Mylo
Chris Says:
September 7th, 2007 at 11:32 pm
Interesting comment Mylo. I have to say you make great points but, of course, I have my own thoughts also. In our scenario the ISA server is a domain member in the DMZ to provide the Kerberos Constrained Delegation in the Web Publishing that we are providing. The swiss cheese you are talking about is really only for traffic coming out of the heavily secure ISA server to the Domain Controllers and web servers. While not as secure as only allowing 443 through the back end firewall, it is still far better than to put the web server in the DMZ since the ISA server still uses the excellent firewall services to protect itself. I don’t agree that we are diluting security, rather we are leveraging exactly what the ISA product group had in mind when they gave the option of using a unihomed ISA server (hence the available template).
And let us not forget that in my environment politics rule and we can only push for so much before we are stepping on the wrong toes…
Cheers!
Mylo Says:
September 8th, 2007 at 9:55 am
Hi Chris,
You make some good points and agreed it’s absolutely better than slapping the web server in the DMZ. I’m kind of glad you mention it’s a domain member and using KCD. It’s better than the stand-alone ISA scenario. Just not sure whether all those Windows protocols should be floating round the DMZ before they tunnel thru your firewall to your DC (LDAP, RPC etc)
Good luck with pushing the boundaries and re-educating a few souls
Regards,
Mylo