Security Watch

Using RPC Over HTTP

Specifics help build security.

• By Roberta Bragg
• 04/12/2004

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 HTTPS.

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.