DCE and Firewalls

Resolving The Problem

Introduction

This note provides some DCE configuration tips that can help DCE applications co-exist with firewalls. You might also be interested in IBM redbook SG24-4949-00, "Security on the Web Using DCE Technology", specifically chapter 8 (DCE over Firewalls), although that information is somewhat dated (it was written in June 1997) and some details are AIX-specific.

By "firewall", we mean a creature (either software or hardware, or both) that filters network traffic based on some configurable set of rules that usually restrict protocols or ports for incoming and/or outgoing traffic. Usually, incoming traffic is more heavily restricted. The term "packet-filtering router" is sometimes used to describe the type of firewall that we consider in this note.

For example, many organizations have firewalls installed on the router machines that connect their internal networks to the Internet. These firewalls might be configured to prevent incoming connections to any ports except for the organization's web server and ftp server ports. In more complex environments, traffic from the outside to the inside of the organization might have to pass through multiple firewalls, each with a different set of rules. For example, there might be a firewall between the outside world and the company's web/FTP server machine(s), and then a second firewall might sit between the web/FTP server machine(s) and the company's internal network.

In general, the issue with firewalls is that they only allow certain defined types of traffic to pass through them. If a DCE application consists of a client on one side of a firewall and a server on the other side, then the firewall and DCE must be configured in a way that allows the DCE traffic to pass. For example, if the web server mentioned at the end of the previous paragraph is a DCE client (perhaps talking to a DCE server to do some sort of database work in order to do its job), the total communications path might be: web browser on outside machine -> first firewall -> web server -> second firewall -> DCE server on internal network -> back-end database. Since the DCE RPC traffic passes through the second firewall, the firewall must be configured so as to allow DCE traffic to pass.

Typically this requires the firewall administrator to modify the rules in order to "open up" the ports that DCE needs, and it requires the DCE administrator to take steps to make DCE's port usage predictable enough to satisfy the firewall administrator. This note concentrates on the latter problem: how a DCE administrator can control port usage of his/her applications so appropriate firewall rules can be constructed.

This problem is non-trivial because DCE clients and servers use "dynamic" port numbers. That is, if you stop and start a DCE CDS server five times, the server will almost always listen for connection requests on a different port each time it comes up. In fact, the CDS server will typically listen on two diffferent ports each time it comes up: one UDP port and one TCP port.

This is in contrast to other services like say a web server that always listens on TCP port 80, or the FTP service that always uses TCP ports 20 and 21. Firewall admins are fond of services like these, ones that have predictable port usage. They hate services like DCE's, where the only predictable ports are the ones used by the endpoint mapper. (The endpoint mapper daemon always uses TCP and UDP ports 135; and of course it's the endpoint mapper on each machine who keeps track of the ports that other DCE servers use, so clients can learn which ports their servers are using at the moment).

