FortiOS 7.6.7 – Significant increase in daily log volume sent to FortiAnalyzer without configuration changes

Hi AEK,

thank you for the suggestion.

I displayed the Hit Count column in the firewall policies and checked the highest-hit rules. The most active policies are:

policy 127  ~8.6M hits
policy 0    ~8.3M hits
policy 124  ~5.4M hits
policy 341  ~4.3M hits
policy 112  ~2.9M hits
policy 130  ~2.2M hits
policy 339  ~1.8M hits

After that I created some custom FortiAnalyzer datasets to check which policy/application/log type is responsible for the increased log volume.

For Application Control logs, the largest contributors were mainly normal generic web/network applications:

policy 127  SSL                  ~1.4M logs
policy 127  SSL_TLSv1.3          ~1.2M logs
policy 127  HTTP.BROWSER_Chrome  ~1.1M logs
policy 127  WebSocket            ~1.0M logs

policy 124  SSL                  ~968k logs
policy 124  SSL_TLSv1.3          ~920k logs
policy 124  WebSocket            ~866k logs

policy 130  SSL                  ~319k logs
policy 130  SSL_TLSv1.3          ~285k logs
policy 130  WebSocket            ~246k logs

For Traffic logs, the same policies are also on top:

policy 127  close       ~1.33M logs
policy 124  close       ~949k logs
policy 339  accept      ~777k logs
policy 112  accept      ~465k logs
policy 127  accept      ~402k logs
policy 130  close       ~304k logs

For Web Filter logs, most of the volume is normal allowed/passthrough web traffic:

policy 127  chat.xxxxxxxx.cz        passthrough  ~701k logs
policy 124  chat.xxxxxxxx.cz        passthrough  ~538k logs
policy 130  chat.xxxxxxxx.cz        passthrough  ~199k logs
policy 127  h.xxxxxxxxx.cz           passthrough  ~150k logs
policy 127  chat.nxxxxxxx.cz       passthrough  ~150k logs
policy 124  chat.sxxxxxxxxxx.cz  passthrough  ~140k logs
policy 124  chat.xxxxxxxx.cz       passthrough  ~123k logs

So it looks like the increased log volume is not caused by one new firewall policy or one obvious configuration change. It is mostly generated by existing high-traffic policies, especially policy 127 / 124 / 130, which already existed before the upgrade.

I also checked the Application Control profile used on these policies. The profile has:

extended-log disable
other-application-log disable
unknown-application-log disable

but there is one broad pass entry with logging enabled:

edit 16
    set category 5 7 12 15 17 21 22 23 25 28 29 30 36
    set action pass
    set log enable
next

This means that many normal allowed application categories are explicitly logged. After the upgrade to FortiOS 7.6.7, it seems that the FortiGate/AppControl engine started matching/logging much more normal web/network traffic such as SSL, TLS 1.3, WebSocket, Chrome/Edge browser traffic, Microsoft 365, etc.

As a test, I changed this broad pass entry to:

set log disable

while keeping the action as pass, so blocked applications are still logged, but normal allowed high-volume categories should no longer generate so many AppControl logs.

I will monitor the FortiAnalyzer daily log volume now and see whether the Application Control log volume drops.

So far, the conclusion seems to be:

- Firewall policies were not changed.
- The highest log volume comes from existing high-hit policies.
- Application Control and Web Filter logs increased significantly after FortiOS 7.6.7.
- The main AppControl contributors are generic allowed apps like SSL, SSL_TLSv1.3, WebSocket and HTTP.BROWSER_Chrome.
- The broad Application Control pass category entry with log enabled is probably the main reason why the new FortiOS version generates much more log volume.

Thanks again for pointing me to the policy hit count — it helped narrow this down.

Jirka

Two raw log exports (rlog) were pulled from FortiAnalyzer for comparable 3-hour windows

Pre-upgrade                                 Post-upgrade

Time span covered by 100k rows:
501 s (~8.3 min)                          249 s (~4.15 min)
Estimated log rate:
~200 logs/sec                             ~402 logs/sec

Overall log rate roughly doubled.

The increase is concentrated almost entirely in appcat="Network.Service" app-ctrl entries, which grew from ~36% to ~72% of sampled volume. Within that category, three specific app signatures account for nearly the entire delta:

                             appRate beforeRate afterMultiplier

WebSocket            0.22/s     68.5/s             ~310x
SSL                        32.8/s 1  05.9/s             ~3.2x
SSL_TLSv1.3         15.6/s     83.4/s             ~5.3x

These three signatures alone account for ~209 logs/sec of the ~202 logs/sec total increase.

Per-session log density was also compared between the two samples, confirming that 7.6.7 generates more app-ctrl log entries per individual session (not just more sessions overall):

                                                   7.4.12                                       7.6.7

Total app-ctrl logs (sample)    100,000                                    100,000
Unique sessions                        41,751                                     34,226
app-ctrl logs per session               2.40                                         2.92
Sessions with 2+ app-ctrl logs      53.0%                                    70.8%

This indicates that in 7.6.7, the same session is more likely to generate multiple app-ctrl log entries over its lifetime (e.g., re-classification/re-logging as the detection engine refines its verdict), rather than the increase being purely driven by a higher number of new sessions. This supports the hypothesis that the change originates in the application detection engine's logging behavior rather than in actual traffic volume or session count.

No firewall policy or Application Control profile configuration was changed during the upgrade. The most plausible explanation is that the built-in IPS/Application Control detection engine and/or signature database bundled with FortiOS 7.6.7 changed detection/classification granularity for generic protocol traffic:

WebSocket appears to be newly recognized as a distinct application signature post-upgrade — pre-upgrade, this traffic was apparently not being logged as a discrete per-flow entry (or was folding into a broader SSL/SSL_TLSv1.3 classification).
SSL and SSL_TLSv1.3 per-flow log volume also increased substantially, suggesting the new engine may segment TLS handshake/renegotiation events differently for long-lived connections (chat keep-alives/reconnects).

Jirka