Additional server and software setup

SNMP versions

SNMP version 3 (SNMPv3) is the most secure solution for Unix monitoring. You do not need to install anything to use SNMPv3 for monitoring, but you do need to configure the SNMPv3 daemon on all of your hosts.

SNMP versions 1 and 2c are unencrypted. SNMP version 1 also has limits in terms of both performance and the data types it offers, making it highly unsuitable for monitoring.

SNMPv3 and 2c both provide the same data, and although v3 has a slight performance overhead because it encrypts the traffic, the ease of management of using the same protocol across the network makes it the preferred choice.

Configure an SNMPv3 user

This section describes how to configure SNMPv3 for use in the most widely used mode (authPriv), with configuration of other modes briefly described.

Note: We strongly advise against using SNMPv3 without authentication and encryption.

SNMPv3 has three separate options for security and privacy (secLevel):

• noAuthNoPriv — no authentication, no privacy.
• authNoPriv — authentication but no privacy.
• authPriv — authentication and privacy.

SNMPv3 provides two different authentication mechanisms:

• sha1 — recommended, a strong cryptographic algorithm that is fast to compute.
• md5 — not recommended, now mostly supported for backward compatibility.

SNMPv3 also provides two different encryption algorithms:

• AES — recommended.
• DES — not recommended, has known security issues and provides weak encryption.

Before you begin, you must ensure the following:

• net-snmp is installed on the host server.
• The host server is reachable on port 161, TCP, and UDP.

Password tips:

• You can construct safe passwords that are still easy to work with from a few words strung together, like horse.eats.bananas.
• Shell meta-characters are best avoided in passwords and community names. The most common problematic characters are $, ~, !, ;, ?, *, (, ), [, ], \, ", and '.

To add a new SNMP v3 user you need to edit two files:

• /var/lib/net-snmp/snmpd.conf — includes the createuser commands.
• /etc/snmp/snmpd.conf — includes access configuration.

Perform the following steps to grant user op5user, authenticated with authPass and submitting privPass as a communication encryption key, read access to the SNMP tree.

1. Stop the SNMP daemon:

   systemctl stop snmpd.service

2. Add the following line to /var/lib/net-snmp/snmpd.conf, ensuring that you set the user name op5user and passwords authPass and privPass to secure ones of your choosing:

   createUser op5user SHA authPass AES privPass

   Note that when you restart the SNMP daemon at the end of this procedure, the createUser command line in /var/lib/net-snmp/snmpd.conf changes to look like this:

   usmUser 1 3 0x80001f88801fe67e4b048e4d5500000000 0x6b616b6100 0x6b616b6100 NULL .1.3.6.1.6.3.10.1.1.2 0xcab3cb478072eef2df19c0403f030678 .1.3.6.1.6.3.10.1.2.4 0x0f6c0d5d2e521c53630039b1f04354d8 0x

3. At the end of file /etc/snmp/snmpd.conf, add the following line to give the new user read-only access to the full tree:

   rouser op5user priv .1

4. Start the SNMP daemon back up again:

systemctl start snmpd.service

5. Verify the configuration by running command snmpwalk:

   snmpwalk -v 3 -l authPriv -u op5user -a sha -A authPass -x aes -X privPass localhost .1

   If the configuration is correct, the command results in a lot of output. If this is not the case, check your snmpd configuration for errors, restart snmpd, and make sure that you have configured your firewalls correctly.

Below are other examples of ways to create SNMPv3 users and enable them for read-only access.

/var/lib/net-snmp/snmpd.conf

# Create users with varying levels and types of authentication credentials
# If a password or hash/encryption type is omitted, requiring those credentials
# for queries will result in a configuration error when starting snmpd.
# username authProto authPass privProto privPasscreateUser auth_nonecreateUser auth_md5 MD5 md5_passcreateUser auth_md5_des MD5 md5_pass DES des_cryptcreateUser auth_md5_aes MD5 md5_pass AES aes_cryptcreateUser auth_sha SHA sha_passcreateUser auth_sha_des SHA sha_pass DES des_cryptcreateUser auth_sha_aes SHA sha_pass AES aes_crypt

/etc/snmp/snmpd.conf

# Allow user 'auth_none' read-only access to the entire SNMP tree
# user mode subtreerouser auth_none noauth .1rouser auth_sha auth .1rouser auth_md5 auth .1rouser auth_sha_des priv .1rouser auth_sha_aes priv .1rouser auth_md5_des priv .1rouser auth_md5_aes priv .1

Note: After configuring SNMPv3 user access, you must disable unencrypted access to the server to prevent unauthorised access, by commenting out all lines starting with com2sec, access, rocommunity, or rwcommunity in your snmpd configuration file.

Configure an SNMP version 2c user

This section explains how to configure a user with SNMP version 2c. Note that we recommend using SNMPv3 whenever possible.

