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 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).

Access Control and Access to Port 388

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 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.