Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.

How to Use SNMP To Monitor a SecureData Appliance

How to Use SNMP To Monitor a SecureData Appliance

SNMP is a very popular protocol used to manage enterprise appliances, this guide shows you how to expose our Voltage SecureData appliance using SNMP.  There are many different approaches one could take to monitor the appliance using SNMP, this is just one example on how you can accomplish this.

Note: Third Party Monitoring Agents

While MicroFocus does not test or provide support for third-party monitoring tools (such as SNMP) that are added to the appliance, and does not make any product recommendations, many SecureData customers have been able to add SNMP to our appliances with no adverse effects. In the event that Voltage Support needs to troubleshoot a SecureData issue, our support staff may require the customer to remove all third-party software from the appliance. Likewise in the case of product upgrades, all third-party software may need to be removed and then reinstalled after a SecureData upgrade. All testing and support of the third-party software would be the responsibility of the customer.

PREREQUISITES:

  • Latest copy of SNMP Software Package from Voltage SecureData Professional Services
  • A functioning SecureData Appliance

HOW TO STEPS:

  1. Login to the appliance as root
  2. Upload the package provided by Secure Data Professional Services to the /tmp directory of the appliance
  3. Extract the package in the directory
    cd /tmp
    tar -xvf sdasnmp_<DATE>.tar.gz
    cd /tmp/snmp
  4. Edit the snmpd.conf file for your appliance
    vi snmpd.conf
      
    ###############################################################################
    #
    # snmpd.conf:
    #   An example configuration file for configuring SNMP to monitor SecureData.
    #
    ###############################################################################
    ####
    # First, define a community name used to poll the SNMP OIDs and map it to a security name.
    # Note this should not be "public" into a "security name"
    #       sec.name  source          community
    com2sec notConfigUser  default       sda
    ####
    # Second, map the security name into a group name:
    #       groupName      securityModel securityName
    # To allow snmp v1 uncomment the line below.
    #group   notConfigGroup v1           notConfigUser
    group   notConfigGroup v2c           notConfigUser
     
    ####
    # Third, create a view for sda community name to have rights to:
    # Here we add the system MIB, UC Davis MIB, and the EXTENDS MIB to the view
    #       name           incl/excl     subtree         mask(optional)
    view    systemview    included   .1.3.6.1.2.1
    view    systemview    included   .1.3.6.1.4.1.8072
    view    systemview    included   .1.3.6.1.4.1.2021
     
    ####
    # Grant the group read-only access to the systemview view.
    #       group          context sec.model sec.level prefix read   write  notif
    access  notConfigGroup ""      any       noauth    exact  systemview none none
    # -----------------------------------------------------------------------------
    ###############################################################################
    # System contact information
    #
    # Set the system contact Info Below
    sysContact = "SecureData Admins <email@companyname.com>"
    sysLocation = "ESXi Host"
    sysDescr = "Dev Management Console SecureData Appliance"
     
    ###############################################################################
    # Logging
    #
    # To disable excessive log messages in syslog
    dontLogTCPWrappersConnects yes
    ###############################################################################
    # Process checks.
    #
    #  The following process will be monitored on the appliance.
    #
    #Comment the line below if you are not using Atalla HSMs, used to monitor boxcar which is the service used to talk to the Atalla HSM
    proc boxcar
    #Monitor the MC proxy service, this should be monitored on all appliances.
    proc runvsscp.sh
    #Monitor the docker service, this should be monitored on all appliances.
    proc dockerd
    #Monitor the auditd service, this should be monitored on all appliances.
    proc auditd
    #Comment the line below if you have disabled splunk
    proc splunkd
    #NTP process should be monitored on all appliances
    proc ntpd
    #comment or remove the line below if this is a 5.x appliance
    proc firewalld
    #Comment the line below if you have disabled ssh
    proc sshd
    #SDA 6.x uses rsyslogd, comment or remove the line below if this is a 5.x appliance
    proc rsyslogd
    #SDA 5.x uses syslogd, comment or remove the line below if this is a 6.x appliance
    #proc syslogd
    # -----------------------------------------------------------------------------
    ###############################################################################
    # disk checks
    #
    # Check the / partition and make sure it contains at least 8 GB (10% remaining of 80 GiG HD), if the SDA has a larger HD than 80 Gigs adjust the number below accordingly.
    # If less than 8 Gigs of space is availabe the error flag will be set.
    disk / 8000000
     
    ###############################################################################
    # CPU load average checks
    #
    # load [1MAX=12.0] [5MAX=12.0] [15MAX=12.0]
    #
    # 1MAX:   If the 1 minute load average is above this limit at query
    #         time, the errorFlag will be set.
    # 5MAX:   Similar, but for 5 min average.
    # 15MAX:  Similar, but for 15 min average.
    # Note that since you need to set the threshold as an integer, you need to multiply your threshold by 100 when setting the value in the config file (so for a single core system setting a threshold of 70% would mean setting the
    # value to 70).  Also CPU load average is per core so you must multiply expected operating range and alert values by the number of CPU cores on your SDA. For example, if the SDA has 8 cores each running at 100% the
    # CPU load average would be 8 (as reported by the top command, or as read from the UCD-SNMP-MIB::laLoad.1 OID).  To set the threshold in the config to set the error flag at 70%, take the 70% X 100 (integer value) X 8 (number of
    # cores) = 560.
    #Configure the error for the 1,5,and 15 min load averages, for a single core system at 70% utilization
    load 70 70 70
    #Extend MIB config
    #if you want to run synthetic rest transaction pass in the following parameters (note REST is only available on 6.x version of the appliance):
    #   district name (do not include voltage-pp-0000.)
    #   Authmethod (can be one of SharedSecret or UsernamePassword)
    #   Authdata - base64 encoded authentication credentials if using UsernamePassword this will be the base64 encoded value of userid:password
    #   Identity
    #   Format
    #   DataIn - data to protect
    #   Expected ciphertext result
    #Example:
    extend health /bin/sh /etc/snmp/scripts/synthetictransaction_rest.sh <DISTRICT_NAME> <AUTHMETHOD> <AUTHDATA> <IDENTITY> <FORMAT> <DATAIN> <EXPECTED RESPONSE>
    #if you want to run synthetic soap transaction pass in the following parameters (note it is unnecessary to run both the SOAP and REST transaction):
    #   district name (do not include voltage-pp-0000.)
    #   Authmethod (can be one of SharedSecret or UsernamePassword)
    #   Authdata - credentials
    #   Identity
    #   Format
    #   DataIn - data to protect
    #   Expected ciphertext result
    #Example:
    #extend healthSOAP /bin/sh /etc/snmp/scripts/synthetictransaction_soap.sh <DISTRICT_NAME> <AUTHMETHOD> <AUTHDATA> <IDENTITY> <FORMAT> <DATAIN> <EXPECTED RESPONSE>
     
    #if you want to implement the client policy check
    #   district name (do not include voltage-pp-0000.)
    #Example:
    extend cpolicycheck /bin/sh /etc/snmp/scripts/sda_client_policy_check.sh <DISTRICT_NAME>
    #if you want to implement the wsdl check - This should only be done if the appliance is running the SOA service
    #   district name (do not include voltage-pp-0000.)
    #Example:
    extend wsdlcheck /bin/sh /etc/snmp/scripts/sda_wsdl_check.sh <DISTRICT_NAME>
    #if you want to implement the maintenance mode check - This should only be done if you have implemented the maintenance mode file
    #   district name (do not include voltage-pp-0000.)
    #Example:
    extend maintenance /bin/sh /etc/snmp/scripts/sda_maintenance_mode.sh <DISTRICT_NAME>
    #if you want to implement the public parameters check
    #   district name (do not include voltage-pp-0000.)
    #Example:
    extend publicparams /bin/sh /etc/snmp/scripts/sda_public_params_check.sh <DISTRICT_NAME>
    #if you want to implement the wsdl check - This should only be done if the appliance is running as a PIE server
    #   URL for the PIE server
    #   Merchant Name
    #Example:
    #extend piekeycheck /bin/sh /etc/snmp/scripts/sda_pie_key_check.sh <PIE_HOSTNAME> <MERCHANT_NAME>
    #These scripts are used to monitor processes that we can't monitor above, no modifications are necessary
    extend tomcatcheck /bin/sh /etc/snmp/scripts/sda_tomcat_proc.sh
    #Comment out the line below if this appliance is not running the MC service
    extend vsmgmtcheck /bin/sh /etc/snmp/scripts/sda_vsmgmt_proc.sh
    #This has been deprecaded due to the proc runvsccp.sh process monitoring above.
    #extend vsscpcheck /bin/sh /etc/snmp/scripts/sda_vsscp_proc.sh
    #if you want to monitor the district certificate:
    #   District name (include the voltage-pp-0000)
    #Example:
    extend ssldistrictcertcheck /bin/sh /etc/snmp/scripts/sda_ssl_cert_check.sh voltage-pp-0000.<DISTRICT_NAME>
    #if you want to monitor the MC certificate:
    #   hostname
    #Example:
    #extend mccertcheck /bin/sh /etc/snmp/scripts/sda_ssl_cert_check.sh <MC_HOSTNAME>
    #if you have additional SOA hostnames that you would like to monitor the certificate for (create an entry for each additional hostname), add additional lines if you have multiple hostnames:
    #   hostname
    #Example:
    #extend <SOA_HOSTNAME>certcheck /bin/sh /etc/snmp/scripts/sda_ssl_cert_check.sh <SOA_HOSTNAME>
    #if the appliance is using an Atalla HSM and you would like to monitor the client certificate used to connect to the HSM:
    #Example:
    #extend atallaclientcertcheck /bin/sh /etc/snmp/scripts/sda_atalla_cert_check.sh
    #if the appliance is using a Thales HSM and you would like to monitor the HSMs via SEETEST:
    # Note this script assumes the seetest (or seetest64) utility has been placed in /opt/nfast/bin directory
    #extend seetestcheck /bin/sh /etc/snmp/scripts/seetestcheck.sh
    #if the appliance is using a Thales HSM and you would like to monitor the hardserver process:
    #Example:
    #extend hardservercheck /bin/sh /etc/snmp/scripts/sda_hardserver_proc.sh
  5. Run the snmp_install.sh script
    ./install_snmp.sh
  6. To uninstall SNMP, run the uninstall SNMP script:
    ./uninstall_snmp.sh

