NTP servers used do not match across cluster members-paloaltonetworks-panos

NTP servers used do not match across cluster members-paloaltonetworks-panos
none 3.0 1

NTP servers used do not match 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 NTP servers they are using are different.

Remediation Steps:
Review the NTP configuration on each device to ensure they match.

How does this work?
This script pulls the Palo Alto Networks firewall’s active configuration and extracts the configured NTP servers from there.

Why is this important?
Tracking the currently configured NTP servers on all devices is important to ensure consistent time sync.

Without Indeni how would you find this?
An administrator may write a script to pull this data from devices and compare against a gold configuration.

panos-show-config-merged-monitoring-xml

name: panos-show-config-merged-monitoring-xml
description: Fetch the running config (xml)
type: monitoring
monitoring_interval: 60 minute
requires:
    vendor: paloaltonetworks
    os.name: panos
    product: firewall
comments:
    certificate-expiration:
        why: |
            Palo Alto Networks firewalls use certificate for a variety of different purposes. One purpose, for example, is inbound SSL inspection. If the certificate used by the firewall expires, certain services may be unavailable to external users.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration, reviews the certificates saved and retrieves their subject and expiration date.
        can-with-snmp: true
        can-with-syslog: true
    timezone:
        why: |
            Most configurations in Palo Alto Networks firewalls are synchronized across cluster members. Some are not, the timezone is one of them. It is important to verify that the timezone is the same on all cluster members to avoid confusion or issues.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the timezone from there.
        can-with-snmp: false
        can-with-syslog: false
    domain:
        why: |
            Most configurations in Palo Alto Networks firewalls are synchronized across cluster members. Some are not, the domain name is one of them. It is important to verify that the domain name is the same on all cluster members to avoid confusion or issues.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the timezone from there.
        can-with-snmp: false
        can-with-syslog: false
    login-banner:
        why: |
            Most configurations in Palo Alto Networks firewalls are synchronized across cluster members. Some are not, the login banner is one of them. It is important to verify that the login banner is the same on all cluster members to avoid confusion or issues.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the timezone from there.
        can-with-snmp: false
        can-with-syslog: false
    syslog-servers:
        why: |
            Tracking the currently configured Syslog servers on all devices is important to ensure consistent logging.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured Syslog servers from there.
        can-with-snmp: false
        can-with-syslog: false
    radius-servers:
        why: |
            Tracking the currently configured RADIUS servers on all devices is important to ensure consistent authentication and access.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured RADIUS servers from there.
        can-with-snmp: false
        can-with-syslog: false
    dns-servers:
        why: |
            Tracking the currently configured DNS servers on all devices is important to ensure consistent name resolution.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured DNS servers from there.
        can-with-snmp: false
        can-with-syslog: false
    ntp-servers:
        why: |
            Tracking the currently configured NTP servers on all devices is important to ensure consistent time sync.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured NTP servers from there.
        can-with-snmp: false
        can-with-syslog: false
    unencrypted-snmp-configured:
        why: |
            SNMPv2c is an unsecure protocol and should not be used. Users should prefer the more secure SNMPv3.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured services from there.
        can-with-snmp: false
        can-with-syslog: false
    telnet-enabled:
        why: |
            Telnet is an unsecure protocol and should not be used. Users may enable telnet unintentionally and should be alerted if they do so.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured services from there.
        can-with-snmp: false
        can-with-syslog: false
    http-server-enabled:
        why: |
            HTTP is an unsecure protocol and should not be used. Users may enable HTTP unintentionally and should be alerted if they do so.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the configured services from there.
        can-with-snmp: false
        can-with-syslog: false
    license-elements-used:
        why: |
            Collect information about the license usage and report installed licenses.
        how: |
            This script pulls the Palo Alto Networks firewall's active configuration and extracts the license information from there.
        can-with-snmp: false
        can-with-syslog: false
    app-update-acceptable-lag:
        why: |
            App update acceptable lag is important to determine because app updates can become out of date if the scheduled update job doesn't succeed.
        how: |
            This script runs determines the configuration scheduled and how frequently the updates should have run.
        can-with-snmp: unknown
        can-with-syslog: true
    av-update-acceptable-lag:
        why: |
            Anti-virus update acceptable lag is important to determine because Anti-virus updates can become out of date if the scheduled update job doesn't succeed.
            This script runs determines the configuration scheduled and how frequently the updates should have run.
        can-with-snmp: unknown
        can-with-syslog: true
    panw-app-update-action:
        why: |
            It is important to track the content (app/threat) version update action in the schedule. Following best practices this should be set to download and install based on a schedule. The rule will alert if not following best practices.
        can-with-snmp: unknown
        can-with-syslog: false
    panw-av-update-action:
        why: |
            It is important to track the anti-virus version update action in the schedule. Following best practices this should be set to download and install based on a schedule. The rule will alert if not following best practices.
        can-with-snmp: unknown
        can-with-syslog: false

steps:
-   run:
        type: HTTP
        command: /api?type=op&cmd=<show><config><merged></merged></config></show>&key=${api-key}
    parse:
        type: XML
        file: show-config-merged-m.parser.1.xml.yaml

cross_vendor_ntp_servers_comparison

Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/rules/templatebased/crossvendor/cross_vendor_ntp_servers_comparison.scala

I’ll comment the same as I did on the DNS server mis-match rule.

It is important to note when NTP servers may accidentally be misconfigured or even missing between HA peers. However, in some architecturally specific use cases such as business continuity or disaster recovery, unique NTP servers may be required. The primary site NTP servers may not become available in the new site if they are not load balanced/mirrored.

This is going to be a unique alert to the Indeni platform. If anyone knows of other systems that monitor this situation please comment. Also, if you have a DR/BC scenario where you wish not to receive this alert you can simply set the alert to be ignored for those devices only.