Remote Procedure Call (RPC)

In the mid-1980s, Sun developed the Remote Procedure Call (RPC).
This allows a program running on one computer to transparently
execute a function that is running on another computer.
Soon the U of California at Berkeley developed an implementation
of RPC.

Sun's RPC uses a system called XDR (external data representation)
to represent binary information in a uniform manner and bit order.

Sun developed a program called portmap in SunOS 4.x, and renamed
rpcbind in Solaris 2.x (SunOS 5.x).  The program is called portmapper.

When an RPC server starts, it dynamically obtains a free UDP
(User Datagraph Protocol) or TCP (Transmission Control Protocol)
port, then registers itself with the portmapper.  When a client
wishes to communicate with a particular server, it contacts the
portmapper process, determines the port number used by the
server, and then initiates communication.

Sun RPC services use ports that are currently unused.  The
only port that RPC must have is port 111, its assigned port
for the portmap service.

Carefully review the RPC services that are configured into
your system for automatic start when the system boots, or
for automatic dispatch from the inetd.  If you don't need
a service, disable it.

The standard Unix portmapper assumes that security will be
handled by the servers, allowing any network client to
communicate with any RPC server.  You can improve security
by using Wietse Venema's portmapper replacement program.
This portmapper allows for improved logging, as well as 
access control lists.

Many sites further restrict access to their portmappers by
setting their firewalls to block packets on port 111.

Portmappers are started at boot time.  Daemons that offer
RPC services tell the portmapper on what port they listen.
Unlike the services registered with the inetd, RPC network
port numbers may change each time the system is booted.
Whenever a client wants to use an RPC service, it is
supposed to first ask the portmapper on what port the
corresponding daemon is listening.  The rpcinfo command
can tell you what RPC services your system offers.

The "securelib" shared library implements access control
for all kinds of RPC services, not just the portmapper.

Vendors still ship portmap implementations that allow
anyone to read or modify its tables and that will forward
any request so that it appears to come form the local
system.

Early versions of portmap allowed any program to register
itself as an RPC server, allowing attackers to register
their own NIS servers and respond to requests with
their own password files.  Sun's current version of
portmap rejects requests to register or delete services
if they come from a remote machine.  However, not
every vendor's version of the portmap daemon performs
these checks.  The result is that an attacker might
be able to replace critical RPC services with his own,
booby-trapped versions.

Look through /etc/inetd.conf and disable all unneeded
services.  Protect the remaining services with
tcpwrapper or a similar program.

The rpc.rexd (tcp port 512) is a Sun RPC server that allows
for remote program execution.  Using rpc.rexd, any user
who can execute RPC commands on your machine can run
arbitrary shell commands.  You should not run the rexd
server.

NFS file exports via the portmapper.  NFS export
restrictions can be bypassed.  A malicious NFS client
can ask the server's portmapper daemon to forward the
request to the mount daemon.  When the mount daemon
receives the request from the portmapper, the mount
daemon will believe that the request comes from the
file server, and not from the malicious client.
More information on NFS vulnerabilities are
available from CERT Advisory CA-94:15.

You must run a portmapper (or rpcbind) that does not
forward mount requests.

Filter packets at your firewall/router.  Filter
TCP port 111, UDP port 111 (portmapper), TCP port
2049, and UDP port 2049 (nfsd).

To determine which port is running NFS: rpcinfo -p

If NFS is on a different port, then that is the
port number to block at the firewall.

Consult your vendor or your firewall documentation for
detailed instructions on how to configure the ports.

Use a portmapper that disallows proxy access (such
as Venema's portmapper and rpcbind).  Be sure
you do this for every host that runs a portmapper.
For Solaris 2.x, use a version or rpcbind that
disallows proxy access.

rpcbind 1.1 is an rpcbind replacement with tcp wrapper style
access control.  The main task of rpcbind is to maintain
a table of available RPC services and of the network
ports that they are listening on.  Rpcbind incorporates
the tcp_wrapper-7.2 security software.  You can make this
rpcbind reject requests from certain hosts, IP addresses,
networks, etc.

rpcbind process does not run as root.  The access control
files should therefore be world-readable.  The rpcbind
server is started by the script /etc/init.d/rpc.

The NFS and NIS protocols, among others, use RPCs to request
and respond to queries for information over the network.

There is an increasing interest in access control for the
NIS, mount, and other rfc-based services that are registered
with the portmap process.  Possible attacks on RPC dameons
involve: theft of NIS (YP) password files, ypset to force
hosts to bind to a rogue NIS server, theft of NFS file handles.

The latest portmap and rpcbind is at ftp.win.tue.nl/pub/security/