This article highlights an issue in Sophos UTM where user information is not logged when files are downloaded and scanned by Sophos UTM. It shows how this issue affects reports (both the the web usage reports on Sophos UTM, and in Fastvue Sophos Reporter), and how to work around the issue.
How Sophos UTM logs scanned file downloads
When downloading a file through Sophos UTM 9.4, the default behavior redirects the user to Sophos UTM’s download progress page (https://passthrough.fw-notify.net) while Sophos UTM scans the file for anything malicious.
Here’s what the web filtering log shows once the download completes:
The first log record shows a normal web hit. In this case, a gif image on the aarnet mirror page where you can download the latest Linux ISOs. The image URL is shown in the url=… field, and the page it was on is shown in the referrer=… field. But more importantly, notice the presence of the source & destination IPs, username, group and AD Domain (marked in red).
The second log record above is what Sophos UTM logs when actually clicking on the Linux ISO file and downloading it. Notice in yellow that only source IP is logged. The destination IP, user, group and AD domain are all empty. The referrer is also now passthrough.fw-notify.net which is the UTM’s download page. Highlighted in green is the URL of the file downloaded.
The actual function of downloading the file works fine, but the log event for the file download does not include useful ‘user’ information. When the browser is redirected to the passthrough URL, user information is dropped from the log.
How Sophos UTM scanned file downloads are displayed in reports
This issue of course affects your reports. As there is no authenticated username, the only information the reports can show is the Source IP, which Sophos UTM and Fastvue Sophos Reporter kindly resolve to a hostname.
Fastvue Sophos Reporter would ordinarily go one step further and match the authenticated username with a user object in Active Directory, then display the user’s real name in reports, dashboards and alerts. But as there is no way to match an IP or hostname to a user in Active Directory, Fastvue Sophos Reporter still shows the resolved host name, and the Departments section displays the unauthenticated traffic under the “Unknown” department.
Forcing Sophos UTM to log user information for scanned file downloads
You can force Sophos UTM to log username information for file downloads by adding the Web Filtering exception “Do not display Download/Scan progress page” for all users.
The downloaded file still gets scanned by Sophos UTM, but users will not be redirected to the progress page on the UTM (passthrough.fw-notify.net). This means there will be no visual progress as Sophos UTM downloads and scans the file, but once complete, the browser’s default download behavior springs into action as the scanned file is downloaded from the UTM.
Although this behavior may not be ideal as the user doesn’t see the scanning progress of a large file download, the username is now correctly logged with the downloaded file, and the reports reflect this.
Below is a screenshot of the logs with the exception enabled. The first log record again shows a normal web hit (an image downloaded from the web page that was accessed), and the second log record shows the large file that was downloaded. Both log entries include IPs, user, group, and AD Domain (shown in green).
Without the Do not display Download/Scan progress page exception, Sophos intercepts file downloads and redirects users to the Download/Scan progress page and only logs Source IP (which is resolved to a hostname in reports, but not in the logs).
Once the exception is enabled, Sophos UTM will still intercept the file to download and scan it, but the user will not be redirected to the Download/Scan page. The upside of this is that their username information will be logged along side the file download, which flows through to your reports.
It would be ideal if Sophos UTM logged username information when redirected to the Download/Scan page, but hopefully this workaround helps in the mean time.
A big thank you to Andrew Priest for researching, testing and sending through the information above!