Understanding the Dangers of Remote Procedure Call (RPC) Traffic

Of all the protocols on the Internet today, none has gotten more of a bad rap than the Remote Procedure Call (RPC) protocol. RPC is a favorite protocol for programmers because it allows for a high degree of functionality and ease of use. Along with these powerful capabilities, however, come powerful risks. RPC was directly responsible for many of the more common and destructive exploits to traverse the Internet, including the notorious Blaster virus.

RPC exploits and security issues have caused many organizations to severely restrict RPC communications, which has had the unintended effect of diminishing end user productivity. A better, more intelligent method of allowing secured RPC access was necessary.

Fortunately, ISA Server 2004's advanced Application layer filtering abilities enable organizations to take back control over their RPC communications, restricting RPC traffic to conform to only specific types of requests and reducing the overall threat inherent in the services. These types of capabilities position ISA as an excellent gateway product to protect networks not only from external traffic but from internal RPC exploits and viruses as well.

Examining How Remote Procedure Call (RPC) Traffic Works

To understand the basics of the problem, it's important to first understand, at least in outline, the specifics of how the RPC protocol works. RPC is very powerful, and provides programmers with efficiency and enhanced functionality. It is therefore commonly used for many applications and services.

NOTE

The scope of this chapter is not on the intricate programming specifics of RPC, but more information can be found at the following URL:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/rpcank.asp

In short, RPC works by publishing an endpoint mapping port (Port 135) on a server running RPC services. This port is responsible for directing clients to dynamically assigned high-range ports for the services. These ports may be any of the TCP/IP ports in the range of 1024 through 65,536, depending on a random assignment by the RPC endpoint mapping service. The fact that so many ports must be opened to allow RPC is one of the reasons why it has gotten a bad rap in security circles.

Another problem with the way that RPC operates is that it is very chatty, and by default exposes much information about the services that run on the particular server. It doesn't take too much probing of the default RPC endpoint mapping port to retrieve sensitive information about which RPC interfaces are available.

The fact that RPC was so powerful, yet so insecure, brought many organizations face to face with a dilemma: They could allow the RPC access and expose themselves to threats and exploits, or they could block access to it, and limit the productivity advances that IT technologies could provide them. A solution that provided for secure RPC access became necessary, which gave rise to the RPC filtering capabilities of ISA Server.

Outlining RPC Exploits

The world became uniquely acquainted with the power and destructive capabilities of RPC with the release of the Blaster worm a few years back. Blaster took advantage of a Microsoft security hole in the Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface, which effectively allowed a remote hacker to use an exposed RPC port to take over a server remotely. These types of exploits take advantage of the fact that a "bare" RPC interface that is opened on a server effectively has all ports from 1024 to 65536 open, leaving a much larger surface area exposed.

Although most RPC traffic is blocked on the Internet today, the real arising problem is that RPC exploits are becoming increasingly common on "trusted" networks, such as internal corporate LANs. Simply clicking on the wrong website and downloading scumware, malware, and viruses from the Internet can turn a client on the network into an attacking host, exposing critical server components to exploit and damage.

Understanding the Need for RPC Filtering Versus RPC Blocking

The reaction to RPC issues in the past has been to block the RPC traffic by disallowing Port 135 between network segments on routers and/or firewalls. This can cause severe problems with internal network traffic because a large quantity of critical network services rely on RPC calls and protocol access. For example, shortly after the Slammer virus was released and wrecked havoc on IT infrastructure, it took months to sort out what routers were blocking necessary functionality such as Active Directory domain controller replication. The initial reaction was to drop all RPC traffic, regardless of whether it was needed or not.

What is needed is a way to secure the RPC protocol itself, by delving further into its functionality than simple Layer 3 packet analysis can. Intelligent Application layer filtering of the traffic using ISA Server 2004 is one excellent approach to solving this problem.