moving exchange to a DMZ

Smallguy

Hi

I was asked a question from out infrastructure guy and just wanted some confirmation on it

he wants to move our exchange box to a DMZ since it is our only publicly accessibility box which is not in a DMZ

this means changing it's IP as well form lets say 10.10.10.156 to 172.16.0.3 (just examples)

now i know that internally we will need to hvange the host record to reflect that ip change but how will the clients handle this

I know they will look for email.mydomain.com as per there exchange settings but is it possible that the clients will have records cached still pointing to the 10.10.10.0 network instead of the 172.16.0.0 network

it's something that if we do it will probably end up being labbed just to over everything

but I wanted to see if my line of thinking was correct that if the host records are updated the clients should find the server with a different IP

CoryS

I recently did this in my test lab with Exchange 2007 as I was getting ready for a new site design.. As long as you update your A records accordingly you should be good to go, remember though if you are using 07 that you update your Autodiscover record as well, and make sure everything is routeable with your network layout. If you have the luxury of a lab like you said, go ahead and plow through it a couple times so you can do it in your sleep when you are going to apply changes to your production side.

Also you may need to do an ipconfig /flushdns on some machines if they are using stale records, I got caught by this the other day early in the morning before I had a chance for some coffee sometimes the easy stuff bites you in the bum.

Of course, if any of what I say is inaccurate or confusing please dont hesitate to critique or ask for clarification.

HTH

Smallguy

we are running exchange 2k3

my plan is to try and lab it


I did read over on msexchange that this is a bad idea for security but I'll need to see exactly ho our guy plans on doing this since he is pretty security conscious

royal

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.

Turgon

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.

Or you could consider a hardened exim mailer in the DMZ and have that forward mail onto your internal server. I found that worked well to keep the mailserver out of the DMZ in the past.

HeroPsycho

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!

Turgon

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!

Hardening the OS your mailer runs on will help to some extent.

We never bothered with OWA at our shop so it worked just fine for onsite send and receive mail. A nice place to buffer mail as well when we had Exchange maintenence, and useful spam filters.

HeroPsycho

A smart host is definitely the way to go for mail delivery. It should also be running anti-spam and anti-virus software.

In reality, the optimum design for Exchange 2003 is as follows:



You would then have a third NIC off the ISA Server(s) that connect to an isolated DMZ, and put your SMTP Smarthosts in that network, publish them to the External network (Internet), and then allow access to and from the SMTP smart hosts to your internal mail servers/gateway server. You would also need access rules from your internal gateway/mail servers to the smart hosts, and the smart host to the internet.

In this design, even your smart hosts would benefit from SMTP application/protocol layer filtering within ISA, the front ends would be securely published to the internet with application layer filtering provided by ISA inspecting even within SSL encrypted tunnels, and access between the DMZ and internal network is minimal.

I would also put a PIX or some other hardware ASIC proc packet filter running something other than Windows in front of the ISA server, too. It would more efficiently filter most BS traffic that would be dropped than ISA does, and that way your firewalls don't have a common core OS vulnerability.

blargoe

If your infrastructure guy saw everything that 2003 OWA has to have in order to live in the DMZ, he would change his tune pretty quick. It MUST be a domain member. 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. I forget.

ISA is the correct answer. You can configure ISA to be THE front end exchange server, if you wanted to.

royal

blargoe wrote:

You can configure ISA to be THE front end exchange server, if you wanted to.

One thing to keep in mind about this, is if you have multiple BE servers, you still need a FE for routing intelligence which ISA can't do.

HeroPsycho

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.

