In order to receive data in near real time the LDM requires round the clock Internet connectivity. With the ever-increasing risk of computer breakins, 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.
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 search for "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 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
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 might need root privileges is to implement logging. LDM version 6.12 and
earlier use the system logging daemon. LDM version 6.13 and later can be built to use the system logging daemon.
Such logging is initiated via the hupsyslog program, which sends a HUP signal to the system logging
daemon (e.g., syslogd, rsyslogd). This can only be done if the hupsyslog
process is owned by root. When the system logging daemon receives a HUP, it closes all 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).
When the LDM was designed it was necessary for it to perform its own access control. This is implemented in the
form of ALLOW entries in the configuration file ldmd.conf. In that file,
ALLOW entries specify hosts that may connect to the localhost to receive data. Subnet regular
expressions 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 does not use TCP-Wrappers. Nor is it spawned by inetd, so TCP-Wrappers provide no benefit
with respect to the use of port 388.
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.