14.3 Use a Good Antivirus Scanner

Team-Fly    

 
Malicious Mobile Code: Virus Protection for Windows
By Roger A. Grimes
Slots : 1
Table of Contents
Chapter 14.  Defense

14.3 Use a Good Antivirus Scanner

The basic job of an antivirus scanner is to sift through target files comparing found code against a database of known malicious code bytes. Early scanners were simple programs made to look for a particular type of malicious code, say, the Brain virus. The scanner would notify the user if it was found, and in some cases, a second program had to be run to remove Brain. To detect another type of virus, another program had to be downloaded and executed.

McAfee VirusScan figs/u2122.gif was the first popular antivirus scanner to search for multiple rogue programs at once. To do this, a separate signature database was used. That way, only the database had to be updated when more rogue programs appeared. Today, most scanners have a separate database where scan strings and removal instructions are located (see Figure 14-2). The scanning engine does not need to be updated unless an entirely new type of code is found that the engine does not handle or detect. For example, NT Streams viruses caused all antivirus scanning engines to be updated, because none of them previously looked for NT secondary file streams. In another example, prior to the ability of email-embedded script virus, like KAK, antivirus software need only scan the file attachments of emails. Now, they have to scan the bodies and signatures of emails.

Figure 14-2. Typical antivirus scanner model
figs/mmc_1402.gif

Some antivirus vendors get around having to frequently update the engine by including new engine components in the database upgrades. The engine program is more of a shell that pulls its executable code from the database. This results in larger database files, of course.

We've already talked about how scanners had to evolve to handle encrypted and polymorphic viruses. These types of rogue programs either forced scanners to decrypt the virus or forced antivirus scanners to execute code into an emulated environment. Scanners now scan boot sectors, program files, documents, data files, email, PDA viruses, and incoming browser code. Scanners have to be able to open up files packaged in different archival containers, like PKZIP files. When a scanner opens a packaged file, it is known as recursive scanning . Some scanners do not perform recursive scanning, and instead scan the file as it is unpackaged.

Many of today's modern scanners do not simply do a straight signature scan on every file. They examine the file first, determine the mostly likely areas for malicious code to be present, rule out as much malicious code as they can, and then only scan for the types that are left. As each file is examined, statistical analysis is performed to determine the likelihood that a particular type of file has a particular type of code. Host files with a low likelihood of containing a particular type of file are not scanned for that malicious code type.

For example, when scanning an MS Word document, scanners will immediately discard any signatures of viruses that cannot correctly infect a Word document. Then the scanner might look for the presence of an auto macro, and if it isn't found, rule out all viruses that use auto macros. If a class file is found, then the scanner might look for a particular class object, and begin comparing signature scans there. So instead of comparing each file it finds against 50,000 plus signature strings, the MS Word document might be compared against a few dozen . A good antivirus scanner might be able to narrow down the needed signature scan strings to just a few.

14.3.1 Checksums Versus Scan Strings

Some scanners use checksums instead of signature strings to detect malicious mobile code. In either case, a portion of the host file is read and compared against a previously stored result. If the scanner uses checksums, then the examined code is run through the scanner's checksum process and the answer is compared against the stored checksum result. If the two match, then a rogue program is present. Checksum scanning can result in smaller signature databases because a checksum only occupies a byte or two of space. A good signature string can be 8 to 32 bytes long. Whether a scanner uses a scan string or checksum may even depend on the type of virus and previously noted attributes. Either way, the scanner has to be swift and precise.

14.3.2 Traits of a Good Antivirus Scanner

There are over 50 different antivirus scanners. What makes a scanner a good scanner?

14.3.2.1 Fast and accurate

First, and foremost, a good antivirus scanner must be quick and reliable. No one is going to use a slow scanner very often. The best scanning programs allow administrators and users to configure how much processing time is used. The program can be throttled to maximize the cost/benefit relationship of the scanning program. Users complaining of desktop slowness and with low risk can dedicate less CPU time to the antivirus program.

