RE: Exchange in the DMZ

• Previous message: TSimons@Delphi-Tech.com: "RE: Secure / Encrypt Terminal Services"
• Maybe in reply to: Dean Pullen: "Exchange in the DMZ"
• Next in thread: David Sommers: "RE: Exchange in the DMZ"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 26 Nov 2002 09:47:07 -0800
From: "Welsh, Armand" <Armand.Welsh@SSCIMS.com>
To: "Pidgorny, Slav" <slav.pidgorny@anz.com>, "Dean Pullen" <deanpullen@yahoo.com>, <focus-ms@lists.securityfocus.com>

Exchange on the internet is just not very secure.. Generally speaking..
It uses RPC and this means that you have to hack the registry to force
the NSPI, SA, and DS services to use specific ports, and do the same for
other RPC service that are needed. The alternative is to open all ports
greater that 1024 which is very risky.

If the front end server is for SMTP and HTTP access, then you are better
off using an SMTP daemon (like sendmail) and an http proxy server (like
squid, although squid has it's own security risks) on the DMZ so that
they front end the web mail and smtp interface into exchange. Then
exchange resides only on the inside network. This allows you to setup
firweall rules so that only smtp and http(s) are allowed from the dmz
gateways to the exchange front end server. Internet users can only
access boxes on the DMZ, and only DMZ systems can access specific
internal systems.

If you want to use outlook/exchange MAPI access from the internet, then
you are best off utilizing a vpn for this type of access, since mapi
access requires each and every internet exchange server have internet
exposure for mapi functions. With SSH and other products, it's a
trivial matter to setup an SSL wrapper on the DMZ that has the needed
(limitted) visibility to the exchange servers, and talks only SSH
(22/tcp, recommend changing to other port number though) to the
internet. Then you establish your mapi connections through an SSL
tunnel, which would work just like the proxy services, only it's
encrypted as you like, and benefits from the added feature of two factor
(token) authentication as well.

The proxy and the gateway will give you the buffer you are wanting, plus
there is an added advantage, you can use these gateway systems as honey
pots too. So this way you can get an early warning if any unauthorized
activity occurs on these systems. Although it's not generally
recommended to turn production systems into honeypots, in this scenario,
it's not really such a bad idea since these systems could even be
configured (via firewalling) to allow unidirectional access to a
honeynet.

All around, using non microsoft gateways for your inbound exchange
traffic is a good idea..

Regards,
Armand

• Next message: David Sommers: "RE: Exchange in the DMZ"
• Previous message: TSimons@Delphi-Tech.com: "RE: Secure / Encrypt Terminal Services"
• Maybe in reply to: Dean Pullen: "Exchange in the DMZ"
• Next in thread: David Sommers: "RE: Exchange in the DMZ"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]