The important thing up front, here is the GitHub link to the FortiGate filesystem hash checker: https://github.com/KevinGuenay/fortigate-fs-hash-checker
As I was looking at my notes to enhance my FortiGate baseline, before publishing it, I came across a Fortinet technical tip article I saved months ago that talks about making periodic hash checks of FortiGate files as a best practice.
This is definitely something you should do, but there really is only the command to list the hashes and as the article states:
“It is important to note that this command does not do any comparison on its own; it will simply provide the hashes. It is possible to take a known-good hash from the unit and save it in a secure place, then run this command periodically to compare against the known-good file.”
So the comparison is something you have to take care of, and since there are, on my 70G running 7.6.6, 3695 files, doing this manually is quite the task. To make this easier and more approachable, I wrote the FortiGate filesystem hash checker.
What is it?
The FortiGate filesystem hash checker is a Python script whose main purpose is to compare a known-good hash list of FortiGate system files with a new list of hashes. It highlights modifications, additions, and removals, or tells you that everything is in order.
To function, you first need to create a hash list, and you can either provide this as a raw file using the “diagnose sys filesystem hash” command or by having the script connect to the FortiGate via SSH, executing the command, grabbing the output and saving it to a file. Once you have both a known-good file and a new file, let the script do its comparison and optionally save the result.
The script can take in a CSV file so you can compare multiple FortiGates with a single script execution.
For a more in-depth explanation of the script and how to use it, please read the README.md on the GitHub repository.
https://github.com/KevinGuenay/fortigate-fs-hash-checker
Why would I use it?
If your FortiGate was ever attacked and compromised, it is possible that files were in some way changed, added or removed to gain persistence, deploy malicious code, exfiltrate data, etc. These file actions would be reflected in the hash changing, a new hash appearing or an existing one disappearing, and this can be an Indicator of Compromise (IoC). This has happened in the past, like with FG-IR-22-398.
Fortinet is aware of these things and has implemented both pre- and post-boot mechanisms to check file integrity. Pre-boot, there is a BIOS-level signature and file integrity check and post-boot, there is a real-time file system integrity check, but checking all files is still a best practice.
When do I use it?
Right now! There is no time like the present, and without a known-good baseline, you won’t ever know if something happened.
Once you have your known-good file, run the FortiGate filesystem hash checker:
- Periodically, for some peace of mind
- After you suspect a breach
- Before an upgrade
- After an upgrade, to build a new known-good file
Note that some file hash changes simply happen from time to time, and this is expected, because these are all files on the system, so certificates and related files, regularly updated files (signatures, ISDB, the geo IP database, etc.) and so on will also show up.
Wrapping up
I am aware that the FortiGate filesystem hash checker isn’t going to be for everyone, but if the script helps even one person, that’s time well spent as far as I’m concerned.
With that in mind, check out the GitHub repository, look at what’s there, and make your own decision about how useful it is to you. I hope you will only ever see a “Everything is OK. No changes detected between the old and new filesystem hash files.” message if you expect the worst.
In the meantime, thank you, dear reader.
Leave a Reply