Crashlog entries have been logged-fortinet-FortiOS
Vendor: fortinet
OS: FortiOS
Description:
Critical crashlog entries have been recorded to the crashlog file.
Remediation Steps:
- 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
Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/rules/templatebased/fortinet/FortinetCrashlogCriticalStatusRule.scala