RPC security ports

Overview: About random TCP usage

RPC Security Through TCP Port Handling/Control

The RPC protocol has probably been most recognizably popular for being used in one of these rather completely different ways:

This article is likely to focus more on NFS and MAPI.

Both of these protocols involve transferring data that many people would like to be protected, but may do so without encryption. Although this article was originally written to discuss NFS, the reasons likely also apply to MAPI and possibly other traffic that uses RPC. So, as quotations are read about NFS, realize that these concepts are not really very specific to NFS and can also apply to other RPC-using protocols.

Overview: How Port Mapper works

Programs that use the “Port Mapper” service will use a protocol called “Open Network Computing Remote Procedure Call” (“OPN RPC”), frequently just called “RPC”, and use that protocol while communicating over TCP port 111 or UDP port 111, which are the ports where the “Port Mapper” service listens for traffic. Other names for such protocols include “rcp.portmap” or simply “portmap”. After version 2 of the protocol, version 3 was given an additional name, “rcpbind”.

The job of the “Port Mapper” service is to help a (client) program that uses “RPC” to determine what TCP ports and/or UDP ports a server is listening on.

OpenBSD man page for portmap: “BUGS” section states, “If portmap crashes, all servers must be restarted.” (Of course, that manual page is only referring to servers that use portmap.)

Using NFS is designed to require trust. Apparently NFS's usage of Port Mapper was meant as a security feature, by randomizing the TCP ports in order to make it harder for an attacker to know what port to attack. The end result is a protocol that isn't really much harder for a skilled attacker to determine what port is desired, but is infeasible to protect using the standard method of relying on a firewall to block a small number of TCP ports.

Since then, some NFS implementations have added features to be able to control which TCP ports to use. Red Hat Enterprise Linux documentation: Running NFS Behind a Firewall shows some configuration options that affect TCP and UDP ports with NFS. Scott Francis's first post on an OpenBSD-Misc “mailing list” thread on passing NFS traffic through a firewall notes that FreeBSD and NetBSD “both offer the -p option”.

However, Theo DeRaadt, who is in charge of the OpenBSD project, did not like such an option. In Theo DeRaadt's first post in an OpenBSD-Misc “mailing list” thread on passing NFS traffic through a firewall, he stated, “there are a whole lot of vile issues, and quite frankly there is not much security to be gained from this.  You cannot really provide any real security on a local net when doing RPC at the same time.” In Another post by Theo DeRaadt in the same OpenBSD-Misc “mailing list” thread on passing NFS traffic through a firewall, Theo noted about the -p option found in FreeBSD and NetBSD “I think that is completely ridiculous.  Hardcoding RPC utilities to non-random ports .... to try to tie it to something else, to increase your security.” The basic argument seems to be that NFS is considered insecure enough that a firewall is not sufficient protection for this traffic. A post by fellow OpenBSD developer Ted Unangst, in this OpenBSD-Misc “mailing list” thread on passing NFS traffic through a firewall explains that he categorizes

nfs traffic into the "stuff not supposed to be going through the firewall" category.  a firewall implies there are bad people on one side of it, and you don't want bad people to access nfs, ever.

The only approach that seems acceptable is his next statement, “i'd use a vpn of some sort to tunnel through the firewall.” In fact, that approach is documented by OpenBSD FAQ on Simple NFS usage, which states, “If you are allowing outside access to your NFS server, and you have any kind of sensitive data stored on it, we strongly recommend that you employ IPsec. Otherwise, people can potentially see your NFS traffic. Someone could also pretend to be the IP address which you are allowing into your NFS server. There are several attacks that can result. When properly configured, IPsec protects against these types of attacks.”

A forum post by jggimi notes, “desire to move your data in plaintext beyond a firewall, which assumes over an insecure network, and this is considered a bad decision.” (The term “plaintext” is likely meant to simply refer to being unencrypted.)

This isn't to say that nobody has ever tried. A post in OpenBSD-Misc “mailing list” thread on passing NFS traffic through a firewall points out a method for using OpenBSD to parse NFS-related ports for dynamic PF anchors. The related script appears to need some customization:

This guide decided not to develop this solution any further, thereby investing in an approach that multiple OpenBSD developers seemed uncomfortable with (from security-related conerns). Instead, this guide is going to simply assume that all machines involved in the NFS communication are trusted, or that they are unable to interpret traffic payload because they are simply relaying traffic encrypted using some method like IPsec. The result is that this guide is going to use some overly-broad permissions. People who are not comfortable with these overly-broad permissions are encouraged to use a different protocol, or use a network design that does secure things well enough for the overly-broad permissions to be acceptable. Of those options, using a different protocol will probably be the more sensible approach, in many cases.

Further commentary/resources