Network interface ipv4 subnet does not match across cluster members-f5-all

Network interface ipv4 subnet does not match across cluster members-f5-all

Vendor: f5

OS: all

Description:
Indeni will identify when two devices are part of a cluster and alert if their network interface ipv4 subnet are different.

Remediation Steps:
Ensure the network interface ipv4 subnet setting matches across devices in a cluster.

How does this work?
This alert logs into the F5 unit through the iControl REST API and retrieves the IPv4 subnets of all self IP’s.

Why is this important?
To be able to search for IP addresses in indeni, this data needs to be stored.

Without Indeni how would you find this?
An administrator could login and manually check the “Self IP” subnets by logging into the web interface and clicking on “Network” -> “Self IPs”.

f5-rest-net-self

name: f5-rest-net-self
description: Determine self ip and network mask
type: monitoring
monitoring_interval: 5 minutes
requires:
    vendor: f5
    product: load-balancer
    rest-api: 'true'
comments:
    network-interface-ipv4-address:
        why: |
            To be able to search for IP addresses in indeni, this data needs to be stored.
        how: |
            This alert logs into the F5 unit through the iControl REST API and retrieves the IPv4 addresses of all self IP's.
        can-with-snmp: true
        can-with-syslog: false
    network-interface-ipv4-subnet:
        why: |
            To be able to search for IP addresses in indeni, this data needs to be stored.
        how: |
            This alert logs into the F5 unit through the iControl REST API and retrieves the IPv4 subnets of all self IP's.
        can-with-snmp: true
        can-with-syslog: false
    f5-port-lockdown-not-none:
        why: |
            Unless this is intentionally configured, such as a dedicated cable or VLAN for HA, it is recommended for security reasons to have the Self IP configuration to be set to "Allow None". In previous versions the default option when creating a self IP was to allow "Default" and that configuration would follow during upgrades. This metric keeps track of self IP's listening on any services. Please note that ICMP is implicitly allowed no matter what the port lockdown settings are, and does not need to be specified.
        how: |
            This alert logs into the device through SSH and uses TMSH to retrieve the port lockdown configiguration for all self IP's.
        can-with-snmp: false
        can-with-syslog: false
    f5-default-port-lockdown:
        why: |
            In earlier versions of TMOS the default port lockdown setting was "default". Leaving this setting in place could allow an attacker access to the management services of the device
        how: |
            This alert logs into the device through SSH and uses TMSH to retrieve the port lockdown configiguration for all self IP's.
        can-with-snmp: false
        can-with-syslog: false
steps:
   -  run:
          type: HTTP
          command: /mgmt/tm/net/self?$select=fullPath,address,allowService
      parse:
          type: JSON
          file: rest-mgmt-tm-net-self.parser.1.json.yaml

CrossVendorClusterInterfaceIpv4SubnetVsx

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