Re: Front End/Back End communication
- From: James Eaton-Lee <james.mailing@xxxxxxxxx>
- Date: Tue, 16 May 2006 15:06:46 +0100
On Tue, 2006-05-16 at 00:50 +0000, timpacalypse@xxxxxxxxx wrote:
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.
What you're talking about is creating an IPSec tunnel from the host to
the destination rather than using IPSec in transport mode, which is the
normal configuration for front/back end exchange. Essentially, you'd be
treating your DMZ as the outside world and making a VPN connection as a
client with remote access would.
You could do this using IPSec support in the device which is doing the
NAT, if it supports it, or by passing through IPSec or L2TP/IPSec (or
pptp) traffic to a VPN server behind the device using something like
Routing and Remote Access (again, if it supports it - if your options
are portforwarding, then you're fairly out of luck). If you don't mind
answering on a public list, what is your NAT-performing-device, and what
is it running?
In any case, doing this without terminating the connection at the NAT
device and filtering it (or generally doing filtering 'off' the DMZ'd
box) would make your DMZ completely redundant as your DMZ'd host would
logically be 'in' your internal network anyway and an intruder on the
DMZ'd host would have complete access to your internal machines as if
there were no DMZ.
To be honest, as a previous poster has said, you're not in the best
position having used NAT between two machines that should really have
traffic being routed between them, and a topology change to make your
DMZ segment routed onto your LAN (with filtering) would ultimately cause
you the least pain.
this will generally break if you just portforward it)
You wouldn't even have to pay money to do this (or use isa) - a firewall
like m0n0wall or any of the other linux/BSD firewalls would probably do
you just fine (although m0n0wall has the best combination of ease of use
and applicability to specifically what you want). Most packages like
m0n0wall and IPCop have support for IPSec built in too, even if you
decided to continue going with NAT and wanted, as above, to terminate
the IPSec connection at the router.
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.
Ideally - at the end of the day ISA solves lots of headaches involved
with securing front/backend exchange and presenting exchange to the
world in general - the application-layer filtering exchange will do with
OWA as well as SMTP is really really nice, and I would strongly consider
it for any internet-facing exchange deployment.
Hope that helps!
- James.
--
James (njan) Eaton-Lee | 10807960 | http://www.jeremiad.org
Semper Monemus Sed Non Audiunt, Ergo Lartus - (Jean-Croix)
sites: https://www.bsrf.org.uk ~ http://www.security-forums.com
ca: https://www.cacert.org/index.php?id=3
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- References:
- Re: Front End/Back End communication
- From: timpacalypse
- Re: Front End/Back End communication
- Prev by Date: Re: Front End/Back End communication
- Next by Date: RE: Front End/Back End communication
- Previous by thread: Re: Front End/Back End communication
- Next by thread: RE: Front End/Back End communication
- Index(es):
Relevant Pages
|
