Everytime I log onto this blog another person has commented a load of tripe (RUBBISH). When will we ever get any decent intelligent information / comments?

I have a comment concerning file extension exclusions for realtime scanning.

(Please note that I advocate no exclusions at all for off-line scanning such as manual or scheduled scans. In these cases performance is not as much of an issue as with realtime scanning.)

As of today, files with a .log extension are not executable under Windows and I don't see that changing very soon. As such .log files pose no direct threat to the security of any windows computer.

An interesting experiment would be to create a windows shortcut to an executable file and call it 'tst.log'. See if you can manage to execute the original executable file by means of 'tst.log' alone.

If these files were to be used as payload containers for illicit code, they would still need a loader/executer/interpreter to be effective. This loader/executer/interpreter would necessarily be contained in a executable file which can and will be inspected by ao anti-virus software.

Hence there is no actual benefit for the malware writer to use .log files as payload containers unless he would endeavour to create a loader/executer/interpreter that would be too generic to be detected by explicit virus definitions and not generic enough to be detected by heuristic rules. I consider it highly unlikely that such sofwtare could succesfully be made and excape detection from all realtime scanners.

Therefore I would indeed recommend to exclude any .log files from realtime scanning. In fact I would advocate to add exclusions for many more extensions: .txt, .cpp, .obj, .bmp and *.cfg to name but a few.

The main benefit is of course reclaiming the lost performance due to realtime scanning of files for which realtime scanning offers no security benefits.

Regards and season's greetings,
Erik Cumps

And… what about your own white paper. Take a lot at http://trendedge.trendmicro.com/pr/tm/te/document/OSCE_8_0_MS_File_Exclusions.pdf

Lame-lame-lame

Is this something that the writer just stuffed together for the holiday week so they could get credit for it?

It must be a slow news day. This article was first published in 2003. The article does say something to the effect of "Antivirus vendor recommendations supercede those of this article" The article was written before Microsoft and Antivirus vendors had a come-to-Jesus meeting regarding the stuff in the OS that the AV software broke and the OS stuff Microsoft allowed the AV vendors to see to make their software work better. One classic example is SYSVOL replication (NTFRS). AV software would slightly modify the file and trigger replication. If you were running AV concurrently on DC's, you would be succeptible to collision and otherwise, replication would be out of control. Since SYSVOL contains group policies, you would effectively break them and become less secure.

I do not think any file/folder should be excluded from an AV's real-time scans; however, I do think that some files/folders/extensions should be excluded from on-demand scans in the interest of brevity. After all, it it didn't catch it real-time, how is it going to catch it on-demand?

Regards,

In your experience, have you come across a situation like what they describe in the MS Article where a virus scan, scanning these folders, has caused a machine to fail to work correctly?