In my previous anti-virus review for SEP11, I briefly touched on NOD32 and its underground fame among some IT enthusiasts on the web. Because NOD32 is an impressive personal scanner, I wanted to seriously consider ESET’s enterprise offering and possibly dethrone Symantec as my favorite enterprise AV solution. Through the use of numerous daily virus definition updates and a very aggressive heuristic scanning engine, NOD32 has managed to stay on top of the VB100 list by not missing any threats since 2002.
There are 3 installation components to the enterprise NOD offering: The NOD client, the ESET Remote Administrator Server (ERAS), and the admin console (ERAC). All 3 parts should be installed on the server to manage the environment, the console can be installed on an admin workstation for remote management. Component versions as tested are 4.x upgraded from 3. Licensing is per installed client enforced via a license file and ESET requires a username and password to pull virus definition updates from their servers. The client comes in both x86 and x64 flavors while the management components are x86 only. I had no trouble at all installing all components on Server 2008 R2.
When first launching the ERAC, it connects to the configured server on tcp/2223, by default, and asks for login credentials which can be optionally cached by the administrator.
At first glance the layout seems daunting.
The console can be customized in number of ways including column, color, and highlighting options for almost every piece of the layout. (Tools—>Console Options)
The next logical step is to configure virus definition updates and the other applicable global options. Under Tools—> Server Options, a number of things can be configured including passwords and access management for the ERAC, logging and DB maintenance, the update username/password and update interval, along with SMTP and optional upstream NOD server replication. As is the case with any enterprise technology, RTFM, but I really disliked the update setup requirements. The mandate of a username and password just to pull definitions is annoying and the “update mirror” setup used for definition storage is hardly intuitive. The mirror settings should come pre-defined in a base installation allowing further refinements if needed.
The performance statistics displayed on the General tab in Server Options is a nice touch albeit a bit out of place in a global configuration dialog.
Notification options seem robust and plentiful, at first glance. A number of pre-defined notification rules can be tweaked with HAS, HAS NOT, and IS types of filter parameters along with a number of wildcard fields that you can expose. Some of the default descriptions include wording that leaves much to be desired like “Primary clients with a non-cleaned infiltration during the last computer scan” instead of a much simpler “New threat detected.” Notifications also fall short in information richness. You can be notified that a “non-cleaned infiltration” was detected but you will have to log into the ERAC to find out exactly what that infiltration was. You cannot have the name of the detected threat included in the notification email.
We experienced a great deal of frustration surrounding alerting with this product. Server based alerting was slow and unpredictable at best leaving us to configure policies that enabled clients to send administrators SMTP alerts directly so we at least knew what was going on. Not good.
Policy management, again, seems very rich and robust, at first glance. NOD employs the traditional parent/child inheritance model making it easy to create and deploy child policies to specific machine categories such as department or function. Each policy can be edited/viewed individually or in a merged state to display the effect of parent policies.
Configuring policies themselves can be a daunting task with hundreds of stacked options available to you. While I would normally find this level of control of positive thing, it’s implementation here is very user UNfriendly. Although the search feature works fine here, trying to pinpoint and enable or disable a very specific behavior can be very challenging [and frustrating].
Another problematic behavior of this policy model is that it follows an append behavior by default. So any policy changes you make will simply be tacked on to the client’s existing policy, not changed or deleted. First level ESET support told us this was by design (bad) although level3 ESET support tells me there is a way to flag a policy item as delete so the client will remove it. Going back through the dialogs now I don’t see that option anywhere. If it exists it should have been made plainly clear in the Policy Manager console. Scanning profiles are used to control on-demand scans and configured via policies then deployed to clients. We had a hard time making these profiles “stick” after any policy change. We kept wondering why clients weren't running their weekly full scans, it was because the scanning profile dropped and the weekly's never kicked off!
The level of configurable policy detail is immense, but most notably lacking is the ability to modify a client’s Scheduler/Planner settings, namely startup scans. By default the NOD32 client will initiate a scan each time a user logs in (even workstation unlocks) and when the virus definitions are updated. The logic behind this is understandable which is to ensure maximum protection, but it comes at a hefty, and annoying, performance penalty. Add in the complete inability to centrally control and you have a very large annoyance. Tasks can be added to the Scheduler/Planner via Policy Manager but not deleted.
ThreatSense is the heuristic scanning engine that makes the product look good in virus tests and marketing materials but those of us in the trenches know good and well that this is a slippery slope. I always disable heuristic scanners because they are too difficult to control and often block perfectly legitimate applications from operating properly. ThreatSense is no exception. In our tests it seemed to haphazardly block legitimate operations even after allowing them to run a few times before, such as application deployment via our KBox. So much so that we started looking to NOD first when any application wasn’t functioning correctly. Settings for ThreatSense are controlled outside of the normal real-time AV rules. My advice, disable ThreatSense during the installation just like you would in any other AV product, the headache is not worth it!
Scheduled scans are also configured in policies (buried under ESET Kernel\Scheduler/Planner) but we found the execution to be sometimes unpredictable. Instead of firing at the specified times, these scans seemed to kick off when they wanted to even though they were expressly set.
Remote client installation from the server works well enough but clients reporting into the ERAC is somewhat unpredictable. The display is only updated periodically so it is hard to tell if a client is really out of date or disconnected just from looking at the console. Requests to update individual clients from the ERAC also seem to go by unanswered.
Other pain points include the lack of fine-tuned resource throttling for scans actively running on machines with other workloads. The NOD client will simply take as much of the CPU as it wants to even though the scanning profile is set to run background scans with low priority. All you can do is to stop the scan, which in and of itself is sometimes difficult to do. ESET touts it’s low resource utilization which may be true for real-time AV protection but I beg to differ on full scanning operations.
There is a lot to like with the NOD client itself, however. It is clean, un-intimidating, and tells you exactly what you need to know. It will even turn red in the system tray to warn you when new Windows updates are detected, overkill yes but it wants you to be secure.
The full advanced configuration dialog is accessible via the client in a much more condensed, clean and user-friendly form. It is very clear that ESET has spent a great deal of time and effort developing their client.
Working with this product for awhile now it is clear that ESET built a very good AV client then bolted an attempted enterprise management piece on top of it (ESET support confirmed this). In version 4 of the enterprise platform I expected much more, especially after upgrading from version 3. While clunky and very unrefined in spots, if you have the time to mess with it, this solution should work for very small environments, even though you will spend much more time here configuring and tweaking.
There are a few key points that make the enterprise solution a complete deal-breaker for me in its current state. Notification options/behavior, predictable manageability, and policy behavior are bad enough, in my opinion, that I cannot recommend the product. In my conversation with ESET’s level 3 support, he acknowledged many of my concerns and remarked that the development group that works on the enterprise piece is not exactly steeped in what a real enterprise requires, being a very small dev shop themselves. Would I run NOD32 at home? Sure, but that is where my recommendation ends. For your SMB+ sized enterprise you would be much better served implementing a tried and true solution built for the enterprise market.
0 Comments