And while no scanner can detect 100 percent of all malicious programs, a good scanner should be able to detect 100 percent of the common types (in unpackaged form) and over 90 percent of all malicious code types. Different sources and reviews will rank antivirus software in terms of reliability. The good ones always detect somewhere around 98 percent of all known malicious mobile code types. Make sure your scanner looks into the Recycle Bin and other related areas, like Windows ME's C:\_Restore folder. Since these are not normal areas for execution, some scanners ignore them. A few malicious mobile code programs have used these folders to store themselves to escape detection.

The ICSA (http://www.icsalabs.net) and Virus Bulletin (http://www.virusbtn.com) are well-respected antivirus software review sites.

And just because a scanner might detect 100 percent of all malicious code types doesn't make it a good scanner. A scanner must not impulsively call clean files infected, otherwise known as a false-positive . This was the original problem with polymorphic viruses. Some scanners are also famous for detecting viruses in previously infected files that could only be partially cleaned, and is known as a ghost-positive . While false-positives are always bad, ghost-positives are not. Many antivirus customers want to know if a file was corrupted by a virus and if the scanner is unable to clean and restore the file to a completely clean state. Any good antivirus scanner should have a tiny ratio of false-positives. Any file turning up as a ghost-positive should be replaced .

I also believe that it is important for a scanning program to identify the specific rogue program that it finds. Some scanning programs rely on generic scan strings to increase scanning speed. In those cases, when a malicious program is found, it is reported with a generic name . This makes it harder to learn about the rogue program and what it does if the scanner does not completely remove it and its damage. Many scanner programs will remove the rogue program, but not undo other types of damage, like registry edits, renamed files, etc. If the scanner identifies the malicious mobile code effectively, you can research about the rogue code on the Internet and make sure everything is cleaned and repaired.

14.3.2.2 Stability

A good product must be stable in your environment. A few years ago, file server-based scanners were notorious for causing file-server lockups. Although antivirus products are getting better, in a large environment you can count on antivirus software causing problems. There is going to be a cost/benefit trade off caused by the scanner. Learn what those risks are and if they are acceptable. A network administrator should do wide-scale testing of an antivirus product before deploying to the entire network.

14.3.2.3 Transparency

Antivirus software is a necessary evil. No one really wants to buy and run it. As such, it should do its job with a minimum of end user intervention. Preferably, after installation and configuration, the only sign that it is installed and working is a small tray icon.

14.3.2.4 Runs on your platforms

A good antivirus product should protect most of your personal computers and servers. This means if you run a mixed environment of Windows NT, Macintosh, Lotus Domino figs/u2122.gif , and Novell Groupwise figs/u2122.gif email servers, your antivirus software should be able to run natively on those platforms. And even if a product says it runs on a particular platform, investigate its methods . For example, a good Windows NT scanner should install itself as a service, to be loaded earlier and be able to interact with the kernel. Lotus Domino users can insert infected documents into Notes Database files ( .NSF ), so if Domino is used in your environment, make sure to get a scanner that understands .NSF files. The best antivirus vendors usually support DOS, Windows 3.x, Windows 95/98, Windows ME, Windows NT, Windows 2000, OS/2, Linux, Macintosh, Microsoft Exchange, Netware, Lotus Notes/Domino, MS-Proxy, PDA's, and firewalls. A list of common antivirus vendors and the platforms they support can be found in the Appendix.

14.3.2.5 Customizable

You should be able to tell the scanner what and when to scan. It should scan important areas, like the boot area, memory, and Windows system files upon every bootup . You should have the ability to scan some, or all files, and the ability to add new file extension types. Conversely, you absolutely need the ability to tell the scanner what not to scan, including specific files and subdirectories. Some files and programs can be catastrophically damaged if a virus scanner manipulates it. Large databases and email server directories are particularly susceptible to this type of damage. Also, the program should allow the network administrator, or end user, to turn off temporarily as needed. Many software vendors will recommend turning off antivirus protection during installation of new software, even if it goes against the grain of why the scanner is installed in the first place. Of course, the ability to disable protection should be password protected in an enterprise environment.

14.3.2.6 Scanner should protect itself

All good scanners take extra precautions to protect themselves from infection and third-party manipulation. Most do a checksum routine just after starting and will refuse to continue if modifications are found. They should make sure no malicious code is in memory that would cause the antivirus scanner to infect more programs.

14.3.2.7 Good cleaning rate

It is not enough to reliably detect malicious code. An antivirus product should be able to successfully remove malicious programs and repair damage if it is possible. Some of the damage done by viruses, Trojans, and worms cannot be repaired. However, if the information is not overwritten, destroyed , or deleted, the antivirus program should make a good effort at repair.

When a dirty file is found, I like being prompted to skip, delete, repair, or quarantine it. Depending on the file type and the circumstances, I may choose one option verses the other. In enterprise versions, network administrators should be able to specify the default action taken on behalf of the user. I also like programs that back up infected files before repairing. That way if the repair is worse than the infection, the repair can be reversed . I've seen antivirus software wipe out entire documents and spreadsheets when trying to remove a simple macro virus.

14.3.2.8 Scanning archived files

A good antivirus product should be able to open common file archival types, like PKZIP and PKARC , and scan files inside. Because malicious mobile code writers are relying more than ever on packers to bypass scanners, a strong recursive scanner should keep up with the most common types of packers, or allow the user to add additional archival types, as necessary. Most scanners will open PKZIP files, but other common archival types are: PKARC , LHARC , PKLITE , ICE , LZEXE , and TAR . I personally find it acceptable if a scanner skips archived files as long as it always scans files when they are unarchived.

14.3.2.9 Heuristics

One of the biggest flaws in standard antivirus scanning is that a rogue program's signature string must be included in the scanner's database in order to be recognized. Newly released or slightly repackaged files are free to bypass scanners. To get around this problem, many scanners offer a heuristic scanning module that interrogates all incoming code for malicious-like behavior. Heuristic scanners look for coding tricks, structure, run-time attributes, and behaviors associated with malicious code. Unfortunately, state of the art heuristics only detect 70 to 80 percent of new viruses and they have a tendency to produce more false-positives than regular scanning. The best scanners today use a combination of heuristics and signature scanning to do their job.

14.3.2.10 Rescue diskette

As we covered in Chapter 2, the most accurate antivirus scanning takes place on a clean- booted machine, where programs, good or bad, cannot interfere with the scanning process. This was relatively easy to do with DOS and early versions of Windows. This process becomes more complicated in the days of NTFS volumes and disabled boot drives . These days, most people do not cold boot to a clean, write-protected floppy disk to run a scan. But you still should if you suspect malicious mobile code and a regular scan did not turn anything up. Today, many antivirus programs make rescue diskettes . They allow you to do a scan with a clean, booted floppy, and contain backups of important files that the antivirus program can use to repair with. Rescue diskettes need to be made during the scanners initial install, before the machine is infected.

14.3.2.11 Automated updates

Engine and signature database updates should be easy to get or automated. Most scanners are updated, at most, every two weeks. With 500 new bugs appearing monthly, updates have to be frequent. It should be easy to pull-down antivirus updates, or preferably, they should be automatically pushed down when released. I'm a big proponent of computers getting pushed new minor updates, but I'm a little more reserved about automatically pushing big upgrades. There have been instances where antivirus companies pushed buggy engines or databases that caused lock ups or damage. Significant updates should be tested before wide-scale deployment. Also, updates should not require a reboot to activate.

Another point to negotiate when buying a corporate antivirus license is whether employees can take product home to install on their personal computers. Since a large amount of malicious code is brought in from well-meaning home users, installing antivirus software there, too, will result in less problems at work. Although supporting home user installs can become cumbersome.

14.3.2.12 Good technical support

A good antivirus program cannot be great without a great company to stand behind it. I look for industry longevity, a great technical support web site, multiple ways to submit suspected files, good response times, and a good virus encyclopedia (where I can do research). No matter how you contact the antivirus vendor, they should respond in a reasonable amount of time. I recommend testing the vendor prior to purchasing. If you are a large enterprise, negotiate 24-7 coverage with guaranteed response times.

14.3.2.13 Proactive research

I want the antivirus company I'm dealing with to proactively deal with new threats and be actively involved with the antivirus industry. For example, most of the good antivirus companies have already developed PDA scanners even though PDA Trojans and viruses really aren't much of a threat, yet. It is comforting to know that when the threat is a reality, your vendor is prepared. Second- tier antivirus vendors will wait until a threat has exploded before they develop a solution.

14.3.2.14 Enterprise capabilities

When running an antivirus product in a corporate environment special features are needed that standalone products do not have. First, an enterprise antivirus product should have a centralized management console where all antivirus software, whether on the desktop, server, or gateway, can be managed. The console should be easy to understand and be able to be remotely viewed and configured. An enterprise product should allow all copies of their product, no matter where distributed, to be remotely configured. A network administrator should not have to go to the user's desktop to reconfigure the user's scanner. Many products today come with HTML-based consoles, so administration can be done over slow network links and the Internet. Any product configured and distributed by a network administrator should not be able to be disabled or uninstalled by the end user. Usually the software will allow administrators to prevent users from disabling, but preventing uninstalls is a determined by operating system security.

An enterprise product should allow network administrators to obtain and redistribute updates in multiple ways. Although most products are easily updateable over the Web, the Web may be down during a bad malicious code hit. The vendor should have alternate connection methods like FTP, CD-ROM, diskettes, and dial-up bulletin boards .

14.3.2.15 Logging

A good product should keep activity logs and allow centralized reports to be generated. Logging can be on the local desktop, to a centralized management console, or even to the NT application event log. Some products do all three at once. Logs should be exportable to common data formats for external analysis.

14.3.2.16 Notification

An important consideration of antivirus software is who should be notified when malicious code is found? At the very least, the answer should include the end user with the problem, the centralized console, and responsible network administrators. Notifications can be communicated via email, by pagers , from SNMP traps, or other forms of network messaging. Email notification can be unreliable when a large email worm outbreak happens, but it suffices for the most common method. The notification message should tell what rogue program has been identified, the time, the date, and what machine it was found on, what user is involved, and the file and path of the infected program.

Most antivirus products are built for single PCs, or small to medium companies. Truly large environments, with hundreds of distributed locations and tens of thousands of machines know that most of today's antivirus tools will not scale smoothly. You should consult independent antivirus consultants for advice when picking the right tools for large environments like this.

14.3.2.17 Email capabilities

If you buy a scanner with the ability to scan incoming and outgoing email, make sure it scan more than just file attachments. With Kak and Bubbleboy, rogue code can be embedded within the body or signature of the message. Also, if the email or attachment cannot be scanned, is the email still sent or opened? And if it can't be sent or opened, will the end user be notified? A good email-scanning program will give multiple options.

If your antivirus software is meant to scan on email servers, make sure it is completely compatible with your email server. In most cases, you do not want scanning software to do a file by file scan of email servers. Software designed to scan email servers is specifically coded for that task. Some versions scan each user's inbox, others scan the email server's database, and still others scan emails before they ever arrive at the server.

Antivirus solutions for Exchange can use a few different methods for protecting the server. The most common way is using the Messaging API (MAPI) interface which logs into each user's inbox and scans new messages as they arrive. Unfortunately, this method cannot keep up in busy environments and it is possible for infected attachments to get by. Newer Exchange scanners using Virus Scanning API (VAPI) or Extensible Storage Engine (ESE) interfaces to scan. Microsoft introduced the VAPI interface with Service Pack 3 of Exchange server. It allows the antivirus scan to run as a process in Exchange's Information Store and guarantees that incoming file attachments will be scanned before the user can open the email. Unfortunately, the current implementation of VAPI has drawbacks. It doesn't allow an antivirus program to provide as much information in notification messages, specifically, who sent or received the infected message; and there have been a few other reported corruption problems (fixed in Service Pack 4). At least one antivirus vendor has been successful at placing their software between Exchange's Information Store and Microsoft's Extensible Storage Engine. Although Microsoft doesn't official support the ESE-type interface, it does acknowledge that no corruption has been documented and that ESE-based products offer a valid solution. Products using either interface can result in faster, more accurate scanning, and should be considered after studying the vendor's online support databases for current issues.


Team-Fly    
Top


Malicious Mobile Code. Virus Protection for Windows
Malicious Mobile Code: Virus Protection for Windows (OReilly Computer Security)
ISBN: 156592682X
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net