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

5
Inside the firewall protected security perimeter: the trusted network
One or more hardware firewalls should be used to create a security perimeter surrounding more than a single cluster.
The inside of such a security perimeter is referred to as a “security domain”. Within a security domain, security among
clusters (more literally, among root users on clusters) could be compromised. Hence, generally, it is required that any
computer that is not isolated by an external defense must have a trusted root user. Root users have unlimited access to
the networks, and no security measure would prevent them from engaging in various attacks based on forged network
packets or spying on network traffic.
It is also required that the security domain be physically protected from untrusted computers. It would be a serious
breach to allow an untrusted user to connect a laptop or PC to a network inside the perimeter. Such a user, given
appropriate knowledge, skill, and motivation, could eventually exploit Serviceguard to gain root on all Serviceguard
nodes in the cluster.
Summary of threats that must be environmentally defended:
• Within the security domain defined by the security perimeter, root on one computer must be trusted by all
• Within the security domain, every computer must be competently administered such that an untrusted user cannot
gain root
• Within the security domain, even non-root users must be trusted to not launch disruptive attacks
A future-hardened Serviceguard
Conceivably, Serviceguard could be provided with security options allowing it to operate securely in a
very hostile environment. The Serviceguard security patch of 2004, however, is based on the defenses described in
this document.
The HP Serviceguard security patch of 2004
The Serviceguard security patch of 2004 hardens the Serviceguard authentication mechanism. One enhancement is the
use of the UNIX
®
/Linux auth service, and its TCP daemon—identd—to identify users. This patch is not motivated by
customer reported issues; rather, it’s based on internal analysis that predicts that a small portion of our customer base
may be exposed to some threats, which we can do better to defend against. HP strongly recommends this patch to be
installed, and that identd be configured to achieve greater security.
Serviceguard authentication
The essence of this patch is a hardening of the Serviceguard authentication mechanism. Pre-patch, Serviceguard used a
method described as “self-authentication”. The patch replaces self-authentication with reliable methods to determine
which user is attempting to use the Serviceguard functionality.
Authentication using identd
UNIX variants provide a standard “caller id” service, called, variously: “ident”, or “auth”. This service implements
“RFC1413”—a formal specification of the auth protocol. The daemon that implements this service—identd, is shipped
standard on all variants of UNIX; including HP-UX and Linux (on some variants of Linux, such as SUSE Linux, it is called
“pidentd”. Serviceguard Release A.11.20.00, and later on Red Hat uses “authd”). The Serviceguard patch of 2004 and all
further releases of Serviceguard require identd to be configured on all cluster nodes, on any node that intends to use
Serviceguard commands, and on any node running the Cluster Object Manager. See the patch installation documentation
for details. For sites that face no security threat, the use of identd is optional.
Note: That the cluster object manager is no longer available on Serviceguard Release A.11.20.00 and later on Linux and so is
not relevant.