Don't panic! Indeed, don't do anything. Have a cup of tea or coffee don't start bashing away at the keyboard before you've determined what you ought to do. In my experience, a lot of the `damage done by viruses' is actually damage done by people doing things before they've made sure of what they ought to do, which is another way of saying panic. So, don't panic!
A virus is a program that copies itself. That's the definition of a virus. In retrospect, it's unfortunate that the word `virus' was used; it makes the problem sound a lot worse than it is, and people get the plural wrong [the plural is not `viri', or even `virii', it's `viruses']. It might have been better to use the word `weed'. But we're stuck with `virus'.
A virus need do no more than replicate in order to be a virus. Indeed, 95% of viruses do no more than that, plus some trivial extra like beeping the keyboard, or displaying a message. And conversely, if a program does something nasty that you weren't expecting, that doesn't make it a virus, unless it replicates. Such a program is called a `trojan', after the famous horse of Troy.
If a virus does nothing but copy itself, why do people get so worked up when they have one? For example, Form virus beeps every time you hit a key on your keyboard on the 18th of each month, so why does everyone who gets infected want to get rid of it? There are a few reasons for this. If you don't get rid of the virus, there is a strong likelihood that eventually you'll pass it on to a supplier or customer, who will be upset. Over 99% of viruses that actually spread 'in the wild' are memory resident, so there is the possibility of incompatibilities between the virus and some other program you are running [for example, Jerusalem tries to use one of the resources that Novell NetWare uses, so you can't run both Novell NetWare and Jerusalem on the same system]. In addition, even though we have analysed and documented the virus, the user might remain nervous that the virus does more than has been documented, or that he/she has a different version of the virus. So in almost every case that we have seen, people want very much to get rid of the virus [apart, sometimes, for keeping one specimen for a `zoo'].
If you do get rid of the virus, this is going to take time, and time is money. Each PC will take at least several minutes, and each floppy disk will take at least several seconds [and there may be a lot of floppy disks]. It would be nice if you only had to worry about those computers and floppies that are infected, but of course you don't know which ones these are until you've done the virus-hunt, so you have to check everything.
Bugs are not viruses, and viruses are not bugs. I am using a word processor that I know has a serious bug. If you work with a large file for a long time, then eventually something goes wrong inside the program, and it refuses to let you save the file to the disk, so that you lose all the work you've done since the last save. This program comes from a major software house, and they didn't do this on purpose, so it isn't a trojan. The programmers made a mistake. Programmers are human, and humans make mistakes. Programmers, like other humans, have pride, and don't like to admit that they make mistakes, so they call them `bugs', as if the bug had drifted in through the window and settled on the program. All sufficiently complex programs have bugs.
Anti-virus software does not detect bugs. If it did, it would report bugs in just about everything.
False alarms are not viruses. A false alarm is when you think you have a virus, but you are mistaken. Sometimes, people have some hardware or software fault, and after running some diagnostics, eliminate the possibility of hardware or software problems, conclude that it is therefore a virus, and proceed on that assumption. More often, a false alarm is the result of running anti-virus software.
Anti-virus software, in common with other software, is not infallible. The two main mistakes that an anti-virus program can make are to fail to find a virus that is there [I once tested a program that failed to find any boot sector viruses whatsoever, and these account for over two thirds of infections] or to claim that a virus is present when there isn't one, and that is called a false alarm.
When an anti-virus program gives a false alarm, it looks pretty much like the real thing.
There are a couple of things that might indicate that the alarm is false, though.
Unfortunately, there's no hard rule that can be applied. You can't say it's a false alarm if one of the four above is true, or if all four of the above are true. The only way to really nail down a false alarm is to send the suspect file to the product vendor giving the alarm, and ask them to verify that it is a virus by analysing it in their virus lab. And this might take some time.
Meanwhile, a false alarm can be as much hassle as a real virus, or even more. If you have a floppy disk that is infected with Stoned virus, you can simply copy the data off the disk and destroy the infected floppy, or you can get rid of the virus with your anti-virus program, or demand a replacement disk. Whatever, the cost is just a few seconds. But if you get an update of your favourite anti-virus program, and it tells you that you have Stoned virus on one of the files on your file server, then resolving the situation will take longer. You know and I know that Stoned cannot infect files. But just maybe someone has written a file virus and someone has decided to call it Stoned [for example, there are two unrelated viruses, one called Parity and the other called Parity.b]. So, you send the file to your product vendor for analysis and comment. Meanwhile, to be safe, you remove the file from the server [or possibly the product is barring access to that file]. This might mean that some important system won't work any more, as it needed that file. It also means that you have to keep track of the response to the problem, report it up through the usual security breach reporting channel, and so on. You might try deleting the offending file and re-installing the software that is causing the false alarm, but when you've finished doing that you still get the false alarm.
It isn't surprising that some people have changed their anti-virus software after too many false alarms.
Anti-virus software does not detect false alarms. If it did, it wouldn't report the false alarm, would it?
A joke is something that is funny. Of course, what one person finds funny is not the same as what another person finds funny. It depends on your sense of humour. Consider a program that pretends to format your hard disk, and then reveals that it hasn't. Is that funny? It depends on your sense of humour.
Some people love to play practical jokes, and on certain dates one must apply a little scepticism to alleged virus reports. Some anti-virus software detects jokes, and tells you 'You have a joke called . . .'. The reason for this, is that some jokes are fairly widespread, and are known to cause concern, so the anti-virus program is trying to calm things down, by saying `Yes, I know about this, and it's harmless'.
A trojan is a program that does something more than the user was expecting; and that extra function is damaging. This leads to a problem in detecting trojans. Suppose I wrote a program that could infallibly detect whether another program formatted the hard disk. Then, can it say that this program is a trojan? Obviously not if the other program was supposed to format the hard disk [like FORMAT does, for example], then it is not a trojan. But if the user was not expecting the format, then it is a trojan. The problem is to compare what the program does with the user's expectations. You cannot determine the user's expectations for a program.
So, we have to make some judgments. The Aids Information Diskette is generally considered to be a trojan. About 20,000 copies of this were mailed to users in 1989, purporting to be a program that teaches you about the Aids virus. In fact, it was a trojan; after you re-boot your computer 90 times, it encrypts and hides all the filenames on your hard disk, and demands that you pay for your licence to use it. Although the documentation that came with it told you that something bad was likely to happen, it is generally considered to be a trojan. FORMAT is not a trojan.
As a rule, you don't see trojans very often. They don't copy themselves, and don't spread in the way that viruses do. Trojans are not a real threat, except in one of the following circumstances.
Some anti-virus products detect a few trojans [such as the Aids one], but most products don't detect trojans at all.
Some files are simply corrupted [perhaps by a hardware problem], and hang the computer when run. For some reason, these sometimes end up in virus collections, unless the collection is carefully maintained.
Some virus authors are less skilful than they would like to be, and write what is clearly intended to be a virus, but for some reason there is such a major bug that the virus does not work at all. They release these, however, in the fond belief that no one will ever test them [or perhaps they didn't test them themselves]. One typical mistake is to get confused about decimal versus hexadecimal, and so their source code presumably says `int 21' for the DOS function interrupt, but it should have said `int 21h' [which is 33 in decimal].
A dropper is a program that is not a virus, nor is it infected with a virus, but when run it installs a virus into memory, on to the disk, or into a file. Droppers have been written sometimes as a convenient carrier for a virus, and sometimes as an act of sabotage. Some anti-virus programs try to detect droppers.
A germ is an instance of the virus in generation zero, and in such a form that the infection could not have happened naturally. For example, a virus that only infects files larger than 5Kb, but infecting a tiny 10-byte file. Alternatively, it might be an instance of the virus without any host file. If you remove the virus, you are left with a zero-byte file. This is the original file created by the virus author.
The commonest kinds of virus are boot sector viruses [BSVs], such as Form or Stoned. These infect the boot sectors of floppy disks, and either the partition sector [Master Boot Record, MBR] or the DOS boot sector [DOS Boot Record, DBR] of hard disks. Here's how a BSV spreads.
A floppy disk has just arrived, with some data on it [some word-processed files and a spreadsheet, perhaps]. This is part of a project that you are doing jointly with a colleague. What your colleague doesn't know is that his computer is infected with a BSV, and therefore so is the disk he sent you. You put the disk in drive A and start using these files. So far, the virus hasn't done anything. But when you finish for the day, you switch off the computer and go home. Next day, you come in and switch on. The floppy disk is still in drive A, so the computer tries to boot up from this disk. It loads the first sector into memory and executes it [normally, this is a little program written by Microsoft to load DOS; or if it can't find DOS on the disk, to tell you so - `Non-System disk, or disk error. Replace and press any key when ready']. Everyone has seen this message numerous times, and so you open the drive door and press a key.
But this disk is infected with Stoned, so what executed was not just the program by Microsoft, but the Stoned virus, written in 1987 in New Zealand [and so sometimes called the New Zealand virus]. The virus installs itself on the hard disk, replacing the MBR, and copying the original MBR to a place a little further down the disk.
When you start up from the hard disk, the MBR runs, but this is Stoned virus. Stoned virus goes memory resident, capturing the disk read/write interrupt 13h, and then it loads the original MBR, and the boot-up process continues as normal. But, since the disk read/write interrupt is captured, every time any write or read access [you think you're making a read, but the virus decides to write anyway] is made to drive A, the floppy is examined, and if it is not already infected, Stoned virus is installed on the boot sector. Thus, your computer is now infecting every disk put in drive A, and sooner or later one of these will be sent to a colleague, and the cycle continues.
The detail of various BSVs is different, but the principle is the same. They are carried by the boot sectors of infected disks, and only in that way [a BSV cannot spread across a network, for example]. And the only way to get infected is to try to boot from an infected disk, even if the boot fails.
BSVs infect PCs. They don't care what operating system is running, or what security software is installed, because at the time the BSV installs itself the operating system or security program is not running yet. However, with some non-DOS operating systems for example, Windows NT, or OS/2], although the PC is infected the virus cannot copy itself on to subsequent disks and cannot spread. It can, however, still do damage, as was discovered by one surprised UNIX user when Michelangelo triggered on 6 March.
To most people, the fact that viruses can infect in this way comes as a big surprise, which partly accounts for BSVs being so common.
Macro viruses [such as WM.Concept], the latest virus development, seem likely to become a significant threat, for several reasons.
Macro viruses have already had a marked effect. WM.Concept currently accounts for around 50% of all virus reports to our Technical Support department. And while WM.Concept causes no damage to data, we have already seen the first [albeit faltering] steps towards macro viruses which threaten data; one payload of WM.Nuclear, for example, is to attempt to damage the system files [this payload is never delivered, due to a bug in the code].
Macro viruses are not confined to Microsoft Word for Windows. In January 1996, the first macro virus to infect Lotus AmiPro files [APM.GreenStripe] appeared. Unlike Word for Windows, in which macros are directly linked to DOC [and DOT] files, AmiPro macros are contained in a separate file [with the extension SMM]; this makes it possible to exchange AmiPro documents [for example, via e-mail] without exchanging infected macros. And XM.Laroux, which appeared in July 1996, is the first working macro virus to infect Microsoft Excel for Windows spreadsheets.
TSR file viruses are no longer common. As the name suggests, these infect files. These are usually COM and EXE, but there are some device driver viruses, and some viruses infect overlay files; executable programs don't always have the extension COM or EXE, although over 99% do.
For a TSR virus to spread, someone has to run an infected program. The virus goes memory resident, and typically looks at each program run thereafter and infects it if it is not already infected. Some viruses are called `fast infectors', and they infect if you just open the file [for example, a backup might open every file on the drive]. Dark Avenger was the first 'fast infector'. In the case of Green Caterpillar, the infection trigger is anything that determines what files are present [such as DIR]. Other triggers have been used, but the commonest is to infect each program that you are about to run.
It is much easier to write a non-TSR virus, and so many of the budding virus authors do so. But it is quite rare for such a virus to be encountered 'in the wild'; less than 1% of reported outbreaks are a non-TSR virus. With such a virus, running an infected program runs the virus, which at that time looks for another file to infect, and infects it. Vienna is the commonest non-TSR virus; Vienna was the first file virus 'in the wild', but now has the status of 'rare'.
There are a lot of viruses based on Vienna, because a disassembly [which is almost equivalent to source code] was published in a book in 1987.
If you have a COM file and an EXE file with the same filename and type that name, DOS runs the COM file in preference to the EXE file. Companion viruses use this feature of DOS. Each EXE file that you have acquires a companion COM file with the same name. Then, when you try to run your EXE program, actually the COM program runs, and that is the virus. When the virus has finished doing what it wants to do [such as creating another companion for another file], it then runs the EXE program, so that everything seems to work normally.
There have been a few successful companion viruses, but not many. The main advantage to the virus author is that because the EXE file does not change, some change-detection software might not realise that a virus is spreading.
Another type of companion is the `path companion'. This sort of virus puts a program in a directory that is earlier in the DOS PATH than is the victim. When you run a program that is not in your current sub-directory, DOS searches for the program in various sub-directories, as specified by the PATH command in your AUTOEXEC.BAT file. Path companions are harder to write than ordinary companions, so there aren't many of them.
An overwriting virus simply overwrites each file it infects with itself, and the program no longer functions. Because this is so glaringly obvious, overwriting viruses are never successful in spreading.
Some viruses, such as Tequila, infect multiple objects. When you run a Tequila-infected EXE, Tequila installs itself on the MBR. When you boot up the computer, Tequila runs from the MBR, and goes memory resident. While Tequila is memory resident, it infects EXE files. Other viruses, such as some of the versions of Anticad, infect COM, EXE and MBRs interchangeably. Some viruses infect COM, EXE, MBRs and device drivers.
There is a virus that infects OBJ files. There is a virus [Starship] that infects by creating a new DBR, leaving the old one intact, leaving the code on the MBR intact, and changing the pointer in the MBR so that the Starship DBR is executed before the original DBR.
There are other viruses [DIR II and Dir.Byway] that infect file systems by changing the FAT and directories so that files on the hard disk are all cross linked to the virus.
There are all sorts of ways of skinning this particular cat.
As explained above, a 'fast infector' spreads rapidly within a computer by infecting everything that is accessed. A fast infector isn't as bad as it sounds; it is just as easy to clean a computer with 1,000 infected files as one with 10, provided you have an anti-virus program that does a good cleaning job. However, most anti-virus products check memory for viruses, and the possibility of a fast infector in memory is one of the reasons why. If there is a fast infector in memory, and the product opens all your files, you wind up with every file on the computer infected.
The opposite of a 'fast infector' is a 'slow infector'. The idea here is that if the virus spreads slowly, you're less likely to notice it and kill it. There are various ways that a slow infector can work, but the classic slow infector works by only infecting those files that you had intended to change anyway. This means that if you are running a change detector as an anti-virus measure, the change detector will trigger each time there is an infection, but since you had intended the file to change anyway, you'll tell it to accept the change.
Starship is another way of doing a slow infector. It only infects files as you copy them from your hard disk. So no file on the hard disk ever changes, and the change detector is happy. But when you copy a file to a floppy disk, the copy is infected, and when you take this to another computer protected by the change detector, the change detector warns you of the existence of the new file. You will then reassure the change detector that you knew about the new file, and the change detector is happy, and another system is infected.
If a virus is memory resident [as are over 99% of viruses 'in the wild'], then it has hooked at least one of the interrupts. If it is a BSV, then it has hooked the disk read/write interrupt 13h. If it is a stealth virus, and any program that tries to read the boot sector, then the virus says `Aha, someone wants to see the boot sector; I'll just read the original boot sector from where I put it, and present that instead'. So the software sees nothing out of the ordinary. Brain, vintage 1986, was the first virus that used this trick. File viruses can use a similar trick to disguise their presence, so that any software reading the file only sees the bytes that were there before the virus came along. Frodo is an example of this. It is much commoner to see stealth in BSVs than in file viruses, as it is much easier for the virus author to implement stealth in a BSV.
The commonest kind of anti-virus program that people use is the scanner, looking for a repertoire of viruses. So for the virus author this is the kind of product that he would most like to defeat. A polymorphic virus is one where if you take two instances of the virus, there are no bytes in common between them, so you cannot write down a byte-sequence and go looking for that in order to detect the virus. You have to do something a lot more complex and difficult.
We can categorise the damage done by viruses into six groups, according to the severity of the damage. Some authorities postulate the possibility of a virus that actually does good, but no one has yet demonstrated such a virus.
We define damage as: the virus does something that you'd rather it hadn't done. And we quantify damage by measuring how long it takes to put things back the way they ought to be.
We don't include consequential damage in this categorisation [damage done by the user in a mistaken attempt to get rid of the virus]. It is remarkable how many people will format the hard disk to get rid of Stoned, for example. All this does is get rid of all your data. The virus is untouched, as it resides in the MBR, which is not touched by FORMAT. Nor can we include damage done by obscure incompatibilities between the virus and the system. For example, if a computer that was originally set up under DOS 2 [but is now running a later version of DOS] is infected by Stoned, then a large number of files will be corrupted because the design of the virus had not anticipated this situation.
This is done by a virus such as Form [once the commonest virus in the world]. On the 18th of every month, each key that you hit makes the speaker beep. All you need to do is to get rid of the virus. This will usually take seconds or minutes [per computer].
A good example of minor damage is the way that Jerusalem virus deletes any program that you try to run after the virus has gone memory resident, on Friday the thirteenth. At worst, you will have to re-install some programs, so the damage is unlikely to be more than 30 minutes per computer.
If a virus formats the hard disk, scrambles the FAT or overwrites the hard disk, this is moderate damage. The damage is only moderate because you know that it has happened, and you can re-install DOS and re-load yesterday's backup, because you do a backup every day. So, you'll lose on average half a day's work, plus maybe an hour doing the re-install and restore. The virus most famous for moderate damage is Michelangelo.
This is where a virus hits your backups as well as your hard disk. Every 16th time that a Dark Avenger-infected file is run, it overwrites a random sector on the hard disk with `Eddie lives . . . somewhere in time'. This might have been going on for several weeks. You discover Dark Avenger, get rid of the virus, and find `Eddie lives . . .' at several places in several files. You restore yesterday's backup, and find `Eddie lives . . .' in those as well. You might have to go back a few weeks before you can find clean data files, and when you've restored a six week old backup, you'll find that you don't actually have any way to redo that work, because you don't have the original documents to work from.
Severe damage is done when a virus makes gradual and progressive changes [so that backups are also corrupted], but the changes are not obvious [there is no `Eddie lives' to look out for]. You wind up simply not knowing whether your data is correct or changed.
Some viruses [such as Cheeba, Vacsina.44.login and GP1] aim to get the system manager password and pass it along to a third party. In the case of Cheeba, for example, it creates a new user with maximum privileges, with a fixed user name and password. The damage is then done by the third party, who can log in to the system and do anything he/she likes.
It seems to be a common belief that viruses are spread by games, by shareware or by BBSes. The truth is more complex. First, remember how the most common sort of virus, boot sector viruses, work. A physical floppy disk has to be involved, and there doesn't need to be any software on it. You cannot get a BSV by using a BBS.
The most likely routes by which a virus gets into an organisation are engineers and parents.
Other ways of getting a virus include:
in shrink-wrapped software [some of the largest companies have accidentally shipped a virus in shrink-wrapped software]; along with purchased hardware [most hardware comes with disks containing utilities or drivers]; salesmen running demos could unwittingly install the virus they picked up from the last place they ran their demo.
We recommend that everything be virus checked before it is used. This includes floppy disks with data on [remember BSVs] as well as software. This could be done using a scanner such as FindVirus, which could be installed on every computer [for convenience, because if it isn't convenient, it won't get done] or it could be installed on designated 'sheep-dip' computers, which is more convenient for the PC Support people to keep up to date, but less convenient for the users. Alternatively, you can make the whole thing as transparent and painless as possible by installing an on-access scanner, such as VirusGuard [DOS] and/or WinGuard [a VxD for Windows 3.x, Windows 95 and Windows NT]. This means that everything is automatically scanned without the user being aware of it [unless, of course, a virus is found]. The on-access scanner is the route that most people choose, together with some dedicated 'sheep-dip' machines.
Linda had worked in her job for some years. She occasionally took work to do on her home PC, with the knowledge and approval of her supervisor. One day, the PC Support department found a virus on her office PC. Later the same day Linda was fired for bringing a virus on to the premises.
Linda was very upset at what she saw as unfair dismissal and sued the company. She won, because the company she worked for had no rules to tell employees what to do [so she hadn't broken any rules]. Although they had anti-virus software, there were no procedures for checking incoming disks [so she hadn't failed to carry out company procedures].
On investigation, it looked highly likely that the PC Support department had accidentally infected her machine, and only discovered it when they sent disks, copied on Linda's machine, to another company, who did check for viruses and found one on those disks.
If such procedures had been in place and Linda had ignored them, then the company would have had a good reason for firing her. Of course, with proper rules and procedures, they would probably not have been infected by a virus in the first place.
But you have to acknowledge the fact that people behave the way that they do. If you make your anti-virus procedures onerous and difficult, they'll quite likely be ignored on the grounds that viruses are very rare, and the cost and hassle of the procedures is too great.
A good set of rules might be as follows.
Notice that the rules are very simple. That way, people are more likely to remember and follow them. The next thing you need is procedures. The procedure tells the users how to obey the rules. The procedure for checking disks should be written down in detail ['Put the floppy disk in the drive, and type . . .']. If you have a 'sheep-dip' computer, put the procedure up on the wall near to it.
Education is also important. You can't just tell grown-ups to do something and expect that they'll obey without question. You have to explain the reason to them. You can do this with talks, or by getting the Dr Solomon's 'Virus Video' and letting them watch it.
You also have to provide tools. You can't detect a virus with your bare hands. Any sensible anti-virus strategy must take account of the fact that even 'well-educated'users are fallible; and that they will circumvent even the best rules and procedures [either wittingly or unwittingly . . . remember that security is not the primary concern of staff who work in Sales, Marketing and other departments within an organisation]. The foundation of any comprehensive anti-virus strategy, therefore, must be anti-virus tools which will effectively detect, remove and prevent virus infection . . . even when the rules and procedures have not been followed.
A scanner is a program that knows how to find a particular repertoire of viruses. Scanners are updated, quarterly or monthly. For many users, quarterly upgrades are sufficient, but every now and then, a new virus comes out and spreads very fast [such as Tequila, or SMEG]. In that case, you could be unable to detect this 'in the wild' virus for several weeks, depending on where you are in the update cycle. So, many people subscribe to monthly upgrades to avoid this situation.
Scanners can be either on-demand, or on-access. FindVirus is an on-demand scanner, and must be run by the user [although this could be done automatically, at start-up, from the AUTOEXEC.BAT; or using a scheduler].
VirusGuard [DOS] and WinGuard [Windows 3.x, Windows 95 and Windows NT] are on-access scanners, and work continuously. As soon as any disk is accessed, it is checked for boot sector viruses; and as soon as any file is used, it is checked for file viruses. Both programs may be [optionally] configured to check files as they are written to the hard disk [useful if files are being downloaded from a remote site, such as a BBS, or the Internet]. VirusGuard occupies approximately 9Kb of conventional [DOS] memory; WinGuard, which is a Windows-specific program uses zero conventional memory. Any additional time-overhead involved in checking the disk or file is unlikely to be noticeable in most cases. VirusGuard, a DOS TSR program, does not have the full facilities of FindVirus [for economy in memory consumption and time-overhead]; specifically, VirusGuard is not able to find macro viruses [which do not work under DOS anyway] and a small percentage of extremely polymorphic viruses [VirusGuard will find polymorphic viruses in memory, if an infected program has been run]. WinGuard, which does not have the constraints of a DOS TSR program, has the same detection capability as FindVirus.
A checksummer is a change detector. Executable files should not change, except for a good reason, such as updating of software. A checksummer aims to detect changes. The advantage of checksummers is that they do not detect a repertoire of viruses, so do not need updating. The downside of checksummers, is that they are more hassle than scanners [files change on your computer more often than you might have thought, for good and valid reasons], and they do not detect all viruses. For example, checksummers do not detect 'slow infectors'; they do not detect all boot sector viruses [if the hard disk code is left unchanged]; and they have problems with stealth viruses. Some people use checksummers, but they are a minority.
Checksummers can be on-demand [like ViVerify], or on-access.
A network is a group of computers connected together to make it easier to share data. This provides interesting opportunities for viruses, and for dealing with viruses.
There is a common perception that once a virus gets on to a network, somehow it flashes round the whole network very quickly. The truth, of course, is more complex. Firstly, BSVs cannot travel across networks. If several machines on a network are infected, that's because the virus spread via floppy disks in the usual way. Here's how a file virus spreads across a network.
70% of networks use Novell NetWare, so we'll use that as an example, but you can adapt the same principles for other network operating systems.
Unfortunately, some packages can't be run from read-only sub-directories, because they want to write to configuration, or temporary files, in the same directory.
Using a combination of the three techniques above, you should be able to make a large percentage of the files on the server uninfectable [indeed, unchangeable without Supervisor intervention]. This stops viruses infecting most of the executables on the server.
Unfortunately, the important files on the server are the data, and you haven't protected those. The user has read/write access to the data [he/she needs it to do their job], and so the virus also has read/write access to the data. Deleting files is the least of our worries. Consider that some virus damage routines consist of altering files. So how do we protect the data on the server? The only answer is to keep viruses off the workstation as well.
The next thing you can do, if your server is running Novell NetWare, is run an anti-virus NLM [NetWare Loadable Module] on the server. This can be scheduled to check the files on the server. The use of a server-based on access scanner [such as the File Access Monitor in Dr Solomon's Anti-Virus Toolkit for NetWare] provides a multi-layered defence against virus infection, checking files as they are passed to and from the workstations. In addition, users can be denied access to the server unless their workstation is protected.
Similar protection is available for Windows NT. Dr Solomon's Anti-Virus Toolkit for Windows NT offers comprehensive protection for workstations and servers. FindVirus provides on-demand scanning; and a Scheduler, to check the system at pre-defined times. Winguard for Windows NT provides constant background protection, checking files and disks before they are accessed.
If your server is LAN Manager or LAN Server, you can run an OS/2 version of the anti-virus program on the server.
[Back to index] [Comments (0)]