portmap/rpcbind

portmap/rpcbind
Name	portmap / rpcbind
Developer	Various (Sun Microsystems; OpenBSD; GNU; others)
Released	1980s
Repository	Multiple
Operating system	Unix-like systems
License	Varied (Proprietary, BSD, GPL)

portmap/rpcbind portmap and rpcbind are network daemons that map Remote Procedure Call (RPC) program numbers to transport endpoints, enabling clients to locate RPC services on Unix-like systems. They originated in early Sun Microsystems networking stacks and have been maintained and reimplemented by projects associated with OpenBSD, NetBSD, FreeBSD, GNU Project, and various Linux distributions. The daemons interact with system components that provide RPC-based services such as NFS, NIS, Kerberos, and other legacy protocols.

Overview

The service listens on well-known ports and responds to client queries, returning the port and transport (TCP/UDP) where a requested RPC program is available. Historically, the functionality was provided by a single daemon often called portmap; more modern implementations are known as rpcbind and may support additional protocols such as IPv6 and RPC-over-HTTP. portmap/rpcbind forms part of stacks that include server implementations for Network File System, directory services like Yellow Pages (NIS), authentication systems such as Kerberos (protocol), and management tools from vendors including Sun Microsystems and distributions like Debian and Red Hat Enterprise Linux.

History and Development

portmap emerged in the 1980s as part of the SunOS and Solaris ecosystems to support the ONC RPC framework developed by Sun Microsystems engineers. As RPC usage expanded through systems including HP-UX, AIX, and early BSD releases, the daemon was reimplemented and forked across projects such as NetBSD and FreeBSD. During the 2000s, security concerns and protocol extensions motivated redesigns and a rename to rpcbind in many distributions; notable maintainers have included the GNU Project for glibc-related utilities and contributors associated with OpenBSD for hardened implementations. The evolution intersects with historical events in networking such as the proliferation of TCP/IP standards and the adoption of IPv6.

Protocol and Operation

Clients discover RPC services by sending queries to the daemon's reserved port; in legacy systems this was a TCP/UDP well-known port registered via standards bodies and implemented by stacks like BSD sockets and glibc. The mapping binds a 32-bit RPC program number to an address/port tuple; these mappings are used by services such as NFS v2/NFS v3 and name services like NIS+. rpcbind supports operations for version negotiation, transport specification (IPv4, IPv6, TCP, UDP), and may implement authentication steps tied to systems like Kerberos 5 or rely on transport-layer controls implemented in kernels from vendors such as Linux kernel and OpenSolaris. The protocol is defined in RFCs and historical Sun documentation adopted across implementations in X/Open-compliant environments.

Security Issues and Vulnerabilities

Because the daemon reveals service endpoints, it has been a target for information disclosure and remote-code-execution exploits documented by security teams at organizations such as CERT and vendors like Red Hat. Misconfiguration can enable amplification in DDoS attacks or facilitate lateral movement for attackers exploiting services such as NFS or exposed RPC-based management interfaces. Implementations have contained buffer overflows and integer-handling bugs reported in advisories from CVE records and mitigated via patches from projects like OpenBSD and Debian Security. Best practices promoted by institutions such as US-CERT and distribution maintainers include restricting access via firewall rules (e.g., iptables, pf) and using modern replacements or protocol wrappers where possible.

Configuration and Administration

Administrators manage portmap/rpcbind through system init scripts, service units on systemd, or legacy init systems like SysVinit and init(8). Configuration touches include enabling or disabling IPv6 support, binding to specific interfaces, and integrating with access control mechanisms such as TCP Wrappers or kernel-level packet filters like Netfilter. Service discovery in dynamic environments may be coordinated with configuration management tools authored by projects such as Ansible, Puppet, and Chef to ensure consistent firewall rules and to disable unnecessary RPC programs. Logging typically integrates with syslogd implementations and audit systems including auditd.

Implementations and Platform Support

Multiple implementations exist: the original from Sun Microsystems (bundled in Solaris), reimplementations in BSD distributions (FreeBSD, NetBSD, OpenBSD), and userland packages for Linux distributions maintained by GNU-affiliated projects or distribution maintainers at Debian, Red Hat, and SUSE. Some implementations provide compatibility shims for environments managed by Cygwin on Microsoft Windows and integration layers for virtualization stacks like VMware ESXi and Xen Project tools. Packaging and update mechanisms rely on systems such as RPM and DEB repositories.

Alternatives and Deprecation

Because portmap/rpcbind exposes service discovery semantics that are problematic in modern security models and cloud deployments, migrations favor alternatives like service orchestration provided by systemd, RPC-over-HTTP(S) proxies, or entirely different IPC mechanisms exemplified by gRPC and D-Bus for local IPC. Some projects recommend disabling rpcbind and using static ports or firewall-based port-mapping enforced by orchestration platforms like Kubernetes or OpenStack. Several distributions have deprecated automatic enabling of the daemon; maintainers from Ubuntu and Red Hat have published guidance on phasing out rpcbind in favor of secure, authenticated service discovery layers.

Category:Network daemons Category:Remote procedure call