GuidesREST APISlack CommunitySupport PortalOpsview 6.8+ Documentation

## ITRS Infrastructure Agent Security

Opsview Monitor has the capability of a secure method of communication to the [ITRS Infrastructure Agent](🔗). Using SSL certificates offers encryption and authentication, so both the client and server know that they are indeed talking to each other, and not a man-in-the-middle. Please take a moment to read the [PKI documentation](🔗) before continuing with the below.

Opsview and the Infrastructure Agent must be told to use the same using ciphers and SSL certificates. See [Infrastructure Agent Operation](🔗) for more configuration on the agent side, and the below for configuration on the Opsview side. Note that certificates can be generated using any valid method; however, the simplest way to get started is by using the Opsview Public Key Infrastructure. You can follow these steps in [PKI](🔗) to generate both client and server certificates.

## Host Variables

We have added default parameters to every `check_nrpe`-based Service Check that comes with Opsview Monitor. If you check their definitions, you'll see two Host variables - `NRPE_CIPHERS` and `NRPE_CERTIFICATES` - discussed below. Note that you'll have to add these variables yourself if you're upgrading from an older version of Opsview Monitor. To do this add these two variables:

**NRPE_CIPHERS**

  • Label Arg1: Cipher list

  • Default Arg1: ADH-AES256-SHA:ADH-AES128-SHA

**NRPE_CERTIFICATES**

  • Label Arg1: Path to certificate

  • Label Arg2: Path to private key

  • Label Arg3: Path to CA certificate

For each check_nrpe based service check that is to be used with the new feature, add these parameters:


## Opsview Agent Security (deprecated)
Opsview Agent Deprecation
The Opsview Agent and the steps below are now deprecated, and we instead recommend use of the [ITRS Infrastructure Agent](🔗).
Please follow the [instructions above](🔗) for the most up-to-date information.
The Opsview Agent server and clients (`check_nrpe`) must be told to use the same method: ciphers directly or SSL certificates. The Opsview Agent server configuration is in `/opt/opsview/agent/etc/nrpe.cfg` (on Windows in `C:/Program Files/Opsview Agent/opsview.ini`), and the clients are configured by command line parameters.
## Ciphers (deprecated)
In nrpe.cfg, `ciphers` (on Windows in opsview.ini it is `allowed_ciphers`) indicates the cipher list to use. Because there is no authentication involved in using a cipher directly like this, only ADH ciphers can be used here. The list follows the standard OpenSSL convention of colon-separated names, where the program attempts to use each cipher starting from the left, and falls back to the next one if unsuccessful. Similarly, the `-y` parameter to check_nrpe lists ciphers that the client should attempt to use, which, of course, must contain at least one of the ciphers that the server is using.
Each check_nrpe based Service Check is configured to accept the NRPE_CIPHERS host variable. Make sure the value of this variable is the same or contains at least one of the ciphers configured in nrpe.cfg.
## SSL Certificates (deprecated)
In nrpe.cfg, `cert_file`, `privatekey_file` and `cacert_file` (opsview.ini uses `certificate`, `certificate_key` and `ca`) are file paths to a certificate PEM file.  The first value, Arg1, is the path to the certificate on the Collector, Arg2 is the path to the private key and Arg3 is the CA certificate.  These parameters correspond to the `-C`, `-k`, `-r` parameters of the check_nrpe plugin.
The generation and use of the actual certificates is the User's responsibility - please refer to the [PKI documentation](🔗).  The automated installer should create the required certificates for the Orchestrator.  In a single server system (assuming the FQDN of the orchestrator is `opsview.example.com`), the following settings should be used:
###### NRPE_CERTIFICATES
###### NRPE_CIPHERS
  • Arg 1: HIGH:!3DES:!CAMELLIA:!AES128:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS _(note: to match configuration of the Opsview agent)_
Use `pki` to create a `server-cert` certificate:

