EDIT: this post was edited on 9/25/2007 to clarify information related to the hotfix mentioned in KB 937031. Thanks to Vanitha for the edit! As we mention in Exchange 2007 documentation, the...
Updated Jul 01, 2019
Version 2.0
Blog Post
2 MIN READ
Maintaining ActiveSync access to Exchange 2003 mailboxes after deployment of Exchange Server 2007 CAS role
The fact that the CAS isn't within a sandwich of firewalls (ie: a DMZ perimeter network) seems very concerning to me. I know that an ISA will in theory filter via proxying any threats, but what if it's some sort of new zero day buffer overflow attack?
I assume that at some level of the data the HTTP/HTTPS requests are forwarded verbatim through the ISA proxying to the CAS. If some new attack on the CAS were found with some sort of constructed known HTTP(S) payload, not yet known to ISA developers, it could be forwarded to the CAS via the ISA and a compromise happen.
Yes, there are a number of mitigating difficulties for an attacker, but this scenario seems relatively plausible and given what a high value target CAS servers might be to a hacker, it might be well worth one's effort.
With the CAS on the inside with no further firewalling, clearly this would place the rest of your networks wide open for attack.
I'm not sure why the CAS can't (shouldn't) be firewalled and/or why there aren't instructions to do so. We use a enterprise class firewall that has 5gb of throughput, so in theory the high bandwidth requirements could be met. Anything can and should be firewall-able. This is what host intrusion prevention is often about. It should just be a case of defining the required ports and making sure sufficient bandwidth/performance exists through the firewall.
I suppose one option would be to place the entire Exchange infrastructure in a DMZ, including Mailbox Server, Hub Transport Server, and Client Access Server and just pinhole the Exchange services into that, leaving access between the Exchange components wide open. Is this what some do?
Really, putting the CAS on the inside gives me the willies. It doesn't seem "best practice" at all to me.
I assume that at some level of the data the HTTP/HTTPS requests are forwarded verbatim through the ISA proxying to the CAS. If some new attack on the CAS were found with some sort of constructed known HTTP(S) payload, not yet known to ISA developers, it could be forwarded to the CAS via the ISA and a compromise happen.
Yes, there are a number of mitigating difficulties for an attacker, but this scenario seems relatively plausible and given what a high value target CAS servers might be to a hacker, it might be well worth one's effort.
With the CAS on the inside with no further firewalling, clearly this would place the rest of your networks wide open for attack.
I'm not sure why the CAS can't (shouldn't) be firewalled and/or why there aren't instructions to do so. We use a enterprise class firewall that has 5gb of throughput, so in theory the high bandwidth requirements could be met. Anything can and should be firewall-able. This is what host intrusion prevention is often about. It should just be a case of defining the required ports and making sure sufficient bandwidth/performance exists through the firewall.
I suppose one option would be to place the entire Exchange infrastructure in a DMZ, including Mailbox Server, Hub Transport Server, and Client Access Server and just pinhole the Exchange services into that, leaving access between the Exchange components wide open. Is this what some do?
Really, putting the CAS on the inside gives me the willies. It doesn't seem "best practice" at all to me.