Don't get confused with the letters RPC in this scenario.
All you are doing is allowing Outlook 2003 instead of IE(in the case of
OWA), to contact the exchange server over SSL (https, tcp/443), instead
of the RPC ports.
Why they call it rpc over http I do not know, unless you accept their
"explanation" in the deployment scenario doc:
<snip>
The Windows RPC over HTTP feature enables an RPC client (such as Outlook
2003) to establish connections across the Internet by tunneling the
remote procedure call (RPC) traffic over Hypertext Transfer Protocol
(HTTP). Because RPC is not designed for use on the Internet and does not
work well with perimeter firewalls, RPC over HTTP makes it possible to
use RPC clients with perimeter networks and firewalls. If the RPC client
can make an HTTP connection to a remote computer that is running
Internet Information Services (IIS), the client can connect to any
available server on the remote network and can execute remote procedure
calls. Moreover, the RPC client and server programs can connect across
the Internet-even if both are behind firewalls on different networks.
</snip>
Although once you enable your exchange 2k3 FE server to act as a rpc
proxy, it will tell you that ssl must be configured. (So why not call
it rpc over ssl)
Anyways, allowing rpc over http is not the same as allowing the nasty
port traffic thru (tcp/135,137,139,445). You do have to take the same
security measures that you would for SSL sites.
This is one of the main reasons why I strongly encourage anyone who can
to use a front end/back end mail server scenario. Also anyone using OWA
or RPC over Http should require/force their users to use strong
passwords.
Just keep in mind of what you are protecting, it's not the e-mail itself
as it will eventually be transmitted over the wire in clear-text, but
the authentication credentials.
Someone mentioned the ssl/proxy attack. This has been around for a
while and is a "man-in-the-middle" style attack. Besides the technical
prowress it takes to pull such an attack off, makes one of the reasons
you should be careful when using your own CA; create your own CA, sign a
cert for your site using your own CA, instruct users on how to install
the Root CA cert on their machine <not the site cert as newbies often
make the mistake of doing> and also instructing users that if they get
any sort of security prompt to contact their network security team.
________________________________
From: sf_mail_sbm@yahoo.com [mailto:sf_mail_sbm@yahoo.com]
Sent: Fri 1/28/2005 5:36 AM
To: security-basics@securityfocus.com
Subject: Re: RPC over HTTP security
In-Reply-To: <921115752CD94C48BF2F2B8A46AFC1B30398D8@mail3.vdc2.local>
Thanks to all who responded
Just a few remarks:
Referring to the 'tons of links on http://www.microsoft.com/security',
not all the tons of link are related to RPC over HTTP
What I really wanted to know is 'How secure is RPC over HTTP
TECHNOLOGY'?
Is this setup similar to allowing RPC access through port 80 and 443
INSTEAD OF 135, 445... ?
If this is the case, then vulnerabilities like the RPC DCOM could well
be exploited... and what of future vulnerabilities...
So is RPC over HTTP equivalent as if we are opening ports 139, 445 to
the server?
thanks all
