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)
