Chapter 14. Intermediary Protocols

14.1.1. Sun RPC Authentication

In Sun RPC, each server application chooses what kind of authentication it wants. Two authentication schemes are available in normal Sun RPC, known as "AUTH_NONE" and "AUTH_UNIX". If you have a Kerberos installation and a recent implementation of Sun RPC, applications can use "AUTH_KERB" to do Kerberos authentication.

Logically enough, "AUTH_NONE" means that there is no authentication at all. Applications that use AUTH_NONE are available to all users and ask for no authentication data. "AUTH_UNIX" could more appropriately be called "AUTH_ALMOST_NONE". Applications that use "AUTH_UNIX" ask the client to provide the numeric Unix user and group IDs for the user and enforce the permissions appropriate to those user and group IDs on the server machine. This information is completely forgeable; a hostile client can provide any user or group ID that seems desirable.

RPC servers are free to implement their own authentication schemes, but Sun RPC does not normally provide any reliable authentication for them except through Secure RPC. You do not want to allow access to RPC services unless you are sure that they do have their own, reliable authentication. (In general, this means simply disabling remote access to RPC altogether.)

Secure RPC provides another authentication scheme, known as "AUTH_DES". Secure RPC is an extension to Sun RPC that improves user authentication. Secure RPC has become available much more slowly than normal Sun RPC; for many years, Sun was effectively the only vendor that supported it, and it is still relatively rare and difficult to use in large heterogeneous networks.

This is partly because Secure RPC requires more infrastructure than regular RPC, and this infrastructure is often annoyingly visible to the user. Logically, Secure RPC is a classic combination of public key cryptography and secret key cryptography; Diffie-Hellman public key cryptography is used to securely determine a shared secret used for encryption with the DES algorithm. Cryptography, Diffie-Hellman, and the DES algorithm are discussed further in Appendix C, "Cryptography".

Secure RPC is based upon using a public key algorithm that has a maximum key size of only 192 bits in length. This size of key is too small and is considered to make Secure RPC vulnerable to factoring attacks, where an attacker can discover the private key from computations based upon captured key exchange data. An attacker would have to use considerable computing resources to break a key, but once a key was broken, it could be used to impersonate the user at any place those credentials were used.

There are two major difficulties: distributing information about public keys, and getting private keys for human beings. Public and private keys are both big numbers, and they're security critical. If somebody can change the database of public keys, that person can put his or her public key in place of some other public key, and authenticate as any entity he or she would like to be. If somebody can read a private key, he or she can then authenticate as the entity that owns that private key. Normally, you might deal with this by not storing the private key on the computer, but human beings are very bad at providing large numbers on demand.

The Secure RPC infrastructure can deal with the public key information in a number of ways. On Suns, the normal method is to use NIS+, which has a credentials database. You can also distribute the same information as a regular NIS map or as a file. If you put the information in a file, you then have to distribute the file, which is normally done with NFS. As we discuss in Chapter 20, "Naming and Directory Services", normal NIS is not secure; therefore, if you distribute the public key information this way, it will be vulnerable to replacement by attackers. As we discuss in Chapter 17, "File Transfer, File Sharing, and Printing", normal NFS isn't secure, either. To secure it, you run NFS over Secure RPC, which isn't going to work if you need to have access to NFS before you can get Secure RPC running. If you're going to rely on Secure RPC, you must ensure that the public keys are distributed via a secure method (which will generally be NIS+). NIS+ itself uses Secure RPC, but because it is authenticating as the machine (instead of as a particular user, which is necessary for NFS), and is communicating with a known server, it can locally store the information necessary to start up a connection to the NIS+ service, avoiding the bootstrapping problem.

The private key information is also handled by NIS or NIS+. It is distributed in an encrypted form and decrypted using a user-supplied password.

14.1.2. Microsoft RPC Authentication

