Computer viruses represent a threat to the integrity of all computer systems but perhaps especially to networks where programs and data are shared to a greater extent than with standalone PCs. A network connection may make a computer more vulnerable to virus attack, but the same connection can also be used as part of an integrated system of defense against viruses.
This chapter describes the different types of computer viruses and the risk posed by each to networked PCs. It discusses antivirus strategies for networks and examines the features available on a range of workstation and server based antivirus products.
While the term "computer virus" has become common in the popular press over the last few years, it is quite often used inaccurately or out of context. This has given rise to many misapprehensions about what a virus is, how it works, and the harm that it can do.
The first step to protecting your network against viruses is a proper understanding of the nature of the adversary. This chapter therefore starts with a look at viruses in general.
Viruses fall into the broad category of malicious program code. Most software is written to serve a useful purpose for the user, but programs have also been written that attempt to breach security, damage data, or display unwelcome messages.
Most of the code in this very wide category is designed to achieve its goal by being executed by an unwitting user. For example, a program for grabbing user passwords on a network might be called LOGIN.EXE; the user attempts to log on using this program, which behaves like the real LOGIN.EXE except that it also writes the user's ID and password to a file for later use by an intruder. Programs of this type are called trojan horses or "trojans" after the wooden horse of Troyóthe classic example of getting your opponent to breach their own defenses for you by pretending to be something which you are not!
Viruses fall into the broad trojan horse category of malicious code. What distinguishes viruses from other types of trojan horse is their ability to reproduce themselves. All viruses are trojan horses; they can propagate only if their code is executed by a person who is not aware of their existence. The converse is not true, of courseónot all trojan horses are viruses. A password grabbing program is malicious and dangerous, but it cannot propagate itself.
You will of course want to protect your system against all trojan horses, not just viruses. Many of the protective measures described later in this chapter will help to protect against all trojan horses, viruses and non-viruses alike, but for information more directly relevant to non-virus trojan horses, refer to chapter 20, "Tools for Restricting Access".
Virus code must execute to propagate. The most direct way to achieve this is for a virus to attach itself to a genuine executable program file in such a way that when the user runs the program, the virus code executes too. The virus can then attach itself to other executables, from which in turn it spreads to still more. Not all virus code needs to be attached to a file, however. Boot sector virus code copies itself from disk to disk as the workstation boots up but without attaching itself to any files. The various mechanisms used by viruses to propagate themselves are discussed in the "Virus Propagation" section later in this chapter.
Every computer virus in circulation was written by someone who wanted it to infect other people's computer systems. In some cases, that was all they wanted: the knowledge that their code was passing from computer to computer, fanning out across the world over time. Many viruses have no direct effect on the computers that they affect other than the resources (disk space and memory) needed to propagate. These are not to be considered harmless though; virus code is complex and viruses can contain serious bugs that cause the virus to do things not intended by their author.
Some viruses are designed to propagate without the explicit intent of causing harm. These should also be considered as malicious. Any code that executes on your system without your knowledge or consent represents, as a minimum, a breach of security and a potential risk to your data.
If viruses did no more than replicate, they would not represent a very serious problem. But the fact that they replicate means that they can in theory carry out any task that can be programmed on a large number of computers across the world. This is what seems to attract virus writers to the arcane art of low-level programming: The ability to gain temporary control of someone else's computer at a safe remove in time and space. This allows the virus writer to corrupt data, hang systems, display obscene or irritating messages on-screen, or whatever else they decide to program with little fear of having to account for their actions. As a social activity, virus writing fits in somewhere among the arts of mooning, graffiti, defacing banknotes, and the kind of actual vandalism that results in prosecution.
Such activity by a virusóactions other than propagation or avoiding detectionóare referred to as the virus' "payload." Most viruses have a malicious "payload" of one kind or another. The payload is usually activated after the virus has been propagating for a time. If it were to activate every time the virus made a copy of itself, it would be noticed quickly and would not get beyond the first infection or two.
Not only do viruses differ in the payloads they carry but also in the way that they propagate. Knowing how viruses spread and where they hide is vital to any effort to combat them.
There are two basic infection categories:
There are one or two viruses that fit into both categories, but that is because these viruses use both types of propagation mechanism. The mechanisms themselves are completely different, as the next two sections explain.
Remember that virus code must execute before it can propagate. The easiest way to get an unwitting user to run virus code is to trick them into running it when they think they are running something else.
File infector viruses attach copies of their code to regular executable program files. When these programs are executed by the user, the virus code executes as well and it propagates itself to other program files. There are two basic types of file infector viruses:
ï Direct file infector viruses attach themselves to the program in such a way that when the user executes the program, the virus code executes first. It copies itself to other programs and then passes execution to the original program. This means that the program appears to run normally, so the user suspects nothing until some time later when the virus delivers its payload.
ï Indirect file infector viruses are also attached to a regular program. When the program executes, the virus loads into RAM before allowing the real program to execute. It remains in RAM without infecting other files until some time after the real program finishes. The virus only starts to infect other files at a later stage, as they are accessed for execution. Some indirect file infectors infect any executable file that is accessed, even if the file is not executing.
Program files are not the only source of executable code on a computer. The boot drive has code in its boot sector that executes at boot time. Combine this with the fact that boot devicesófloppy disksómove from one machine to another, and the virus writers have another opportunity to ply their trade.
A boot sector virus stores itself in the first sector of a disk, moving the original boot code to a different, unused sector. When an infected computer boots using that device, the virus code executes and the virus looks for other devices with boot sectors. If it finds oneóusually when a workstation with a hard drive is booted from an infected floppyóit infects them, too. It also loads itself into RAM so that it can infect any other boot sectors that present themselves, such as when a file is copied to or from a floppy disk. Finally, it passes execution to the original boot code.
All formatted floppy disks have a boot sector, not just "system" or bootable disks. Non-bootable disks have a minimal amount of boot codeójust enough to give an error message if you try to boot a computer using one. This is enough for a boot sector virus, however, so even non-bootable disks can have a boot sector virus!
If this method of propagation seems less likely than the more straightforward file infection method, think againóthe majority of actual virus infections are boot virus attacks, not file infectors!
Stealth viruses cover their tracks in such a way as to make them difficult to detect. Typically, they watch out for attempts by antivirus programs to detect their presence in RAM or on disk and ensure that the antivirus programs get the "wrong" answers to any questions they ask the operating system.
An antivirus program, for example, may check for the existence of a boot sector virus by checking if the boot code is stored in the correct sector of the boot disk. A stealth virus that has moved the boot code to make room for itself intercepts the query from the antivirus program and returns the value that would have been returned had the disk not been infected. The antivirus program therefore reports that the disk has been checked and found not to have a boot sector virus.
Stealth viruses are no longer new, and antivirus packages attempt to detect their activity. This is not trivial, however, and the development of new stealth techniques with corresponding developments in antivirus software looks likely to continue for some time.
Many anti-stealth programs try to detect stealth activity by watching for suspicious activity on the DOS interrupts normally used for disk access or by comparing reported file contents with the actual contents of the specific disk sector on which the file is stored. These methods cannot detect stealth virus activity on networked drives, which are not accessed using the same interrupts and which are not, of course, read straight from a disk sector.
Not all file infector viruses attach themselves directly to a host program file. Some attach themselves logically; they create files that execute instead of the host program file.
Extension priority companions, for example, make use of DOS rules about program names. If a command (other than a DOS internal command) is issued and DOS finds two files in a directory with the same first name as the command but one having an extension of EXE and the other COM, the COM file executes. A companion virus may "infect" a file called PROGRAM.EXE, therefore, by creating a PROGRAM.COM in the same directory. This file contains the virus. When the user issues the PROGRAM command, the companion executes, runs its virus code, and then calls PROGRAM.EXE, making it look as if nothing out of the ordinary has happened.
Path companions are a little more indirect and can infect COM files too. They examine the DOS path and create a program of the same name in a directory with higher precedence in the DOS path than the program that they are infecting. So if PROGRAM.EXE is stored in C:\BIN and the DOS path is C:\DOS;C:\BIN, the companion is created in C:\DOS. Again, this companion program executes before the real program, does its virus thing, and then runs the real program.
The principal of these viruses is quite simple. While easily detected by a decent scanner, they can fool some integrity checkers that merely note the existence of a new executable file by calculating a checksum for the new file and storing it in their database.
Early viruses replicated themselves precisely. When copying their code to a new host, whether a file or boot sector, they would copy the essential part bit for bit. This was necessary so that the vital part of the virusóthe code that propagated itówas intact on the new host.
This made scanning for viruses relatively straightforward, if laborious. Once a virus had been isolated and identified, a distinguishing pattern of bits from its code could be extracted. A scanner program could simply check all executable files for a pattern of bytes that matched this pattern and report an infection when discovered.
Polymorphic viruses are different. They produce offspring with the same functionality as themselves but using a different sequence of bytes. This means that there is no guarantee that a sequence of bytes found in one infection by a specific virus exists in another infection by the same virus. Each type of polymorphic viruses uses a different method to produce this inter-generational variation.
The simplest polymorphic viruses store most of their code in encrypted form. The key used to encrypt the code varies at each infection, with the result that scanners cannot match any given string from the virus code from one instance of the virus to the next. However, the encryption and decryption code is the same in all copies of the virus. Scanners can simply search for the encryption/decryption code to spot such a virus.
Some antivirus scanners examine the sequences of instructions in executable files and try to detect when the code is capable of "virus-like" activity. Such scanners will not work with polymorphic viruses of this type as the "virus-like" instructions have been encrypted and are not visible to the scanner.
More complex polymorphic viruses store multiple encryption mechanisms and choose between them at random when they infect. This means that a scanner must check each file several times to be certain of detecting an instance of even one such virus.
Other polymorphic viruses intersperse their own code with random instructions that are not executed, making it impossible for a scanner to identify any consistent pattern of bytes that would reveal for certain that a file was infected with even one variant of a virus.
Polymorphic viruses are the most difficult to detect and as a result, they are fast becoming the most common. When choosing an antivirus solution, bear this fact in mind and make sure that the product you choose can reliably detect viruses of this kind.
Not all computer code is binary; many applications have built-in macro languages that let the user to program a sequence of instructions to be executed by the application. The macro code is usually stored in its raw formóthat is, without being compiled, as is the case with COM or EXE filesóand is interpreted by the application at the time when the macro is executed.
While it has long been known that this type of code is capable of carrying a virus, it was not until late 1995 that the first such macro virus appeared "in the wild" on a significant scale. The Winword.Concept virus is attached to a Microsoft Word 6 document. When the infected document is opened, the virus installs itself in the global Word environment as a macro to be executed each time a document is loaded. From then on, any documents opened by that copy of Word are infected with the virus.
The Winword.Concept virus appears to have been written to illustrate the principle of macro viruses rather than to cause any particular damage. However, within a few weeks of its launch, a variant, Winword.Nuclear, was released that used the same basic mechanism as Winword.Concept but caused significant damage on many computers. At least two more Word macro viruses have been released since then. Now that the principle has been established, we can expect macro viruses to become as much a part of everyday life as the more conventional binary viruses.
By now, every major antivirus product can scan files on disk to locate infected Word documents and settings files and remove the virus. Live detectionówhile using Word in the normal wayóis a little trickier and antivirus software vendors have tackled this problem in different ways. Refer to the "AVP" and "F-Prot" sections later in this chapter for information about how these two packages tackled this issue.
In the long run, however, there is a lot of scope for the application authors to tighten up their macro mechanisms. The fact that Word automatically executes a macro with a specific name, to take a case in point, is perhaps a little too trusting for the real world.
Viruses propagate from one host to another host of the same kind. Macintosh viruses, for example, do not spread to DOS machines; the machine code used by the two systems is quite different, so a virus written for one cannot execute on the other. Likewise, DOS viruses cannot infect Macintoshes, UNIX machines, or VAXs.
One apparent exception to this is when a DOS virus infects DOS executable files on an OS/2 machine. In this case, the virus executes and can propagate to other DOS files on the computer. It cannot successfully infect OS/2 executables, however, and the damage it causes if it tries is readily apparent and leads to early detection. In reality, this is not an example of cross-platform infection but of the infection of hosted files.
So viruses only move from one computer system to another of the same type. They don't move through thin air, of course. They require a vector of some sort to carry them, just as biological viruses do. In the case of computer viruses, the possible vectors are
Strictly speaking, the vectors for the virus are executable files in the case of file infector viruses and boot sectors in the case of boot sector viruses. The viruses attach themselves to executable code, not to physical entities such as disks. The items in the preceding list, therefore, represent vectors for the vectors. However, it is more intuitive to refer to them as vectors, so a little linguistic license is applied in the sections that follow.
Viruses can be attached to a file on a floppy disk or stored in the boot sector. Floppy disks are the ideal vector for viruses: Portable, writable, and ubiquitous. That floppy disks are the primary vector for virus infections should come as no surprise.
It may seem like a truism to say that if a hard disk from an infected computer is moved to another machine, the second computer will be infected. After all, it's the hard disk that was infected in the first place, so moving it to a different machine doesn't change much. However, the virus now has a new access point from which to spread, so it is a new threat, and as such it's something to be avoided.
Some service companies will replace a faulty hard drive with one that was already used ("We just tested it in one of our own machines...") without reformatting it. In fact, some will make a selling point of the fact that the disk is second-hand ("It has DOS and HyperBlip already installed!"). You may even transfer a virus yourself, by borrowing a hard disk from a poorly protected machine. Although not nearly as common as delivery by floppy, this possibility should be eliminated by checking all replacement hard drives as soon as they have been installed. If in doubt, boot the machine with a "clean" floppy disk and scan the hard disk with a good antivirus scanner. Consider reformatting the hard disk completely in case any viruses are missed by the scanner.
Backing up an infected file to tape and restoring it later is another way to propagate a virus. The virus may be reintroduced to a system from which it had been cleared or introduced to a previously clean system. That much is simple common sense; the obvious corollary, scanning all files being restored from tape, is often overlooked.
Any medium that can store executable files can store a virus. CD-ROMs, WORM (Write Once, Read Many times) cartridges, magnetic tapes, and so on can all provide an exact replica of whatever was stored on them, possibly including infected files. As these media are passed from one system to another, they represent a risk of virus infection.
In the case of read-only media such as CD-ROMs, the risk is smaller: The CD-ROM cannot become infected as it is passed around. There is still a risk, however. If the original data is infected, the copy on the CD-ROM is too. The CD-ROM is also immune from disinfection by any antivirus utility.
WORM drives can also represent a risk. An infected file stored on a WORM drive can be copied to a live system or executed from the WORM drive. Files on the WORM drive cannot be infected, however. The only way to alter a sequence of bits stored on a WORM cartridge is to turn on additional bits in the sequenceóno bits can be turned off. This means that files on a WORM device can be obliterated but not changed constructively.
Networks are designed to be extremely efficient vectors of data in general, and infected files are no exception. An infected program on a file server, if executed by many users, can propagate much more quickly than by floppy disk transfers alone.
The network can transmit infected files but not (generally) boot sectors. This means that boot sector viruses cannot spread directly across the network. They may be encapsulated in a file in some way, of course, in which case they can be transmitted like any other data. However, they cannot spread by themselves, by executing their fake bootup code. So using the network rather than floppy disks to transfer data may actually reduce the incidence of some viruses.
The NetWare partition of a server cannot be infected by any virus known at time of writing. (Files on the DOS partition can be infected, as can the server's boot sector.) The NetWare partition can certainly store infected files and act as a dissemination point for the infected file and its viral passenger, but the server itself is not infected. The same is not true of machines on a peer-to-peer network, where one of the computers can certainly become infected by sharing a file with another computer.
Bulletin Board Systems (BBSs) are commonly regarded as hot spots of virus activity. An infected file on a BBS may indeed propagate quite far, especially if the file itself is a popular utility or attractively named. In fact, some viruses have been "launched" on the world by being attached to fake versions of popular utilities (in one case, to a well-known antivirus package) and uploaded to a BBS for an unsuspecting public to copy.
Still, BBSs have had an unfair press. The fact is that you are much more likely to infect your PC using a disk borrowed from a colleague than by downloading a file from a BBS. This is largely due to the vigilance of individual BBS administrators, the majority of whom are well aware of the virus threat, know how to confront it, and adopt a strict policy of scanning all material for viruses before allowing it to go public.
The same goes for the Internet, except that the loose organization and enormous scale of the network in this case makes it impossible for anyone to monitor all uploads. This pushes the onus for checking for viruses back where it belongs, on the network user.
Individual archive sites may well scan for viruses, but don't rely on it; scan everything you download before unpacking it. Use an antivirus utility that can scan inside archives, as described in the "Workstation Utilities" section later in this chapter.
Viruses are capable of moving across any pathway that can carry data. Examine the data paths in your organization and assess the vulnerability of each to virus infections. Remember, the media simply transport the data: When you receive programs from someone outside of your system, scan them for viruses before running them.
We have looked at how viruses work, why they are written, and how they propagate. Before moving on to discuss the details of how to combat them, it is worth taking time to consider the nature of the threat that they pose, particularly in network environments. This should help to inform the decisions you must take when formulating a detailed antivirus strategy for your network.
As explained earlier, most viruses come with a payload that is harmful to one extent or another. It is this payload that is harmful, and as payloads vary from one virus to the next, so does the capacity for inflicting damage. The effect of a virus infection on a PC can range from no discernible effect to the complete loss of all data on the machine. The actions of viruses include
Some of these activities are irritating but not particularly damaging, while others represent a complete disaster. As long as the effects are confined to a single workstation, however, the infection is unlikely to be disastrous for the entire organization.
A viral infection on a networked workstation is obviously a serious matter for the infected machine. The implications for other machines on the network vary.
If the infected machine forms part of a peer-to-peer network, and if any files in its shared directories are infected, the virus may spread to other peer computers.
If the infected computer is a client machine on a client/server network, the infection cannot spread to the server per se, but may spread to files stored on the server. From there, it may infect other workstations on the network.
The capacity for a virus to infect files on a server from a client machine depends on the access rights of the user who uses P>ï If the user has full rights, the virus may infect any files executed by the user (or in the case of some viruses, any executable files opened by the user). The most likely files to be infected on a NetWare server are those in SYS:PUBLIC that are shared by all users, so the virus infection could spread rapidly to a high proportion of the machines on the network.
If the user stores files only in their own, personal area on the server, and if these files are not shared with any other users, the only machines that can be infected are those used by that user.
So on a client/server network, the threat from a virus infection on a workstation depends to a large extent on the privileges of the user of the workstation. This means that it is particularly important that any computer that may be used by a privileged user should be kept free from viruses.
Examples of danger points are
Although the seriousness of a viral infection can be more serious on a networked machine, as the virus uses the network to propagate more efficiently, the network can also be used to help to contain the spread of viruses. Sharing files using the network rather than floppy disk can reduce the circulation of floppy disks, the main vector for viruses in most organizations. Some antivirus products can refuse connections to workstations that are not running a particular antivirus scanner, ensuring that only "clean" machines connect to it.
So the network that accelerates the spread of an infection on the server can also help to prevent infections from happening in the first place.
Viruses still appear exotic to many people. The media hype, the crafty programming, and the constant battle between virus writers and antivirus software vendors, all contribute to a slightly unreal perception of the mundane reality of viruses. This can combine with a feeling of being remote from developments in computing to give a false sense of security. "We just do a little word processing", people say, "why would anyone infect our machines with a virus?"
The fact is that viruses have been with us for a long time now. Computer users all over the world share disks and programs, sometimes for software piracy, mostly for legitimate reasons. Viruses have spread to all corners of the world and are kept in circulation by a substantial percentage of computer users who do not take adequate precautions against them or who do not properly eradicate them once detected. The ongoing tussle for superiority between virus writers and the antivirus authors also ensures that new and more complex viruses emerge at a steady rate.
In a relatively recent development, some virus writers have released object code that allows virtually anyone with a little programming experience to produce complex polymorphic viruses. This brings virus writing within the reach of a much greater number of people than in the past. Although the antivirus software companies are dealing with the polymorphism problem, the precedent of encouraging large-scale, broadly based virus writing is worrying.
In summary, viruses are ubiquitous and they are here to stay for the foreseeable future. Unless your network is hermetically sealed from the rest of the computing worldóno floppy disks, no external network link, etc.óyou are vulnerable to an attack. You don't even have to be a target. When the virus infection comes, it is much more likely to be from a computer game via a home computer than it is to be the result of a deliberate attempt to disrupt your organization. The best approach is to face the fact of the existence of viruses, minimize the risk of infection, and ensure that you are in a good position to recover should your defenses fail.
Detection is the essence of any antivirus strategy. If a virus is found, appropriate action can be taken; the virus can be removed, the disk wiped clean, or the infected files replaced by clean backup copies. As a minimum, the infected machine can be taken out of use until the virus has been dealt with, thus protecting other computers. Adequate detection brings awareness of viruses, which is the first step in tackling them; poor or non-existent detection leaves the user helpless.
No virus detection method is perfect (contrary to some of the claims you may see in advertisements). There are two terms that are used to describe the accuracy of virus detection:
1. A false positive occurs when an antivirus program reports a virus infection where none really exists.
2. A false negative occurs when an antivirus program fails to detect the existence of an infection.
False positives can occur when a clean program happens to contain a sequence of bits that which resembles a virus signature (see "Scanning" later in this chapter for more information on virus signatures) or when a program contains instructions that are not malicious in any way but which an antivirus product regards as suspicious for some reason.
These reports are generally little more than an irritant. They can cause confusion, as they may be reported by one product and not by another; attempts to remove the "infection" will not, of course, be successful. By and large, however, false positives merely reflect the fact that an antivirus program is erring on the side of caution.
One situation when false positives are a serious problem is where an antivirus utility attempts to disinfect a file when, in fact, the file is not infected. The disinfection process involves rewriting some or all of the file; unneeded disinfection will scramble at least some of the file.
False positives are relatively uncommon. They typically arise in a new release of an antivirus product as a side-effect of a change in the program and are quickly recognized once the product is released. The author of the antivirus product then usually releases a minor update that does not produce the false positive report.
A false negative is a failure by an antivirus product to detect the existence of a virus. This can happen for a variety of reasons: The virus may be new and hence unknown to the antivirus program; it may employ stealth techniques that evade detection; or it may be a type of virus for which the antivirus program does not search.
False negatives are obviously more serious than false positives, representing a failure by an antivirus product in their central function. They are also more common than false positives. This is because false positives are accidents, caused by the fact that virus code is program code and valid programs may sometimes resemble viruses in some chance way. Nobody tries to produce false positives, and antivirus software authors actively try to avoid them. False negatives, however, are the goal of virus authors who do not want their programs to be detected.
Barring the invention of a perfect virus detection mechanism, false negatives are a fact of life. Your goal, along with the antivirus software authors, should be to minimize them and to make sure you are well equipped to recover from a virus infection.
The most direct approach is to attempt to detect the existence of viruses before they activate. There are two ways to do this:
Viruses being what they are, however, the direct approach is not always the most effective. The indirect approach is used by two further methods:
Let's take a look at each of these methods in turn.
A scanner reads the contents of executable files, looking for virus code and notifying the user when any is found. Some scanners ask the user if they want to remove the virus from the infected file, while others leave that task to a separate utility from the same antivirus package. Every self-respecting antivirus package comes with a good scanner as its main element. Refer to the later sections of this chapter for a description of the criteria to apply when choosing a scanner and for a comparison of some of the available products.
A signature database is at the heart of all virus scanners. This is a collection of bit patterns found in files infected by a range of known viruses.
The simplest scanners simply check each file for the existence of any of the virus signatures in the database. Using a single signature can lead to a high rate of false positives. There are only so many possible permutations of ones and zeros, after all, and whatever string of bits is selected as indicating the presence of a virus probably occurs in some genuine code sooner or later.
The best way to reduce the incidence of false positives is to use two or more signatures for each virus. If the first signature is found, the scanner checks for the existence of the second signature (and possibly more) before concluding that the virus is present. Most scanners now use multiple signatures, although some allow the user to trade speed for thoroughness by selecting the number of signatures used.
Advanced scanners also decrypt code that is encrypted, allowing them to detect polymorphic viruses with a high rate of success. The prevalence of polymorphic viruses means that this functionality is essential in a scanner these days.
There are two types of scanner utility, on-demand and memory-resident.
On-demand scanners execute explicitly, either by the user issuing a command when they decide to check a disk or from a command line in a batch file. They perform a thorough scan of all executable files on a disk, searching for known viruses.
You can run a scanner with a command-line interface from the AUTOEXEC.BAT, but it's not really a good idea. Users will quickly get fed up with the long delay every time they start up and will disable the scanner. It's better to educate them in the need for regular scanning and encourage them to scan regularly on their own initiative.
Don't use any disks entering your organization unless they have first been scanned for viruses. It is often tempting not to wait the minute or so per floppy that a scan can take, but the cost in hours of missing an infected disk can be much higher. All users must be made aware of the importance of this step, as they all have the capability of introducing a virus to the organization.
Memory-resident scanners are loaded into memory when the computer starts up, and they remain there until the computer is shut down, scanning files as they are accessed. If a virus is detected, the scanner reports it and warn the user to disinfect the machine. Some memory-resident scanners lock the PC as soon as they display their warning message, preventing the virus, which is now in RAM and ready to infect, from inflicting any damage.
These scanners work in much the same way as their on-demand cousins, using a database of virus signatures and a scanning engine that attempts to match one or more signatures in each executable file. There are some differences though:
On-demand scanners store their database in a file on disk. Memory-resident versions generally store a shorter database in memory, although some can save memory at the expense of performance by reading the signatures from disk every time a file is scanned.
Most non-technical users are not willing to run an on-demand scanner on a regular basis. If you cannot persuade your users to do so, then installing a memory-resident scanner on all workstations is an acceptable compromise. This should of course be used in conjunction with other antivirus measures such as the footbath computers described in the "Sheepdips and Footbaths" section later in this chapter.
Whether the memory-resident scanner merely warns of the virus or locks the PC (a far safer option), it is important that users be briefed on how to respond; refer to the Recovery and Education sections below for suggestions.
Most antivirus packages come with both on-demand and memory-resident utilities. These serve different purposes and the best approach is to use both:
The best scanning policy, then, is to rely on a TSR as an early warning system and to sweep the system regularly with a good scanner for deep security. Scanning is at best only part of a proper antivirus strategy, however, as subsequent sections should make clear.
The principal drawback with scanners of the type previously described is that they can scan only for known viruses. A new virus, one without a signature in the scanners signature database, will not be detected.
Producing a program that can detect all viruses, even those not yet written, has been something of a holy grail to antivirus software authors for some time. Most viruses use one of the limited number of techniques described earlier in this chapter; a program that can detect patterns of behaviour typical of such viruses should be able to detect all viruses of those types without the need for a signature string.
A program that scans files looking for such patterns is called a heuristic scanner, as it uses heuristic, or trial-and-error, methods to identify suspicious instruction patterns. Many scanners of the type described in the previous section use at least an element of heuristic analysis in tandem with signature scanning, while others use a separate heuristic analysis utility.
In reality, the task is more complex than what has just been stated. Many genuine programs use sequences of instructions that resemble those used by viruses. Programs that use low-level disk access methods, TSRs, encryption utilities, and even antivirus packages can all at times carry out tasks that are also performed by viruses. A heuristic analysis engine must attempt to distinguish between suspicious code that is malicious and that which is not.
There are other difficulties. As with all antivirus techniques, the existence of heuristic analysis engines has spurred virus authors to write viruses that can evade heuristic analysis. The difficulties are exemplified by those polymorphic viruses that intersperse their essential instructions with random "noise" instructions; how can a scanning utility properly distinguish between those instructions that form part of the viruses essential code and those that do nothing?
The net effect of these difficulties with heuristic analysis is that scanners which use the technique tend to produce a higher rate of false positives than signature-based scanners. This can have one of two undesirable side-effects:
1. Users will get used to frequent messages warning about "possible virus activity" and will quickly learn to ignore them. When a genuine virus infection occurs, they may treat it like all the other (false) warnings they've seen and fail to react.
2. The irritation factor of lots of incorrect warnings means that many users will completely disable the scanner, possibly removing the entire antivirus package. This can leave them with an unacceptably low level of protection.
Nevertheless, heuristic analysis is a powerful technique. It can be particularly useful at detecting hitherto unknown viruses that have not yet become known to the antivirus authors or whose signatures are not contained in your current version of the signature database. The best approach is to use heuristic analysis on central checking machines (such as the footbath computers described in the "Sheepdips and Footbaths" section later in this chapter) and on the workstations of privileged users. These, after all, are the most critical in terms of preventing the spread of viruses across the network.
Another approach to the idea of a generic antivirus utility is to monitor programs for virus-like activity while they execute. This is done using a behavior blocker, a TSR program that monitors activity by programs after they are loaded into the workstations memory and while they execute. If a suspicious sequence of instructions is carried out, the blocker warns the user and asks them if they want to allow the program to continue.
The activities that can trigger a warning from this type of program are the same as those searched for in a different way by the heuristic scanners previously described: formatting commands, low-level disk accesses, strange file modifications, and so on. As with heuristic analysis, the tricky part of designing a behavior blocker is trying to distinguish between strange behavior that is malicious and that is legitimate.
The difficulties encountered are also similar. Behavior blockers generate a high rate of false positives and are liable to be rejected by users. They are perhaps best suited to particularly sensitive machines, such as footbath systems or workstations used by privileged users.
One of the simplest approaches to detecting virus activity is to note details about each executable file (and the boot sector too, for good measure) and watch for changes. The virus may evade detection, the reasoning goes, but its effects certainly won't!
To this end, an integrity checker examines each executable file on the system. Checkers differ in their interpretation of what constitutes an executable file, with some including only COM, EXE, and SYS files while others embrace DLL, DRV, OBJ, LIB, OVL, and occasionally user-defined extensions too. The checker calculates a checksum for each file examined and stores it in a database. It also calculates a checksum for the boot sector.
When one of these files is accessed, a TSR calculates the file's checksum and compares it with the checksum stored in the database. If the two values differ, foul play is suspected and the integrity checker warns the user.
On the face of it, this looks foolproof enough. Start out with a clean system, take a simplified snapshot of each file (the checksums) and watch for changes. Perhaps for this reason, the authors of some integrity checkers tout their packages as being the ultimate in protection, proof against all possible viruses, and so on.
In reality there a number of practical difficulties with this approach.
In summary, integrity checkers are of limited use in programming environments or where new packages are regularly installed. They are also heavy on disk space and may be impractical to maintain on a network drive where there may be many thousand files occupying several gigabytes. Some viruses target the better known integrity checkers and in some cases are capable of evading detection.
They can, however, help to keep a clean, stable system clean. As such, they may be useful on a footbath machine or in a "cleanroom" environment where the integrity of files is accepted as being sufficiently vital to justify any potential nuisance value.
All four detection methods listed above can run on any workstation, including a client machine. Behaviour blocking utilities work only on a workstation, at run time. This is because they need to sit in memory to watch other programs execute. The other methods can run either on a server or a client machine.
Having informed yourself of the threat posed by viruses, you should set about designing a strategy that will protect your installation from viruses. There is no perfect solution; some of the more effective antivirus measures are unacceptable to users because they are too intrusive or inconvenient, while others may be too expensive. You will need to weigh the cost of protection against the risk of infection and decide on an integrated strategy that is appropriate for you.
This section should be read along with the chapters on restricting access, backups, and disaster recovery. These cover many topics of direct relevance to the formulation of an effective antivirus strategy.
Prevention is certainly a good deal better than cure in the case of virus infections. It may not be possible to fully recover data damaged by a virus, and even if it is, the cost in time and computing resources may be high. In any case, prevention is relatively straightforward if appropriate measures are introduced and adhered to by all concerned.
There are a number of computing practices that increase your exposure to viruses. While not directly related to virus activity, avoiding these practices can help to reduce the incidence of viruses:
After an awareness of safe computing practices, the first active line of defence against viruses is a reliable detection mechanism. The different methods used were described earlier; specific products are covered later in this chapter.
Scanners and heuristic analysis utilities can help identify infected programs before they execute and behavior blockers can help to warn of impending virus activity. Integrity checkers can only tell you about virus activity after the fact, but they are a useful preventive measure nonetheless. By warning that a virus attack may have taken place, they alert the user to the need for action and can thus help to contain a virus outbreak.
A file infection on a file server can be disastrous, especially if the infected file is accessed by a large number of users. Such an infection can occur if the file is accessed by a user with write privileges from an infected workstation. You may not be able to guarantee that all workstations are free from viruses at all times, but you can go a long way towards reducing this type of risk by restricting the degree of access to the server for all users, including privileged users:
In extreme cases, it may be necessary to remove or disable the floppy drives in almost all workstations. Leave the floppy drives in one or two well-protected machines in a central location and insist that these machines alone be used for introducing data or programs from floppy disk.
The SUPER utility by Wolfgang Schreiber allows supervisor equivalent users to toggle their supervisor equivalence on and off. Use it in the login script of all supervisor equivalent users to turn their privileges off. They must then explicitly run the utility to turn their privileges on again.
This means that privileged users will not normally have write access to public files on the server, significantly reducing the likelihood of infecting them with a virus.
SUPER only works for users who start out with supervisor equivalence, by the way, so it is not a security risk!
A sheepdip or footbath machine is one that is used to check all disks coming into an organization. This machine is isolated from other machines and equipped with a high quality, up-to-date antivirus package (or two!). All incoming material should be scanned on this machine for viruses, and if a behavior-blocking utility has been installed, any incoming programs should be executed here first. The aim is to detect virus infections as they enter your system, rather than waiting until they manifest themselves on user workstations.
Systems of this type make little sense if material enters the organization by means other than floppy disk. If users have direct access to the Internet or to external BBSs, for example, they will download material directly to their workstation. They should then scan the material on their own machine before using it, and the footbath machine is not part of the process.
All users should be trained in how to use it and made aware of the importance of checking all disks before using them. Most importantly, the procedure to follow when an infection is discovered must be clearly explained (see the Containment section later in this chapter for suggestions).
One of the most important steps in avoiding virus infections is to inform yourself and your users of the risks associated with viruses. While privileged users have a special responsibility for combating viruses in a network environment, all users can potentially introduce a virus into the organization. Except for the most extreme cases, it is not possible to prevent users from bringing data in to the organisation from outside.
It is therefore vital that all users be fully informed of the risks involved in transferring data, the precautions to take and the steps to take should they see a warning about a virus. There a number of steps:
1. Use seminars and newsletters to inform people about the reality of viruses, what they do, and how to combat them. Many people rely on the popular press for information of this kind and as a result, have a poor idea of what viruses are all about.
2. Explain the reality of the virus threat to your enterprise. People are much more likely to cooperate in the antivirus effort if they perceive that it is in their interests and not just the hobby-horse of the computer department.
3. Train users in the operation of whatever antivirus product is installed on their machine. Show them how to scan, tell them how often to do so, and make sure they understand what to do in the event of a virus alert.
4. Maintain an awareness of virus issues with regular newsletters, reminders, software updates, and so on.
Finally, an essential part of protecting against virus damage is to minimize the effects of losing any data on the workstation. Assume that a virus is going to get through sooner or later, and safeguard your data accordingly.
If you keep only a single copy of all essential data, with no backups and no way of retrieving data from a crashed disk, a virus infection that wipes the disk will be a disaster indeed. If you have recent copies of all essential material and back up disks that will allow you to reboot and re-install all applications, a virus attack won't be quite so serious.
A particularly useful measure is to prepare a recovery disk for each workstation. Make (and test!) a bootable disk with the following contents at least:
Examine the startup files on the disk and make sure that no programs are run from the hard disk. The aim is to be able to boot the workstation from the floppy only, without reading anything from the hard disk. The first time the hard disk is read following bootup will be when the scanner program kicks in.
Finally, write-protect the disk. This ensures that it remains uninfected. Floppy drives are built so that they will not write when the write-protect tab is open, and no virus has yet been written that can flip those little bits of plastic!
No matter how good your protection strategy, viruses will occasionally infect machines on your network. For this reason, your antivirus strategy must look beyond the detection/protection stage and deal with failureóthat is, infection.
When a virus infection occurs, the first thing you will want to do is remove the virus and get the machine working in a safe manner again. How you go about this depends on how the virus was detected and how much damage it did. In general, the sequence of events is
1. Deactivate the virus
2. Remove it from all disks
3. Recover any lost or damaged data
4. Prevent a re-occurrence
If the virus was detected by a memory-resident scanner, take note of the name of the virus that it reports. This information may be necessary at the disinfection stage if your antivirus package has separate scanning and disinfection utilities.
Not much can be done while the virus is active in memory. The first step must be to stop it from running. (This step obviously does not apply where a virus is inactiveóthat is, it was detected during a routine scan of a workstationóproceed to the next step in that case.)
First, turn off the computer as soon as the virus makes its presence known. This will halt any nefarious activity which it may be carrying out. Note that a warm reboot may not be completely safe, as some viruses intercept Ctrl+Alt+Del and simulate the effects of a reboot while remaining active.
Next, locate the recovery disk you prepared earlier. Make sure that the disk is truly clean by checking it from another workstation. If you can't locate the recovery disk, use a clean, write-protected boot disk.
Then reboot the computer using the recovery disk. The computer will now be running, with the hard drive accessible and the virus inactive. Only when you get to this stage can you proceed to the removal of the virus.
Do not access the hard disk nowónot even to check if it is accessible.
With the virus inactive and the computer running, load the disinfection utility. Some antivirus programs use the same program for scanning and disinfecting, others have separate utilities.
Follow the instructions for the product you use, and attempt to remove the virus. This procedure may be straightforward or not, depending on the type of virus and the capabilities of your antivirus package. The details of how to go about it are different for each package.
Some boot sector viruses that infect the Master Boot Record (MBR) such as Michaelangelo and Stoned can be removed by rewriting the disk's Master Boot Record. Entering FDISK /MBR will create a new Master Boot Record. You can then make the disk bootable again using the DOS SYS command:
ï SYS C:
Depending on the type of virus present, this technique may render the data on the hard disk unusable! The One-half virus, for example, encrypts the data on the disk and decrypts it as the user reads it back; as long as the virus remains active, the data appears normal. If the MBR is overwritten, however, the decryption key will be lost along with the virus, rendering the encrypted data irretrievable. Use FDISK /MBR as a last resort or when you don't care about the data stored on the disk.
Once the virus has been disabled, the seriousness of a debilitating viral infection depends largely on the state of the workstation's backups. Data recovery is not always possible, even with regular backups.
Many viruses are destructive; some will suddenly wipe the contents of a disk or overwrite the contents with garbage. Others are more insidious, changing a bit or two now and then. The latter type may slowly corrupt data over time before being detected, with the corrupt data perhaps being assiduously backed up at regular intervals.
It may not be obvious which files have been damaged, so you may need to examine each one separately. Consider whether the contents of these files are sufficiently important to justify this type of examination, let alone the effort repairing any damage. In the case of application directories, the simplest thing may be to restore the entire directory from backup or to reinstall it from scratch.
The best way to recover lost or damaged data is to restore an undamaged copy from backup. This may take a long time, especially if many files have been affected by the virus. It cannot be emphasized enough, though, that it is the only sure way of getting an undamaged file back.
Even restoration from backup may not be entirely safe. If an infected file was inadvertently backed up, you may reintroduce the virus to the workstation by restoring the file. For this reason, it is advisable to do a full scan of the workstation again after restoring any files from tape.
If your backups are inadequate you may need to rely on the disinfection features of your antivirus package. Such utilities can achieve wonders, but there are times, such as when two viruses infect the same file, that they are helpless. For this reason, it is best to use backups or reinstallations whenever possible.
The last thing you want is to deal with the same outbreak multiple times. Whenever you deal with a virus infection, stamp on it hard and make sure you have left no opening for the virus to reappear.
In all cases, following the disinfection of a machine, run a full scan (with the maximum level of "thoroughness" that the scanner is capable of) on all hard disks and on all floppy disks used on that machine since the last full scan. Notify all others in the vicinity (including those who do electronic business with the owner of the infected workstation) that a virus incident occurred, and encourage them to scan their own machines and floppy disks as a precaution.
The person who discovers the virus should always notify the designated contact person, even if they have managed to remove the virus from their own machine. Trying to figure out how the virus entered the system is important, and it will be necessary from time to time to make some adjustments to the antivirus strategy to take account of the real risks posed in your environment. There is no better way to identify those risks than to take proper note of each virus incident.
Finally, if you suspect that floppy disks used in the infected machine may have been sent outside the organization, don't hesitate to recall them; the potential embarrassment of doing so is less than the damage to your company if a virus spreads as a result of an oversight on your part.
Viruses can disrupt your network and compromise your operation, so a coherent and well documented security policy for your network should cover antivirus procedures.
Start by evaluating the security of your network from the vantage point of a virus. Give your network a look over and identify all possible entry points for viruses. Examine your work practices and those of other users with a view to tightening up weak points. You may not be able to eliminate viruses completely, but there is no point in leaving unnecessary opportunities for them.
Next, try to figure out what the potential effect of a virus infection is. Estimate the cost of a serious virus outbreak in terms of human and financial resources, lost business, and tarnished image if the virus spreads beyond your company. This should help in establishing a budget for antivirus measures.
Then design a strategy to reduce the incidence of viruses and to minimize the effect of those infections that will eventually occur no matter what. The details of this strategy need to be particular to your environment, but the following points should be kept in mind:
Once drafted, the policy should be discussed with all users before being formally adopted. Everyone has a role to play in the antivirus effort, and this phase can be used to heighten awareness of the issues as well as to ensure that users will not balk at unsuitable measures foisted on them without adequate consultation.
Finally, educate all concerned on the procedures to be followed. It is especially important that users and support personnel are aware of how to behave in the event of an outbreak to minimize damage and stop the spread of the infection to other machines in the organisation.
The information gathering role is important. For example, if you find that a significant number of viruses are entering your organization on disks brought by staff from home computers, it may be in your company's best interests to purchase a comprehensive antivirus package for all such home PCs, or to extend a corporate licence to cover home PCs too. If this seems like a lot of money to spend protecting privately owned computers, consider the alternatives: Tolerate an unnecessarily high incidence of virus outbreaks or try to prohibit users from bringing disks from home. The latter option is impossible to enforce in all but the highest security installations.
Viruses are not entirely bad news for everyone. Their success in spreading across the world and disrupting the work of computer users everywhere has led to the development of the antivirus software market.
A number of companies now make a living from producing antivirus programs. Their sales effort is made easier for them by the fact that the popular media do a good job of raising awareness of the virus threat but a poor job of explaining what exactly it is. This means that everyone knows that they need antivirus software but few know what they need.
Some antivirus software houses have played on peoples fears and lack of information to sell sub-standard products. There is at least one antivirus package on the market that is so poorly written that it may represent a significant liability to the integrity of a user's data. (For obvious reasons, it cannot be named here.) The majority of producers are genuine in their efforts, but even among these, there are significant quality differences.
The difficulty faced by a system administrator trying to select a product is that so many claim to be the best and to use some new and particularly clever method to detect "all" viruses. In reality, some of the better results are obtained by products with little hype and using solid, established methods to achieve their ends.
Short of building up a large collection of real viruses (an unsafe practice for sure, best left to the professionals) and testing each product on them, how do you choose between the different products on the market?
Many antivirus products invite you to choose them on the basis of the enormous number of viruses that they can detect. Figures of several thousand viruses are common enough in advertisements. The difficulty with figures of this kind is that companies count viruses in different ways. What is a virus to one is a variant to another. Unless the company adopts a formal set of naming conventions, such as those published by the Computer Antivirus Research Organization (CARO), comparisons of figures like this are meaningless.
The growth in polymorphic viruses also renders such figures increasingly meaningless. A scanner may be able to detect one instance of such a virus and miss others. What matters is its overall success rate, not whether it once managed to detect one case of the virus.
A more meaningful indication of the quality of a product is its score in an objective test where it is pitted against a large number of real viruses in a laboratory environment. The test data usually includes thousands of file and boot viruses, with polymorphic viruses making up a significant proportion. The results are usually quoted in terms of the percentage of each type of virus detected.
The Virus Bulletin is a good place to look for such results. This journal frequently provides objective comparisons of the performance of many of the main players in the antivirus market and can help greatly in assessing the merits of the various options available.
Another place to check for review information is the Virus Test Center at the University of Hamburg. Their FTP server (ftp://ftp.informatik.uni-hamburg.de/) holds many product reviews in the pub/virus/texts/tests/vtc directory.
The top scoring packages generally catch 95%+ of the viruses in the test, with a success rate of less than 70% being considered very poor indeed. However, it is best not to get too hung up on these success rates. These rates depend in part on the test data used and, particularly with the polymorphic viruses, on an element of chance. A product with a 97% success rate may not really be any better than a product with a 95% rate. The difference becomes even less important if you consider that most users will come across a virus only rarely, especially if a proper antivirus policy is in place and adhered to in their workplace.
On the whole, comparative percentage success rates can help to separate out the very bad packages from the very good but should not be used by themselves as a means of deciding between the top scoring packages.
Detection success rates are only part of the equation when selecting a product. Other factors include
Cost Cost is bound to be a very significant factor. Typical costs of $50 and up per workstation can add up quickly when applied to a network. Server based scanners can work out cheaper at $500ñ$1,000 per server, but they offer only partial protection and are best used with workstation-based scanners as part of an integrated solution.
If you require a solid commercial package with good documentation and support, you will have to pay good money. If you are content with a package that is technically of a very high standard but comes without documentation or support, the shareware version of F-Prot is a good option. It costs just $1 per workstation (with up to 75% bulk discount!) and uses the same technology as F-Prot Professional.
The essential components of a workstation-based product are a scanner and a disinfection utility. Most packages come with both on-demand and memory-resident scanners. Some also use heuristic analysis, and many come with other utilities not directly related to virus detection or disinfection.
The next sections outline the features of a number of the more common (and better quality) workstation-based packages. All of these packages score quite well in independent tests.
Produced in Russia by Eugene Kaspersky, AVP (Antiviral Toolkit Pro) is rich in features and particularly suitable for use by system administrators who like to get their teeth into a problem at a quite technical level. The menu interface is sufficiently simple to be used by most users, but the advanced features may intimidate some.
AVP has on-demand and memory-resident scanners, an integrity checker, and a host of utilities. The action of the scanning engine is highly configurable, with options for heuristic analysis, scanning of EXE headers or entire files and so on. There are quick selection options for Fast versus Reliable scanning.
It also comes with a database editor that allows the user to add new virus signatures to the virus database. This is completely beyond the average user and tricky to do properly, even for the experienced. However, it may prove useful in the event of an infection by a new or unknown virus. The cynical network administrator may care to extract signatures from game programs and add them to the database.
Other utilities include a disassembler for examining active viruses, along with memory and interrupt probes. AVP can scan inside ZIP and ARJ archives on the fly, as well as properly interpreting the contents of packed EXE files.
The strategy used by AVP to block Word macro viruses is quite robust. It installs its own code as the macro to be executed when a new document is opened so that all documents subsequently opened are scanned for viruses. This is effective but the price may be too high for many usersóthe Word document wizard feature is disabled as an unfortunate side-effect.
The AVP documentation gives an astonishing amount of information on the methods used by AVP to detect viruses and recover from infections. It is hoped that this Glasnost does not make AVP a target for the virus authors.
Dr. Solomon's Anti-Virus Toolkit, produced in England by S&S International, comes in separate DOS, 16- and 32-bit Windows, OS/2, and NetWare versions.
This is the pick of the corporate products, combining a smooth interface with a high detection rate. S&S and their various national agents have a good reputation for technical excellence. The price of $150ñ$200 or so per workstation reflects this, but bulk rates may be more attractive.
Dr. Solomon's comes with an integrity checker as well as the usual on-demand and memory-resident scanners. The on-demand scanner, FindVirus, is particularly strong on the detection of polymorphic viruses. It can scan inside ZIP and ARJ archives, as well as scanning packed EXE files correctly.
One noticeable drawback is that scanning an infected disk can take several minutes, a source of much anxiety for the inexperienced user who may already be in a state of panic at the time.
F-Prot is produced in Iceland by Frisk International. The founder, Fridrik Skulason, is an authority on viruses and his expertise makes this simple, non-fussy program a very solid performer.
F-Prot comes with a memory-resident scanner called VIRSTOP and an interactive, menu-driven program called F-Prot that both scans and disinfects.
F-Prot performs signature-based scanning with an optional additional heuristic analysis. It can scan inside packed EXE files but not inside ZIP or ARJ archives. VIRSTOP is weaker than F-Prot on polymorphic viruses (by the author's own admission) but otherwise solid.
The strategy used by the F-Prot WVFIX utility to block Word macro viruses is different to that used by AVP. WVFIX also installs its macro code into a standard Winword macro name, but it is executed every time a document is saved rather than every time a document is opened. This means that it can protect against the macro viruses without interfering with the word document wizard feature.
At $1 per workstation for commercial use (with discounts of up to 75% for bulk purchases) and no charge for personal use, F-Prot is a steal. It means that cost is no obstacle to dependable antivirus software.
One of the longest established antivirus companies, McAffee Associates produce VirusScan. This has two elements: Scan, an on-demand scanner, and VShield, a memory-resident scanner.
There are a plethora of command-line options that make customization by batch files simple. The main drawback with VirusScan is its low detection rate for polymorphic viruses. At $50+ per workstation, it is not particularly cheap, and the cost is not justified by its poor performance.
Written in the Netherlands by Frans Veldman, TBAV consists of a number of separate utilities: on-demand and memory-resident scanners, separate memory, disk and file access behavior blockers, an integrity checker, and a signature extractor.
The scanner is exceptionally fast and achieves one of the highest detection rates, particularly for polymorphic viruses. The virus signature extraction utility is not something for the average user, but as with AVP, it may be useful.
Macintosh users have generally been spared the worst excesses of virus writers, perhaps in part due to the difference in cost of Macintosh and Intel-based hardware. Macintosh viruses certainly exist, however, and they are in wide circulation.
Without a doubt, the cream of the Macintosh antivirus programs is John Norstad's Disinfectant. It comes as a single application that consists primarily of an on-demand scanner but that has a menu option for installing a memory-resident scanner. Disinfectant is a solid program with a very high success rate.
Disinfectant is free. It is available from ftp://hyperarchive.lcs.mit.edu/info-mac/vir and from many other locations as well. Updated versions appear regularly. All in all, there is no excuse for having a Macintosh without solid antivirus software.
If the NetWare server is a PC, it can be infected by viruses like any client workstation. It has a boot sector and a DOS partition, and runs DOS for at least part of its working life. Once NetWare starts to run, DOS is no longer active.
Despite the fact that the server is vulnerable to virus attack only for the brief time it takes to boot up and load SERVER.EXE, it makes sense to protect it from viruses. As a minimum, check for boot sector viruses and scan the DOS partition regularly.
The real focus in server protection, however, is on the files on the network partition. As many of these files are accessed by a large number of users, it is particularly important that they be protected from infection.
These partitions are protected to some extent by features of the NOS. Access restrictions mean that only authorized users can access the server, and when they do so, they can only access designated files with pre-determined rights. It is particularly important that these rights be limited to the minimum necessary.
Assuming that users have write access only to files in a designated home area, it may be sufficient to have each user run a regular scan of their home area as well as their workstation. Files on the server are still files, after all, and can be scanned like any others.
The fact that files are stored on the server opens up another possibility, however. A server-based programóan NLM, in the case of a NetWare serverócan scan all files on any of its volumes at a time designated by the network administrator. It is not necessary for the user to initiate the scan or even to be aware of it. The NLM has full rights to all files.
This is not as comprehensive a solution as is offered by most workstation-based packages. An NLM does not run under DOS, and so it cannot perform any of the behavior-blocking functions employed to one extent or another by memory-resident utilities. Nor can it deal with boot sector viruses, the most prevalent type of infector in the real world.
It is also possible to make use of the fact that users log on to the server to verify that their workstation has the latest version of the antivirus software. This can be done using automatic distribution methods described or running a utility which verifies that the appropriate memory-resident scanner is active.
Don't load antivirus TSRs from the system login script! Loading a TSR while LOGIN.EXE is in memory leaves a hole when LOGIN terminates, wasting a substantial chunk of RAM.
A number of antivirus software authors now provide NetWare server versions of their scanner product. This generally consists of the scanner engine incorporated in an NLM. The administrator can schedule the times when scanning should take place, the details to be contained in the report file, and any users to be excluded from checks by the NLM.
Some offer extra features. Dr. Solomon's Anti-Virus Toolkit for NetWare, for example, can deny logons to workstations not running VirusGuard, the memory-resident utility. It can also be used to distribute updates of VirusGuard to the workstations. Another novel feature is the ability of the NLM to take control of the scanner on the workstation, getting it to scan the workstation's memory or hard disk and report the results. McAffee's NetShield is much simpler and includes optional integrity checking measures.
In summary, server-based scanners can offer an extra level of protection against viruses in a network environment. Automated scans of network partitions can pick up infections missed by users who do not scan their own files. But these NLMs are not to be relied upon as the only antivirus measure for a network. Workstations are where viruses are active, and where the thrust of antivirus activity should be.
Users of networked computers are potentially more vulnerable to computer viruses than are the users of stand-alone machines because infected files can be accessed so easily by many computers. The recent appearance of real macro viruses and their rapid spread across the world illustrates the potential for viruses to proliferate across a network if the necessary preventive measures are not in place.
The network can also be used to protect against viruses. Some of the best antivirus software can be downloaded from the Internet and file servers can be used to distribute antivirus programs within an organization. Using the network rather than floppy disks to share data helps to prevent the spread of boot sector viruses, the cause of most virus infections in the world today.
The existence of computer viruses is a reality for all computer users. Network managers must recognize this fact when considering the issues of access rights and security, while also being pro-active in introducing antivirus strategies for their user community. The network can be viewed as a medium for the spread of viruses but also as a tool in the fight against them.
