Port 111 – RPCbind / Portmapper

Port 111 is the default port for rpcbind (also called the portmapper or portmap), the ONC RPC service that tells clients which TCP or UDP port a given RPC program is listening on. When a program like NFS or mountd starts, it registers its program number and current port with rpcbind; a client then asks rpcbind on port 111 “where is program 100005?” and gets back a port to connect to. That directory role is exactly why port 111 is worth checking first — one query to it maps out every RPC service on the host.

Why It’s Open

You’ll find rpcbind on almost any Unix or Linux box running ONC RPC services: NFS file servers, NIS/yp directories, rquotad, statd, and the mountd daemon that hands out NFS exports. It ships enabled on most traditional server distros and on a lot of NAS appliances, storage arrays, and older Solaris/AIX/HP-UX systems. Admins rarely think about it directly — they enable NFS, and rpcbind comes along as a dependency. Where you see port 111 open, NFS on port 2049 is usually one hop away, and the dynamically-assigned RPC ports it points to often land in the 32771+ range.

Common Risks

• Service map disclosure. A single rpcinfo query returns every registered RPC program, its version, and its live port. That’s a free inventory of what’s exploitable behind the portmapper — NFS, mountd, statd — without touching those services directly.
• NFS as the real target. Port 111 is the front door; the prize is usually NFS. Once rpcbind reveals mountd, showmount -e lists the exports, and a world-readable or no_root_squash share turns into file theft or a root pivot.
• UDP amplification / DDoS reflection. rpcbind answers spoofed UDP queries with a much larger response. Attackers use internet-exposed portmappers as reflectors — a 68-byte query pulls back up to ~1,930 bytes (roughly 7–28× amplification), so an open port 111 makes your host a weapon aimed at someone else.
• Denial of service on the daemon itself. Crafted packets have crashed or exhausted rpcbind outright — see the rpcbomb memory-exhaustion bug (CVE-2017-8779) and the PMAP_CALLIT use-after-free (CVE-2015-7236) below.
• Legacy RPC daemons behind it. The services rpcbind advertises are frequently ancient. mountd, statd (rpc.statd), and ypserv have a long history of remote root bugs, and rpcbind is what tells an attacker they’re present and reachable.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 111 <target>

Scan both transports and run the rpcinfo NSE script

nmap -sSUC -p 111 <target>
nmap -sSU -p 111 --script=rpcinfo <target>

Dump the RPC program map with the native client

rpcinfo -p <target>
rpcinfo -T udp <target>

Look for mountd, nfs, status, and nlockmgr in the output — each is a service to follow up on, and the reported port is where it’s actually listening.

Pivot to NFS if mountd is registered

showmount -e <target>
nmap -p 111,2049 --script=nfs-showmount,nfs-ls,nfs-statfs <target>

Enumerate with Metasploit

msfconsole -q
use auxiliary/scanner/misc/sunrpc_portmapper
set RHOSTS <target>
run

Test the rpcbomb denial-of-service condition (CVE-2017-8779)

msfconsole -q
use auxiliary/dos/rpc/rpcbomb
set RHOSTS <target>
run

Record every registered program and reachable export you confirm so it lands in the final pentest report rather than a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2017-8779 — “rpcbomb.” rpcbind through 0.2.4 and libtirpc through 1.0.1 don’t cap RPC data size when allocating memory for XDR strings, so a crafted UDP packet to port 111 makes the daemon allocate large chunks it never frees. Remote, unauthenticated memory-exhaustion DoS (CVSS 7.5). Public PoC at Exploit-DB 41974 and a Metasploit module.
• CVE-2015-7236 — Use-after-free in xprt_set_caller (rpcb_svc_com.c) in rpcbind 0.2.1 and earlier. A remote attacker crashes the daemon with crafted packets that abuse the PMAP_CALLIT procedure — the same indirect-call feature that also drives the UDP amplification abuse.
• CVE-1999-0002 — Buffer overflow in NFS mountd giving remote root, mostly on Linux. It isn’t a bug in rpcbind itself, but it’s the classic reason attackers query port 111 first: the portmapper points them straight at the vulnerable mountd behind it. A reminder that the portmapper’s risk is mostly the services it advertises.

Mitigation

• Don’t expose port 111 to the internet. Firewall it (and the NFS/mountd ports it maps) to the storage network or trusted hosts. rpcbind on a public interface is almost never intentional.
• Restrict rpcbind directly. Use -h to bind it to specific interfaces, and lock it down with /etc/hosts.allow / hosts.deny (tcpwrappers) so only known clients can query it.
• Kill the UDP reflection vector. If you don’t need remote RPC, block UDP/111 at the edge; portmapper reflection only works because spoofed UDP queries reach the daemon.
• Move to NFSv4 where you can. NFSv4 folds mounting into the protocol on port 2049 and no longer needs the portmapper or the separate mountd/statd ports, shrinking the attack surface.
• Patch rpcbind and libtirpc. Run versions past the rpcbomb and PMAP_CALLIT fixes (rpcbind > 0.2.4, libtirpc > 1.0.1).
• Turn off unused RPC services. If NFS/NIS aren’t in use, stop and disable rpcbind entirely — then confirm port 111 is closed with a rescan.

Real-World Example

In August 2015, Level 3 (later CenturyLink) reported that attackers had started abusing internet-exposed portmappers as DDoS reflectors. Because rpcbind answers a tiny spoofed UDP query with a much larger reply, a single 68-byte request could pull back up to 1,930 bytes — an amplification factor of roughly 7 to 28× — and there were well over a million reachable rpcbind servers to bounce traffic off. It was a textbook lesson in why a “harmless” directory service left open on UDP turns into everyone else’s problem: the operators of those portmappers weren’t the target, just the unwitting amplifiers.

FAQ

What service runs on port 111?

rpcbind, also known as the portmapper or portmap. It’s the ONC RPC service that maps RPC program numbers to the TCP/UDP ports those programs currently listen on, so clients can find services like NFS and mountd.

Is port 111 dangerous?

Open by itself it mostly leaks information — a single rpcinfo query enumerates every RPC service on the host. The real danger is what it points to (usually NFS and mountd) and its use as a UDP amplification reflector. An internet-facing port 111 should be firewalled or closed.

What’s the difference between port 111 and NFS on port 2049?

Port 111 is the lookup service: it tells a client where NFS and its helper daemons are listening. Port 2049 is where NFS actually serves files. In NFSv4 the mounting logic moved onto 2049 itself, so the portmapper on 111 is no longer required.

How do I close port 111?

If nothing on the host uses ONC RPC, stop and disable the rpcbind/portmap service and rescan to confirm it’s closed. If you need NFS, keep rpcbind bound to internal interfaces only, firewall port 111 to trusted hosts, or move to NFSv4 which doesn’t need it.

TL;DR

• Service: rpcbind / portmapper (ONC RPC port mapper)
• Default port: 111/TCP and 111/UDP
• Biggest risk: RPC service enumeration, an NFS pivot via mountd, and UDP amplification DDoS
• Mitigation: firewall or disable port 111, restrict rpcbind to trusted hosts, patch rpcbind/libtirpc, and prefer NFSv4