Update: The issue described below appears to be resolved in SonicOS 6.5. Make sure you also have DPI-SSL correctly enabled and configured, and the QUIC protocol disabled or blocked, as described in our article The Best SonicWall Configuration for Detailed Logging and Reporting.

We have noticed two issues in SonicWall’s logging that you need to be aware of if you are running SonicOS 6.2.7 and above, and you need to alert or report on Google searches.

Final Google Search Not Logged

When performing a Google search, a new ‘instant search’ is triggered on every key press. These get logged with a URL that looks like:

/complete/search?q=my+search

Then, once all the keystrokes settle down, a final search request is logged without the ‘complete’ part in the URL:

/search?q=my+search

Unfortunately, SonicWall is not logging these final requests. Only the ‘instant search / auto-complete’ requests are logged.

URLs are Truncated

To make matters worse, it appears Google’s URLs have become longer recently. I’ve previously raised the issue where SonicWall truncates URLs to 127 characters, which unfortunately means that search terms are often not logged, or only partially logged as they are now pushed further along the URL.

So even extracting the search terms from these ‘auto-complete’ requests is no longer working in most situations.

Logging Google Searches – Examples

This image shows the correctly logged activity resulting from three Google searches:

  • This is a test search
  • This is another test search
  • This is yet another test search
Logging Google Search URLs - Correct

The above activity is logged by another firewall (not SonicWall). You can clearly see all the auto-complete requests, then one final request with the full search term (highlighted in red). Notice the full URLs are logged and not truncated.

This image shows the same activity in SonicWall’s logs.

Logging Google Search URLs - SonicWall

Notice that only the auto-complete requests are logged and all URLs are truncated, preventing the full search term being extracted from any log lines.

Testing

This issue was verified in SonicOS 6.2.7.1-23n, as well as the new 6.5.0.0-25n beta (SonicOS 6.5.0_25n-1010750).

Tests were run with and without safe-search, and force-safe-search options enabled on SonicWall. Searches were done using Chrome (with Quic disabled), Firefox and Safari.

Testing was done by looking at the raw syslog text files created by Fastvue Syslog, but you could easily use something like Kiwi Syslog for the same purpose.

Effects on Alerts and Reports on Google Searches

This issue obviously affects any reports and alerts that work on the ‘Search Terms’ field in Fastvue Reporter for SonicWall, such those we’ve described in our article on monitoring web searches to prevent extremism and radicalisation.

The Search Terms section in User Overview Reports may be blank or only show partial searches.

We have informed SonicWall of the issue and hopefully, they will make a fix available soon! We’ll keep you posted!

Update: The issue described below appears to be resolved in SonicOS 6.5. Make sure you also have DPI-SSL correctly enabled and configured, and the QUIC protocol disabled or blocked, as described in our article The Best SonicWall Configuration for Detailed Logging and Reporting.

In other news, SonicWall has fixed another issue we reported previously where the ‘size’ of DPI-SSL traffic was not being correctly logged and affecting bandwidth reports. This is available in hotfix 6.2.7.1-23n—HF187283 which you can request from SonicWall support.