53 (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) - Domain Name System (DNS).
• 80 (TCP) - Required for Outlook Web Access access for communication between front-end and back-end Exchange servers.
• 88 (Transmission Control Protocol [TCP], UDP) - Kerberos authentication.
• 123 (UDP) - Windows Time Synchronization Protocol (NTP). This is not required for Windows 2000 logon capability. However, it may be configured or required by the network administrator.
• 135 (TCP) - EndPointMapper.
• 389 (TCP, UDP) - Lightweight Directory Access Protocol (LDAP).
• 445 (TCP) - Server message block (SMB) for Netlogon, LDAP conversion, and Microsoft Distributed File System (DFS) discovery.
• 3268 (TCP) - LDAP to global catalog servers.
• One port for the Active Directory logon and directory replication interface (universally unique identifiers [UUIDs] 12345678-1234-abcd-ef00-01234567cffb and 3514235-4b06-11d1-ab04-00c04fc2dcd2). This is typically assigned port 1025 or 1026 during startup. This value is not set in the DSProxy or System Attendant (MAD) source code. Therefore, you must map the port in the registry on any domain controllers that the Exchange server must contact through the firewall to process logons. Then, open the port on the firewall.

http://support.microsoft.com/kb/270836

Translation: you need to borrow Calvin's transmogrifier to turn your firewall to swiss cheese.

Also, note in the above article concerning Exchange 2007...

"In this article, the process for static port mapping for Exchange Server 2003 and Exchange 2000 Server still works in Exchange 2007. However, installation of a Client Access server in a perimeter network is not supported. It is not supported to put a Client Access Server in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet), or in any configuration with a firewall between it and the mailbox or domain controllers."

famosbrown

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

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 FE, use ISA instead. It protects better than a front end would.

famosbrown

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.

Your opinion...but I would use FE/BE since that setup is Best Practice for Exchange Server OWA access from the outside. I would also recommend this if you aren't knowledgeable about ISA. To be honest, I've never been in an environment that even uses ISA...usually hardware Firewalls/Proxies.

HeroPsycho

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.

famosbrown

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.

Looks like you've done some research...or you just know it off of the top of your head . I'm not bashing ISA, but I wouldn't recommend it unless you have a SME (Subject Matter Expert) on ISA. I also must note that ISA is definitely SOFTWARE and has vulnerabilties. It also sits on a Windows OS that has known vulnerabilities too. My instructor actually showed us a few things that were used to attack ISA...now they are patched up, but I'm sure there are others out there not found yet. Of course, nothing is FULLY secure.

As far as other security devices...I've never been in an organization where we lacked SME's for Cisco and Security devices, so maybe my opinion is biased because of that. ISA on the other hand, I just haven't seen it, and it being software just kind of scares me. Might be a bad example, but it's like telling users to depend on their Windows Firewall for XP and don't worry about securing that hardware router connecting them to the internet.

Again, we all have our opinions, and although you have implemented and seen ISA in many places, I have yet to see it...not even working for one the largest government agencies in the U.S. Hardware IDS's, Sniffers, and firewalls/proxies are some of the main devices I've seen, and accomplish all of the advantages you listed that a simple FE sitting out facing the internet with no other protection would not have (who would have an FE out there like that anyway ) . Maybe the devices in the past couldn't, but like you said "some here and there" does.

Here is a link describing ISA 2000 working with Exchange and some other security methods for Remote Access to Exchange.

http://www.tacteam.net/isaserverorg/exchangekit/bettertogether/bettertogether.htm


After doing a little bit of reading, I change my recommedation. Implemet both hardware and software security hardening to protect your OWA. Not only use ISA/FE/BE, use some hardware IDS, firewalls, packet sniffers, etc.

Maybe that will make everyone happy ?

HeroPsycho

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.

blargoe

Yes ISA is software. But so is Exchange. Either you have your PIX set up to translate inbound connections to the ISA front end in the DMZ, or to the Exchange front end on the LAN. Either way, once it passes the translation and is accepted as a valid packet, it's going to be an SMTP, HTTP, or POP connection directly to software.

famosbrown

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.

Well...I will have to read through your entire post a little later, but I did skim. I can and will not give examples of appliances used as that would be irresponsible and would give a potential attacker more information and leverage in attacking. I don't have the exact number, but we get at least 100K hack attempts per day...or maybe it was a million+... I can't recall what the Security Manager briefed me on. Internet browsing is one of the best tools for vulnerability discovery.

