RE: Front End/Back End communication
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- Date: Wed, 17 May 2006 19:51:40 -0500
Thomas W Shinder, M.D.
MVP -- ISA Firewalls
From: Devin Ganger [mailto:deving@xxxxxxxxxx]
Sent: Wednesday, May 17, 2006 2:31 PM
To: Thor (Hammer of God); timpacalypse@xxxxxxxxx; Focus-MS
Subject: Re: Front End/Back End communication
On 5/16/06 9:23 PM, "Thor (Hammer of God)"
Consider the following illustration:
<snip the FE perimeter description>
Initially, the benefits of the FE Exchange Server in the DMZ areenough, one strives
counter-intuitive. I think this is because, ironically
to totally protect all "trusted" assets- thus the defaultinstinctive action
to "bring the FE into our protected network." It for thisvery reason that
I believe we should further protect the FE Exchange Server:if that asset is
compromised, the potential risk of further internalcompromise is greatly
escalated due to its trusted role in the infrastructure -particularly when
the FE is located on the internal network with typicalfull-stack access to
the rest of the network.
I whole-heartedly agree with this in theory. However,
security is about risk
management, because of the following real-world limiting conditions:
1) There is no such thing as security perfection. I can't set
things up once
and walk away, because attacks and attackers evolve.
2) The more complex my security regime is, the more it limits
TOM: But this is the rub -- the configuration is not that complex, no
more than the average PIX or Check Point. I'm not that smart and I can
do it, so most enterprise or even mid sized biz admins can do it with
the proper guidance. Of course this doesn't apply to SBS because it
can't be secured.
3) The more complex my security regime is, the more it costsTOM: Just a one-time cost of setup. Takes maybe an hour at the most to
-- either in
materials or in time.
perform the actual config. Then you back it up and if something goes
haywire, you restore from backup. Really, its not that hard, I know a
number of orgs (those that I've set up and those others have set up)
that use this kind of robust security zone segmentation. It take maybe a
couple of hours in the lab to practice setting it up and getting
familiar with the concepts and principles, but after that, you're in
like Flynn. :)
4) Admins never have enough time.TOM: The configuration is a one-off, and it isn't that difficult. Anyone
who has deployed an Exchange organization that is more complex than a
single front-end/back-end Exchange Server will find this setup to be
child's play once they get the practice in their VM lab. How much time
is a more robust security infrastructure worth? You can get up to speed
in a few hours, better yet, go to Tim's and Jim's class and learn it
from the masters. Remember to harass them for giving me some credit ;)
Therefore, here's my question to you and the other readers to
this architecture protect me from enough risk to warrant the
and loss of functionality? Note that by risk I mean not just
threat, but from a threat whose likelihood has been judged to
be high enough
to warrant the expense of preventing or mitigating it.
TOM: Yes, for a few hours of work you gain more than what you put in.
Plus, you'd pass my compliance audit for placing Internet facing servers
on a different security zone than non-Internet facing servers.
I'll get to my thoughts on that in a minute.
Since we, by design, offer OWA access from the web,to an asset on
we basically extend an interface from an untrusted network
the internal network in the standard publishing model (evengiven the
"non-swiss cheese" application filters used in ISA publishing)
TOM: Keep in mind that the Internet facing FE server is on an
AUTHENTICATED ACCESS DMZ. A lot of the "port openers" in the crowd think
that DMZs are all created equal, but they're not (I know you already
know that). In an authenticated access DMZ, no connections are made to
the Internet facing server *until* those connections are
pre-authenticated by the ISA firewall. This is separate and distinct
from the anonymous access DMZ, where its party down on the published
servers and you have to depend on any stateful packet and application
layer inspection the ISA firewall can provide before the anonymous
connections try to do what they can do to those servers.
I would disagree with this characterization. ISA isn't merely
relaying communications from untrusted networks to trusted
networks. It is a
true application proxy when configured to publish Exchange.
to compromise both ISA's filtering/proxying code *as well as*
SMTP code in order to successfully exploit a vulnerability --
and they are
two different codebases.
Thus, it stands to reason that an asset important enough tobe protected by
the internal "protected network" should be even betterprotected in an
environment where only the necessary services/protocols areallowed in to
the "real" network. Particularly when the service isextended to the web.
The "real-world" communication requirements for "proper"(meaning "secure")
FE operations are quite overstated, even in the Microsoftdocumentation.
Understand that the Microsoft documentation isn't trying to
attain the maximum restrictions necessary. They're trying to define to
maximum restrictions necessary to adequately guard against
the likely risks
(as judged by the product team, who gets the feedback from a lot of
customers and from their own IT deployment) to an Exchange
while allowing the customers who deploy this configuration to
maintain and administer their Exchange machines using supported
methodologies and procedures.
TOM: From my assessment of the Microsoft Exchange Server network
security recommendations (and unfortunately the ISA UE group picked up
the same infection), they're all based on ease of use. Sure, its easier
to but the FE and BE on the same security zone, but its not the best or
most secure method. Putting an Internet facing device on the same
security zone of a non-Internet facing device just isn't good policy. It
would be like allowing your users or your internal DNS servers to
perform recursion against Internet DNS servers, instead of using a
caching-only DNS server in your anonymous access DMZ.
In other words, they're striking a balance between maximum
security and the
ability for the inexperienced admin to gain a "good enough" degree of
security while still having a supported configuration that
can be properly
maintained and updated.
TOM: The problem is that if you use ISA, the security you get can be
much better by segmenting the security zone. That's what I'd call good
enough. I strongly believe that the ISA and Exchange PGs need to be up
front and provide guidance for "good enough" and "preferred" security.
Steve Riley, one of Microsoft's security gurus, makes a very
argument that a lot of security measures end up being nothing
tweaks. He and Jesper Johansson (writing together in "Protect
Network From Perimeter to Data", Addison-Wesley, ISBN
out that many of the major security incidents in the last
aren't stopped by configuration tweaks because they're really
unpatched vulnerabilities. Therefore, the process of keeping
secure necessarily includes making sure they can be updated
quickly and as
easily as possible -- preferably in an automated fashion.
TOM: I'll keep that in mind when I talk to my neurosurgeon friends --
that all the extra measures they take to make sure something bad doesn't
happen aren't required because they're just tweaks, and they probably
will have only a very small effect on his morbidity and mortality rate.
They draw their conclusions from a very small cohort and then make
wide-sweeping conclusions. I think it works as a "feel good" measure,
but I assert that every "tweak" that doesn't create a dysfunctional or
non-functional system is worth making. If for no other reason is that
you can't predict the future and anything can happen, so why not do what
you can, with a minimal amount of effort, to improve your security?
Rules to support *only* the Perimeter network box to *only*the internal
Domain Controllers object for:up Kerberos-Adm
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
(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 thisis required.]
Note that the Exchange Server 2003 Security Hardening Guide
(http://go.microsoft.com/fwlink/?LinkId=25210) gives you a
precise list of
which services need which ports incoming and outgoing.
TOM: Actually, that list is not correct. Tim has worked out what is
actually required and moves the configuration even closer to the goal of
least privilege. But I'm not going to let the cat out of the bag since
he teaches you that stuff in his class and he worked a long time over a
hot NetMon to figure it out. Very good stuff -- and expands on the DMZ
work I did for ISAserver.org.
LDAP (TCP and UDP 389)from the box]
LDAP GP* (TCP 3268)
[LDAP is only necessary if you need Global Catalog access
All Exchange 2000/2003 servers require GC access. If you cut
off an Exchange
server from a GC, you can suffer any number of errors, from subtle
impossible-to-diagnose glitches to message routing errors to flat-out
services not starting, depending on your configuration.
This minimal rule-set will allow the FE Exchange Server to functionauthentication/NetBIOS
perfectly without having to allow all the other
traffic in/out. NOTE: This will not allow you to managethe FE Exchange
Server from the internal network via the Services ManagerMMC (or any other
means) as no OUTBOUND traffic for these protocols isallowed. This is a
_good_ thing... You *NEVER* want to allow authenticationprotocols to
*leave* your network. That's just silly. You shouldmanage 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.)
Well, that's not all it breaks. Many environments today worry about
regulatory compliance and must be able to track messages through their
Exchange organization. In order to use Message Tracking, I
have to enable
port 445 traffic on that FE server...
Sometimes I can't allow people to RDP into a box and have to allow MMC
management. "You should" is great in a perfect world, but
there are plenty
of good reasons why management and security administrators
won't do things
that way. Why wouldn't I want admins on the box? Well,
is a big one again; if I let all of my admins log into the
box, instead of
just a small subset, I have potentially magnified my risks.
How do I audit
their actions? How do I protect against a junior admin doing
gain escalated access?
Now, you need rules to support *only* the Perimeter networkbox to *only*
the internal back-end Exchange servers that house themailboxes the OWA
users must access: it is a "good news, bad news" scenario.
Please don't forget that OWA isn't the only reason to use FE
are still people using POP3 and IMAP, and other people have
their FE server
do double-duty as bridgeheads. These will all increase the
TOM: Yes, and ISA enables you to use least privilege and limit access to
*only* the required posts. How many worms do you know of that use random
ports that are outside of the handful of protocols that we actually
require? That's what least privilege is all about.
Also, remember that ISA firewall is the intermediator. With
IPSec, ISA is not a third party intermediator, so if the FE and BE are
compromised, you don't have an intermediator that says "nope, that's not
allowed". And since the ISA firewall is the "hardest" machine on your
network, no one is going to compromise it, since the FE and BE are much
OK, I'm tired of typing now. I don't like to get long winded unless
someone is paying me for it :)))
There is detailed information regarding this topology onISASERVER.ORG,
which rocks. Additionally, Jim Harrison and I are leadinga 2 day training
at the Vegas Blackhat specifically on ISA configurationsfor those who are
It's a great configuration, yes -- if the extra expense and
effort solve the
problems you're trying to solve. Unfortunately, it adds quite a bit of
complexity. It doesn't address, in my mind, one of the
biggest problems with
the FE architecture, which is that a successful compromise of
the FE server
potentially leaves the attacker with really good access to my
infrastructure. Unfortunately, that's an artifact of the current FE/BE
design and there's not really anything I *can* do about that.
I can solve the issue of using the FE as a jump point into
the rest of my
network by using Group Policy to distribute IPSec filters
that prevent the
rest of my machines from accepting inbound connections from
Defense in depth is a good thing. I'm going to be looking at
regardless of my DMZ configuration...
So don't take this as me knocking the extra DMZ architecture
There are lots of networks that it's a good configuration
for, but it brings
an elevated set of challenges with it (how do I get patches
to my box? How
do I address specific compliance concerns?). That's why I
the ISA-in-the-DMZ approach; it makes the fewest assumptions
existing network configuration and security measures, gives
good value for
the amount of effort that is required to implement it,
protection for the vast majority of risks, and is simple enough for
overworked admins (and their non-tech managers) to fully
understand (so they
don't later end up compromising some of their protection
because they don't
realize the implications of something they just did).
Dang, I'm long-winded; I guess I need to contact the Church
of Security As A
Process and see if they have any job openings for evangelists. :)
Devin L. Ganger Email: deving@xxxxxxxxxx
3Sharp LLC Phone: 425.882.1032 x 109
15311 NE 90th Street Cell: 425.239.2575
Redmond, WA 98052 Fax: 425.702.8455
(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/
- Prev by Date: RE: RE: Front End/Back End communication
- Next by Date: Re: Front End/Back End communication
- Previous by thread: RE: RE: Front End/Back End communication
- Next by thread: SecurityFocus Microsoft Newsletter #291