CIL....
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
-----Original Message-----
From: Devin Ganger [mailto:deving@3sharp.com]
Sent: Wednesday, May 17, 2006 2:31 PM
To: Thor (Hammer of God); timpacalypse@yahoo.com; Focus-MS
Subject: Re: Front End/Back End communication
On 5/16/06 9:23 PM, "Thor (Hammer of God)"
<thor@hammerofgod.com> wrote:
Consider the following illustration:
<snip the FE perimeter description>
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.
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
usability.
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 costs
-- either in
materials or in time.
TOM: Just a one-time cost of setup. Takes maybe an hour at the most to
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
consider: does
this architecture protect me from enough risk to warrant the
additional cost
and loss of functionality? Note that by risk I mean not just
a potential
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,
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)
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
filtering and
relaying communications from untrusted networks to trusted
networks. It is a
true application proxy when configured to publish Exchange.
Attackers have
to compromise both ISA's filtering/proxying code *as well as*
the Exchange
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 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.
Understand that the Microsoft documentation isn't trying to
necessarily
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
organization,
while allowing the customers who deploy this configuration to
continue 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
compelling
argument that a lot of security measures end up being nothing
more than
tweaks. He and Jesper Johansson (writing together in "Protect
Your Windows
Network From Perimeter to Data", Addison-Wesley, ISBN
0-321-33643-7) point
out that many of the major security incidents in the last
several years
aren't stopped by configuration tweaks because they're really
exploits of
unpatched vulnerabilities. Therefore, the process of keeping
your systems
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:
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.]
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)
LDAP GP* (TCP 3268)
[LDAP is only necessary if you need Global Catalog access
from the box]
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 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.)
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,
regulatory compliance
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
something to
gain escalated access?
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.
Please don't forget that OWA isn't the only reason to use FE
servers. There
are still people using POP3 and IMAP, and other people have
their FE server
do double-duty as bridgeheads. These will all increase the
number ports
required.
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
softer targets.
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 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.
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
entire AD
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
my servers.
Defense in depth is a good thing. I'm going to be looking at
these filters
regardless of my DMZ configuration...
So don't take this as me knocking the extra DMZ architecture
you describe.
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
usually recommend
the ISA-in-the-DMZ approach; it makes the fewest assumptions
about their
existing network configuration and security measures, gives
good value for
the amount of effort that is required to implement it,
provides adequate
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@3sharp.com
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/
--------------------------------------------------------------
-------------
--------------------------------------------------------------
-------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
