royal wrote: If he's that security conscious, get ISA and reverse proxy everything. Putting any Exchange in DMZ will still require you to open a bunch of ports to your back-end making the firewall swiss cheese. If you do this, put the Front-End in the DMZ, only allow IPSEC protocol to pass from FE to BE and set up IPSEC policies for all FE to BE communication.
HeroPsycho wrote: Yeah, but that doesn't help with secure OWA. There's very little point putting anything in the DMZ if you have to open virtually every port that hackers usually exploit into the Internal Network. ISA is the way to go!
blargoe wrote: You can configure ISA to be THE front end exchange server, if you wanted to.
blargoe wrote: So you would have to open Kerberos, NetBios, LDAP, HTTPS (also HTTP if you're doing ActiveSync), DNS, and SMTP at a minimum. Maybe more.
famosbrown wrote: If Security is really a big concern, I would recommend a FE/BE setup and host the OWA site on the FE server, with secure communications between the FE and BE. Outside clients access the FE through port 443 (And hopefully you are utilizing FBA), and allow the FE to do the rest for communicating with the BE. If internal clients for some reason needs OWA, just host one internal on the BE just for them.
HeroPsycho wrote: famosbrown wrote: If Security is really a big concern, I would recommend a FE/BE setup and host the OWA site on the FE server, with secure communications between the FE and BE. Outside clients access the FE through port 443 (And hopefully you are utilizing FBA), and allow the FE to do the rest for communicating with the BE. If internal clients for some reason needs OWA, just host one internal on the BE just for them. You however really do not need a FE/BE implementation if you only have one backend server. Instead of a more costly FE, use ISA instead. It protects better than a front end would.
HeroPsycho wrote: ISA is absolutely more secure than simply opening ports to a front end server. A front end server does absolutely nothing in application layer inspection at all, neither do hardware firewalls, aside from some here and there such as PIX's mailguard on SMTP. Other firewalls do not inspect and filter within an SSL tunnel. A front end is simply effectively a dumb proxy for OWA traffic with intelligence to determine the back end server for the user, and can do effectively SSL offloading from the backend. You should absolutely have one or more to figure out which backend a user is on if you have multiple back end servers, but with a single backend, you're better off with an ISA server than a front end if you had to choose. Obviously, it's even better to have ISA + Frontend + Backend, but if you had to, cut the front end out instead of ISA in a single backend configuration. ISA is specifically geared to be able to proxy the connection as a front end can serve to do in a single backend topology, but you do not need to turn any firewall to swiss cheese to do it. As a matter of fact, ISA could be the internal firewall. You can still do SSL offloading if you wanted to for whatever reason instead of keeping it encrypted all the way to the backend. It is much easier to breach a front end than ISA server. A front end doesn't guard against attacks against the HTTP protocol, does not limit access to only the virtual directories that are needed for OWA/OMA/ActiveSync, does not have protection against TCP/IP attacks such as SYN floods, does not have intrusion detection, does not have the ability to purchase AV add ons to inspect the web traffic that eventually hits the back end, cannot protect against IP spoofing attacks, does not have HTTP connection limits, is required to be a part of your domain yet is still being directly exposed to the internet traffic being forwarded to it without any inspection of that traffic aside from port number, and does not have the ability to extend the HTTP filter it doesn't have to prevent new attacks as they arise. I could go on with more advantages if you'd like. And FYI, Microsoft best practices are to use ISA to publish Exchange. As for advising not to deploy it if one doesn't have the knowledge, you deploy what you need to secure your environment. It's up to you to decide if you feel you need the additional protection ISA can provide over other solutions. However, saying don't deploy it if you don't know it is like saying don't deploy any firewall at all if you don't have experience with firewalls. My response to that is it's security suicide to not deploy a firewall regardless if you know how to deploy them or not. While not using ISA is less severe, if you need the additional security, you need it regardless if you know how to deploy it. That's what learning or hiring a knowledgeable person is for. I've run into lots of places with ISA 2000, 2004, and 2006 deployed, have also implemented and migrated many environments myself. Part of the reason it isn't more readily deployed is because there are ignorant assumptions about ISA and firewalls in general. People think firewalls are firewalls and don't appreciate the difference between what are essentially packet filters in most hardware firewalls and what ISA does. They also are honestly prejudiced against Microsoft and will not believe they made a product that goes above and beyond what an industry trusted PIX can do, even though ISA absolutely does.
HeroPsycho wrote: Yes, I know it off the top of my head. I'm certified in Exchange 2000, 2003, ISA 2004, and ISA 2006. A few things I wanted to respond to in your post: #1. Every case I've seen where an ISA server has been breached or a breach was demonstrated was when the ISA server was not properly hardened. Hardening an ISA server since it's running Windows is absolutely required. You'd have to do the same thing to a PIX if IOS was a general purpose OS, too. Microsoft has explicit documentation AND a Security Configuration Wizard profile to help you do this. #2. Saying ISA is a "software firewall" and a PIX isn't is not being genuinely honest. What do you mean by that exactly? A PIX has software in it, and there are vulnerabilities found in it that you have to patch. Any firewall has software in it. Do you mean it's not an appliance? If so, you can get ISA now in appliances, too. And what would that matter anyway? An "appliance" to most people means it's got no moving parts in it like hard drives, but it still has an OS, and is subject to vulnerabilities in that OS. The firewall portion of either a "hardware" or "software" firewall is a piece of code running on the unit, AKA software. #3. I've seen places with PIX's deployed with no SME's on site. I've seen ISA deployed with no SME's on site. You don't need SME's on site necessarily to have a well implemented and maintained firewall infrastructure unless you're constantly needing to make firewall policy changes. You need SME's to properly implement enterprise class firewalls. After that, you're usually fine aside from the occasional problem that turns up. In fact, maintaining ISA and getting reports or what not is far easier for the typical network admin than a PIX is. How do you patch an ISA server? Windows Update or WSUS. It's no different than any of your other Windows machine. How do you get reports? Go to the Monitoring node, click reports tab, and go through the wizard. How do you monitor connections? Go to the monitoring and easily select the filter rule you want if any. So get to know the product before you're scared of it. #4. Tell me which proxies you've used that literally decrypt inbound SSL traffic, inspect the traffic for application layer attacks, re-encrypt it, and send it to your Exchange server, and it's looking for attacks specific to OWA, authenticates you before a packet ever touches an Exchange server, and locks down which virtual directories packets can be sent to. On top of that, which proxies have you used where the HTTP filter can be extended with third party add ons or your own to prevent viruses, worms, etc. from hitting your Exchange servers even if the attack were done within an SSL tunnel. I'm not attacking you about this. I've been telling people ISA is the only one that can do all that, and I don't want to be lying about that point. Now, with all that said... I would not use ISA as an edge firewall. Three reasons: #1. "Hardware" firewalls that basically only do packet filtering based on ports do a very good job dropping most packets that hit it that would be blocked no matter what firewall you use on your edge. With their ASIC processors, they're very good at that. I like PIX or other similar firewalls, too. This would actually increase the performance of ISA behind it since ISA would only have to inspect the traffic being forwarded in. #2. It's better to have two firewalls with different core OS's than two with the same OS, or just one firewall. Now your infrastructure isn't relying on the security of one firewall OS and firewall code. #3. I don't like to judge the security of a product by which product is the most exploited because it's undeniable that the reason Windows is attacked the most is because it's the most prevalent OS out there. If Linux were to supplant Windows, it would be attacked more than Windows eventually. However, this would be a situation where you do have to take the fact that Windows is attacked more into consideration. Take the recent TCP/IP stack vulnerabilities within Windows as an example. Sure, this also happens to other firewall OS's, too, but the Windows one will surely be exploited in a shorter amount of time. And ISA since it uses a Windows TCP/IP stack would be vulnerable to that attack. Therefore, I wouldn't want my edge firewall to be something that uses Windows as an OS. Hence, my recommendation is and has always been to use something like a PIX on the edge, ISA behind it, then production network. In the case of ISA to inspect OWA traffic only, you don't even need to integrate ISA as an actual firewall where traffic literally routes through it. You can use ISA as a simple proxy server for this too. And one last question I have for you... Do you agree now that if you had just a single Exchange backend server that an ISA server would be better than a front end server if you had to pick one or the other? Again, my point on that was that ISA gives you far better protection, and honestly in that situation having a front end + ISA + Exchange isn't really gonna buy you much. You really only need ISA + the backend.
HeroPsycho wrote: Again, you can stick with a front end/back end config even in a single backend config if you desire. But it's less secure than using an ISA server in place of the front end, there's absolutely no question about that.
sprkymrk wrote: And ISA is not the only TRUE proxy/deep packet inspector/whizbang firewall out there. The PIX sure had it's short comings, but it was more than a packet filter. Symantec has some absolute great firewall products that have for years had excellent proxies and inspect each packet and actually tear down/rebuild rather than simply "pass" on traffic. Netscreen and Gauntlet are also far more than packet filters - they would not have the reputation they have today or been market leaders for this long if they had been simple packet filters that are "full of holes". There are also many vendors that will do SSL bridging to inspect the contents of such traffic better than or as good as ISA.
