NOD32 for Windows NT/2000/XP/2003/X64 with centralized management

2005-11-01

Matt Ham

Virus Bulletin, UK
Editor: Helen Martin

Abstract

Matt Ham Reviews the latest offering from Eset - NOD32 for Windows NT/2000/XP/2003/X64 with centralized management


Introduction

Before I begin, I must thank the folks at ESET who offered their product for review at very short notice after the software I had originally planned to review was withdrawn. I must also point out that, given such a tight schedule to perform the review, there were some areas where I could not perform quite as many tests as I otherwise would have done.

Secondly, a few words about the product title. The 'x64' part of the product description is inclusive rather than exclusive. That is to say, the executable supplied should run on both 32-bit and 64-bit versions of the operating systems noted, detecting the appropriate software to install automatically. Due to time constraints, the tests were performed on both 32-bit and 64-bit hardware, but the test operating systems were exclusively 32-bit. (As next month's comparative review will cover the 64-bit version of Windows 2003 Server, there will not be long to wait for the product to be tested on that platform.) One thing that occurs to me is that the product's name may be a problem in future, since calling a 64-bit program 'NOD32' seems something of an anachronism, while renaming to 'NOD64' might cause loss of brand awareness. No doubt ESET's marketing department is pondering this very point as I write.

ESET is a Slovakian company which has enjoyed a long and successful presence in Virus Bulletin's comparative reviews over the years. While the effectiveness of the product has remained more or less constant, the company and product feature set have experienced several changes.

The company now has a much more global presence even than two years ago, with aggressive marketing having worked well from the point of view of sales and general product awareness. While two years ago NOD32 was little known outside the anti-virus industry, it now features strongly when users are asked to name well-known products.

As for the product's feature set, this has improved markedly from the point of view of a larger organisation. Administration tools are now fully supported, having been non-existent initially. The administrative features were thus investigated in this review as a point of major interest. With comparative reviews in the months before and after this review both featuring NOD32, the detection capabilities of the software were not investigated in this test.

The platforms used for testing were Windows 2000 and 2003 Server on Intel and Windows XP Professional on AMD64 and Intel. Unless otherwise noted, comments refer to the Windows 2000 Server platform with Windows XP Professional workstations.

Web presence and documentation

ESET's primary web presence can be found at http://www.eset.com/, with various foreign language versions also available. The site contains a collection of press releases, product information and virus data which can be said to be typical of the genre.

While much of the virus data is available in a particularly uninspiring list format, the information on virus occurrences as reported by NOD32 users is very interesting. Data here is available for particular problem items, with detailed breakdowns of occurrence available over various timescales. 'Problem items' is a term chosen with care, since phishing emails figure largely in the statistics alongside the more easily categorised worms.

Due to the short timeframe available for the review, the documentation was supplied only in PDF format. In the process of testing the documentation proved thorough, useful and laid out in a logical fashion. The only problems lay in the extensive use of graphics within the file, for decorative rather than illustrative reasons, which made scrolling through the manual somewhat jerky.

However, only light use of the documentation was required, since the help functions within the software and the readme.txt files located in the Start menu gave ample information on how to operate the software. Particularly useful features were the 'How do I add servers?' and 'How do I add clients?' links in the main Remote Administrator Console. These served far better than most quick start guides in providing immediately useful detailed information.

Installation and updates

Scanner installation was performed on all platforms from a single 9 MB file. Initially this decompresses to a temporary location before offering the obligatory three options for installation. In this case the options are Typical, Advanced and Expert, with Expert being chosen for the purposes of investigation.

Once this selection has been made the licence agreement appears. Since virus detection statistics can be sent to ESET when certain installation options are chosen, this agreement includes a privacy clause. The clause contains the potentially paranoia-inducing statement that this may be information concerning 'you and/or the user of the computer and/or platform' and that ESET may then 'share this information with trusted third parties'. On a different note, this licence agreement is one of the few which would allow the product to be used in nuclear power stations, life support or air traffic control systems.

nod1.jpg

Next, the choice returns to the mundane with the selection of the location for installation. This is followed with the rather more important setting of update parameters. In order to use the automatic updating feature a username and password are required for the ESET update servers. These can be specified at this point. Five server locations are available, though no information is given as to the physical location of these. The facility for automatic selection of server probably makes this information unnecessary, though for particularly paranoid users, it would be helpful to be able to set one download address in stone.

Next in the settings, silent mode may be engaged. This feature is likely to be of little use in a standalone machine, and is clearly designed for administered machines. In silent mode, only those actions requiring direct user intervention are announced on the machine where the software is installed. However, all information is logged for the administrator. Similarly of greater use where an administrator controls the machine, there is the option to password-protect existing settings.

Look and feel options are the next to be addressed in the Expert setup process, with the presence or absence of an ESET splash screen being configurable. More control is offered over the whole GUI, with the option to use the nonstandard ESET style of interface or a GUI that is more instantly recognisable as being Windows-based. The ESET interface is certainly novel in some of its behaviour, so this option may be useful where users who are particularly easily confused are concerned. The change from one to the other can be performed at any time, though some strange window resizing issues were noted after having done this without an interim reboot.

As mentioned, silent mode supports the gathering of information and the next settings deal with whether additional information is passed by email, instant messenger, both or neither.

The following section concerns ThreatSense.Net, which is ESET's statistics and automated sample submission system. It is this which requires the privacy statement within the EULA. Details given at this point are somewhat more reassuring though. .DOC or .XLS files are never submitted as part of the automated process, which removes a good deal of potentially sensitive data from the equation. The generic data sent for statistical purposes is also far less personalised and less likely to be used for any marketing purposes than the EULA might potentially allow. It is also possible to turn off sample and/or statistical submissions, or to fine tune automated sample submissions by extension. In combination these settings should cover the security requirements of a wide range of potential users.

The next step in this exhaustive setup procedure is to select whether the on-access scanner, AMON, is started automatically when the machine is rebooted. At this point there is a warning that terrible things may occur if another on-access scanner is activated already.

In reality, terrible things did not occur when NOD32 was installed over a limited selection of other on-access scanners. On the other hand, the installation process on Windows XP SP2, did not make use of the Security Center to detect that another product was already present. This would also seem to be a very late stage of the installation decision-making process at which to discover that the machine is not ready for installation due to the presence of other software.

Options continue with those offering access to the on-demand scanner. Context menu activation is a default, though desktop shortcut placement is not, but may be selected. Further selection of options allows the specific scanning of Microsoft Office file types using a separate on-access module, in this case named DMON.

Another similar function is available for POP3 and HTTP traffic, this being called IMON. IMON apparently has the potential for conflict with several other products, which makes it a bad choice for server installations, though activated by default on workstations. Admittedly POP3 and HTTP should not be used much, if at all, on most servers and conflicts with, for example, Microsoft SQL server can be considered a more important potential source of problems.

Outlook also has its own scanning module, this one named EMON. However, this functionality is not available for any other common mail clients.

With all these selections made, the process of installation takes only a few seconds to finish. However, the full installation process does not complete until a reboot has been performed - a minor issue on most workstations but a source of grievance on servers.

nod2.jpg

The administrative server and console were also installed for the purposes of the review. This process was trivial, even when selecting the Expert installation method.

Updates were performed using two different methods, with a third also available. The first method is that used in most Virus Bulletin tests in the past - that of a manual update on a local machine. This has been replaced in general usage by the Internet update system, the setup of which was described above. This performed with no hiccups.

The default update timer is one hour, though updates may be set to occur at boot in addition to those scheduled. The initial, largest, update took no more than two minutes on a one-Mbit ADSL line, with updates after this being almost negligible in duration. Clearly, some larger updates will be required on occasion, but network traffic did not seem excessive during normal use. The third method of updates is that achieved through use of the administrative tools. These will be discussed later.

Features

When installed there are three main components to the whole package, which can be considered as separate, though interlinked, entities. These are the main scanning interface of the NOD32 Control Center, the Remote Administration Console and NOD32 Configuration Editor.

The Control Center offers the usual functionality of any on-demand and on-access scanning interface and thus warrants only a few comments.

The most noticeable feature visually is the split window interface. Rather than starting as an application with a large blank right-hand pane, ESET has opted to open these panes as and when needed. This works well after the initial culture-shock. However, this aesthetic is not fully complete, with tabbed dialogs opening up for some configuration options and the main scanning interface. This is an area which could perhaps be more completely integrated.

The Configuration Editor is installed as part of the Administration Console package, although it is a standalone application in its own right. The main use of this will likely be the production of custom NOD32 configurations to be installed onto other machines.

The configuration files, in their native state, consist of XML and as such can be hand-edited by anyone with the barest idea of how XML is formatted. The use of this interface, however, speeds up the process markedly. Allowing trees to be collapsed and temporarily ignored, for example, takes away the pain of regarding a ten-yard-long file while editing otherwise separated portions in the body.

The Remote Administration Console is the part of NOD32 with which I am the least familiar. As is to be expected in such applications there are two main parts of the administration functionality: the Server and Console. The Server portion must be installed on a machine which has a source of NOD32 to offer - in most cases this will be a machine connected to an update source. Whether this is connected directly to the ESET servers or from updates supplied by a further server is a decision for the individual administrator. Once the Server software is installed it acts as a service and is not visible in day-to-day usage.

Interactions with the Server are made through the Console, which may be installed on any machine which has access to the Server, including the Server itself.

The Console links to the Server, controlling the various possible administration activities. The link between Console and Server proved problematic initially, but the frequent tweaks I was performing turned out to be the problem rather than the solution they were intended to be. Upon leaving the Console and Server in a stable state for several minutes they connected with no further problems.

nod3.jpg

As an administration tool, of course, there must be another factor in addition to the Console and Server, this being provided by the clients. Most Windows-based platforms are supported, though those that do not hail from the NT family - primarily Windows ME and Windows 98 - do lose some administrative functionality.

Existing clients are one matter, but also of interest is the installation from the Server to machines which are not already running NOD32. This can be performed in several ways. The most likely is the push method. Using this method a distribution package is produced from an existing installation source of the product. There is capacity for producing a variety of different packages as desired, so as to cater for different users. The clients may be arranged in groups with different packages associated by group.

With the distribution package ready, all that remains is for the package to be pushed to the potential client machines. Many machines may be selected for installation simultaneously, and the network can be scanned for machines which are not already clients. The combination of these two functions allows large-scale distributions to be performed with relative ease. One factor does seem to be a potential irritation, however: machines which have had the package installed require a reboot to initiate scanning, and there did not seem to be an easy way to trigger this automatically. Admittedly, automatic reboots have a habit of enraging end users, but it would be nice to be able to force a reboot upon recalcitrants.

However, this method is not the only one supported. In addition, a smaller application may be sent via email, which when executed will pull the remaining portion of the software across the network and perform the installation. This is the recommended method on Windows 95, 98 and ME machines. As a user, however, this would leave me with serious doubts, since I have been trained to think of all unexpected email-borne applications as being potentially harmful. A better use of this method - which is indeed suggested in the help files - would be as part of a logon script.

With the installation of machines thus catered for, the updating of machines is a similar, yet less involved task. Since machines to be updated can be assumed to have NOD32 installed on them already, it is simply a matter of setting the clients to poll the Server for updates, which can be done in their initial configuration. Servers too can be set to receive their updates from local or net-based locations in their initial rollout or subsequently.

Of course the installation and updates process is only half the requirement within the administration component. The other factor is that of centralising the results and alerts from their various clients.

The results are available in two forms. The less useful is the raw data, available under the clients, log, task and remote install tabs of the Console. As they stand these are likely to become overwhelming quickly without some sort of filtering method. Filters are thus provided which can exclude or include servers, clients and varying subgroups of these. Within each category there are more specific filters - for example the 'Show only problems' filter on the clients tab is simple, yet undoubtedly of great use.

Even this degree of filtering has its limits in producing overviews and summaries however, and for this omission the reports tab is supplied. This has a comprehensive listing of different reports available, from those useful for statistical analyses of various virus frequencies to those useful in determining problematic clients. There are sufficient tweakable settings here to produce a good range of statistics in many different formats.

Conclusion

The addition of administration features to an already sturdy scanner is always a good thing for the company involved, as long as the administration can be performed usefully. From the (admittedly small-scale) tests done here the basic functionality required in such a product would all seem to be present. Such important matters as the effects of network congestion when installing to many clients were not tested, and thus cannot be commented upon, however.

With its more aggressive marketing methods, and some fairly high-profile head-hunting of new staff, combined with this relatively new administrative clout, ESET is clearly hoping for increased market share, especially in the United States. While the future currently looks promising for ESET, many other companies with similar ambitions have crossed from Eastern Europe with varying degrees of success. Where NOD32 will be in the market-share pecking order in two or three years time still remains something of an unknown quantity.

Technical Details

Test environment

Identical 1.6 GHz Intel Pentium machines with 512 MB RAM, 20 GB dual hard disks, DVD/CD-ROM and 3.5-inch floppy drive running Windows XP Professional SP2, Windows 2003 Server and Windows 2000 Server. AMD64 3800+ machine with 1 GB RAM, 80 GB hard disk, DVD/CD-ROM and 1 MBit ADSL Internet connection running Windows XP Professional SP2.

Developer

Eset Software, 1172 Orange Ave, Coronado, California, 92118, USA. Tel: +1 619 437 7037. Fax +1 619 437 7045. Email

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest articles:

VB99 paper: Giving the EICAR test file some teeth

There are situations that warrant the use of live viruses. There are also situations where the use of live viruses is unwarranted. Specifically, live viruses should not be used when safer and equally effective methods can be used to obtain the…

Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return more than four years ago, Office macros have been one of the most common ways to spread malware. In this paper, Aditya K Sood and Rohit Bansal analyse a campaign in which VBA macros are used to execute PowerShell code, which in…

VB2017 paper: Android reverse engineering tools: not the usual suspects

In the Android security field, all reverse engineers will probably have used some of the most well-known analysis tools such as apktool, smali, baksmali, dex2jar, etc. These tools are indeed must‑haves for Android application analysis. However, there…

VB2017 paper: Exploring the virtual worlds of advergaming

As adverts in gaming (‘advergaming’) ecosystems continue to become more sophisticated, so the potential complications grow for parents, children and gamers, who just want to play without having to worry about where their data is going (and how it is…

Distinguishing between malicious app collusion and benign app collaboration: a machine-learning approach

Two or more mobile apps, viewed independently, may not appear to be malicious - but in combination, they could become harmful by exchanging information with one another and by performing malicious activities together. In this paper we look at how…


Bulletin Archive