This content has been marked as final. Show 6 replies
We also had problems with jar files, dating way back to my predecessor and the 7.x days. Now at 8.5, we still exclude jar and js? basically because "its what we've always done". That reasoning bugs the heck out of me, but our corporate "culture" makes it extremely hard to change such a situation. (Its working, so leave it alone. Why don't you just test the changed settings? Oh, I'm way too busy to actually test my programs with your new settings. etc.etc. Sorry, end of rant:D)
So, I'd be interested to hear if 8.5 has fared any better with jar files, too.
The problem with .jar files is that they are encrypted and thus take a long time to scan even if your scan time out is low it will cause performance deterioration. My default process policy states not to scan archived files. This allieveated lots of performance issues. I find the risk is mitigated because once the file is unzipped and executed it will be scanned again and the malware would be discoverred.
I dont exclude any folders.
I exlude certain executables that were falsely being identified as Malware.
With 8.5i and above you can exclude folders from scanning on read or write. I suggest if you must exclude a folder, then only exclude on read, that way you will catch anything that attempts to write/overwrite that folder.
Thanks. In the VirusScan 8.5i course I took, the book does say that there are two ways of dealing with performance issues with .jar files. One to turn off on access scanning for archives (as you suggest), and the other is to exclude all .jar files. So if we turned off scanning archives, besides .JAR, .CAB, and .ZIP, what other archives would be excluded?
The one thing that concerned me in the book was the statement that Sun and Microsoft Java Virtual Machines do NOT write files to disk when .JAR files are unpacked, so any virus infected Java files would not be caught by the On Access scanner. Is this really the case?
Pretty much. If you say dont scan this... It wont, and without a scan it wont make a detection. We decided the risk was acceptable. Every ogranization will need to decide that for themselves. Aside from that java uses more than just .jar files. You will find even with .jar excluded applications that use java will continue to be slow with archive scanning enabled.
If your company uses a lot of java apps. I would recommend disabling archive scanning. It also helps as you said with .cab etc for installing various windows componants including SMS.
In my experience SMS is dog slow, even with the named componants being excluded.
I would at least keep archive scanning on in scheduled scans, its invaluable in picking up all those packed trojans from various torrents and keygen files
Nope it hasn't.
I've been fighting developpers off my phone and office because compiling slows down to a crawl in some cases.
So I created specific subgroups for developpers and for those I don't scan JAR, EAR, .class and other files. But I do weekly scans including those...
For most cases, skipping scans on Read was enough but I've got a group of developpers who still get performance issues and for those I also excluded scans on writing the files.
Edit : here's a link to another thread where someone asked about specific exclusions for SERVERS, and I put a link to MSFT's KB