Sandstorm - finding suspicious files, not sending them for analysis

Hi jlbrown,

Judging from the data you provided, it seems that either your UTM cannot reach the Sandstorm server, or there was a problem with the Sandstorm service itself. Please verify the following:

• Does /var/log/sandboxd.log contain any errors?
• Is the Sandstorm daemon running? You can verify it by executing 'ps aux | grep sandboxd' from the console.
• Is sandbox.sophos.com:443 reachable from your box?

Kind regards,
Niriel~

Thanks for replying Niriel.

• /var/log/sandboxd.log was empty

• ps aux | grep sandboxd

  810      13731  0.0  0.0 103152   504 ?        Ssl  Mar31   1:16 /var/chroot-http/usr/bin/sandboxd --chroot /var/chroot-http --u httpproxy

  100      32733  0.0  0.0   3628   736 pts/1    S+   10:24   0:00 grep sandboxd

• from my desktop, can't reach sandbox.sophos.com:443. If I try https://sandbox.sophos.com it gives me: 40x: Error. If I enter: sandbox.sophos.com:443 in my URL bar it just says that it can't open the page because the server unexpectedly dropped the connection. Do I have to do it from the UTM? If so how?

Thanks, James.

Hi James,

It looks like the Sandstorm daemon is properly running.

The logfile is most probably empty since it's rotated daily and you don't have any Sandstorm submissions (failed or successful) today, so please check the logfile of the day when you encountered the error. It can be found under /var/log/sandboxd/YEAR/MONTH/sandboxd-YEAR-MONTH-DAY.log.gz. Since the older log files are compressed, you can use 'zless /var/log/sandboxd/YEAR/MONTH/sandboxd-YEAR-MONTH-DAY.log.gz' to check its contents.

If you don't know which day the error happened and just noticed the results afterwards, you can find the time by executing 'find /var/log/smtp/2016/ -exec zgrep -- 'Analyzing message content' {} +'. Note: The older log files are found under /var/log/smtp/YEAR/MONTH/smtp-YEAR-MONTH-DAY.log.gz (replace YEAR, MONTH and DAY with the actual date), so if you can narrow down the time window when the error happened, e.g. in March, you can modify the above command to 'find /var/log/smtp/2016/03/ -exec .....' to make it run faster. This should return you one or two lines (depending on whether the two suspicious files that should have been submitted were attached to a single mail or different ones) from the SMTP logs, which contain the exact time when Sandstorm was invoked. Using these times, you can check the corresponding day's Sandstorm log.

Regarding reaching sandbox.sophos.com, using 'ping sandbox.sophos.com' should be fine, but you can do the same on WebAdmin > Support > Tools > Ping check page. :)

Kind regards,
Niriel~

Thanks Niriel.

Ping won't tell me I can connect on port 443 will it?

Not sure what error you are talking about.

Today there were 5 suspicious files in Emails, but it looks like they were not sent for analysis:

When I run that find command I get:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

repeated over and over

Thanks again Niriel for your help,

James.

Hi James,

I'm expecting to see some errors in sandboxd.log, as suspicious files - if not excluded - should clearly be submitted for analysis. The "Suspicious" counter on the Advanced Threat Protection page comes from the SMTP daemon and shows how many files were identified as suspicious as part of the AV scanning process. The "Sent for analysis" counter however is increased by the Sandstorm daemon after it submits the file for analysis to the Sandstorm server, so the problem was somewhere in between.

One of my ideas - without knowing any details - is that maybe the Sandstorm daemon cannot contact the remote server, so if you can verify that outbound HTTPS traffic (port 443) is enabled from your network and you're able to reach the remote Sandstorm server (at sandbox.sophos.com), we can either rule out or confirm this possibility.

From your last message, let me confirm: there were 5 suspicious mails today, however /var/log/sandboxd.log is still empty? If that's so, then there's most probably no point in looking at older logfiles. Otherwise please try executing the commands as root, you may not have access to the directory containing older log files otherwise.

Kind regards,
Niriel~

Confirming: 5 suspicious mails, nothing uploaded for analysis, empty log.

Logging in as root and executing the find command gives:

# find /var/log/smtp/2016/ -exec zgrep -- 'Analyzing message content' {} +

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

I agree that the problem seems to be with connecting to sandbox.sophos.com.

How can I "verify that outbound HTTPS traffic is enabled on our network"? I can access external https web sites from within my network no problems. But even from my home computer (so Sophos UTM) https://sandbox.sophos.com returned a page with just:

40x: Error

on it.

Hi James,

This is going to be very basic, but please confirm these just in case: you DO have an active Sandstorm license and you DO have the "Enable Sandstorm" option turned on at Email Protection > SMTP > Malware tab, right?

Kind regards,
Niriel~

You got it Niriel!

License was active (using the beta one at the moment, valid until 17 April). But "Enable Sandstorm"  was turned off in Mail Protection/SMTP/Malware scanning. Have turned it on now, so hopefully tomorrow the logs will so files being uploaded to Sandstorm.

I will report back tomorrow.

Thanks Niriel.

Hi James,

It seems like I overcomplicated things a bit... :)

Suspicious items will be detected and displayed on WebAdmin even if you don't have Sandstorm turned on or don't even have an active Sandstorm license in the first place, so you will be able to see if your traffic includes suspicious elements. Using that knowledge you can make the decision whether your system will benefit from using Sandstorm or not.

Having turned the feature on, you should now start seeing suspicious items being submitted for analysis and dealt with according to its result. I will await your reply!

Kind regards,
Niriel~

Adding a test for sandstorm tool for diagnosing connection issues might not be a bad idea

Could do something like

Checking that Sandstorm is configured to be active...passed
Checking that Sandstorm daemon is running... passed

DNS Server Connectivity Test 
Successfully pinged your DNS servers. ... passed

Google Lookup Test 
Successfully performed a DNS lookup on www.google.com... passed

Outbound Sandstorm Lookup Test 
Successfully performed a DNS lookup on sandbox.sophos.com... passed

Internet Connectivity Test 
Successfully Pinged google.com... passed

Sandstorm Connectivity Test 
Successfully Pinged sandbox.sophos.com... passed

Secure connection to Sandstorm established
Successfully connected to Sandstorm over port 443 ... passed

Uploading of Test file for analyst... passed
Received results ...... passed

Checking error log for exceptions ... passed

It works!

Re 'overcomplicated things a bit', as soon as there is a step-by-step instruction document detailing all the places things need to be turned on, you'll get people like me not knowing if it is working or not, or how/where to turn it on.

All our Web files were being 'excluded by policy' - took a bit of hunting to realise where that setting was.

Anyway, all good now.

Thanks again Niriel.

It works!

Re 'overcomplicated things a bit', as soon as there is a step-by-step instruction document detailing all the places things need to be turned on, you'll get people like me not knowing if it is working or not, or how/where to turn it on.

All our Web files were being 'excluded by policy' - took a bit of hunting to realise where that setting was.

Anyway, all good now.

Thanks again Niriel.