Crashlog entries have been logged-fortinet-FortiOS

Crashlog entries have been logged-fortinet-FortiOS
0

Crashlog entries have been logged-fortinet-FortiOS

Vendor: fortinet

OS: FortiOS

Description:
Critical crashlog entries have been recorded to the crashlog file.

Remediation Steps:

  1. Login via ssh to the Fortinet firewall and run the FortiOS command “diag debug crashlog read”. The command output shows the crashlog in a readable format.
    |2. In many cases, entries and crashes in the crashlog are normal like an interface status change as is explained here: https://kb.fortinet.com/kb/viewContent.do?externalId=FD35212
    |3. A crashlog can be considered suspicious when: i) It happens at the same time with an abnormal FortiGate behavior. For example, an unexpected system reboot. ii) The crashed process is related with the FortiGate feature that failed. For example, a crash in the sslvpnd process when all SSL VPN connections went down. iii) After an unexpected reboot where crashlog and log should be reviewed
    |4. In some cases, the crashlog can provide information to Fortinet developers about the crash cause.
    |5. The explanation for each signal value logged to the crahslog can be found here: https://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm
    |6. Contact Fortinet Technical support at https://support.fortinet.com/ for further assistance.

How does this work?
This script is connected remotely to the Fortigate by using SSH and parses the log enties from the crashlog files by exectuing the “diagnose debug crashlog” FortiOS command. Log entries from the crashlog file about interfaces status change or with the status=0x0 / status=0x100 flags are ignored since are not considered as critical.

Why is this important?
Capture whether critical crashlog entries have been logged to the crash log file of the fortigate. Non-critical information logged to the crashlog file is ignored. More information can be found here: https://kb.fortinet.com/kb/viewContent.do?externalId=FD35212. The explanation for each signal value logged to the crahslog can be found here: https://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm

Without Indeni how would you find this?
The administrator will have to manually login to the device and check the crashlog file and logs. More information can be found here: https://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-toubleshooting-54/troubleshooting_tools.htm

fortios-diagnose-debug-crashlog

name: fortios-diagnose-debug-crashlog
description: FortiGate crashlog crtical entries status
type: monitoring
monitoring_interval: 59 minutes
requires:
    vendor: fortinet
    os.name: FortiOS
    product: firewall
comments:
    crashlog-critical-status:
        why: |
            Capture whether critical crashlog entries have been logged to the crash log file of the fortigate. Non-critical information logged to the crashlog file is ignored. More information can be found here: https://kb.fortinet.com/kb/viewContent.do?externalId=FD35212. The explanation for each signal value logged to the crahslog can be found here: https://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm
        how: |
            This script is connected remotely to the Fortigate by using SSH and parses the log enties from the crashlog files by exectuing the "diagnose debug crashlog" FortiOS command. Log entries from the crashlog file about interfaces status change or with the status=0x0 / status=0x100 flags are ignored since are not considered as critical.
        can-with-snmp: false
        can-with-syslog: false
steps:
-   run:
        type: SSH
        command: diagnose debug crashlog read
    parse:
        type: AWK
        file: diagnose_debug_crashlog.parser.1.awk

FortinetCrashlogCriticalStatusRule

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

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

import com.indeni.server.rules.RuleContext
import com.indeni.server.rules.library.templates.{NumericThresholdOnDoubleMetricTemplateRule, StateDownTemplateRule}

case class FortinetCrashlogCriticalStatusRule() extends NumericThresholdOnDoubleMetricTemplateRule(
    ruleName = "FortinetCrashlogCriticalStatusRule",
    ruleFriendlyName = "Fortinet Devices: Crashlog entries have been logged",
    ruleDescription = "Critical crashlog entries have been recorded to the crashlog file.",
    metricName = "crashlog-critical-status",
    threshold = 1.0,
    alertDescriptionFormat = "Number of critical crashlog entries: %.0f",
    baseRemediationText = """1. Login via ssh to the Fortinet firewall and run the FortiOS command “diag debug crashlog read”. The command output shows the crashlog in a readable format.
                            |2. In many cases, entries and crashes in the crashlog are normal like an interface status change as is explained here: https://kb.fortinet.com/kb/viewContent.do?externalId=FD35212
                            |3. A crashlog can be considered suspicious when: i) It happens at the same time with an abnormal FortiGate behavior. For example, an unexpected system reboot.  ii) The crashed process is related with the FortiGate feature that failed. For example, a crash in the sslvpnd process when all SSL VPN connections went down. iii) After an unexpected reboot where crashlog and log should be reviewed
                            |4. In some cases, the crashlog can provide information to Fortinet developers about the crash cause.
                            |5. The explanation for each signal value logged to the crahslog can be found here: https://people.cs.pitt.edu/~alanjawi/cs449/code/shell/UnixSignals.htm
                            |6. Contact Fortinet Technical support at https://support.fortinet.com/ for further assistance.""".stripMargin
)()