FSCS 9.x slows down login whie scanning printer drivers
i'm experiencing a problem which I hope to solve with some F-secure settings. or if anybody knows what Group policy settings could be used to solve this.
When a user logs into one of our domain computers their printers are mapped via Group Policy Preferences. From a Server 2008R2 print server. (shared printers)
FSCS 9.x (all the versions i've tried) scans the printer drivers while they are being mapped. this would not be a problem if it did the scans in a swift manner, it is a problem when it turns what should be a 30 second - 60 second login into 15 minutes.
FSCS uses 100% of the processor during the scan, (or 50% or 25% depending on number of cores).
does anybody know of a setting either in FSPM or Group Policy that would prevent this unnecessary behavior? Maybe a setting to prevent scanning of signed drivers?
what printers are beeing connected?
Are the drivers local?
check fa.log to find WHAT file causes that problem.
Does it help to exclude that file from scanning.
If yes submit the file to analysis.com and mention this thread in the comment. Post the received Ticket ID here.
Thanks for the info.
The drivers are not local, they are stored on the print server but are installed during the printer mapping process.
The file that seems to cause the problem is the x2UNIVI6.cab that exists in the Xerox Universal Print Driver.
upon further investigation there is an additional nested CAB which houses the problem files, specifically the xrx8560.cab
Based on what i've seen all of the files which cause f-secure to time out are in this nested CAB
I don't know of a way to exclude this file from scanning, as the file is being transfered from the server and installed on the local computer on user login. Is there is an f-secure setting that will prevent real-time scanning of this particular file? I'd rather not blanket allow .cab files if possible. Or blanket allow archive files.
I should have mentioned before that this slow down, only occurs on the first login of a user to a computer. once they have gone through this 12 minute login while the printers are being mapped, they no longer experience a slowdown on login.
I'll run a few tests on my guinea pig machine and i'll follow through on your suggestions.
it seems that you have activated "archives" and/or "all files" in real time scanning. Please turn that off again.
Thanks for the info,
we've decided that rather than disabling realtime scanning on all files or on archives, we've just added the CAB file extension to the excluded file type for realtime scanning.
for anybody else who may have this issue,
some things had to be done,
remove the CAB file extension for the list of compressed files in the advanced view of FSPM
enable excluded file extensions from realtime scanning
add CAB as an excluded extension from realtime scanning.
this way FSCS will still scan other compressed files, but will not scan CAB files.
CAB files don't have a built in autorun so even if malicious software comes in in a CAB the user still has to extract it at which point the files would no longer be CAB files and would be scanned. not the best, but ok for us.
Thanks for the pointers on where to look.
neither scanning "all files" nor scannining "inside archives" makes any sense in relatime scaning. All really vulnerable file-formats are covered by F-secure and forcing the scanner into trying to detect a malware in some BMP or in a wrong location for the malware slows down the system significantly and will sooner or later produe false positives.
if you scan inside archives the archive in unpacked to memory first then scanned with high priority over the network, then downloaded to local temp, scanned again (because writen to local temp). now the archive gets unpacked and each file inside the archive gets scanned again.
And because each file inside the archive gets scanned when the archive is unpacked you do not need to scan the archive first.
The archive is no danger to the system, nor are the files inside as long as these do not get executed. (i.e. even copying malware is basically not a dangerous action).
The task of an Antivirus is to avoid that malicious code, that gets executed in the CPU can perform its action.
if we are able to identify that code before loading then we are fine, but it does not make sense (for performance reasons) to search the same thing in the same file several times.
A malware inside an archive is as unproblematic as the same malware on an USB-stick, a share, the internet, or even inside a temp folder.
I think you get the point.
Please deactivate "allfiles" and "archives" fro real-time scanning!
Exclusions are only acceptable as a temporary workaround. The AV has to handle this by itself.
Excluding CAB in general poses a high risk to you system, while turing off theabove mentions options does not increase your risk at all!