Securing RPC Traffic Between Network Segments

As outlined, the problem of RPC traffic is most evident between internal network segments. An infected or compromised client in an environment can destroy critical infrastructure through the use of RPC exploits. On the other hand, locking down all RPC port access between network segments severely cripples needed network functionality and makes troubleshooting extremely difficult. Scanning RPC traffic and allowing only acceptable RPC queries is therefore necessary.

Outlining How ISA RPC Filtering Works

ISA Server 2004 secures RPC access through the use of RPC server publishing rules, which scan the RPC traffic for specific universally unique identifiers (UUIDs) and allows only those UUIDs that are associated with that particular service. For example, Figure 15.1 shows some of the UUIDs (referred to as interfaces) that are utilized to allow Exchange MAPI traffic, which utilizes RPC.

Figure 15.1. Examining MAPI UUIDs used in an RPC server publishing rule.

When the client is restricted to requests made to particular services, it no longer becomes necessary to allow promiscuous queries to be made to the RPC endpoint mapper service on port 135. In fact, when secured through ISA, the endpoint mapper releases very little information about what available services are running, and instead relies on the client itself to issue requests to specific services. This has the effect of greatly reducing the risk that RPC services pose because ISA allows only specially formatted requests, often very benign in nature, as in the case of MAPI.

In addition, at the packet layer, ISA Server 2004's RPC filtering does not require the dynamic ports to remain open. Instead, ISA dynamically negotiates the port between the client and server and opens that port only after the negotiation. This eliminates the need to blindly open multiple ports to get RPC to work properly.

Deploying ISA for RPC Filtering

Of course, aside from reverse proxy of web-related (HTTP, HTTPS) traffic, ISA Server can use server publishing rules, including RPC rules, only if the traffic sent between client and server flows through ISA server. This requires ISA server to have multiple network interfaces, and for the client traffic to be routed through it, either because ISA is the default gateway or because the routing traffic is configured to flow through ISA. Through these types of deployment configurations, as shown in Figure 15.2, ISA Server RPC filtering can greatly limit the risk of RPC-based attacks.

Figure 15.2. Using ISA Server to secure network segments.

If a client becomes infected with an RPC-based virus or worm, or if an internal employee uses an RPC exploit to attempt to "hack" a server, this type of deployment scenario effectively contains both.

It is important to note that ISA is very flexible about the method in which it is deployed, and certain other deployment scenarios can take advantage of ISA RPC filtering and other server publishing scenarios. For example, in the scenario illustrated in Figure 15.3, ISA Servers are deployed to protect an Exchange server environment, allowing only MAPI and OWA traffic from anywhere else on the network.

Figure 15.3. Using ISA Server to secure Exchange server network segments.

Obviously, many other deployment options are available, but it is important to understand the limitations of RPC publishing, and when it is possible to use it or not.