Using RPC Over HTTP
Specifics help build security.
- By Roberta Bragg
The more narrow and specific your instructions, the closer you
come to securing an operation. For instance, you don't get users
to create strong passwords by leaving the definition of "strong"
up for grabs. You can't write a good firewall policy by saying "allow
only the traffic you need" nor harden a host well by saying
"disable all services that you don't need."
Instead, specify what you mean: A strong password is composed of
upper- and lower-case characters, digits, special characters and
is at least 8 characters long. For a firewall, try blocking all
traffic and only allow access to the ports that are necessary, such
as port 80 access to the Web server, or use the Microsoft-provided
security baseline template for servers to disable all services you
can possibly disable and still have the server boot. Then only enable
a service if you require it, such as adding the DNS server service
if the computer will be a DNS server. You can argue that your idea
of fulfilling these common directives would be different, but you
must admit that they provide much more information and are significantly
more likely than the former statements to improve security.
This doesn't mean that simply making narrow definitions of what
something should be constitutes good security. It does mean that
narrowing down the specifications for a security directive, and
even for some generic operations, and precisely defining how to
meet the requirements of a security policy, principal or directive
is more likely to provide good security than not doing so.
Here's an example: If it's your job to protect your internal LAN
from Internet-based attacks, you probably start with a firewall
that blocks all communication by default but allows you to write
rules allowing desirable and approved access. You'll balk at requests
to open up new forms of access and have an absolute hissy fit if
someone requests RPC communications across the firewall. Your rationale
is sound -- but outdated. Now I agree that it's not good practice
to simply open access to all RPC ports. RPC uses such a wide range
of ports that doing so would reduce your firewall to Swiss cheese.
However, I believe there's a way to narrow the "RPC communications
across the firewall" statement to something acceptable.
A major use of RPC is in e-mail communications between the Outlook
client and the Exchange server. At first glance, this is exactly
the type of situation to avoid for Internet communications. After
all, you can use SMTP or POP3, or Outlook Web Access; neither choice
requires turning your firewall into a sieve. There are, however,
other security issues posed by these mail transport protocols, so
let's see what can be done with RPC.
First, move from generic "RPC across the firewall" to
RPC over HTTPS. If properly implemented, you won't need to write
a single rule to specifically deal with RPC traffic. In addition,
you probably already allow SSL traffic, so you won't have to open
any new holes in the firewall.
Second, determine exactly which Exchange servers in your organization
will permit RPC over HTTPS communication from the Internet and limit
connectivity to those specific servers. Specify, via a Registry
entry, which ports the RPC proxy can use to connect to the servers.
Remember, the RPC traffic may traverse the firewall from the client
to the RPC proxy using HTTPS, but the Exchange server is expecting
an RPC connection. By specifying exactly which ports and servers
the RPC proxy can connect to, you limit the risk.
Next, specify via a Registry entry which RPC port numbers will
be used by the Global Catalog Servers in the forest for RPC over
Finally, specify the configuration of the Outlook client by defining
the RPC over HTTPS profile that will need to be implemented. The
profile should indicate where the RPC proxy lies and the location
of the GC. It also needs to require that all connections use SSL.
Also, specify RPC encryption on the client and the use of NTLMv2
on the clients.
When you have this all figured out, it's time to implement and
test the system. You can find instructions in the Microsoft article
"RPC Security" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/using_http_as_an_rpc_transport.asp.
Providing a similar experience whether a user is on the road or
sitting at headquarters and connecting directly to the LAN is important,
but doing so securely takes precedence. Using RPC over HTTPS allows
you to do both.
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.