From: Thor (Hammer of God) (thor@hammerofgod.com)
Date: Fri Apr 13 2007 - 09:53:45 EDT
I sent this once, but didn't see it post so I'm re-sending...
> My concern would be a 0-day exploit for the service that is exposed. An
> internal MS Exchange server responding to public internet traffic, seems
> less secure than say... a postfix server in the DMZ and a MS Exchange
> server on the internal network.at least in this situation you would need
> two services to be exploitable (Postfix SMTP and MS Exchange) rather than
> just MS Exchange.
>
> Is this an over paranoid stance? What if the company falls under
> "Executive Order on Critical Infrastructure Protection"?
It's not overly paranoid at all... It is a standard way of deploying SMTP on
Exchange, and provides security in depth. It is a good idea.
As Dr. Shinder and Jim Harrison have pointed out, this entire thread has
been wrought with misinformation.
The OP was in regard to someone "port forwarding" TCP 25 to the SMTP service
on an internal Exchange box. You don't "port forward" "native Exchange"
services from the internet. If you want to securely deploy external client
access to your Exchange server, do so via RPC over HTTP using ISA.
While "port forwarding" TCP 25 to your internal Exchange server will
certainly work, it is not a very secure posture. Think about MS05-021 and
the "X-Link2State" vulnerability. Deploying an SMTP gateway in the DMZ
(which should be done anyway for virus/spam) and then publishing SMTP via
ISA is the way to go. That way, all SMTP traffic is analyzed by the ISA
SMTP application filter to ensure that only approved SMTP commands and
corresponding command lengths are allowed through. Exchange SMTP services
published through ISA like this were automatically protected from
X-Link2state issues. Also, by default, violations of application filter
settings immediately tear-down the connection rather than leaving it open as
the case would be if someone directly connected to the Exchange SMTP
service.
The "OWA front-end in the DMZ using IPSec," comments were not on topic per
se, but did arrive at a better topology for OWA deployments-- conceptually
at least. However, securing an OWA FE server in the DMZ via IPSec doesn't
quite work that way. The FE must be able to contact all BE servers via
HTTP, and must be able to authenticate to the DC's via Kerberos at a
minimum. You'd have to ensure IPSec communications are available to all
associated internal servers in that case. Besides, that really doesn't
solve your problem from a security standpoint. The reason to isolate the
OWA server is in case it gets compromised. After all, initially, the OWA
front end is reachable anonymously on the Internet (you have to log on, of
course, but anyone can get to that page). If the OWA FE gets owned, They
have a full stack into the internal network via the IPSec tunnel. They
could fire off whatever attacks they wanted to the internal Exchange boxes
and AD controllers and not be detected. The IPSec model alone doesn't buy
you anything except for securing the FE to BE communications that must be
made over HTTP (but it is good for that).
A better model would be to isolate the OWA FE server in its own protected
authenticated perimeter network segment off of ISA server, and to only allow
the minimum rules required for FE operation to only those boxes on the
internal network. That would be Kerberos-Sec (UDP), LDAP, DNS and ICMP
(Ping) to the DC's, and HTTP to the BE's. That's all you need for proper
OWA functionality. Now, if you want to interactively log on to that OWA
box, then you'll need RPC (all interfaces) from that guy to the DC's, but
only for the logon process when you need to patch the box. Of course, the
Exchange team won't support this because they want to you just stick the OWA
box on the internal network and ISA to publish OWA to that guy, but what
else is new. If you're using ISA anyway, you might as well stick in another
network card and configure a few rules and be done with it.
We cover all these topology designs in our "Microsoft Ninjitsu: Black Belt
Edition" training at Blackhat in Vegas this year for anyone interested:
http://www.blackhat.com/html/bh-usa-07/train-bh-us-07-tm-ms-bbe.html
t
Timothy Mullen, MCSE, MCT, MCSD
Microsoft MVP, Windows Security
Vice President of Consulting Services, NGS Software
www.ngssoftware.com
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Are you using SPI, Watchfire or WhiteHat?
Consider getting clear vision with Cenzic
See HOW Now with our 20/20 program!
http://www.cenzic.com/c/2020
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:43 EDT