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.
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
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
(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
Also, like FTP and HTTP, network communication between LDMs
occurs via a limited, well-defined protocol. That protocol is defined in the
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
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 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
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 decided that it would perform its own access
control. This is implemented in the form of
allow lines in the
ldmd.conf. In that file
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
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
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.