rpcbind is opening port 873 UDP but rpcinfo -p shows no program bound to that port

Question

I'm looking at lsof -i output on several Linux servers in our environment and finding that rpcbind opens the usual port 111 in both TCP and UDP protocols, but also opens port 873 UDP for no apparent reason. This is raising security flags because port 873 is assigned to rsyncd, and our policy requires rsync to use ssh transport (rsyncd performs no encryption and authentication is by trust relationships only).

Usually when I'm suspicious of an RPC process, I look it up in rpcinfo -p to see which service is actually opening the port. However, on these servers, I only see port 111 for the portmapper and high-numbered ports for status and nlockmgr, with port 873 nowhere to be seen.

I've seen a lot of bug reports out there (including RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=103401 and kernel: https://patchwork.kernel.org/patch/10153769/) saying that the culprit is the bindresvport() function in glibc, but that function can't be changed there without massive breakage. I've seen three different solutions suggested:

• RHEL provides a daemon called portreserve to pre-allocate these ports before rpcbind starts. This doesn't help me because it guarantees these ports are open, which we don't want for security reasons.
• Debian and its progeny implement a configuration file at /etc/bindresvport.blacklist which would be ideal for our purposes, except for the fact it appears to be undocumented and subject to being stepped on by the distribution.
• The nfs-utils package upstream of the distributions honors /etc/services and doesn't bind to registered ports.

What I'm trying to nail down, though, is why would rpcbind be opening the extra port in the first place, and how can it be prevented? All I have checked so far seems to indicate that the port is assigned randomly at boot time, and restarting the server has been shown to push it to a different port, but that's no way to operate.

Answer 1

Actually only versions present up to Debian 9 or RHEL 7 have this problem, not Debian 10 or RHEL 8. The feature causing the random privileged UDP port binding has been disabled in rpcbind 1.2.5, the release coming after 0.2.3 and 0.2.4.

From Debian 10.1+'s /usr/share/doc/rpcbind/README.Debian:

Since version 1.2.5 due to security concerns upstream has turned off the remote calls functionality by default and added a configuration flag at build time to enable it.

This functionality caused rpcbind to open up random listening ports. With remote calls turned off rpcbind stops to receive any broadcast query causing breakage on systems depending on this feature, e.g., NIS systems.

On Debian systems the remote calls can be turned on at run-time using the command line argument 'r'. See rpcbind(8) for more details.

I could verify on Debian 9 that (forcefully) upgrading rpcbind to Debian 10's version is enough to lose the additional privileged bound port. Using the new Debian-specific -r option provided by a Debian patch (which mostly recompiles with --enable-rmtcalls and adds a runtime option) "restores" the feature, except it appears the bound UDP port is not privileged anymore.

Usage of this remote call feature is with rpcinfo -b (or Kodi) to send broadcast queries to all LAN's portmappers. Eg to discover RPC prognum 100005 version 3 (for NFSv3's mountd):

rpcinfo -b 100005 3

This will send a broadcast to port 111/UDP and the replying portmappers will use the additionally bound UDP port as source (in a typical firewall-unfriendly method similar to TFTP). Without this port, they won't answer, but can still answer direct unicast queries directly from port 111/UDP as usual.