Viruses and worms—once partial to Windows systems—are turning on Linux. Linux has become a larger target as the platform becomes more prominent in the server room. However, even when a virus is not geared towards the Linux OS, there is the possibility that viruses stored on a shared partition on Linux will go undetected.

While the costs associated with virus infection can be difficult to determine, spending on prevention clearly saves significant resources. As a result, we’re going to take a look at a Linux solution: Vexira Antivirus from Central Command. Vexira offers three versions of its antivirus software for Linux:

  • ·        Vexira Antivirus for Linux Server
  • ·        Vexira Antivirus for Linux Workstation
  • ·        Vexira Antivirus for Mail servers – Linux edition

The first article in this series will look at the version for Linux servers. I will cover the version for Linux mail servers in a subsequent article.

Obtaining and installing Vexira Antivirus
Unlike much Linux software, Vexira Antivirus for Linux Server is a commercial product. Fortunately, there are downloadable demos that can be explored prior to purchase. While operating in demo mode, Vexira will only report infected files it finds. No corrective action will be taken, and software updates will not be available for download. 

To install Vexira, download the appropriate package, and if you have purchased the software and obtained a key, then place the key into the installation directory after unpacking. Extract the files, then su to root and run the install script (as shown below):
tar xpfz valxsrv.tgz
cd vexira-server-2.1.6/

The program files will be placed in /usr/lib/Vexira and configuration files are placed in /etc. Installation of VaGuard, the on-access portion of Vexira, requires the compilation of a Dazuko kernel module. Dazuko is GNU-licensed software that intercepts file access calls and passes them to the virus scanning daemons before allowing the calls to proceed. There are two versions of Dazuko, one each for SMP and non-SMP kernels. Change into the source directory, unpack the Dazuko distribution, cd to the new Dazuko directory, and make the module (as shown below):
cd vexira-server-2.1.6/src
tar xpfz dazuko-1.1.2-pre1.tar.gz
cd dazuko-1.1.2-pre1
make dazuko [or make dazuko-smp for multi-processor kernels]

This will create the file dazuko.o. To actually install this newly created module, rerun the install script and pass it the file name and path as an argument, like this:
./install vexira-server-2.1.6/src/dazuko-1.1.2-pre1/dazuko.o

See the Dazuko Web site for more installation information.

Once the package has been installed, programs will be accessible via /usr/lib/Vexira/vexira and /usr/lib/Vexira/vaguard.

Configuring Vexira
Upon installation of both the main Vexira package and the Dazuko module, you will be prompted to enter configuration settings. If you have an idea of what you’re looking for, the information can be entered at that time. You can also go back and run the configuration scripts at /usr/lib/Vexira/configvexira and /usr/lib/Vexira/configvaguard.

Alternatively, settings can be entered manually through the program config files /etc/vexira.conf and /etc/vaguard.conf. Settings for vexira.conf include the target e-mail address for virus notifications, how often the autoupdater should run, and log settings. By default, Vexira will log using the syslog daemon and will follow its defaults. But you can also choose to log to a custom file simply by providing the full path and file name in the config file. The facility and priority can also be set for the program’s interaction with syslog. The defaults are to log as user and with a priority of notice.

Configuring VaGuard
The configuration for VaGuard is a little more complex as this is what controls the on-access kernel module. These settings can have performance implications and it’s a good idea to go over them carefully before making the config changes. 

First, you can set the number of daemons that will run concurrently with NumDaemons. Since VaGuard is checking files as they are accessed, it can be important to have multiple daemons running in the background. Settings for this option run from 3 to 20, and will be dependent on the type of server involved. The default is 3, but servers running protocols such as HTTP or NFS with a high number of file accesses would want more daemons to help with the additional system calls. You may want to keep an eye on the daemons and how much of the overall system resources they use. A setting of 0 completely disables VaGuard.

The next setting is the AccessMask.  This defines when VaGuard will scan the file: on open, on close, or both. The default is both. While this results in extra overhead, coverage is more complete. Every time a file is created, viewed, or copied it is checked for infection. 

A further setting, RepairInfected, allows you to configure whether or not the program will automatically attempt to repair the virus. If the virus can be successfully removed from the afflicted file, access is restored. If not, access to the file is blocked. Additionally, when a virus is found but cannot be removed, you can tell VaGuard what it should do. Available options are log only, rename, and move. How you want to handle files when they are found to be infected is up to you. False positives are always a possibility, and as a result, manual inspection of suspect files is usually recommended.

VaGuard can also be configured to scan only certain paths. It may be better performance-wise to scan more dynamic directories, such as /home, rather than other paths that could be scanned during periods of lighter load.  Subdirectories of this IncludePath can be kept out of the scan process with the ExcludePath option.

Compressed files can be included for scanning with the ArchiveScan setting. The default is no, and the reason mainly is I/O performance. If VaGuard has to decompress large files to scan their contents, this takes away from the resources available to the system in general. The default is to not scan compressed files and scanning these files may only be recommended on a system that is a known threat or one where a performance hit would be minimal.

Running Vexira
Vexira has a number of options available at runtime. While VaGuard (if running) waits and listens, the command line scanner can be run manually or through a cron entry. Vexira for Linux was designed specifically for a UNIX environment, not ported from its Windows version, so its target audience is mainly those familiar with the command line. There is no GUI included with the package (but there is a GUI that is part of the Lindows distribution).

Here is a short list of options to give you a look at how the command line scanner operates.

A typical installation may choose to do a complete scan only at night or during other periods of downtime. This is perhaps best done with a cron entry similar to this.

This would kick off a scan of all files under the root directory (“/”), including all subdirectories, at 2:15 AM. With the “-e” and “-ren” options, Vexira will try to clean infected files and will rename them if unable to do so. Renaming should prevent further file use until manual intervention is possible.

Linux as a target
While Linux systems have not yet been hit by a monumental virus or worm incident comparable to some of the nasty ones that have hit Windows, an increasing number of viruses are showing up on Linux. As Linux becomes more widespread, this growth increases the likelihood of Linux becoming a target. Through the use of software such as Vexira Antivirus for Linux Server, you can help defend against not only viruses that would directly affect your server, but also guard against malicious files that may just be passing through before infecting other operating systems.