This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

OSX Exclusions

Hi,

Currently investigating Sophos for an enterprise deployment. Our environment coveres Windows, Linux and OSX. There's lots of reading regarding file/folder exclusions for Windows desktops and server but AKAIK less so for OSX exclusions. I appreciate that a lot of it is environment-specific, but wondered on member's recommendations.

For example, I've noticed this post:

http://openforum.sophos.com/t5/Sophos-Anti-Virus-for-Mac-Home/Consuming-huge-amounts-of-disk-space-during-scan/m-p/107

Therefore, DMGs could be excluded.

What about other file/folders? Our environment is publishing so InDesign files would be excluded for example - what do other OSX enterprise users do?

Any pointers, thoughts, suggestions welcome.

Thanks

:8049


This thread was automatically locked due to age.
  • HI,

    I think much of it comes from the understanding of the applications that are running and how they behave.  Establishing the roles a machine provides or common applications used, would be the first place to start.  I think it is safe to discount the OS to a large degree as any exclusion that "needs" to me made in the AV software already is.

    As an example if a file is being opened, updated, saved, opened updated, saved etc., then as a result SAV will have to re-scan the file each time it is opened as it is changing, and if on-write scanning is also enabled it will be scanning it in quick succession.  The number of times around that loop and the quicker it loops the more of a performance hit something like SAV will have.  

    A good example of this is a database file as these are constantly changing.   A configuration file may also be updated in a similar fashion but typically in a less intensive manor.  For this reason a database file, whatever format it might be would be a good candidate to exclude from on-access scanning.  It can always be scanned later with a scheduled scan; just be careful with any automatic actions taken. It would be safer to take no action in my opinion, the last thing you need is for SAV to find a fragment in the file only to delete an entire database, when through some viewer that understands the format of the data file and can present it, it could have been looked at and dealt with appropriately.

    From a Windows standpoint, just running Process Monitor on a machine for 10 mins and then choosing: "Tools" - "File Summary..." and sort by the number of "Opens", "Writes", etc, might give you a good ideas as to what might be worth considering for excluding but only if you are suffering from significant slow down.  At that point you can then decide on the chance of the file being infected, and if it's really executable in the format on disk.  For example a mail file.  If a virus is downloaded to an inbox, it might exist in a .eml file in some encoded form.  How much of a risk does that eml file pose on a standalone machine without a viewer such as Outlook to render it and make it dangerous to a user?  

    Starting a commonly used application with Process Monitor running would be another good example, as you can see all the files the application opens, updates etc.  A few careful exclusions may speed up the start-up time of that application but it really depends on the application.   Is there something similar on Mac to Process Monitor?

    I think ultimately, there are many reasons why people exclude files, not all of them are necessary valid.  One reason might be that files in the past have been automatically deleted due to people configuring their AV software to automatically delete which is a bad idea.  This has influenced people to exclude "important" files as it seems safe.  Maybe they want to automatically delete viral files but can't choose in the software to only delete virus files if they are in directory X which is maybe just the temporary internet files or Windows\user temp.

    Other reasons might be that the way a file is opened and written could result in a deadlock, especially if on-access is set to scan on read, rename and write.

    Performance is clearly another reason and as long as the security trade off is calculated and deemed acceptable then it's fine.  Using the method mentioned above it's possible to find good candidates for exclusion.  Otherwise contacting the vendor and or searching on their forums/knowlegebase is the best idea as they should know how the application will behave and what files are intensively read and written to.

    Jak

    :8067