Comments on: Exchange Deployment and ISA Firewall Nightmare Scenarios — Getting to Know the "Nightmare on Exchange Street" and "Hork Mode Sandwich" Scenarios http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/ Written by Dr Thomas W Shinder, consultant to Microsoft, HP and many Fortune 500 companies on ISA firewall and Web proxy deployments this blog is where administrators get information about ISA Server Universal Threat Management firewalls. Topics include how to manage, deploy, and troubleshoot ISA Server as a network firewall, Web proxy/Web cache, remote access VPN server and VPN gateway to provide a high level of network security for all corporate computers. Fri, 21 Nov 2008 06:16:34 +0000 http://wordpress.org/?v=MU by: Mylo http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118480 Sat, 08 Sep 2007 15:55:49 +0000 http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118480 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 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

]]> by: Chris http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118417 Sat, 08 Sep 2007 05:32:18 +0000 http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118417 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! 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!

]]> by: Mylo http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118354 Fri, 07 Sep 2007 22:22:22 +0000 http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-118354 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,

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

]]> by: the capslock assassin » Blog Archive » Tom Shinder on "hardware" firewalls http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-116421 Fri, 31 Aug 2007 04:19:18 +0000 http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-116421 [...] 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. [...] […] 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. […]

]]> by: Chris http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-116287 Thu, 30 Aug 2007 18:04:13 +0000 http://blogs.isaserver.org/shinder/2007/08/29/exchange-deployment-and-isa-firewall-nightmare-scenarios-getting-to-know-the-nightmare-on-exchange-street-and-hork-mode-sandwich-scenarios/#comment-116287 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! 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!

]]>