Enabling SNMP version 2c while keeping SNMP version 1 disabled means you have to configure specific access groups. This allows you fine control over which areas of the SNMP tree to allow a specific user to access.

The following example configures community name everything to have read-only access to everything, while community disks only has read access to storage information. Neither community has write access to the SNMP tree.

# Map 'disks' community to the 'disksOnly' user
# Map 'everything' community to the 'allThings' user
# sec.name   source    communitycom2sec   disksOnly  default   diskscom2sec   allThings  default   everything
# Map 'disksOnly' to 'diskGroup' for SNMP Version 2c
# Map 'allThings' to 'allGroup' for SNMP Version 2c
# sec.model sec.namegroup diskGroup   v2c      disksOnlygroup allGroup    v2c      allThings
# Define 'diskView', which includes everything under .1.3.6.1.2.1.25.2.3.1
# Define 'allView', which includes everything under .1 (which is everything)
# incl/excl   subtreeview    diskView   included    .1.3.6.1.2.1.25.2.3view    allView    included    .1
# Give 'diskGroup' read access to objects in the view 'diskView'
# Give 'allGroup' read access to objects in the view 'allView'
# group     context   model   level    prefix  read       write   notifyaccess    diskGroup   ""      any     noauth   exact   diskView   none    noneaccess    allGroup    ""      any     noauth   exact   allView    none    none

Extend the SNMP daemon to run local scripts and plugins

You can extend the SNMP daemon to run local scripts and plugins. You can find more information on extending net-snmp on the ITRS Support pages and on the Red Hat customer portal.

NRPE commands

NRPE comes with a few predefined commands, located in file /etc/nrpe.d/op5_commands.cfg.

You can add your own commands in your own file in directory /etc/nrpe.d/. You must add file extension .cfg to configuration files, otherwise they are not loaded into NRPE when the daemon restarts.

NRPE commands have the following syntax:

command[foo]=/opt/foo --args

There are two sides to NRPE command definitions, with an equals sign (=) as their separator:

Syntax segment	Description
command[foo]	The string between the square brackets, which in this case is foo, is the name of this command. Typically this gets passed as the first argument to the plugin. Do not use white space in command names.
/opt/foo --args	The command-line syntax you want to execute. The executable needs to be available on the local host. This also applies to any plugins you want to call remotely.

The following steps add a command that looks for a process named smsd using plugin check_procs:

1. Log into the host where NRPE is installed, as root.
2. Create a new configuration file in directory /etc/nrpe.d/new_file.cfg.
3. Edit the new file to add a command definition:

   command[proc_smsd]=/opt/plugins/check_procs -w 1: -c 2:2 -C smsd

4. Save the file and restart NRPE.

Plugins used with NRPE

The only plugin used with NRPE is check_nrpe. To use the plugin with an NRPE command, use the following syntax in your service definition:

/opt/plugins/check_nrpe -H $HOSTADDRESS$ -C proc_smsd

For more information on specifying commands in service definitions, see Manage commands.

Bastion mode

The NRPE agent is designed to listen to messages from allowed hosts, then run the selected commands on its host target. By default it listens to itself over the network through allowed_hosts, a common configuration for Unix agents.

NRPE can also listen for OP5 Monitor commands run against targets without NRPE installed. Such checks are called indirect checks, therefore using this approach is known as indirect mode, or bastion mode. The host with the NRPE agent installed becomes a bastion, able to talk to outpost targets on its side of a firewall, otherwise incapable of talking directly to the OP5 Monitor server.

For example, if a web server on the other side of a firewall from the OP5 Monitor infrastructure needs to take requests, the firewall only allows access to OP5 Monitor through one port to a bastion server running NRPE. You can create an NRPE check_http command to run against the outpost.

Note: While this works, it is much more convenient to use an OP5 Monitor poller. If you use a bastion server, you need to configure every check command for the outpost targets nested inside another check_nrpe. Using a poller makes better use of parent-child relationships and allows easy swapping between hostgroups. For more information on setting up pollers, see Scale up your monitoring environment.

To set up bastion mode:

1. Determine the processes and the ports that are open on the final target.
2. Create a host in OP5 Monitor for the bastion server, adding it to host groups and services based on NRPE configuration. For guidance, see Add new hosts in Manage hosts and services.
3. Create a host in OP5 Monitor for the outpost server. For guidance, see Add new hosts in Manage hosts and services.
4. Configure the bastion server as a parent of the output server. For guidance, see Add new hosts in Manage hosts and services.
5. Configure the outpost server as a child of the bastion server. For guidance, see Add new hosts in Manage hosts and services.
6. Create an NRPE command to run against the final target.
7. Add the command to nrpe.cfg on the bastion server.
8. Set the command as a check_nrpe command argument value for the bastion host. For guidance, see Configure a host in Manage hosts and services.