Verify SNMP OIDs

Now that the SNMP configuration has been updated to expose what we need, we can verify the updates by retrieving the exposed MIB either from the SDA appliance, or from a remote host.  To query the entire MIB run the following command (this can be done from the SDA itself or any Linux machine with the standard SNMP packages installed:

 

 

snmpwalk -v2c -c sda <IP Address of SDA>

 

 

The result should contain a lot of data, in the next steps we will home in on what we want to configure our monitoring software to monitor.  As a general note, when querying the MIB the snmpget and snmpwalk commands will return the name of sub-tree element, some monitoring tools require the OID of the sub-tree element in order to query it.  If your tool requires the OID, you can use the snmptranslate command to look up what the OID is of the respective sub-tree element name.  For example, if you need the OID to query the UCD-SNMP-MIB::dskPercent.1 subtree element you can use the following command:

 

 

#snmptranslate -On <IP ADDRESS of SDA> <MIB OID NAME>
snmptranslate -On 172.16.11.135 UCD-SNMP-MIB::dskPercent.1
.172.16.11.135
.1.3.6.1.4.1.2021.9.1.9.1

 

 

For the above command if you are trying to translate an OID from the NET-NSMP-EXTEND-MIB use the following format (take note of the escaped quotes around the names).

 

 

#snmptranslate -On <IP ADDRESS of SDA> <MIB OID NAME>
snmptranslate -On 172.16.11.135 NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"atallaclientcertcheck\".1
.172.16.11.135
.1.3.6.1.4.1.8072.1.3.2.4.1.2.21.97.116.97.108.108.97.99.108.105.101.110.116.99.101.114.116.99.104.101.99.107.1

 

 

The command above returns a lot of information and is a bit overwhelming, to limit the amount of data returned, we can query just a sub-tree.  The relevant ones we are after are the following:

  • .1.3.6.1.2.1.1 - Provides system details
  • .1.3.6.1.4.1.2021.4 - Provides RAM utilization details
  • .1.3.6.1.4.1.2021.9 - Provides the Disk utilization details
  • .1.3.6.1.4.1.2021.10 - Provides the CPU Load Average details
  • .1.3.6.1.4.1.2021.2 - Provides the Process Monitoring details
  • .1.3.6.1.4.1.8072.1.3 - Provides the custom script details

For example to query the Disk utilization details use the following SNMP walk command:

 

 

#snmpwalk -v2c -c sda <IP ADDRESS of SDA> <MIB Subtree OID>
snmpwalk -v2c -c sda 172.16.11.135 .1.3.6.1.4.1.2021.9
UCD-SNMP-MIB::dskIndex.1 = INTEGER: 1
UCD-SNMP-MIB::dskPath.1 = STRING: /
UCD-SNMP-MIB::dskDevice.1 = STRING: /dev/mapper/rootvg01-lv01
UCD-SNMP-MIB::dskMinimum.1 = INTEGER: 100000
UCD-SNMP-MIB::dskMinPercent.1 = INTEGER: -1
UCD-SNMP-MIB::dskTotal.1 = INTEGER: 15292416
UCD-SNMP-MIB::dskAvail.1 = INTEGER: 13249072
UCD-SNMP-MIB::dskUsed.1 = INTEGER: 2043344
UCD-SNMP-MIB::dskPercent.1 = INTEGER: 13
UCD-SNMP-MIB::dskPercentNode.1 = INTEGER: 0
UCD-SNMP-MIB::dskTotalLow.1 = Gauge32: 15292416
UCD-SNMP-MIB::dskTotalHigh.1 = Gauge32: 0
UCD-SNMP-MIB::dskAvailLow.1 = Gauge32: 13249072
UCD-SNMP-MIB::dskAvailHigh.1 = Gauge32: 0
UCD-SNMP-MIB::dskUsedLow.1 = Gauge32: 2043344
UCD-SNMP-MIB::dskUsedHigh.1 = Gauge32: 0
UCD-SNMP-MIB::dskErrorFlag.1 = INTEGER: noError(0)
UCD-SNMP-MIB::dskErrorMsg.1 = STRING:

 

 

 

 

Configure Your SNMP Monitor

Now that we are exposing the relevant details via SNMP the next step is to configure your SNMP monitor to poll the appropriate MIB OIDs.  This will vary from tool to tool, below are recommended MIB OID's to poll. If your tool requires the OID instead of the name, you can use the snmptranslate command in the previous section to get the appropriate OIDs.  The sub-trees from the previous section are displayed below in full, the OIDs we recommend polling are highlighted below, however you can utilize any of the OIDs below for your monitoring.

If your monitor requires you to upload the MIBs to monitor, the following MIBs are used and can be downloaded from the net-snmp.org site.

Example OIDs to Monitor

Title Oid Name OID Comments
System Description SNMPv2-MIB::sysDescr.0  .1.3.6.1.2.1.1.1.0 Returns Description String e.g. "Dev Management Console SecureData Appliance\"
System Contact SNMPv2-MIB::sysContact.0 .1.3.6.1.2.1.1.4.0 Returns Contact String e.g. SecureData Admins securedata@companyname.com
System Name SNMPv2-MIB::sysName.0 .1.3.6.1.2.1.1.5.0 system name
System Location SNMPv2-MIB::sysLocation.0 .1.3.6.1.2.1.1.6.0 location of system
System Up time DISMAN-EVENT-MIB::sysUpTimeInstance .1.3.6.1.2.1.1.3.0 System uptime
Disk percent  UCD-SNMP-MIB::dskPercent.1 .1.3.6.1.4.1.2021.9.1.9.1 Percentage of disk full, should alert at 80% or higher
Disk error UCD-SNMP-MIB::dskErrorFlag.1 .1.3.6.1.4.1.2021.9.1.100.1 Will be set to 1 if threshold is met, 0 otherwise
RAM Free UCD-SNMP-MIB::memTotalFree.0 .1.3.6.1.4.1.2021.4.11.0 Should send alert if over 90% is utilized
CPU Load Avg 5 min error flag UCD-SNMP-MIB::laErrorFlag.2 .1.3.6.1.4.1.2021.10.1.100.2 Send alert if set to 1
CPU Load Avg 15 min error flag UCD-SNMP-MIB::laErrorFlag.3 .1.3.6.1.4.1.2021.10.1.100.3 Send alert if set to 1
VSSCP Service UCD-SNMP-MIB::prErrorFlag.1  Dynamically set Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
docker service UCD-SNMP-MIB::prErrorFlag.2  Dynamically set Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
auditd service UCD-SNMP-MIB::prErrorFlag.3   Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
splunk service UCD-SNMP-MIB::prErrorFlag.4   Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
ntp service UCD-SNMP-MIB::prErrorFlag.5  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
ssh service UCD-SNMP-MIB::prErrorFlag.6  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
syslog service UCD-SNMP-MIB::prErrorFlag.7   Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
synthetic health check NET-SNMP-EXTEND-MIB::nsExtendResult."health"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
WSDL retreival check NET-SNMP-EXTEND-MIB::nsExtendResult."wsdlcheck"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
MC Cert Expiration Check NET-SNMP-EXTEND-MIB::nsExtendResult."mccertcheck"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
Tomcat service check NET-SNMP-EXTEND-MIB::nsExtendResult."tomcatcheck"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
Client Policy Check NET-SNMP-EXTEND-MIB::nsExtendResult."cpolicycheck"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
Public Parameter Check NET-SNMP-EXTEND-MIB::nsExtendResult."publicparams"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
Cert Check NET-SNMP-EXTEND-MIB::nsExtendResult."uvma00013certcheck"  Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
Cert Check NET-SNMP-EXTEND-MIB::nsExtendResult."uvma00014certcheck"   Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation
District Cert Check NET-SNMP-EXTEND-MIB::nsExtendResult."ssldistrictcertcheck"   Dynamically set  Send alert if set to 1, Refer to Verify OID's section of this doc to determine the OID value per your installation

 

Labels (2)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
9 of 9
Last update:
‎2019-12-03 07:17
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.