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.