RE: RPCs over HTTPS through the firewall

["david singleton" <david_rh_singleton () hotmail com>]

Following on from what was written below....

> From what I have read, you would have your PC with a connection to the 
Internet, launch Outlook 11/2003, its proxy configuration value would point 
it at a URL that was E2K3, the traffic would hit the external firewall, it 
would (for the sake of argument) let in only 443 traffic,  the traffic would 
hit a reverse proxy in the DMZ, then ...

At this point we already past the external firewall without authentication.  
Should the equipment in the DMZ be doing the authentication.  If so that 
means putting the Exchange front-end server in the DMZ and not the private 
LAN.  Is that the best practice?

If the front-end is in the DMZ it completes authentication by passing calls 
through the internal firewall to W2K AD.  After which the E2K3 front-end 
passes the traffic to the back end, and you'd check your email.

Microsoft told me that they advocate putting the front-end servers in the 
private LAN

Which way should we be designing the Outlook 11/2003 MAPI of HTTP?
Dave





David RH Singleton
MCSE 2000
Cisco CNA
Compaq ASE
MS Industrial Administration





> From: Mark Tinberg <mtinberg () securepipe com>
> To: Ben Nagy <ben () iagu net>
> CC: 'david singleton' <david_rh_singleton () hotmail com>,     
> firewall-wizards () honor icsalabs com
> Subject: RE: [fw-wiz] RPCs over HTTPS through the firewall
> Date: Thu, 24 Apr 2003 18:45:21 -0500 (CDT)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 22 Apr 2003, Ben Nagy wrote:
> [snip]
> > Finally, "conventional" port 443 traffic basically contains unsecured,
> > unsecureable rubbish, passing through the firewall encrypted, so that 
> it's
> > all one Big River of Risk as far as an admin is concerned. Does it 
> matter
> > much if we add RPC to the sludge? Nnnnnnnope.
>
> I would not agree with that.  HTTP traffic over 443 or 80 has a similar
> risk profile, although encrypting traffic over 443 prevents several types
> of shenanigans that can be had on the intervening network links.  RPC on
> the other hand generally exposes a much richer interface, directly into
> the core of the OS that generally was never designed with security as even
> a tertiary concern.  There are way more things that can go wrong and you
> have far less access control opportunities than with a web service.  I
> would say that allowing RPC from random hosts on the Internet without at
> least authenticating the source before allowing the traffic through is a
> no-go.
>
> - --
> Mark Tinberg <MTinberg () securepipe com>
> Network Security Engineer, SecurePipe Inc.
> New Key fingerprint = FAEF 15E4 FEB3 08E8 66D5  A1A1 16EE C5E4 E523 6C67
>
>         Your daily fortune . . .
>
> Weekends were made for programming.
> - - Karl Lehenbauer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://quantumlab.net/pine_privacy_guard/
>
> iEYEARECAAYFAj6odxIACgkQFu7F5OUjbGdQCACePPwKd2geMkSqby535hbZdUD7
> frkAn2srPeYBSkMC0EL1AxA8/J6KyarT
> =Yx8o
> -----END PGP SIGNATURE-----


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards