Overview

This page outlines best practices for GroundWork Monitor Enterprise. This is an evolving document.

1.0 Hardening a GroundWork Server for Production

With every system, there is a trade off between Security and Application Performance. For this reason, GroundWork cannot provide a definitive list of steps to take to harden the GroundWork server, after a GroundWork Monitor installation, that will work in every case. Therefore, we are providing the following list of Security Best Practices at a minimum should be considered when running a GroundWork server in a Production environment. Additional measures may need to be taken based on your organization's security requirements. Since every environment is different, it is important to test each of these changes to see how they affect your GroundWork server's performance. All security changes you make to the GroundWork server should be fully documented to ensure ease of troubleshooting and future system upgrades.

1.1 OS level suggestions

• Only GroundWork software and OS packages should be running on system, do not install other vendor tools
• Do not install an X11 desktop and/or browsers during OS installation, use server distributions
• Do not install a compiler on the GroundWork Server, or, if one is essential, remove it after use
  • Consider running headless browser programs on a separate system
• Ensure all OS security patches are installed and kept current
• If GroundWork is running on a VM, ensure guest tools (VMware tools) and hypervisor patches are installed, maintained, and up to date
• Enable ModSecurity for Apache
• Enable firewall rules and only allow ports that need to be remotely accessed for monitoring, for example:
  • If SNMP Traps is not being used, then block UDP 162
  • If the server is only using IPv4, block IPv6
• Enable SELinux in permissive mode for a calibration period
  • Then use audit2why and audit2allow to identify specific blocked behaviors and create a policy to allow as appropriate
• Upgrade Java to Zulu JDK (see Technical Bulletins for your release)

1.2 Application level changes

• If not using LDAP, change default passwords for default accounts in the GroundWork portal
  • Change portal super user (default is root)
  • DO NOT change the default account names except root
• Enable LDAP Authentication for user and role management if available
  • Additionally, consider restricting LDAP over TLS 1.2
• If using GDMA, turn on and change the Bronx encryption and set an encryption password
• Change default REST credentials regularly
• Thoroughly vet community supplied code and plugins before running on the GroundWork system
• If untrusted 3rd party code must be run, it should be done on a child server or another dedicated host
• Services that are not being used should be disabled from starting, for example:
  • Ntop
  • NeDi
  • Cacti
• Enable HTTPS
  • Additionally, consider restricting over TLS 1.2 only
• Change Java KeyStore password from the default (typically 'changeit'), and document the change in a secret manager
• Only install trusted CA certificates in OpenSSL and Java KeyStores
• Consider a regularly rotated certificate, for example Let's Encrypt
• Regularly update certificates and update CRLs
• If using a GroundWork child server, proxy JOSSO through Apache to the parent

1.3 Accessing the GroundWork server

• Configure local or LDAP authenticated accounts for SSH access to the GroundWork server
• Restrict or disable root SSH access
• Sudo access should be restricted to commands needed for SSH users
• SSH using public keys only - not password based authentication

2.0 Customer Use Cases

Agents

• Customer Use Case:
  Installing software on monitored systems creates an opportunity for unknown code to be introduced to those systems. Such code may contain malware, viruses, or be vulnerable to compromise.

• Security Measure/Best Practice:
  GroundWork makes every effort to not include malware and viruses. The code we supply is compiled in some cases, but the source is always available on request, if review is desired. This is also the case when GroundWork interfaces to the monitored system via an open source package such as NRPE or Beats. While no software is free of flaws, GroundWork does monitor the underlying packages we bundle and supply for security issues, and will occasionally issue technical bulletins to address any serious flaw. In addition, GroundWork regularly updates virtually all packages in it's point releases, and this includes agents.
  
  The GDMA (GroundWork Distributed Monitoring Agent) does not contain code that listens on a TCP/IP or UDP port, and so network compromise of this package is not theoretically possible. This is a preferred choice when security is a high concern.

Access control policy

• Customer Use Case:
  The GroundWork server can contain scripts and executables that store credentials used to stop, start, or otherwise control services on monitored nodes (see Event Handlers). Attackers compromising the GroundWork server may be able to use the stored credentials to perform unauthorized actions on remote nodes.
• Security Measure/Best Practice:
  GroundWork server itself does not need to store credentials of monitored hosts (it can, but this is generally possible to work around). If this is a concern, please work with GroundWork Support to eliminate the storage of such credentials, and where it's absolutely necessary to have them present, limit the credentials to those of non-privileged accounts.

Event handlers

• Customer Use Case:
  Event Handlers would allow monitored systems and services to be controlled by the GroundWork administrative interface, creating higher risk if the GroundWork console were to be compromised by attackers. Systems and services may potentially be disabled by attackers if Event Handlers were handled.
• Security Measure/Best Practice:
  Event handlers are system commands (scripts or executables) that, if enabled, run whenever a host or service state change occurs. Event handlers are normally used with NRPE or SSH-based checks, or are run on the GroundWork server itself.
  
  Event Handlers are optional, and GroundWork does not generally recommend them, as we do consider the security risk significant and the benefit small. In the rare cases where their use is justified, an agent such as NRPE or NSClient can be installed, which has its own authentication methods and restrictions on what can be run. Thus, to use Event Handlers for an exploit would require that the authentication and restrictions be changed, itself requiring privileged access to the monitored server. The narrow case where the defined and authorized action of an Event Handler could be used as an attack vector to a monitored server would be limited to the utility action of, say, restarting a process. This is equivalent to a Denial of Service attack, not a data breach.
  
  Event Handlers can be disabled at the server level by setting the value in the Configuration > Control > Nagios main configuration, uncheck the Enable event handlers option. Event Handlers can be disabled for agents by disabling the plugins involved, or by using GDMA instead of NRPE/NSCLIENT or SSH as a monitoring method.