SonicOS 6.2.6.0-20n New CFS and New Logging Bugs

SonicWALL have released a firmware update (6.2.6.0-20n) that features a complete re-working of their Content Filtering System (CFS), as well as a new sandboxing feature called Capture Advanced Threat Protection (ATP) feature.

These new features are amazing, but there is a problem we'd like all our customers to be aware of before upgrading.

Update #1: We’ve been notified that SonicWALL have fixed this issue described below in a hotfix (6.2.6.0-20n–HF176616-1n). Customers can request this via SonicWALL support now, and it will be included in 6.2.6.1 generally.

Update #2: We’ve tested the hotfix and unfortunately there is another logging issue. The size values go from crazy-huge (see below) to crazy-small. SonicWALL are aware of the issue and are working towards a fix.

Update #3: SonicWall released another hotfix for the tiny size values (6.2.6.1-25n--HF180023-1n). This only fixes the problem but only for normal HTTP traffic. HTTPS traffic going through DPI-SSL is still logged with tiny size values. This issue is also present in the newer 6.2.7.0 release.

Update #4: SonicWall released another hotfix for the small size values in DPI-SSL traffic. The hotfix to request from SonicWall support is SonicOS 6.2.7.1-23n--HF187283. But please be aware of another logging issue in this firmware version that affects reporting on Google searches.

Received Size Logging Bug in SonicOS 6.2.6.0

Unfortunately, there is an issue with the syslog messages sent to Fastvue Reporter for SonicWALL, where most of the 'received size' values are astronomically large.

Here are two log lines sent by SonicWALL running SonicOS 6.2.6.0-20n

id=firewall sn=18B1691F9960 time="2016-08-09 12:50:26 UTC" fw=10.1.1.219 pri=6 c=1024 m=97 app=11 n=304 src=192.168.168.133:53880:X0 dst=104.244.43.199:443:X1 srcMac=28:cf:da:ef:f9:2c dstMac=18:b1:69:1f:99:60 proto=tcp/https sent=517 **rcvd=7562717807960391680** dstname=pbs.twimg.com arg=/ code=58 Category="Social Networking"

id=firewall sn=18B1691F9960 time="2016-08-09 15:34:15 UTC" fw=10.1.1.219 pri=6 c=1024 m=97 app=11 n=4722 src=192.168.168.133:59992:X0 dst=74.125.200.214:443:X1 srcMac=28:cf:da:ef:f9:2c dstMac=18:b1:69:1f:99:60 proto=tcp/https sent=225 rcvd=5367667152344055808 dstname=app.pendo.io arg=/ code=15 Category="Business and Economy"

Note the "rcvd" field. The values here are 7562717807960391680 and 5367667152344055808 respectively.

Affected Reports in Fastvue Reporter for SonicWALL

In Fastvue Reporter for SonicWALL, you will probably first encounter the affects of this problem on the Overview Dashboard:

Notice the Total, Average and Largest download sizes. Alternatively, you may see all the values here displayed as zero (0).

Any report, alert or dashboard widget that displays size information will be affected in similar ways.

Pretty...

If you have already upgraded, you may like to turn off the 'Large Download' alert as this bug may cause it to be triggered for almost every log record. To do this, go to Settings | Alerts and switch the Large Download alert to Off.

The good news is that the new update fixes the bug we previously reported where categories were not being logged for allowed traffic.

Current Status

It's important to note that SonicWALL Analyzer, GMS and any other syslog collection/reporting tool will also be affected by this issue.

We have informed SonicWALL of the bug and it is currently with engineering. Hopefully, they resolve the issue soon.

Latest Update: SonicWall has fixed these issues in hotfix SonicOS 6.2.7.1-23n--HF187283. The hotfix currently needs to be requested from SonicWall support. But please be aware of another logging issue in this firmware version that affects reporting on Google searches.

We'd love to find a way to work around this, but unfortunately, there's no way we can make sense of the received size value in the data SonicWALL is providing us via Syslog.

In the mean time, hold off on that upgrade if you're enjoying your Fastvue Reports!