RE: why rpc over http?
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Thu, 17 Nov 2005 22:46:52 -0600
Hi Ara,
Secure Exchange RPC publishing is great depending on your enviroment and
the scenario.
However, there are limitations to secure RPC publishing:
1. "Open a Port" firewall admins often will block the RPC endpoint
mapper (TCP 135). This was a big problem when blaster hit, and even the
moron ISPs decided to DoS their customers by "doing them a favor" and
blocking outbound access to this port. Things are much better now, and
I've been able to use Secure Exchange RPC at most hotels and airports,
but there are still a number of locations that block this port, or have
unintelligent firewalls/firewall admins who don't support RPC outbound
from the remote location
2. You need to publish each mailbox server. In a simple one or two box
Exchange organization, secure Exchange RPC is a great option. But for
companies that have lots of Exchange Servers, publishing each one can be
a hassle.
3. The weak link in many companies security chain "the network guy" will
balk at opening the packet filters on their packet filter device (aka
"firewall") in front of the ISA firewall. Since the Syphco rep slipped
the network guy some roofies, he's convinced Spyhco is a security
company, when in fact their a network company and security is a
sideline, and if they were to secure something, its this "network"
thing, instead of security the server applications that require the
security. So, you'll end up in a war with the "open a port" dude and
management doesn't know the difference, other than he paid 50 grand for
the hardware firewall and only 5 grand for the ISA firewall, and since
money talks and BS walks, you lose because the psychiatric (notice I
used the term psychiatric and not psychological, because there's clearly
some psychopathology involved with spending that much money for a really
faster packet filter) motivators are on his side, not yours.
4. When remote users get stuck because the trisomy running the packet
filter device (ah, I mean firewall) doesn't understand RPC or the RPC
endpoint mapper is blocked, then you have to rely on VPN. Unfortunately,
some popular packet filter firewalls don't have PPTP NAT editors, so you
can't use that. OK, you could use L2TP/IPSec, which is secure and fully
supports NAT-T, and the network guy on the remote client end probably
hasn't figure out where the "close a port" button is for that. But this
then highlights the reason why you choose to use Secure Exchange RPC
publishing in the first place, which was to avoid the user of VPN -- not
because VPN isn't good, because its very good, not because you can't
limit VPN users based on user/group to access only the Exchange Server
using the MAPI client, because you can, but because of the user
overhead, which is what you were trying to avoid.
5. So, instead of falling back on VPN, Microsoft came up with the great
idea of doing what the criminals do, but without the criminal intent. In
fact, quite the oppostite of criminal intent becaues they did this to
allow users to access via the full Outlook MAPI client to the Exchange
Server in spite of the criminal stupidity of the NAT devices, packet
filter firewalls, and lissencephalic "hardware" firewall admins who
check their horoscopes and throwin' bone to see what "port they should
open" today. The great idea is to tunnel a another protocol inside an
HTTP header, in this case Exchange RPC. Since "open a port" firewall
admins don't care about application security (they're only concerned
with 'port attackers' and 'pinhole abusers'), they allow outbound TCP
ports 80 and 443. RPC/HTTP uses TCP 443 to reach the RPC proxy, where it
is then detunneled and the nekkid RPC communcaitons move from the RPC
proxy to the Mailbox server. The responses return to the RPC proxy, the
HTTP header is added, and returned to the client. No need for VPN, no
need for RPC endpoint mappers. All secure within an SSL tunnel.
Well, those are some of the reason. When the enviornments on the client
and server side for Secure Exchange RPC publishing are right, then its
r0XOrS. When they're not, life S0XouRxS.
Now I must return to more important things, like figuring out how many
acorns I have.
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
**Who is John Galt?**
> -----Original Message-----
> From: Ara Avvali [mailto:ara.avvali@xxxxxxxxxxxxx]
> Sent: Thursday, November 17, 2005 10:17 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] why rpc over http?
>
> http://www.ISAserver.org
>
> Hello everyone
>
> I am sorry if this sounds stupid but since having an ISA
> server 2004 in
> front of exchange 2003 and following the article posted on
> http://isaserver.org/articles/2004securerpc.html is fairly easy to
> achieve and you don't necessarily have to have xp client with outlook
> 2003, why would some one invest time in rpc over http? Is the
> single rpc
> method less safe than the other way? Is it less feature rich
> compared to
> rpc over http?
>
> Thanks for clearing this
>
> ------------------------------------------------------
> List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
> ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
> ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
> ------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.com
> ------------------------------------------------------
> You are currently subscribed to this ISAserver.org Discussion
> List as: tshinder@xxxxxxxxxxxxxxxxxx
> To unsubscribe visit
> http://www.webelists.com/cgi/lyris.pl?enter=isalist
> Report abuse to listadmin@xxxxxxxxxxxxx
>
>
Other related posts:
