Validating Exceptions

Thanks.  My testing has revealed the following, which confuses me.  When i try to save the file to an excluded directory on my file server, the file server sends a warning message about a potentially dangerous file, but doesn't act on it, but waits for me to acknowledge it before it lets the file show up in the directory.

if i copy it to a directory that's not excluded, i get an immediate virus found and removed message.  So.  why do i even get a warning if scanning is disabled?  if i get a warning, then, the this tells me the directory isn't excluded from scans, just any action is prevented.

could someone clarify?

I'm not sure how you set up your tests: which file(s) you use for testing, where they reside and how you copy them. Does on my file server mean you are testing locally on the server? Sounds like you are using a browser (which one) and the message is part of the browser's save dialog. Sophos' messages are easily identifiable (if it doesn't look like Sophos it isn't Sophos :smileyhappy:) and only the DLP component offers a choice. Browsers, unpackers and other applications might also use temporary copies which further complicate testing.

In order to verify that certain paths are actually excluded it's best to

1. configure the exclusions
2. turn off on-access scanning
3. put the test file(s) in the directories of interest (optionally rename them if you want to exclude file patterns)
4. turn on-access on again
5. access the files/directories using the applications of interest (note that it might be necessary to use also the 8.3 names in the exclusion list)
6. if files are unexpectedly blocked look at SAV.txt and compare the displayed paths with your exclusions

If you still are getting "incomprehensible " results please post as many details as possible 

Christian

Here is what i did.

I modified an OnAccess scanning policy to exclude a network directory that exists on FileServer1.  I then modify the policy that 

fileserver1 is using to exclude that directory for OnAccess scanning.  Then, from a workstation that has scanning disabled.  I copy the file to fileserver1's excluded directory.  On the server console you see that it has found the eicar virus.  But, it doesn't deal with it, just tells me that it has found a dangerous file.  If i remove the exclusion, and then do the same procedure, the virus is found and is quarantined immediately.

So again, if an excluded directory is truly excluded, why would i even get a warning about a dangerous file.

On the server console you see that it has found the eicar virus ... why would i even get a warning.

Maybe I'm more than a little bit dense - are you referring to the SEC which shows an alert for the server? I have no idea what you mean by warning. A virus alert is a positive detection and dealt with (depending on your cleanup settings the minimum action is block and quarantine). What kind of scan lead to the detection is not visible in SEC but the client's Anti-Virus  log (SAV.txt) will tell you the details.

As you see yourself testing is not as simple as one might imagine. But first of all some words about scan settings and how they affect detection. You can enable/disable scan on read, write and rename. Thus if you have scan on read only and a file is written nothing is expected to happen until the file is opened for read. If the utility used verifies the copy (or the target folder is open in explorer) the file will immediately be opened for read though and the scan kicks in. Having the folder(s) open in Explorer often causes reads at the wrong moments and can cause confusion.

Files and paths: One rarely thinks about the intricacies of file systems and file access. When an application calls the applicable API to open a file this might not result in an actual open of the object sought for. Other routines are called when necessary (as is the case with files on the network). This can cause the path to get rewritten or translated. Sophos uses the path in use at the interception point. Thus for network files the scanner could record the UNC path whereas the open interceptor sees the original request. If you want play around a little turn off scanning, put eicar in a folder, share this folder, locally map this share as a drive, turn on scanning and access the test file via the mapped drive (watch for the drive letter reported). Now repeat this procedure this time excluding the local folder where eicar resides from scanning. Then once more mapping the share from a remote machine ... oh, and while you are at it - hardlink (fsutil hardlink create) eicar.com ...

I hope this is of some help. In general exclusions (especially of executables) should be avoided on workstations. Suspicious files can be authorized via policy, false positives (usually generic detections) should be sent to Support (note that signed applications are handled with slightly more "trust").

Christian