OS name mismatch across cluster members-paloaltonetworks-panos

OS name mismatch across cluster members-paloaltonetworks-panos
4.0 1

OS name mismatch across cluster members-paloaltonetworks-panos

Vendor: paloaltonetworks

OS: panos

Description:
Indeni will identify when two devices are part of a cluster and alert if the OS installed is different.

Remediation Steps:
Install the correct versions of software on each device.

How does this work?
This script uses the Palo Alto Networks API to retrieve the software name and version installed on the device. indeni then compares the result to the same script run on other members of the same cluster.

Why is this important?
Two or more devices which operate as part of a single cluster must be running the same version of software.

Without Indeni how would you find this?
Manual tracking by an administrator is usually the only method for knowing when two devices are not running the same version of software.

panos-show-system-info-monitoring

name: panos-show-system-info-monitoring
description: Fetch system info for monitoring
type: monitoring
monitoring_interval: 5 minute
requires:
    vendor: paloaltonetworks
    os.name: panos
comments:
    uptime-milliseconds:
        why: |
            When a monitoring system loses connectivity to a device, it may be difficult for it to determine whether the device restarted, or is simply unreachable. To deal with that, the uptime is tracked. The uptime of a device resetting is a clear indicator of a device restart.
        how: |
            This alert uses the Palo Alto Networks API to retrieve the current uptime (the equivalent of running "show system info" in CLI).
        without-indeni: |
            An administrator will normally find out that a device has restarted when a service outage actually occurs.
        can-with-snmp: true
        can-with-syslog: true
    software-eos-date:
        why: |
            Ensuring the software being used is always within the vendor's list of supported versions is critical. Otherwise, during a critical issue, the vendor may decline to provide technical support. Palo Alto Networks posts the list of supported software on their website ( https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-life-summary ). indeni tracks that list and updates this script to match.
        how: |
            This script uses the Palo Alto Networks API to retrieve the current software version (the equivalent of running "show system info" in CLI) and based on the software version and the Palo Alto Networks provided information at https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-life-summary the correct end of support date is used.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when a given device may be nearing its software end of support and is in need of upgrading.
        can-with-snmp: false
        can-with-syslog: false
    hardware-eos-date:
        why: |
            Ensuring the hardware being used is always within the vendor's list of supported models is critical. Otherwise, during a critical issue, the vendor may decline to provide technical support ( https://www.paloaltonetworks.com/services/support/end-of-life-announcements/hardware-end-of-life-dates ). indeni tracks that list and updates this script to match.
        how: |
            This script uses the Palo Alto Networks API to retrieve the current hardware model (the equivalent of running "show system info" in CLI) and based on the model and the Palo Alto Networks provided information at https://www.paloaltonetworks.com/services/support/end-of-life-announcements/hardware-end-of-life-dates the correct end of support date is used.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when a given device may be nearing its end of support and is in need of replacement.
        can-with-snmp: false
        can-with-syslog: false
    current-datetime:
        why: |
            The clock of a Palo Alto Networks firewall should always be accurate, as inaccuracies may result in issues with some features, as well as causing a mess in log analysis. Normally, administrators are encouraged to use NTP to keep the clock in sync (and indeni has a script for verifying NTP is working). If NTP is not used, one should still verify that the clock is set correctly.
        how: |
            This script uses the Palo Alto Networks API to retrieve the current date and time (the equivalent of running "show system info" in CLI). indeni then compares the result to its own clock to find possible discrepancies.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when a given device's clock may be off.
        can-with-snmp: false
        can-with-syslog: false
    os-version:
        why: |
            Two or more devices which operate as part of a single cluster must be running the same version of software.
        how: |
            This script uses the Palo Alto Networks API to retrieve the software version installed on the device. indeni then compares the result to the same script run on other members of the same cluster.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when two devices are not running the same version of software.
        can-with-snmp: false
        can-with-syslog: false
    model:
        why: |
            Two or more devices which operate as part of a single cluster must be running on the same hardware.
        how: |
            This script uses the Palo Alto Networks API to retrieve the hardware model of the device. indeni then compares the result to the same script run on other members of the same cluster.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when two devices are not running on the same hardware.
        can-with-snmp: false
        can-with-syslog: false
    os-name:
        why: |
            Two or more devices which operate as part of a single cluster must be running the same version of software.
        how: |
            This script uses the Palo Alto Networks API to retrieve the software name and version installed on the device. indeni then compares the result to the same script run on other members of the same cluster.
        without-indeni: |
            Manual tracking by an administrator is usually the only method for knowing when two devices are not running the same version of software.
        can-with-snmp: false
        can-with-syslog: false
    panw-panos-panorama-cert-expr:
        why: |
            On April 3rd, 2017, Palo Alto Networks notified all customers that an upgrade to Panorama may be necessary to ensure uninterrupted communications between the Panorama device and the firewalls. Knowing which Panorama installations are affected is important.
        how: |
            This script uses the Palo Alto Networks API to retrieve the software name and version installed on the device.
        without-indeni: |
            An administrator would need to be aware of the issue and manually look at the software version of all Panorama installations.
        can-with-snmp: false
        can-with-syslog: false
    panw-installed-app-release-date:
        why: |
            Application package release date is important to keep track of the vendor release trains and subsequently the corresponding features.
        how: |
            This script uses the Palo Alto Networks API to retrieve the release date of the application package installed on the device.
        without-indeni: |
            Manual tracking by an administrator is usually the only method to know the application package release date.
        can-with-snmp: false
        can-with-syslog: false
    vendor:
        skip-documentation: true
    serial-numbers:
        skip-documentation: true
    concurrent-ssl-decryption-limit:
        skip-documentation: true
