Re: Front End/Back End communication
- From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
- Date: Tue, 16 May 2006 21:23:48 -0700
This is great advise, and provides some really solid security benefits. I
wish more people thought like this...
Taking all of Devin's ideas into consideration, one can also use ISA Server
2004 (2006) to further extend the "protected network" segment concept to
provide an even more robust posture in a Back-to-Back ISA DMZ topology
utilizing a perimeter network relationship on the "internal" facing ISA
Server. Consider the following illustration:
Internet
|
External ISA Server
|
DMZ Assets (SMTP Gateway, DNS, Customer Web/SQL, Etc)
|
Internal ISA Server *--> [Perimeter Network Segment for FE Exchange]*
|
Internal Network
This topology extends the protected network "out," allowing you to
encapsulate the FE Exchange Server into it's own perimeter network segment
while still isolating that box to the DMZ (The above "Perimeter" segment
represents a separate segment off the Internal ISA Server).
Initially, the benefits of the FE Exchange Server in the DMZ are
counter-intuitive. I think this is because, ironically enough, one strives
to totally protect all "trusted" assets- thus the default instinctive action
to "bring the FE into our protected network." It for this very reason that
I believe we should further protect the FE Exchange Server: if that asset is
compromised, the potential risk of further internal compromise is greatly
escalated due to its trusted role in the infrastructure - particularly when
the FE is located on the internal network with typical full-stack access to
the rest of the network. Since we, by design, offer OWA access from the web,
we basically extend an interface from an untrusted network to an asset on
the internal network in the standard publishing model (even given the
"non-swiss cheese" application filters used in ISA publishing)
Thus, it stands to reason that an asset important enough to be protected by
the internal "protected network" should be even better protected in an
environment where only the necessary services/protocols are allowed in to
the "real" network. Particularly when the service is extended to the web.
The "real-world" communication requirements for "proper" (meaning "secure")
FE operations are quite overstated, even in the Microsoft documentation.
You can deploy an Exchange FE server in the DMZ with minimal firewall rules.
Here is all that is necessary:
Rules to support *only* the Perimeter network box to *only* the internal
Domain Controllers object for:
DNS (both TCP 53 and UDP 53 as Exchange uses both for DNS lookups)
Kerberos-Sec* (UDP 88)
[*This is the big one. Most documents will have you open up Kerberos-Adm
(both UDP and TCP 749), Kerberos-Sec TCP (88), Kerberos-IV (UDP 750) as well
as CIFS and RPC in BOTH freaking directions. None of this is required.]
LDAP (TCP and UDP 389)
LDAP GP* (TCP 3268)
[LDAP is only necessary if you need Global Catalog access from the box]
These rules need only be INBOUND rules from the perimeter to the internal
network. The established return traffic will suffice.
This minimal rule-set will allow the FE Exchange Server to function
perfectly without having to allow all the other authentication/NetBIOS
traffic in/out. NOTE: This will not allow you to manage the FE Exchange
Server from the internal network via the Services Manager MMC (or any other
means) as no OUTBOUND traffic for these protocols is allowed. This is a
_good_ thing... You *NEVER* want to allow authentication protocols to
*leave* your network. That's just silly. You should manage the box via
RDP (requires an OUTBOUND only rule to just that box) outbound. The creds
are encrypted, and all traffic is on your RDP port (typically 3389.)
Microsoft was smart enough to build redundant protocol usage into
authentication protocols. CIFS, RDP, Kerberos-SEC TCP, etc may be a bit
quicker, but if you prevent them from being accessible, FE to DC
authentication will be forced to use UDP 88 exclusively.
Now, you need rules to support *only* the Perimeter network box to *only*
the internal back-end Exchange servers that house the mailboxes the OWA
users must access: it is a "good news, bad news" scenario.
Good news is that it is only HTTP for mail delivery to the FE client. Bad
news is that it is *only* HTTP ;) HTTPS for FE to BE communications is not
supported (won't work at all) even though Ex2k3 allows you to choose the
authenticaion method to be basic, digest, integrated, or whatever that other
one is that I can't remember right now. Mail data gets pumped out over HTTP,
and HTTP only (even if the client-to-FE is HTTPS.)
The OP was exactly right in his concern regarding mail traffic being exposed
to the internal network for all FE to BE *mail* traffic (but not
authentication traffic, that is Kerberos). It's all in the clear. You now
DO want to use IPSec to encrypt the HTTP traffic between the Fe and the BE.
But that is OK... The Internal ISA Server will already be an member of the
internal Domain (protected by the External ISA Server) so certs are not an
issue. Since the network segment of the Perimeter segment has a ROUTE
relationship to the INTERNAL network, you don't have to worry about NAT
traffic. The beauty is, you still have a NAT relationship between the
EXTERNAL (which, to the Internal ISA box is the DMZ) network and the
INTERNAL network.
There is detailed information regarding this topology on ISASERVER.ORG,
which rocks. Additionally, Jim Harrison and I are leading a 2 day training
at the Vegas Blackhat specifically on ISA configurations for those who are
interested.
Thought I would give just an overview of a different configuration.
Thanks.
T
On 5/15/06 4:28 PM, "Devin Ganger" <DevinG@xxxxxxxxxx> spoketh to all:
Better yet, get an ISA Server 2004 box and put *that* in your DMZ. Then
you can move the FE back to the protected network where it belongs, with
all of the advantages:
1) You can easily apply a single IPsec policy via Group Policies for
your Exchange servers. Any new Exchange servers you stand up in the
future will automatically use IPSec just by being a member of the
correct OU.
2) Your firewall configuration between the DMZ and protected network
stops resembling Swiss cheese, as you can close down the holes for
Kerberos, LDAP, GC lookups, SMB, DNS, SMTP, MAPI, and more.
3) You get an application-level proxy that filters incoming SMTP and
HTTP requests and drops malformed/corrupt ones on the floor before they
ever get to your Exchange server.
Microsoft publishes some good guidance on the various FE/BE options and
their security implications. The first guide you should read (if you
haven't already) is the _Exchange Server 2003 and Exchange 2000 Server
Front-End and Back-End Topology_ guide:
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/febet
op.mspx
---------------------------------------------------------------------------
---------------------------------------------------------------------------
- Follow-Ups:
- Re: Front End/Back End communication
- From: Devin Ganger
- Re: Front End/Back End communication
- References:
- RE: Front End/Back End communication
- From: Devin Ganger
- RE: Front End/Back End communication
- Prev by Date: SecurityFocus Microsoft Newsletter #291
- Next by Date: Re: Front End/Back End communication
- Previous by thread: RE: Front End/Back End communication
- Next by thread: Re: Front End/Back End communication
- Index(es):
Relevant Pages
|
