What does the Reliable Logging feature on FortiGate/FortiAnalyzer do?

Because in order for logs to be useful, they need to exist...

What does the Reliable Logging feature on FortiGate/FortiAnalyzer do?
Photo by Patrick Fore / Unsplash
💡
This is part of an on-going series in cybersecurity foundations. Check the cyber 101 article tag index from time to time for more content.

Security logs are absolutely critical for effective cybersecurity operations. While that mindset can apply to any security control, it's especially true for firewalls. There's a modern-day challenge though: if logs are ultimately consolidated off-device, how do you know you have every log event properly stored? What assurance is there that logs aren't skipped/lost in transit? That's what the "Reliable Logging" feature aims to address.

At its core, the Reliable Logging feature focuses on three big needs:

  • Preventing log loss - I mentioned this at the intro but I'll repeat it: we need a way to essentially guarantee that logs generated by the FortiGate are successfully delivered to the configured log server (FortiAnalyzer).
  • Encrypting logs during transmission - This is optional but often helpful since logs can occasionally have sensitive information. Reliable Logging has a feature to encrypt the transmission of the data using SSL-encrypted OFTP (Optimized Fortinet Transfer Protocol).
  • Ensuring correct order - Storing log data is important but there's also an inherent expectation to store the data in the correct order/sequence. Reliable Logging helps with that to by tracking logs with IDs.

How it works

OK, enough context. Let's walkthrough how it works :-) Basically there are six parts, done in partnership with FortiAnalyzer:

  1. Log Generation - Something happens on the FortiGate that requires logging. This could be anything (e.g. traffic activity, security events, admin actions, etc). The decision on what to log is handled elsewhere in the configs and is part of standard settings. Once the FortiGate decides it needs to log something, it writes the corresponding data to a memory queue.
  2. Initial Transmission - The FortiGate attempts to send the log events to the FortiAnalyzer.
  3. Sequence Numbers - Both the FortiGate and FortiAnalyzer use sequence numbers (seq_no) to track the logs it has received.
  4. Confirm Queue - After the FortiGate attempts to send logs to FortiAnalyzer, the logs are then moved to a "confirm queue" (which is still local) on the FortiGate. This is essentially a special holding area (either in memory or disk depending on what's available with the FortiGate unit) while the firewall waits for confirmation of receipt from the FortiAnalyzer.
  5. Acknowledgement and Clearing - The FortiGate periodically queries the FortiAnalyzer for the latest sequence number of the logs it has successfully received. Once the FortiGate receives this information, it clears the corresponding logs from it's confirm queue.
  6. Retransmission upon disruption - If there's a connection issue between the FortiGate and the FortiAnalyzer, the FortiGate continues to cache new logs in its memory queue. When the connection is restored, the FortiGate resends the logs that are still in the confirm queue (which the FortiAnalyzer hasn't acknowledged receipt for).

That's it! Pretty straight-forward, huh. For more information check out the following resources:

FortiAnalyzer log caching | Administration Guide
Improve FortiAnalyzer log caching | New Features