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

4
Ports used by HP Serviceguard Manager on HP-UX and Linux:
• compaq-https 2381/tcp
• compaq-https 2381/udp
• cpq-wbem 2301/tcp
• cpq-wbem 2301/udp
Additionally, the port 1118 is used for Apache-Tomcat communication within the local host, and this port should
be opened.
Rules should be established for Serviceguard and Serviceguard Manager for both IPv4 and IPv6 network addressing.
Serviceguard uses ports in the dynamically allocated range. Dynamic ports are typically in the range 32768-61000 in
Red Hat, 49152-65535 in HP-UX and 1024-29999 in SUSE.
All of these ports must be isolated, by using an external firewall, from any hostile activity. Hostile activities include
nuisance connections to the port, connections to the port from foreign nodes masquerading as cluster nodes, and
attempts to crack into the system.
Crucially, the firewall must also never pass traffic that originates on the outside of the firewall, but which claims to be
from inside the firewall.
Host based configurations (Not recommended)
It is not recommended to utilize host-based configuration to achieve isolation from potentially hostile activity.
In most situations, we do not recommend the use of local IP filtering—sometimes called a “software firewall”—to
achieve any of our security requirements. IP filtering, configured on the node being defended, requires great care to
defend against spoofing and denial of service attacks, which are relatively simple to defend at the external firewall.
While for some sites a combination of internal configuration and an external firewall or formally authenticated
communications is optimal, for most sites the external firewall is the correct platform to implement defense against
potential exposure. It’s far simpler, and thus easier to analyze and to maintain. Observe that the external firewall cannot
detect some kinds of spoofs either, but it is possible for it to prevent external computers from spoofing internal ones.
The use of IP filtering to meet non-Serviceguard security requirements is fully supported by Serviceguard.
inetd.sec
On HP-UX, inetd can be configured to reject selected transactions based on ip addresses. This is configured via the file
inetd.sec. However, inetd requires roughly the same kind of protection that Serviceguard requires, in order for this to be
useful. It is vulnerable to spoofing. inetd.sec should never be seen as protection from hostile threats.
Internal threats
All nodes in a cluster must reside inside of a common security domain (See the “Inside the firewall protected security
perimeter: the trusted network” section for the definition of “security domain”); root (refer to the glossary for the
Serviceguard non-standard definition of “root user”) on one node inside a cluster cannot be prevented from achieving
root privileges on another node in the same cluster. Hence, isolation of one cluster node from another is of no major
value, and the security analysis should accept this basic assumption.
In addition to the actual cluster nodes, the security domain of a cluster includes all machines that can place arbitrary
packets onto the networks connected to the cluster. The Serviceguard security model prevents non-root users inside the
security domain from exploiting Serviceguard to gain root access on a node running the Serviceguard daemons.
Serviceguard is exposed to denial of service attacks from internal, non-root users. Although we are not expanding on the
details here, we advice that the security analysis take into account this potential threat We expect that system
administrators will not grant any access or accounts to users who might feel hostile or are inclined to disruptive pranks.