Securing Serviceguard Security analysis for HP Serviceguard clusters - Technical white paper

6
Weaknesses with “auth”
Identd and the auth protocol it implements are no more reliable than the computer they are running on. If that computer
has been compromised, the computer can report any name it chooses. Thus, trusting the information reported by identd
is dependent upon trusting the root user on that computer.
It can and should also be observed that the information provided by identd is no less reliable than the computer
supplying the information.
Is identd a security threat?
Security experts sometimes recommend that identd be disabled, because it gives out information about users on that
computer. The information given out is “login name” (as recorded in/etc/passwd, or whatever local technology is
replacing/etc/passwd). If two login names share the same user ID, the name reported is usually, but not always, the first
one in/etc/passwd. Given the nature of the trust required inside the firewall, it is unlikely that system security would be
compromised due to identd service.
Serviceguard does not require the external firewall to pass any identd traffic, either incoming or outgoing. Hence, we
recommend blocking the incoming service requests for identd (port 113) at the external firewall, to prevent the minimal
information that it exposes to the internet.
Stronger alternatives to identd
Stronger authentication mechanisms than identd exist. These mechanisms requiring source credentials to be configured
are available with an option to get them certified by a trusted third party.
Such measures require significant administrative load at configuration and maintenance time. Serviceguard has selected
the use of identd as more appropriate for our customers. Serviceguard is evaluating the future potential to supply an
option to use stronger security for those customers who seek to use Serviceguard in a more hostile context.
Weaker alternatives to identd
Serviceguard strongly recommends the use of identd. However, a weaker alternative, not requiring identd, exists which
is suitable for installations where all users are trusted not to be attempting hostile activity. Please see
the Serviceguard
manual and patch documentation for details.
./.rhosts
Serviceguard has always allowed the use of /.rhosts (more precisely, ~root/.rhosts) to expose cluster nodes to each
other. However, the use of /.rhosts exposes the nodes to other threats, and has long been discouraged as a security
weakness. Since very early Serviceguard releases, it is not required or even recommended to use /.rhosts.
Note: That after Serviceguard Release A.11.19, the usage of .rhosts and host equivalency will not be supported for access
control policies.
cmclnodelist, Role Based Access
Prior to Serviceguard A.11.16, we have provided a Serviceguard only method—the cmclnodelist file—as a replacement
for using /.rhosts. $SGCONF/cmclnodelist works much like /.rhosts, but was only used by Serviceguard, and thus is not a
general exposure. When $SGCONF/cmclnodelist exists, /.rhosts is not used by Serviceguard at all. Previous to
Serviceguard A.11.16, the cmclnodelist file was used to configure all inter-host access for Serviceguard commands. For
A.11.16 or later, this file is used only to configure the cluster. Once the cluster with Serviceguard A.11.16 or later is
configured, an internal access control list is used. This internal list defaults to allowing root from any cluster node to
manage any other cluster node, but rejects all external nodes. See the
Serviceguard Release A.11.16 or later manual for
a more complete description of Role Based Access (RBA).