| • |
|
|
|
|||
|
||||
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 how the structure and setup requirements with respect to security.
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 user 'ldm'.
Similarly, all child processes run as user 'ldm' and thus do not have
root privileges.
(The LDM should always be invoked as user 'ldm' and never as '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.
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 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 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.
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | |||||
|
|||||
