A response to my previous blog post asked a fair question: what sets
NOD32 apart or even on par with Trend Client-Server Messaging? I decided that I
would do some testing with Trend. Since I am using NOD32 without the Exchange
component, I tested Trend Client-Server without the Messaging component.
KeyFinder Problems
I've been building a UBCD4WIN version 3.12 ISO file as my test case. UBCD4WIN includes a
large number of plug-ins. One of them is keyfinder.exe, the Magical Jelly Bean
Keyfinder version 1.51. This handy program can display and update Windows and
Office installation keys.
I installed the Trend 3.5 agent on my workstation and tried the UBCD4WIN
build. The build failed because the keyfinder.exe file was missing. By
uninstalling and re-installing UBCD4WIN, and temporarily disabling the Trend
agent, I confirmed that Trend is deleting this file without logging it as a
virus or spyware and without sending it to quarantine. Trend is supposed to
encrypt and save suspicious files on the client in C:\Program Files\Trend
Micro\Client Server Security Agent\Suspect, but that folder is empty. I finally
got Trend to leave the file alone by adding keyfinder.exe to Trend's exclusion
list.
Is this a bug? I guess I'd better try the latest version, Trend 3.6 with Patch 1.
I downloaded the 336MB installation file, upgraded the server, and let it push
out the 3.6.1095 client. No reboot was requested.
After removing the file exclusion from the Trend configuration, I opened Windows
Explorer and highlighted keyfinder.exe (but did not execute it). The Trend icon
in the system tray indicated activity, then I got a message from Windows
indicating that my system may be vulnerable because Trend was not running. The
Trend system tray icon disappeared when I put the mouse over it. So scanning
keyfinder.exe caused the Trend Real-Time scanner to crash.
I rebooted the client and did the same test, highlighting the file in Windows Explorer. This time keyfinder.exe was
not deleted and the Trend real-time agent did not crash. However, the
UBCD4WIN build process, which actually copies keyfinder.exe, failed again
because access was denied on that file. When I went back to look at
keyfinder.exe in Windows Explorer, it was deleted before my eyes. The Trend
Client/Server Security Agent real-time scan window still tells me that there are
0 infected files; “Last virus/malware found” is blank. So Trend is again
deleting it without any warning or logging. I had to add the file back to the
exclusion list so I could complete the UBCD4WIN build.
The Numbers
Once I got the UBCD4WIN build to complete, I tested it with various levels of
extension exclusions as I had NOD32. The results, along with the NOD32 2.7
results from the previous post:
| Trend Client-Server 3.6.1095 | NOD32 2.7.39 | |
| Trend Intelliscan | 14 minutes | N/A |
| Scanning only specific extensions | 12 minutes | 14 minutes |
| Scanning all extensions | 15 minutes | 20 minutes |
Some other numbers that are interesting from a system administration point of view are
installation size and memory overhead. The table below summarizes these numbers
for both server and workstation installations.
| Trend Client-Server 3.6.1095 | NOD32 2.7.39 | |
| Server | ||
| Installation File Size | 336MB | 25MB |
| Installed Folder Size | 1010MB | 86MB |
| Memory Usage | 163,992KB | 41,152KB |
| Workstation | ||
| Installation File Size (from client packager) |
49MB | 13MB |
| Installed Folder Size | 197MB | 28MB |
| Memory Usage | 59,072KB | 27,564KB |
The server install of Trend Client-Server includes its web-based management
console. The server install of NOD32 includes the
ESET Remote Administrator Server and Console 2.0.56.
Conclusions
ESET NOD32 has a reputation for being lean and fast. Compared to Trend Client-Server 3.6, NOD32
definitely looks “lean” on disk space and memory footprint. However, Trend
allowed the UBCD4WIN build to proceed a little faster than NOD32.
My greatest concerns with Trend come from areas other than performance. One
was the experience back in February 2007 of Trend passing on a “possible worm”
to the client desktop, which would have allowed users to run the worm. I was amazed that there
was no way to configure Trend to not pass possible malware to end users. The
other experience is the one described above: deleting a file without
warning and without logging. I wonder if I have lost other files that way and
will never know.
Clearly there is no perfect anti-virus solution. Both NOD32 and Trend CS(M)
have their own configuration hassles and “gotchas.” I do
appreciate the reduced memory footprint of NOD32, and the fact that my SBS
server no longer sends me a daily alert that it is running out of allocated
memory. We'll see how well it performs in the long term.
I only tried Trend once. After spending all afternoon trying (using some remote desktop tool) the Trend support tech agreed that the product wouldn’t install on this machine. It was a clean install of XP Pro, but the Trend wouldn’t install. Sent it back, got a refund, but there’s an afternoon of my life I won’t get back (or paid for).
Currently, I am promoting NOD32. I am concerned that, for Exchange servers (and therefore SBS servers) you can’t do on-demand scans unless you are willing to let it scan everything. That’s right, you can’t define exclusions for on-demand scans – only for real-time scanning. I am talking about Version 2.7 here, which is the only version that offers Exchange protection so far.
So, what would you do? Trust that the real-time scanning is sufficient for your server, or go ahead and scan the entire thing, including the forbidden Exchange folders (and others)?
I’ve not had a problem with NOD32 2.7 on-demand scans causing problems. I did set up exclusions on extensions related to dBASE and SQL database files. You could also exclude Exchange database extensions.
I figure that on-demand scanning and real-time scanning offer differing issues when it comes to interfering with certain critical processes, and I may be making something out of nothing. And, by selecting to scan only certain extensions, and making sure the extensions for the Exchange data files aren’t in the list, you can help be sure not to screw up your Exchange server.
However, this logic has some flaws — from Microsoft’s 822158:
“Do not scan the following files and folders. These files are not at risk of infection. If you scan these files, serious performance problems may occur because of file locking. Where a specific set of files is identified by name, exclude only those files instead of the whole folder. Sometimes, the whole folder must be excluded. Do not exclude any one of these based on the file name extension. For example, do not exclude all files that have a .dit extension. Microsoft has no control over other files that may use the same extensions as the following files.”
I talked to a support rep from Symantec last week, and they demand that the entire folder for their BackuExec product be excluded from virus scanning. There are many filetypes in there that one wouldn’t otherwise exclude, like .exe files. However, scheduling a scan when backups aren’t running would probably alleviate that concern. This is not so easy with files relating to IIS or Active Directory.
Your extensive list of recommended exclusions (posted elsewhere here and at the Wilders site) shows that there are potential issues with scanning everything on an SBS server, and, since being selective is possible ONLY by file extension, one must be pretty careful of either what is scanned or when scheduled scans are run.
In general, I like the NOD32 products. I found it took a few installations to get a feel for its setup, but have confidence in it now. I understand that the on-demand exclusions are possible with version 3, but am not sure when Version 3 for Exchange will be available or when it will be tested long enough to trust it on an SBS server. It makes no sense to me that ESET would ever have released a version that didn’t allow for on-demand exclusions, and also find it surprising that I have found little or no discussion around the topic.
We find v2.7 SO much easier to install on servers due to the low footprint and lean memory useage. It’s a great, tight system. v3 is OK but not quite as fast .. I’m sticking with 2.7 for the mo!
At least with Version 3x, you can configure file and folder exclusions. This can’t be done with 2.7 (at least not for on-deman/scheduled scans), and that is a serious feature to be lacking. Also, for those wishing to provide Exchange server protection, V 2.7 is the only option – that’s not offered with V 3x yet. Frankly, I’d take a performance hit in exchange for the ability to exlcude ket folders from scheduled scans.
I have been using V 2.7 for MS Exchange on SBS servers and V 3 for other servers and workstations. Other than my pet peeve (the aforementioned inability to exclude fodlers from scheduled scans) I am happy with the product. However, that inability is astounding to me – I can’t believe they even released such a version.