The point is though - to put a firewall between Exchange servers requires so 
many ports to be open, not only to all the other Exchange servers, but also to 
the domain controllers, that the firewall between the machines becomes 
practically useless.

I do a lot of deployment for financial services clients - where they have more 
network security people than IT staff. Usually when I go in there, they have 
read about Exchange and want to put the frontend server (on Exchange 2003) or 
the CAS in their DMZ because they have a policy of no internal machines facing 
the internet. Fair enough - a good policy to have. I end that request by simply 
asking for port 135 to be open from the internal network to the less-secure 
network. No network security person is going to allow that, and I am asked for 
an alternative - and I usually suggest ISA.

On your second paragraph, which you have asked Ed to read again, the fact that 
the two servers are not in the same network doesn't really matter. CAS and the 
mailbox servers need to communicate. As there are other ports open to other 
servers on the network (ie domain controllers) then an attacker can simply use 
another server as a proxy. If an attacker is that determined to get in, the 
fact that you have a firewall splitting up two machines that are members of the 
same forest isn't really going to phase him.
As far as I am concerned, the only way a DMZ type network is secure is when the 
machines in the DMZ are not members of the internal domain. That rules out 
placing any other role other than Edge in a DMZ type network.

The other point I think is worth making is the pure financial one. Considering 
that you would need to have a CAS on the internal network to serve internal 
clients, that would mean purchasing an additional Exchange 2007 license and 
hardware. Instead buy an ISA license and use that instead.

I stand by my previous statements, and while you have had a good attempt, I am 
still yet to be given a good argument about why putting an Exchange server 
(that is a member of the domain) in a DMZ type network is a good idea.

Simon.

--
Simon Butler
MVP: Exchange, MCSE
Amset IT Solutions Ltd.

e: [EMAIL PROTECTED]
w: www.amset.co.uk
w: www.amset.info

Need cheap certificates for Exchange, compatible with Windows Mobile 5.0?
http://CertificatesForExchange.com/ for certificates from just $23.99.
Need a domain for your certificate? http://DomainsForExchange.net/





-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Cunningham
Sent: 02 May 2008 00:27
To: Exchange Discussions
Subject: RE: Exchange 2007 questions

Hi Simon,

Firstly, I don't really care if it is a CAS, frontend or OWA. What I do
care about is people that dis a DMZ option with a preconceived idea of
what a DMZ is. A DMZ can be many things. You propose that a DMZ is a
place for sacrificial devices, that is not necessarily so. You blog is
all based on a traditional DMZ premise, which is where it is lacking in
concept. E.g. some organizations use internal DMZs to protect themselves
from the internal masses.

Secondly, look at how I said it was in a DMZ, it is the only server in
that DMZ. So no cross pollenisation between infected DMZ servers is
possible (ie. The web and mail servers in the same DMZ) unless the rules
allow it. If I said it was best practice to run the CAS internally and
put a firewall on the server and lock the ports down, you would probably
say that was a good idea? Well my proposal of a DMZ is exactly that,
believe it or not.... but a hell of  a lot easier to manage.

Thirdly, I'll repeat what I said, but generalize it.
If you leave your <insert your internet facing server here> internal and
it is compromised, whatever compromised it has all 64k network ports to
probe your network and look for vulnerabilities. If your <insert your
internet facing server here> is in its own DMZ and it is compromised
then whatever has compromised it only has access to the ports the
firewall has allowed the <insert your internet facing server here> to.

So as an example you run your CAS server in the DMZ a Trojan compromises
the server via an HTTPS vulnerability and is multi facetted and is able
to scan for SQL server, network share, HTPP/HTTPs vlunerabilites and
Cisco and Nortel DOS just for fun. In the DMZ none of these scans will
be successful (apart from the Nortel switch you are using for your DMZ
;-) ). With the CAS on the internal network, these scans are likely to
succeed, depending on the patch level of your network devices.

As to whether MS supports it or not is just another risk to assess. As
an example there are tens of thousands of people that run MS software on
VMWare, which is not supported by MS.

At the end of the day it comes down to each persons perceived level of
risk/benefit and how they wish to address that. I am not recommending
one way or the other what I am recommending is both options are
considered and both eyes are open.

HTH
Dean


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Butler
Sent: Thursday, 1 May 2008 20:13
To: Exchange Discussions
Subject: RE: Exchange 2007 questions

CAS in the DMZ isn't supported. The only role that is supported in a DMZ
is Edge. If you want something in a protected network for http traffic
then ISA or similar product is your only choice.

While a frontend server was tolerated (despite it making no difference
to the security of the network) Microsoft have decided that they will
not support that type of configuration in the future.

I would have to disagree with you Dean that CAS would be better in the
DMZ. If the machine is compromised it doesn't help because you have to
open access to the domain controllers, so all an attacker has to do is
follow the traffic. I blogged on why Exchange in a DMZ is a bad idea two
years ago: http://www.sembee.co.uk/archive/2006/02/23/7.aspx and still
to date no one has given me a sound reason why putting any Exchange
server in a DMZ is a good idea (except for Edge which is designed to).

Simon.


--
Simon Butler
MVP: Exchange, MCSE
Amset IT Solutions Ltd.

e: [EMAIL PROTECTED]
w: www.amset.co.uk
w: www.amset.info


**********************************************************************
                         Have you clicked on yet?
                              www.nrc.govt.nz
**********************************************************************
NORTHLAND REGIONAL COUNCIL

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
[EMAIL PROTECTED]
**********************************************************************

_________________________________________________________________
List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange
To subscribe: http://e-newsletters.internet.com/discussionlists.html/
To unsubscribe send a blank email to [EMAIL PROTECTED]
Exchange List admin:    [EMAIL PROTECTED]
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016

Please include the email address which you have been contacted with.


_________________________________________________________________
List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange
To subscribe: http://e-newsletters.internet.com/discussionlists.html/
To unsubscribe send a blank email to [EMAIL PROTECTED]
Exchange List admin:    [EMAIL PROTECTED]
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016

Please include the email address which you have been contacted with.

Reply via email to