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

8
Considerations for Continentalclusters
Continentalclusters is our disaster tolerant solution. It uses multiple Serviceguard clusters, separated from one another
by as far as thousands of kilometers.
Continentalclusters releases prior to Release A.08.00 require that all participating clusters must share a security
domain, and thus clusters must share the same firewall-protected network perimeter. This security domain may be very
geographically distributed, but the clusters cannot be firewalled off from each other. The communication paths between
the clusters must not be exposed beyond this security perimeter.
Continentalclusters Release A.08.00 and later requires only the standard Secure Shell (SSH) port for its remote
communications. The SSH port must be open in all participating cluster nodes. In addition to the above, if notifications
that require additional ports are configured for Continentalclusters Cluster Events, then the ports used by the respective
notifications mechanism should be open.
Appendix: Requirements of a trusted network
1. The root user on any node inside the trusted network must be trusted by all nodes. This includes any
Windows® computer.
2. The network must be physically defended against any spoof or sniff attacks.
3. The network firewalls must be correctly configured to defend against external attacks.
Conclusion
Careful analysis of the threats faced by Serviceguard clusters is the foremost step towards warding off network
vulnerabilities. This document helps Serviceguard users in identifying the existing threats. Also, with the help of the
recommendations provided in this document, users can implement defenses suitably and thus improve the protection of
their Serviceguard clusters.
Glossary
Authentication
How to identify who a user is. A special case is the verification that a process claiming to be owned by the root really is
owned by the root.
Authorization
What a user is authorized, or allowed to do.
Denial of service
A security vulnerability, which allows a non-root user to crash a computer, or otherwise disrupt its intended purpose.
Root exploit
A security vulnerability that allows a non-root user to achieve UNIX superuser status by means other than knowing the
password of a root enabled account.
Root user
Any user on a UNIX system with an effective user ID of “0”. Also, includes any user account on any system running
Microsoft® Windows. The relevant issue for this document is whether or not the user can generate arbitrary network
data (including spoofed packets) and can listen on any port—including low numbered ports. If a user meets either of
these criteria, they will be considered a “root user” for purposes of this document.