Microsoft RPC does provide an authentication system, but not all operating systems support it (in particular, it is supported on Windows NT, but not on Windows 95 or Windows 98). As a result, very few applications actually use RPC authentication, since it limits the platforms the application can run on and requires extra programming effort. Instead, applications that need security with Microsoft RPC usually use RPC over SMB instead of using RPC directly over TCP/IP, and use SMB authentication. (SMB is described later in this chapter.)

14.1.3. Packet Filtering Characteristics of RPC

It's very difficult to use packet filtering to control RPC-based services because you don't usually know what port the service will be using on a particular machine -- and chances are that the port used will change every time the machine is rebooted. Blocking access to the location server isn't sufficient. An attacker can bypass the step of talking to the location server and simply try all TCP and/or UDP ports (the 65,536 possible ports can all be checked on a particular machine in a matter of minutes), looking for the response expected from a particular RPC-based server like NFS or NIS.

Direction	Source Addr.	Dest. Addr.	Protocol	Source Port	Dest. Port	ACK Set	Notes
In	Ext	Int	UDP	>1023	111	[28]	Request, external client to internal Sun RPC location server
Out	Int	Ext	UDP	111	>1023		Response, internal Sun RPC location server to external client
Out	Int	Ext	UDP	>1023	111		Request, internal client to external Sun RPC location server
In	Ext	Int	UDP	111	>1023		Response, external Sun RPC location server to internal client
In	Ext	Int	TCP	>1023	111	[29]	Request, external client to internal Sun RPC location server
Out	Int	Ext	TCP	111	>1023	Yes	Response, internal Sun RPC location server to external client
Out	Int	Ext	TCP	>1023	111		Request, internal client to external Sun RPC location server
In	Ext	Int	TCP	111	>1023	Yes	Response, external Sun RPC location server to internal client
In	Ext	Int	UDP	>1023	135		Request, external client to internal Microsoft/DCE RPC location server
Out	Int	Ext	UDP	135	>1023		Response, internal Microsoft/DCE RPC location server to external client
Out	Int	Ext	UDP	>1023	135		Request, internal client to external Microsoft/DCE RPC location server
In	Ext	Int	UDP	135	>1023		Response, external Microsoft/DCE RPC location server to internal client
In	Ext	Int	TCP	>1023	135		Request, external client to internal Microsoft/DCE RPC location server
Out	Int	Ext	TCP	135	>1023	Yes	Response, internal Microsoft/DCE RPC location server to external client
Out	Int	Ext	TCP	>1023	135		Request, internal client to external Microsoft/DCE RPC location server
In	Ext	Int	TCP	135	>1023	Yes	Response, external Microsoft/DCE RPC location server to internal client
In	Ext	Int	UDP	>1023	Any		Request, external client to internal RPC server
Out	Int	Ext	UDP	Any	>1023		Response, internal RPC server to external client
Out	Int	Ext	UDP	>1023	Any		Request, internal client to external RPC server
In	Ext	Int	UDP	Any	>1023		Response, external RPC server to internal client
In	Ext	Int	TCP	>1023	Any		Request, external client to internal RPC server
Out	Int	Ext	TCP	Any	>1023	Yes	Response, internal RPC server to external client
Out	Int	Ext	TCP	>1023	Any		Request, internal client to external RPC server
In	Ext	Int	TCP	Any	>1023	Yes	Response, external RPC server to internal client

[28]UDP has no ACK equivalent.

[29]ACK will not be set on the first packet (establishing connection) but will be set on the rest.

Some newer packet filtering products can talk to the location server to determine what services are where and filter on that basis. Note that this has to be verified on a per-packet basis for UDP-based services. The packet filter will have to contact the location server every time it receives a packet, because if the machine has rebooted, the service may have moved. Because TCP is connection-oriented, the port number has to be verified only on a per-connection basis. Using this mechanism to allow UDP-based services is going to result in high overhead and is probably not wise for applications that perform a lot of RPC.

