Port 111: Portmapper — The Switchboard Operator of Unix

Port 111 carries the portmapper service, and it answers the question that makes distributed Unix possible: "Where can I find the service I need?"

Every time a Unix machine mounts a remote filesystem, locks a remote file, or calls a remote procedure, the conversation begins at port 111. The portmapper is the directory service for the entire Remote Procedure Call (RPC) ecosystem. It's been running since 1985, and it's still running on millions of machines today.

What Port 111 Does

The portmapper (also called rpcbind on modern systems) maintains a registry of all RPC services running on a machine.¹ When an RPC service starts, it registers itself with the portmapper, announcing its program number, version, and the port it's listening on.

When a client wants to connect to an RPC service, it first contacts port 111 and asks: "What port is service X listening on?" The portmapper responds with the port number, and the client connects directly to that service.

This indirection exists because RPC services don't have fixed port numbers. NFS might run on port 2049, but the mount daemon (mountd) and lock manager (nlockmgr) could be on any available port. The portmapper is the only fixed point, the one address everyone agrees on.²

Here's what a typical exchange looks like:

Client → Port 111: "Where is the mount daemon (program 100005)?"
Portmapper → Client: "Port 32767, TCP"
Client → Port 32767: "Please mount /exports/data"

How the Portmapper Works

The portmapper speaks a simple protocol. It understands four basic operations:³

1. PMAPPROC_SET: Register a new service
2. PMAPPROC_UNSET: Unregister a service
3. PMAPPROC_GETPORT: Look up a service's port
4. PMAPPROC_DUMP: List all registered services

When you run rpcinfo -p on a Unix system, you're asking the portmapper to dump its entire registry. The output looks like this:

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100005    3   tcp  32767  mountd
    100021    4   tcp  32768  nlockmgr

Each line is a registered service: its program number, version, protocol, port, and human-readable name. The portmapper itself is program number 100000, always on port 111.

The History

The portmapper was born at Sun Microsystems in 1984 as part of the most ambitious distributed computing project of its era: the Network File System (NFS).⁴

Sun's engineers faced a fundamental problem. They wanted Unix machines to share files transparently across a network, making remote filesystems look like local ones. But Unix had no native facility for remote procedure calls. If you wanted a remote machine to execute a function for you, you had to write your own protocol from scratch.

The team, including Russel Sandberg, Bob Lyon, Bill Joy, Steve Kleiman, and Tom Lyon, built three interlocking technologies:⁵

• XDR (External Data Representation): A standard way to serialize data across different machine architectures
• RPC (Remote Procedure Call): A protocol for calling functions on remote machines
• NFS: The filesystem that used RPC to make remote files look local

The portmapper was the glue. RPC services needed a way to advertise their existence, and clients needed a way to find them. Port 111 became that central registry.

Sun's RPC was influenced by Xerox's Courier protocol from 1981,⁶ and by the seminal paper "Implementing Remote Procedure Calls" by Andrew Birrell and Bruce Nelson at Xerox PARC.⁷ But Sun's implementation became the standard because of one crucial decision: they gave it away. Sun published the protocol specifications openly and encouraged other vendors to implement it.

The first version appeared in SunOS 2.0 in May 1985.⁸ RFC 1050 documented version 2 of the protocol in April 1988, and RFC 1057 followed in June 1988 with clarifications and updates.⁹

The Services That Depend on Port 111

The portmapper is rarely the destination. It's the starting point. These are the services that register with it:¹⁰

• NFS (program 100003): The Network File System itself, usually on port 2049
• mountd (program 100005): Handles mount requests from clients
• nlockmgr (program 100021): File locking across the network
• rquotad (program 100011): Disk quota management
• statd (program 100024): Crash recovery for file locks

In NFSv3 and earlier, all of these services communicate through the portmapper. A client mounting a remote filesystem goes through this sequence:

1. Query port 111 for the mount daemon's port
2. Ask the mount daemon for permission to mount
3. Query port 111 for the NFS daemon's port
4. Read and write files through the NFS daemon

NFSv4, released in 2003, eliminated most of this complexity. It uses only port 2049 and doesn't require the portmapper.¹¹ But NFSv3 is still in production across millions of systems, and port 111 keeps answering.

Security

The portmapper was designed for a world of trusted networks. It answers any query from any source, revealing every RPC service running on the machine. This was considered a feature in 1985.

It is not considered a feature now.

Information Disclosure

Running rpcinfo -p against a remote host tells you exactly what services are available and what ports they're using. For an attacker, this is reconnaissance gold. The portmapper will happily tell you if NFS is running, if the lock manager is exposed, if any vulnerable RPC service is listening.¹²

DDoS Amplification

In August 2015, Level 3 Communications discovered that attackers were abusing the portmapper for DDoS amplification attacks.¹³ The attack works like this:

1. Attacker sends a small query (68 bytes) to the portmapper, spoofing the victim's IP address
2. Portmapper sends a much larger response (up to 1,930 bytes) to the victim
3. Multiply by 1.1 million exposed portmapper servers

The amplification factor can reach 28x. Level 3 found over a million portmapper servers exposed to the Internet, all of them potential amplifiers.¹⁴

Historical Vulnerabilities

The portmapper and its successor rpcbind have accumulated vulnerabilities over the decades:

• CVE-2017-8779 (RPCBomb): A crafted UDP packet could cause unbounded memory allocation, crashing the service¹⁵
• CVE-2015-7236: Use-after-free vulnerability allowing remote denial of service
• Various symlink attacks: Local privilege escalation through temp file manipulation

Mitigation

The portmapper should never be exposed to the Internet. If you need NFS, use NFSv4 (port 2049 only). If you must use NFSv3, firewall port 111 to trusted networks only.

On Linux systems where the service isn't needed:

# Debian/Ubuntu
apt-get remove rpcbind

# RHEL/CentOS
systemctl disable rpcbind
systemctl stop rpcbind

The Protocol Details

The portmapper uses RPC itself, because of course it does. It's program number 100000, version 2, 3, or 4, listening on port 111 over both TCP and UDP.¹⁶

Each RPC message contains:

• A transaction ID (XID) for matching requests to responses
• A message type (call or reply)
• The RPC version (always 2 for this protocol)
• The program number, version, and procedure being called
• Authentication credentials (often AUTH_NONE for the portmapper)
• The procedure arguments, encoded in XDR

The portmapper's own program and procedure numbers are defined as constants:

const PMAP_PORT = 111;
const PMAP_PROG = 100000;
const PMAP_VERS = 2;

/* Procedures */
const PMAPPROC_NULL = 0;
const PMAPPROC_SET = 1;
const PMAPPROC_UNSET = 2;
const PMAPPROC_GETPORT = 3;
const PMAPPROC_DUMP = 4;
const PMAPPROC_CALLIT = 5;

Related Ports