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

How to exclude a process?

Does anyone know how to exclude a process and all files it touches from real-time scan?

We want to improve the speed of backups and would like to exclude backup exec processes and files they read from being scanned by Sophos realtme scan.

Having used other products such as Trend and KAV, both have support for this however we are unable to find a similar feature in Sophos.

Cheers,

Max

:23427


This thread was automatically locked due to age.
Parents
  • Hello Behzad,

    sorry for the rant - here's another one (hidden so you don't have to read it :smileywink:)

    I'm always astonished and surprised when vendors - who should at least have some idea what their application is doing - appear to be clue- and helpless when it comes to issues in conjunction with AV-scanners (not only Sophos). As if running AV was something that couldn't be anticipated, a nice-to-have add-on rarely used. AV vendors are of course trying to make their product as light-weight and non-intrusive as sensible but there's a minimum overhead which can't be avoided. Frequent opens of many small files - not very efficient but inexpensive with today's OSs - will incur quite an overhead when scanning is active (even if a file is not rescanned its "fingerprint" has to be verified). Often the application's architecture and/or processing is somewhat convoluted (did I hear Exchange? - at least Microsoft concedes this and provides an interface for scanners). In addition it's often not possible for the same reasons to run an "AV-unaware" application on a hardened server (so you could feel at ease with setting scanning aside).

    Not surprisingly in this context the offered solution is making concessions - excluding processes (not only their own but "foreign" as well - e.g. databases and webservers), application folders, extensions - once had a vendor who used .py as extension (these were not Python scripts), scattered the files all over the place (they weren't only static but created during execution) and suggested we exclude *.py from scanning - and whatever. Of course they claim that this won't introduce an additional risk (ok, I misjudged them - they are experts in AV :smileytongue:) or that at least the performance gain outweighs any risk by far. Great! Excluding a process means that code it loads is exempted from scanning ...

    Admittedly not even Microsoft can give you clear instructions. Just read How to choose antivirus software to run on computers that are running SQL Server - read it carefully. Your server doesn't meet the criteria for a high-risk server? Fine. Servers that do not meet the criteria for a high-risk server are generally at a lower risk, although not always. Hm? Do you notice that on-access scanning isn't under the Virus tool types or did I miss it (and I'm not sure how vulnerability scanning fits in here)? I especially like the Virus sweep software paragraph: It scans existing files (meaning it does not scan the majority of files: the non-existing  ones :smileytongue:) [...] detects files after they are infected ...  nice description. and This kind of scanning may cause [...] SQL Server database recovery [...] issues. So - maybe this is about on-access, but is DB recovery normal operation? exclude [directories and extensions] from virus scanning [...] however, if these files become infected, your antivirus software cannot detect the infection. Wouldn't have known this without them telling me - so it's up to me to assess the actual risk? Processes to exclude from virus scanning - guess this is deliberately vague and unclear (especially in conjuction with the file exclusions).

    Enough. Sorry. Have to do this from time to time ...

    Don't think (but won't rule it out completely) that it's scanning of the application and its parts which causes the CPU consumption. Likely you can't play that much with different scanning settings, flushing the cache of already scanned files and so on. Thus I can only go along with Jak's suggestion - start with Process Monitor (perhaps use also Process Explorer to identify the processes with high delta I/O). You can save a captured period and analyze it on a different machine.

    Christian

    :26443
Reply
  • Hello Behzad,

    sorry for the rant - here's another one (hidden so you don't have to read it :smileywink:)

    I'm always astonished and surprised when vendors - who should at least have some idea what their application is doing - appear to be clue- and helpless when it comes to issues in conjunction with AV-scanners (not only Sophos). As if running AV was something that couldn't be anticipated, a nice-to-have add-on rarely used. AV vendors are of course trying to make their product as light-weight and non-intrusive as sensible but there's a minimum overhead which can't be avoided. Frequent opens of many small files - not very efficient but inexpensive with today's OSs - will incur quite an overhead when scanning is active (even if a file is not rescanned its "fingerprint" has to be verified). Often the application's architecture and/or processing is somewhat convoluted (did I hear Exchange? - at least Microsoft concedes this and provides an interface for scanners). In addition it's often not possible for the same reasons to run an "AV-unaware" application on a hardened server (so you could feel at ease with setting scanning aside).

    Not surprisingly in this context the offered solution is making concessions - excluding processes (not only their own but "foreign" as well - e.g. databases and webservers), application folders, extensions - once had a vendor who used .py as extension (these were not Python scripts), scattered the files all over the place (they weren't only static but created during execution) and suggested we exclude *.py from scanning - and whatever. Of course they claim that this won't introduce an additional risk (ok, I misjudged them - they are experts in AV :smileytongue:) or that at least the performance gain outweighs any risk by far. Great! Excluding a process means that code it loads is exempted from scanning ...

    Admittedly not even Microsoft can give you clear instructions. Just read How to choose antivirus software to run on computers that are running SQL Server - read it carefully. Your server doesn't meet the criteria for a high-risk server? Fine. Servers that do not meet the criteria for a high-risk server are generally at a lower risk, although not always. Hm? Do you notice that on-access scanning isn't under the Virus tool types or did I miss it (and I'm not sure how vulnerability scanning fits in here)? I especially like the Virus sweep software paragraph: It scans existing files (meaning it does not scan the majority of files: the non-existing  ones :smileytongue:) [...] detects files after they are infected ...  nice description. and This kind of scanning may cause [...] SQL Server database recovery [...] issues. So - maybe this is about on-access, but is DB recovery normal operation? exclude [directories and extensions] from virus scanning [...] however, if these files become infected, your antivirus software cannot detect the infection. Wouldn't have known this without them telling me - so it's up to me to assess the actual risk? Processes to exclude from virus scanning - guess this is deliberately vague and unclear (especially in conjuction with the file exclusions).

    Enough. Sorry. Have to do this from time to time ...

    Don't think (but won't rule it out completely) that it's scanning of the application and its parts which causes the CPU consumption. Likely you can't play that much with different scanning settings, flushing the cache of already scanned files and so on. Thus I can only go along with Jak's suggestion - start with Process Monitor (perhaps use also Process Explorer to identify the processes with high delta I/O). You can save a captured period and analyze it on a different machine.

    Christian

    :26443
Children
No Data