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:
- MAPI (used by Microsoft Exchange).
- Remote Administration (e.g., starting a service on a system running Microsoft Windows, Remote access: RPC)
- internal usage (e.g., TechNet: “What is RPC?” says RPC can be used for, “system services within the computer communicating with each other.” This “is especially common. Much of the Windows architecture is composed of services that communicate with each other to accomplish a task. Most services built into the Windows architecture use RPC to communicate with each other.” (The page goes on to “briefly describes the services in Windows Server 2003 that depend on the RPC system service (RPCSS).” That includes Microsoft's built-in implementation of services such as DHCP, DNS, Print Spooler, and TELNET.)
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
: “BUGS” section states, “If
crashes, all servers must be restarted.” (Of course, that manual page is only referring to servers that use
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
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:
The script seems to refer to a PF table named “
trusted”, which would need to be defined in PF.
is hard-coded to a specific NIC, so that needs to be updated).
- Furthermore, this script is meant to run on the system that will be trying to access the RPC-related services. If there is a firewall between the NFS client and the NFS server, then that firewall may also need to have some dynamic rules applied, requiring more modifications to the script.
The use of
is completely unnecessary
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
- Some HP documentation notes, “In Tru64, the "nfs" service is always in port 2049, which is the standard convention. The "mountd" uses a privileged port by default, i.e. a port number that is less than 1024. The rest of the SunRPC servers use unprivileged ports, i.e. port numbers 1024 or greater.”
- OpenBSD manual section 5: rpc (the /etc/rpc file (the /etc/rpc is also mentioned by Some HP documentation).