and transfer the following files to that server (NOTE: `agent-machine.example.com` should match exactly the `Primary Hostname/IP` configured in Opsview Monitor for the server)
  • `/opt/opsview/etc/ssl/ca.pem`
  • `/opt/opsview/etc/ssl/agent-machine.example.com.pem`
  • `/opt/opsview/pki/ssl/private/agent-machine.example.com.key`
On the `agent-machine.example.com` host, edit nrpe.cfg (or `custom.ini` on Windows), uncomment and change `ciphers` to match the definition used within `NRPE_CIPHERS`, and `cert_file`, `privatekey_file` and `cacert_file` options to point to their respective pem files.  Then, restart the agent.
On Collectors that will be doing the monitoring, each check_nrpe based service check is configured to accept the NRPE_CERTIFICATES variable. The values for this variable refer to the certificate files for the Collector, and not the Host being monitored, as is the case usually with Host variables.
## TLS Versions (deprecated)
To enable TLSv1.2 only and disable older versions of TLS change the Linux Opsview Agent `nrpe.cfg` file. By default only TLSv1.2 is enabled for the Opsview Windows Agent.

# Using Opsview Monitor With Older Agents (deprecated)
Opsview take security very seriously so all recent versions of Opsview Monitor default to using TLSv1.2 for all inter-process communication only. Consequently, agents for older versions of Opsview Monitor are unlikely to work without additional configuration to downgrade encryption to use TLSv1.0 or TLSv1.1. We recommend that you upgrade to later versions of Opsview Agents that support TLSv1.2 however if you have an operational need to run older Opsview Agents then a workaround is available to downgrade to use TLSv1.0 or TLSv1.2 for those specific Opsview Agents only.
Please see <https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.0> for more information on the issues with using TLSv1.0.
The following Opsview Agents support TLSv1.2 and it is recommended that you upgrade to at least these versions:
  • Opsview Windows Agent (NSClient++) - 0.3.9.509 2017-11-21 or 0.3.9.504 2017-07-04
  • CentOS 6 - 6.0.0.201811091647
  • CentOS 7 - 6.0.0.201811091647
  • Debian 7 - 6.0.0.201811091647
  • Debian 8 - 6.0.0.201811091647
  • Oracle Enterprise Linux 7 - 6.0.0.201811091647
  • RHEL 6 - 6.0.0.201811091647
  • RHEL 7 - 6.0.0.201811091647
  • Ubuntu 14.04 - 6.0.0.201811091647
  • Ubuntu 16.04 - 6.0.0.201811091647
Agents or operating systems that do not support TLSV1.2 will need the following workaround to be applied to downgrade to TLSv1.0:
## Workaround Steps (deprecated)
  1. As _root user_, run the following:

NOTE: if you do not have access to the root user, run the following command as the nagios user

  1. Go to Configuration > Apply Changes to apply the changes.
This will modify the Opsview Monitor database to do the following:
  • Create a new Variable called NRPE_PROTOCOL and sets the default value to be ''\\!SSLv2:\\!SSLv3" (which allows TLSv1)
  • Adds the argument "-P %NRPE_PROTOCOL%" to the args list of every check_nrpe service check (replacing any other "-P ...." setting)
  • Makes the Apply Changes Icon change to indicate that Apply Changes is necessary
  • To change the configuration for a limited number of hosts instead of all of them, amend  the NRPE_PROTOCOL variable (menu => settings -> variables) to exclude TLSv1 (by using: "\\!TLSv1:\\!SSLv2:\\!SSLv3") and then amend the configuration on an individual host by adding the NRPE_PROTOCOL variable to override arg1 using 'TLSv1'.
## Revert Changes (deprecated)
Running the workaround steps again will result in a prompt to revert the changes done by the script. This can be done once all agents have been updated to the latest version and all old Linux OS distributions have been upgraded to support the latest TLS versions.

This will:
  • Remove the argument -P TLSv1 from the arguments list of every check_nrpe service check
NOTE: Apply Changes will have to be performed again after running the command above.