TIP: Even though it is not sufficient, you should still block access to the location server because some versions of the location server are capable of being used as proxies for an attacker's clients.

So, what do you do to guard RPC-based services? A couple of observations: First, it turns out that most of the "dangerous" RPC-based services (particularly NIS and NFS) are offered by default over UDP. Second, most services you'd want to access through a packet filter are TCP-based, not UDP-based; the notable exceptions are DNS, NTP, and syslog. These twin observations lead to the common approach many sites take in dealing with RPC using packet filtering: block UDP altogether, except for specific and tightly controlled "peepholes" for DNS, NTP, and syslog. With this approach, if you wish to allow any TCP-based RPC service in a given direction, you'll need to allow them all, or use a packet filter that can contact the location service.

Windows NT provides more control over the ports used by RPC. This will help if you want to allow remote clients to access your servers, but it will not help you allow internal clients to access external servers (unless you can talk the owners of the servers into modifying their machines). Most uses of RPC are actually uses of DCOM, which provides a user interface to configuring ports that is discussed later in this chapter. You can also control the size of the port range used by RPC directly. To limit the size of the port range, modify the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\RPC

so that the "Ports" key is set to the port range you wish to use, the "PortsInternetAvailable" key is set to "Y", and "UseInternetPorts" is also set to "Y".

The procedure for setting the port for a given service varies from service to service. It is sometimes documented in the manuals, and the Microsoft web site gives instructions on setting RPC ports for services that are particularly frequently used through firewalls. Again, most RPC services are DCOM services, and there is a user interface for changing DCOM parameters. It is worth checking the DCOM interface even if you see documentation that advises you to edit the registry directly.

If you set the port that a service uses, be sure to pick a port that is not in use by another server, and a port that is not at the beginning of the RPC port range. Since most servers choose the first free number in the RPC port range, a server that asks for a number very close to the beginning of the port range is quite likely to find it already in use. At this point, either the server will fail to start at all, because the RPC registration fails, or the server will select a random port and start on it. In either case, remote clients who are relying on the server being at a fixed port number will be unable to access it.

14.1.4. Proxying Characteristics of RPC

RPC is difficult to proxy for many of the same reasons that make it difficult to protect with packet filtering. Using RPC requires using the location service, and the proxy server needs to proxy both the location service and the specific service that is being provided. Figure 14-2 shows the process that an RPC proxy needs to go through.

Figure 14-2. Proxying RPC

Normal modified-client proxy systems, like SOCKS, do not support RPC, and no modified-procedure proxies are available for it. This means that there's no external way for the proxy to determine what server the client is trying to contact. Either the client has to be configured to speak RPC to the proxy server, which then always connects to the same actual server, or the proxy server must run as a transparent proxy service, where a router intercepts traffic, complete with server addresses, and hands them to the proxy.

A number of transparent proxy servers do support Sun RPC; a smaller number are now adding support for DCE/Microsoft RPC. Products vary in the amount of support they provide, with some providing all-or-none support, and others allowing you to specify which RPC services you wish to allow.

14.1.5. Network Address Translation Characteristics of RPC

None of the RPC versions uses embedded IP addresses; there is no inherent problem using them with network address translation systems that modify only host addresses. On the other hand, the information returned by the location service does include port numbers. Using RPC with a network address translation system that modifies port numbers will require a system that's able to interpret and modify the responses from the location server so that they show the translated port numbers. In addition, protocols built on top of RPC are free to exchange IP addresses or pay attention to source IP addresses as well as RPC information, so there is no guarantee that all RPC applications will work. In particular, both NIS and NFS use IP source addresses as authenticators and will have to be carefully configured to work with the translated addresses. As discussed in the next section, DCOM, which is the primary user of Microsoft RPC, uses embedded source addresses and will not work with network address translation.

14.1.6. Summary of Recommendations for RPC

• Do not allow RPC-based protocols through your firewall.