RE: Front End/Back End communication

(Resent to list after bouncing due to format)

The problem with trying to do an IPsec tunnel is that it buys you nothing in terms of security. You could probably do it -- but it actually weakens your security in the long run. Instead of exposing your traffic to sniffing, you're now handing an attacker an open door to your BE server (or more, depending on how you configure the tunnel to work). Think about it for a minute -- you now have a tunnel that allows every protocol between your DMZ and your protected network.
This is why Microsoft worked to provide a better configuration option for FE/BE servers, first with ISA 2000 FP1, then with ISA 2004. Putting the FE server in the DMZ open too many holes in the configuration and it gets messy to try to patch them all back up again.

I don't know exactly what firewall you've got between your interior and your DMZ, but if it's not a SOHO variant, then you may very well have the ability to configure the relationship between the two networks like I mentioned before. I've heard of folks doing it with various Cisco boxes, and I have used that capacity in ISA 2004 to good advantage.

The other alternative, I suppose, is to go ahead and let it go unsecured for now, and upgrade to Exchange 2007 once it comes out. That's not much of an alternative, though.

I definitely feel your pain.


--
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/



________________________________

From: Tim McLaurin [mailto:timpacalypse@xxxxxxxxx]
Sent: Monday, May 15, 2006 5:49 PM
To: Devin Ganger; focus-ms@xxxxxxxxxxxxxxxxx
Subject: RE: Front End/Back End communication


I know the ISA 2004 is the recommended way to deploy but at this point using ISA isn't an option.

What I meant by opening each individual port was that for some reason I was thinking that instead of opening ports, 443, 389, 3268, 88, and whatever else, I could tunnel everything via IPSEC. I would only have to allow that to pass through the firewall instead of each one of the ports that are required for the Front End Server to communicate with the Back End Server. So I thought all of that information would traverse the IPSEC tunnel and then the application/server itself would decrypt the tunnel and then use whatever ports it needs. I wish I could draw in e-mail....I think it would less non-sense if I could draw a diagram. Either way I guess I was wrong.

So now it's starting to look like I don't have too many options? I don't have an ISA Server. What types of functionality might it break if we try to use NAT-T?

Everything I've read from microsoft so far says to use ISA server. So I've been trying to figure out a secure, reliable alternative.

Devin Ganger <DevinG@xxxxxxxxxx> wrote:

At Monday, May 15, 2006 10:29 AM, timpacalypse@xxxxxxxxx wrote:

> I'm curious about how people are implementing FE/BE Exchange
> communication. It absolutely kills me that all of this traffic is
> being transported through all of these ports via clear text.

IPSec is the recommended way to secure it.

> I thought about encrypting all of it using IPSEC but we are using NAT
> between the DMZ and the Internal firewall. So all the traffic will
> get dropped.

You can pass IPSec through NAT firewalls: NAT-T (NAT Traversal).

However, that design has got to breaking other functionality. Your FE
server (in your DMZ) has to be a member of the AD domain/forest, which
means it needs to be able to initiate connections into the protected
network. At the very least, you need to get these two subnets on a
routing relationship with each other (that is, have your firewall
perform NAT if it's coming from the protected network destined
externally, but not between the protected network and the DMZ). Your
firewall people (if they're not you) will probably stop listening right
about now, but you should remind them that NAT *is not* a security
measure and is intended to conserve publicly routable IP addresses.

> Another
> question is, even if you do use IPSEC do you still need to open the
> individual ports? My understanding is that you don't but someone is
> telling me that you do.

What do you mean by "open the individual ports"? You're not using IPSec
to tunnel traffic in this config, so you can just say "Encrypt all
communications to IP address M.N.O.P" -- but then the intervening
firewall will need to allow the proper protocols through (and there are
a LOT of them for an FE in the DMZ).

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

--
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/



________________________________

Yahoo! Messenger with Voice. Make PC-to-Phone Calls <http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com> to the US (and 30+ countries) for 2¢/min or less.

---------------------------------------------------------------------------
---------------------------------------------------------------------------

Relevant Pages

  • RE: Front End/Back End communication
    ... between the DMZ and the Internal firewall. ... You can pass IPSec through NAT firewalls: ... Any new Exchange servers you stand up in the ...
    (Focus-Microsoft)
  • Re: Disaster recovery
    ... At your firewall SMTP is routed to your Exchange Servers ... After rebuilding your Exchange server you may have a new IP address assigned ...
    (microsoft.public.exchange.setup)
  • Re: VPN not working when client behind another firewall
    ... [from SBS 2003 Best Practices] ... place a hardwarebased firewall router out in front of SBS 2003 and want ... This area is NAT-T over IPSec across the firewall. ... client and the remote access server must be IPSec NAT-T-capable. ...
    (microsoft.public.windows.server.sbs)
  • Re: Dateien kopieren
    ... > IPsec Firewall alles blockiert. ... Du mußt soviele Ports öffnet, dass sich die Sinnfrage der Firewall ... IPSec-Verbindung auf den Server herstellen. ...
    (microsoft.public.de.german.windows.server.general)
  • Re: Win2k3 Web Edition, where is the protection?
    ... I'm not an IPSec guru and I can't tell you how to set an IP ... recall correctly the Web Edition was a marketing plot figgured out after the ... It's a decent firewall, and one of the better "personal" firewalls ... the applications that are listning to the server ports. ...
    (microsoft.public.security)