After reading more about ISA, I do see it is a good piece of software, and I've only been exposed to it in classroom labs and reading. I'm not afraid of it...maybe a bad term to use...but I've seen some vulnerabilities in it and the OS during the CEH course. Maybe it wasn't configured correctly when he demonstrated...I sure would have never known. And come on, are you really going to put your faith in SCW to fully secure your OS ? I'm not even sure if the original poster even has more than one back end server, or if he is even reading this thread anymore. I still stick with a FE/BE configuration for OWA access on the outside. I never agreed or disagreed with having an ISA instead of a FE for one backend server. I've never had the luxury of having just one backend server to even imagine it. I'm certified in Exchange Server 2003 as well, but I admit I don't know it all...brain would be dead if I did. I'm not certified in ISA and won't ever be unless the business need arise and/or I run into a situation when it will have to be used. Maybe I can re-evalutate the security of my new messaging environment and see if I can make some recommendations to take a look at it and see how much money and time we would save to train efficiently and implement to software to suit our needs. Who knows?

HeroPsycho

Blargoe,

Not sure what you meant in your post. Remember that if it goes to an Exchange front end server from the PIX, you're right, it's going to software without any further examination since the packets that make it to the front end are packets permitted by the PIX.

If it's going to ISA, just because the packet matches the right port number, it doesn't necessarily get passed in to the Exchange server. The packet is scrutinized far more heavily by ISA than a front end server ever would. That's the whole reason why ISA is a good choice.

Not sure if you were agreeing with me or not, but just clarifying it.

famosbrown,

I'm not asking for you to tell me what appliances you use. I asked you to tell me what product does what ISA does. Again, I am not aware of any product that does all that ISA does, and protects potentially from all the attacks ISA would be able to sense and stop that a packet filtering firewall even with SPI won't.

As for trusting SCW, all it does is do what you used to do manually more efficiently. I still verify the ISA server is properly hardened afterwards. If I were a linux admin, I sure as heck wouldn't turn off services manually; I'd use a script. What's the difference aside from working smarter, not harder? Even with scripts in that situation, I'd audit (or preferably get someone else to audit) the server to ensure I didn't miss anything, or the script/SCW did it's job.

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

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.

I for one have always been a fan of ISA server, especially with the huge improvements in ISA 2004. Also, if you want to talk about exploits/vulnerabilities, the ISA has fewer than PIX, ASA, Gauntlet and several other enterprise class firewalls. I saw a comparison on a site that was vendor neutral and had loads of information on about a dozen major firewalls (for the life of me I can't find it now ) including the number of vulnerabilities found, patches, service packs, etc and ISA fared better than most (but not all).

For anyone that is interested, the CBT NUggets video series on ISA is very good, and the instructor is actually a die-hard Cisco guy. He gives a great, honest, and IMO accurate comparison of the ISA vs. Netscreen, ASA, and a couple other firewalls. He doesn't glorify the ISA but gives some real good reasons for using it. If you want to see an ISA fanatic (who goes a little overboard in touting it's greatness) check out Tom Shinder's site at isaserver.org. Lots of great information there.

However, ISA is not the end-all for all situations. You are correct that ISA is the best way to protect Exchange (they were built from the ground up to do that, at least ISA 2004) but you cannot say that it's the absolute best way in an existing environment that does not have an ISA already deployed. You don't just "toss" and ISA server out into someone's existing infrastructure. You've got to take into account what they are currently using. 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.

ISA is a great product and I am all for it, especially in an Exchange Server situation, but let's keep our balance.

Besides, the OP actually only asked about DNS, so we have gotten way off topic.

HeroPsycho

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.

The PIX from my understanding does virtually no application layer inspection other than for SMTP with Mailguard.

I'm not sure about Netscreen or Guantlet, but I was not aware that they do SSL bridging.

What other products do SSL bridging. There aren't that many that I'm aware of. Not questioning what you're saying, I honestly want to know of some.