The Unidata LDM and Network Security
In order to receive data in near real time the LDM requires round the clock
Internet connectivity. With the ever increasing risk of computer break ins,
it is understandable that system administrators feel the need to restrict access
as much as possible. This page describes the security situation of the
LDM.
To the best of our knowledge (and we should know) no computer system
has ever been compromised via the LDM since it was first released in
1994.
General LDM Information
Like FTP and HTTP, the LDM uses a reserved port. Unidata has
registered with IANA to
use reserved port 388. (For more information on port numbers see IANA's
Protocol Numbers and Assignment Services and click on "Port Numbers".)
Under UNIX it is necessary to have root level privileges in order to
acquire a reserved port. For this reason the LDM server, the parent
rpc.ldmd process, temporarily becomes 'root' when opening and closing the port.
At all other times, it has the reduced privileges of the LDM user.
Similarly, all child processes are owned by the LDM user and thus do not have
root privileges.
(The LDM should always be invoked by the LDM user and never by 'root'.)
In order to implement this, LDM installation requires root
privileges to set the user id of rpc.ldmd to root and to set the
SUID bit.
Also, like FTP and HTTP, network communication between LDMs
occurs via a limited, well-defined protocol. That protocol is defined in the
file ldm.h which comes with the source code distribution. If you
would like to read more about the protocol, please see the section
entitled The LDM 6 Protocol
in the
LDM Reference webpages.
The only other purpose for which the LDM needs root privileges is to
implement logging. LDM logging is initiated via the
hupsyslog program, which sends a HUP
signal to the system log daemon syslogd.
When syslogd receives a HUP, it closes any files it has open
and rereads its configuration file. hupsyslog is always
called upon LDM start-up, and is typically run periodically to rotate the
log files.
The LDM makes one more bow to security. It requires a reverse lookup of the
client host name. That is, when a client connects to an LDM server, the server
will confirm that the client's fully qualified domain name (FQDN) resolves to
an IP address, and that that IP address resolves to the same FQDN. For this
reason, the LDM may not work if a client is using an alias and relevant tables
aren't properly updated or a new name has not yet propagated to the relevant
name servers.
Because the top-level LDM server immediately
daemonizes itself, it is not possible for an outside entity to obtain a
user shell by crashing the LDM (even if such a thing were possible).
Access Control and Access to Port 388
When the LDM was designed it was decided that it would perform its own access
control. This is implemented in the form of allow lines in the
configuration file ldmd.conf. In that file allow lines
specify hosts that may connect to the localhost to receive data. Subnets may
be used as host names. The LDM will deny a connection from any host that is
not allowed to connect.
Use of the LDM requires that any host listed in its access control list be
allowed a TCP connection to port 388 on the localhost.
If the localhost is behind a firewall, the firewall must allow TCP access
to port 388.
The LDM was not coded to use TCP-Wrappers. Nor is it spawned by inetd,
so TCP-Wrappers provide no benefit with respect to the use of port 388.
The Portmapper
The LDM does not require that the portmapper program (usually called
portmap or rcpbind) be running on
the host system. If it is running, however, then the LDM will
register its remote procedure call (RPC) service.
The portmapper is not required by downstream LDMs because they
will attempt to connect directly to port 388. Only if they cannot connect
via this port will they then try to use the portmapper.
