RPC portmapper Service Detection (Nessus plugin 10223) means the host answers ONC RPC portmapper queries on TCP or UDP port 111, which lists the RPC services running on it. If nothing uses NFSv3 or NIS, disable and mask rpcbind.socket and rpcbind.service. If NFS needs it, allow port 111 only from NFS clients and block it at the Internet edge.
What the scanner is actually detecting
The finding comes from Tenable Nessus plugin 10223, titled RPC portmapper Service Detection, in the RPC plugin family. It is a remote, unauthenticated check: the scanner sends a portmapper request to port 111 and records that something answered. Tenable’s description is short: the portmapper lets anyone retrieve the port number of each RPC service on the host, either with repeated lookup requests or with a single DUMP request.
| Field | Value on the Tenable plugin page |
|---|---|
| Plugin name | RPC portmapper Service Detection |
| Plugin ID | 10223 |
| Severity | Info (CVSS v2 and v3 base score 0) |
| Reference | CVE-1999-0632 |
On Linux the service behind it is rpcbind, the successor to the old portmap daemon. The rpcinfo man page notes that version 2 of the rpcbind protocol was previously known as the portmapper protocol, which is why scanners still use the older name. Because this is a network-only check, it cannot tell you which package owns the port or whether anything depends on it. A credentialed scan can, which is one of the practical differences covered in credentialed vs uncredentialed scanning.
Real-world risk
On its own this is an informational finding, and Tenable scores it that way. The reasons to act anyway are concrete:
- Reconnaissance. One query returns every registered RPC program and its port, such as nfs, mountd, nlockmgr, status or ypserv. That tells an attacker which higher-risk services to probe next.
- rpcbind UDP amplification. The US-CERT/CISA alert TA14-017A on UDP-based amplification attacks lists Portmap (RPCbind) with a bandwidth amplification factor of 7 to 28. An rpcbind reachable over UDP from the Internet can be used to reflect traffic at a third party.
- Daemon attack surface. rpcbind itself has had flaws. CVE-2017-8779 (“rpcbomb”) let a crafted UDP packet to port 111 cause memory exhaustion in rpcbind through 0.2.4 and affected libtirpc versions.
Priority depends on reachability. Port 111 open to the Internet deserves a fix this week. Port 111 open only inside a server VLAN is cheap hardening that you can schedule normally.
How to confirm it on the host
Start on the host itself to see what owns the port and whether anything uses it:
# Who is listening on 111? If the process list shows systemd, rpcbind.socket holds it
ss -tulpn 'sport = :111'
systemctl status rpcbind.socket rpcbind.service
# Which RPC programs are registered?
rpcinfo -p localhost
# Is NFS or NIS in use here?
findmnt -t nfs,nfs4
cat /proc/fs/nfsd/versions 2>/dev/null
systemctl list-units --type=service | grep -Ei 'nfs|rpc|ypbind|ypserv'
# What depends on the package?
rpm -q --whatrequires rpcbind # RHEL, Rocky, Alma, Fedora
apt-cache rdepends --installed rpcbind # Debian, UbuntuThen test from another machine, ideally from the scanner’s network segment:
# TCP dump of registered programs (portmapper protocol version 2)
rpcinfo -p <host>
# UDP call to the portmapper program itself (program 100000)
rpcinfo -u <host> 100000
# Nmap: the rpcinfo NSE script on TCP and UDP 111 (UDP scan needs root)
nmap -sU -sT -p 111 --script rpcinfo <host>If rpcinfo -p returns a program list from a remote host, the finding is valid for that network path.
How to fix it
Linux with systemd, rpcbind not needed
If the host is not an NFSv3 server or client and does not use NIS, disable rpcbind. Disable the socket as well as the service: with socket activation, systemd keeps listening on 111 and starts rpcbind again on the next request.
systemctl disable --now rpcbind.socket rpcbind.service
systemctl mask rpcbind.socket rpcbind.serviceMasking stops the units from being started manually or pulled in as a dependency. If you prefer to remove the software, read the dependency list your package manager prints before confirming:
dnf remove rpcbind # RHEL, Rocky, Alma, Fedora
apt purge rpcbind # Debian, UbuntuOn Debian 12, nfs-common declares a dependency on rpcbind, so purging rpcbind also removes the NFS client tools.
NFS server that can move to NFSv4 only
Red Hat lists rpcbind as a service required for NFS version 3, and its RHEL 9 procedure for an NFSv4-only server masks it. In /etc/nfs.conf:
[nfsd]
vers3=nThen disable the NFSv3 helpers and stop rpc.mountd from listening for NFSv3 mount requests:
systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
mkdir -p /etc/systemd/system/nfs-mountd.service.d
cat > /etc/systemd/system/nfs-mountd.service.d/v4only.conf <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/sbin/rpc.mountd --no-tcp --no-udp
EOF
systemctl daemon-reload
systemctl restart nfs-mountd
systemctl restart nfs-server
cat /proc/fs/nfsd/versions # expect -3 in the outputEvery client must then mount with NFSv4. Check findmnt -t nfs on clients first, because a vers=3 mount will fail after this change.
rpcbind still needed: block port 111 except for NFS clients
For NFSv3 servers, NIS and other ONC RPC services you cannot retire, restrict TCP and UDP 111 to the hosts that need it. With firewalld (RHEL family), replace the open rpc-bind service with a source-restricted rule:
firewall-cmd --permanent --remove-service=rpc-bind
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="rpc-bind" accept'
firewall-cmd --reloadAdd –zone= if rpc-bind was opened in a zone other than the default, and add an ipv6 rule if clients use IPv6. With ufw (Ubuntu), the first matching rule wins, so add the allow before the deny:
ufw allow from 192.0.2.0/24 to any port 111
ufw deny 111Separately, block inbound TCP and UDP 111 at the Internet edge. The CERT amplification alert’s advice is to disable unwanted services or deny access to local services over the Internet, and there is rarely a reason for rpcbind to be reachable from outside.
The rpcbind man page documents a -h option to limit the addresses it answers UDP on, but notes that -h is ignored under systemd socket activation. You would instead change the ListenStream and ListenDatagram lines of rpcbind.socket (use systemctl edit rpcbind.socket rather than editing the vendor file). Firewall rules are usually easier to audit.
FreeBSD
The FreeBSD Handbook enables rpcbind for NFS with rpcbind_enable=”YES” in /etc/rc.conf. If the host does not serve or mount NFS, turn it off:
sysrc rpcbind_enable="NO"
service rpcbind stopAppliances
NAS units, storage arrays and some embedded devices run their own portmapper when NFS is enabled. Disable NFS (or NFSv3) in the vendor’s management interface if it is unused; otherwise restrict port 111 with a network ACL in front of the device.
How to verify the fix and rescan
- On the host, ss -tulpn ‘sport = :111’ should return nothing if you disabled rpcbind.
- systemctl is-enabled rpcbind.socket rpcbind.service should report masked. Reboot during the next maintenance window and check again.
- From a remote machine outside the allowed range, rpcinfo -p <host> and rpcinfo -u <host> 100000 should fail with a refused connection or a timeout.
- If you used the firewall option, repeat the same test from an NFS client. It should still succeed, and the NFS mounts should still work.
- Rescan with the same Nessus scanner. If that scanner sits inside the allowed subnet, plugin 10223 will still fire by design. Either scan from an untrusted segment as well or record the exception.
What can break and how to roll back
- NFSv3 exports and mounts: clients cannot look up the mountd and NFS ports, and NFSv3 locking stops working.
- NIS: ypbind and ypserv register with rpcbind, so NIS lookups and logins that depend on them fail.
- Package removal: removing rpcbind can take nfs-common or similar packages with it.
- Firewall scope: NFS clients outside the allowed subnet lose access, typically with mount timeouts rather than clear errors.
To roll back a disable or mask:
systemctl unmask rpcbind.socket rpcbind.service
systemctl enable --now rpcbind.socket rpcbind.serviceTo roll back the NFSv4-only change, set vers3=y in /etc/nfs.conf, delete the v4only.conf drop-in, run systemctl unmask rpc-statd.service rpcbind.service rpcbind.socket, then systemctl daemon-reload and restart nfs-mountd and nfs-server. Reinstall removed packages with dnf install rpcbind nfs-utils or apt install rpcbind nfs-common.
Common false positive reasons
- Another device answered. NAT or a port forward can send port 111 to a firewall, NAS or appliance rather than the server named in the report.
- The scanner is trusted. After a firewall-based fix, a scanner inside the allowed range still sees the portmapper. The finding is accurate for that source but no longer reflects exposure from other networks.
- Only the service was stopped. This is not a false positive: rpcbind.socket restarted rpcbind on the scanner’s request. Disable the socket too.
- Stale results. The report predates the change, or the host was rebuilt from an image that still enables rpcbind.
FAQ
Is RPC portmapper Service Detection a vulnerability?
Not by itself. Nessus rates plugin 10223 as Info with a CVSS base score of 0. It reports an exposed service that helps reconnaissance and, over UDP from the Internet, can be abused for amplification.
Why does rpcbind come back after I stop it?
systemd socket activation. rpcbind.socket keeps port 111 open and starts rpcbind.service on the next request. Run systemctl disable –now rpcbind.socket rpcbind.service and mask both.
Does an NFSv4 server need rpcbind?
Red Hat’s documented NFSv4-only server procedure masks rpcbind, rpc-statd and the socket. NFSv3 servers and clients that rely on NFSv3 locking still need it, so check every client’s mount version first.
Is blocking port 111 enough?
It stops remote portmapper queries. Services such as mountd and statd listen on their own ports, so restrict those to NFS clients as well.
Tracking this finding across many hosts
Port 111 findings tend to appear on many Linux servers at once, and each needs a check of whether NFS is really in use. A platform such as SITEY can import Nessus results (as an uploaded .nessus export) and OpenVAS results, draft a host-specific rpcbind change that runs only after human approval through its Linux agent, and re-test each Nessus finding to confirm it closed. If you run agent-based or SSH scans alongside it, our guide to a Linux authenticated scan with SSH and sudo covers the account setup.