This note describes a few environment variables that can be used to make DCE act more like a web server or a FTP server, in that DCE services (including customer-written DCE applications) can be made to listen on more predictable ports so firewall administrators can control DCE traffic as precisely as they can control other types of traffic. In a nutshell, we will describe how to restrict DCE services to a particular range of port numbers which can be opened by the firewall guy. (We still may not be able to predict for sure which DCE service is using which port in the range, but we'll be able to specify the set of ports that we need, which is typically good enough.) Most of this note is relevant to sites that use the full set of DCE services, including CDS and security; toward the bottom, we'll explain a few alternative measures that can be used in simpler environments where perhaps all you care about is DCE RPC, without DCE security or CDS.


The RPC_ Environment Variables

There are three different environment variables that can be used to help DCE work in conjunction with firewalls:

1. RPC_SUPPORTED_PROTSEQS: this can be used to limit DCE RPC traffic to a particular protocol, either TCP or UDP. Sometimes, firewall policy is that only TCP traffic is allowed, and no UDP traffic at all is permitted to flow from outside the company to inside. If this is the case at your site, then you would set RPC_SUPPORTED_PROTSEQS to ncacn_ip_tcp.

2. RPC_RESTRICTED_PORTS: this can be used to limit the range of ports used by DCE programs. It restricts both client-side and server-side ports, so it's useful if you have restrictions in place that control both incoming and outgoing port numbers. You can set it to something like this in order to specify that TCP ports be chosen from the range 2000-2999, and UDP ports be chosen from 4000-4499:
ncacn_ip_tcp[2000-2999]:ncadg_ip_udp[4000-4499]

You must not specify a protseq in RPC_RESTRICTED_PORTS if you have set RPC_SUPPORTED_PROTSEQS to exclude that protseq. That is, if you set RPC_SUPPORTED_PROTSEQS to only ncacn_ip_tcp, then you must not mention ncadg_ip_udp in your setting of RPC_RESTRICTED_PORTS.

One serious problem with RPC_RESTRICTED_PORTS is that it's not possible in general to determine exactly how many client-side ports a DCE process will use, so it's not possible to set RPC_RESTRICTED_PORTS precisely -- that is, it's not possible to guarantee that the entire port range specified will actually be used. You have to allow at least 100 to 200 ports in order to be sure that DCE can do its normal work, and you have to allow additional ports in busier cells. This is very bad from a firewall admin's perspective, since you will be asking him to open up this big range of ports, but you won't know for certain that you'll actually be using them -- so in theory, some hacker could try to get in via one of the open ports that you're not using.

Luckily, firewall administrators often don't care about which ports you use for outgoing traffic -- they just want to be able to control which ports are used by incoming traffic. If that's the case at your site, then the next variable will be of use, and you will not want to use RPC_RESTRICTED_PORTS at all...


3. RPC_RESTRICTED_SERVER_PORTS: this one has the same syntax as RPC_RESTRICTED_PORTS, but it affects only your servers' listening ports. So, if for example you have a DCE machine with a security server and two application servers, then you will need to specify a range of only 4 ports: one for the security server, one for the local CDS advertiser, and 2 for the application servers. (The endpoint mapper will use port 135 regardless of the setting of the RPC_RESTRICTED_ variables.) Your firewall person can now restrict incoming traffic to just port 135 and the 4 ports in the range you set via RPC_RESTRICTED_SERVER_PORTS, and everyone is happy.

RPC_SUPPORTED_PROTSEQS is an OSF-standard variable, so it appears in every vendor's version of DCE, while the RPC_RESTRICTED_ variables were added later by various vendors and may not be available on all platforms. Specifically, RPC_RESTRICTED_PORTS appears in DCE versions 1.1 and higher on Solaris 2.4 and higher, and in AIX DCE 2.1 and higher on AIX 4.1 and higher. RPC_RESTRICTED_SERVER_PORTS was introduced in patch 43 for DCE 1.1 on Solaris 2.5, in patch 4 for DCE 2.0 on Solaris 2.6, and in the base distributions of DCE 3.1 for Solaris 7 and 8 and for AIX. Check with your DCE support organization if you have questions about the availability of these variables on your specific platforms.

In order for these environment variables to be effective, they must be set for every DCE process on the machine(s) of interest. There are several ways to achieve this, depending on your platform.

As always, you should contact your DCE support rep if you have questions about any of this stuff. Happily, it's pretty easy to verify that these variables are doing what you want them to do, just by inspection of the local endpoint map. (Use dcecp -c endpoint show to see the endpoint map on your local machine.) You should be able to play with them and get things working properly on a test machine, so you don't have to bother your firewall team while you're figuring out how to get the control you want.


Alternative: Well-Known Endpoints

All the comments above are directed toward DCE administrators who have full-blown DCE cells that use CDS and security in the usual ways, and whose application servers use the normal DCE dynamic endpoints. However, if your own DCE environment is simpler than that, you may not need to use these RPC_ variables at all.

If the only DCE traffic that crosses your firewall consists of application RPCs (i.e., no CDS or security work done across the firewall), then you might want to just code the application to be firewall-friendly itself. You could for example use the technique of "well-known endpoints" in your server, so it would act kind of like a web server or an FTP server that always listens on the same port. If you do this, then you know exactly which port your firewall has to open, and you don't need to open port 135 for the endpoint mapper since your application client won't even have to look up an endpoint.

A hackish way to accomplish essentially the same thing would be to programatically set the RPC_RESTRICTED_SERVER_PORTS variable in your server program, specifying a range of just one port -- then you'd know for sure which port your server would use. Your client could use a string binding instead of CDS to obtain a binding handle to the server; if you have no need for DCE security, then this would be another way to limit your application to using just one port through the firewall.


NAT Firewalls

We should mention that some firewalls can employ a "network address translation" (NAT) feature that hides internal IP addresses from external users. I've also heard the term "IP masquerading" used for this technique.

DCE applications will probably fail if they are run through such an address-translating firewall, because some DCE RPC packets contain the IP address of the sender. If the firewall re-maps/hides/translates addresses such that the recipient of the DCE RPC packet cannot actually use the IP address that appears in the packet, then the RPC facility will almost certainly fail.

There's an Internet RFC that discusses NAT, RFC 1631. It makes this comment in section 3.3 on Header Manipulations:

In addition to modifying the IP address, NAT must modify the IP checksum and the TCP checksum. Remember, TCP's checksum also covers a pseudo header which contains the source and destination address. NAT must also look out for ICMP and FTP and modify the places where the IP address appears. There are undoubtedly other places, where modifications must be done. Hopefully, most such applications will be discovered during experimentation with NAT.
At this point, we have discovered that DCE is another application where modifications must be done...

In order for a NAT firewall to work with DCE, the firewall would have to be DCE-aware. Specifically, it would have to modify DCE RPC packets on the fly, in such a way as to make them consistent with the addressing scheme that it maintains. Read section 3.3 of the RFC, where the mods for FTP are discussed, to get an idea of the scope of the problem. As the NAT RFC says later in section 3.3:

"Any application that carries (and uses) the IP address inside the application will not work through NAT unless NAT knows of such instances and does the appropriate translation. It is not possible or even necessarily desirable for NAT to know of all such applications."

DCE would seem to fall into this category of application. We have had a few customers attempt to use DCE with NAT firewalls, but as far as we know, none have succeeded. (We would love to hear from customers who have made it work, though; or from customers who know of DCE-aware NAT firewalls!)

Update, June 2000: We have a report from a customer who has had success with DCE over a NAT firewall. Checkpoint's "Products and Solutions" web page says that their Secure VPN architecture supports DCE RPC, and the customer reports that it does seem to work. (This is not an endorsement or a support guarantee, as we have not tested or used this VPN product ourselves, and the web page refers to Microsoft's implementation of DCE; but it's an interesting tidbit... since Microsoft's DCE implementation is supposed to be wire-compatible with other implementations, in theory it seems that this could work.)