steps:
-   run:
        type: HTTP
        command: /api?type=op&cmd=<show><system><info></info></system></show>&key=${api-key}
    parse:
        type: XML
        file: show-system-info-monitoring.parser.1.xml.yaml

cross_vendor_compare_osname

// Deprecation warning : Scala template-based rules are deprecated. Please use YAML format rules instead.

package com.indeni.server.rules.library.templatebased.crossvendor

import com.indeni.server.rules.RuleContext
import com.indeni.server.rules.library.templates.SnapshotComparisonTemplateRule
import com.indeni.server.rules.RemediationStepCondition

/**
  *
  */
case class cross_vendor_compare_osname() extends SnapshotComparisonTemplateRule(
  ruleName = "cross_vendor_compare_osname",
  ruleFriendlyName = "Clustered Devices: OS name mismatch across cluster members",
  ruleDescription = "Indeni will identify when two devices are part of a cluster and alert if the OS installed is different.",
  metricName = "os-name",
  isArray = false,
  alertDescription = "The members of a cluster of devices must have the same OS's installed.\n\nThis alert was added per the request of <a target=\"_blank\" href=\"http://il.linkedin.com/pub/gal-vitenberg/83/484/103\">Gal Vitenberg</a>.",
  baseRemediationText = "Install the correct versions of software on each device.")(
  RemediationStepCondition.VENDOR_CISCO ->
    """|
      |1. Check that the vPC peers have the same NX-OS version except during the non-disruptive upgrade, that is, In-Service Software Upgrade (ISSU).
      |2. Execute the "show version" NX-OS command and check the installed NX-OS version across the vPC peer switches.
      |3. Schedule a Maintenance Window for NX-OS upgrade in order the vPC peer switches have exact the same NX-OS version.
      |NOTE: The vPC could be established between the vPC peers with not exact the same NX-OS name but several problems will be faced when new features are configured. For instance FEX-mismatch SW log message will be generated if you try to connect a FEX via vPC to a pair of vPC switches with different SW version. In this case the FEX will be operational only from one of the vPC peer switches.""".stripMargin
)

This notification is very important especially in scenarios where you are deploying OS updates from Panorama. Doing updates from Panorama increases the likelihood that you wouldn’t notice the red dot for an OS mismatch error on the firewall’s dashboard. If you have direct alerts from the firewalls configured, it will alert you as well.

If you are receiving this notification and while you are doing OS updates it is best not to disable the alert. The alert will “auto-resolve” after you complete your upgrades.

The benefit of this rule is making sure you DO NOT forget to update the entire HA cluster.