Date: Wed, 12 Apr 1995 20:01:51 +0300
From: netz@actcom.co.il (Zvi Netiv)
Subject: Appendix A, revised.


As the network features of InVircible have been significantly improved,
and I am not sure that you have had the time to look into the manual's
updates on this subject, then here is the revised appendix A, for your
convenience. Note the simplification in the daily inspection (no batch
needed anymore), also note the new paragraph about rejecting logon from
an infected workstation.

Regards, Zvi

============================================================

Appendix A. - LAN Protection

The following describes how to implement InVircible for the protection
of local area networks (LAN).

At this date, there are no known viruses that affect the operation of
Novell's Netware software. Yet, DOS viruses may affect executable and
non executable DOS objects, stored on file servers. An infected object,
such as a DOS shared application, when executed, can further spread the
infection, from one workstation to another networked station. 

As a general rule, boot and MBR infectors, excluding multipartite ones,
will not propagate through the network from one station to another. The
effects of such viruses are retained locally and will not extend outside
of the affected workstation. A file server can even be started with its
MBR infected by Stoned or Michelangelo, and none of the other stations
will suffer anything or even notice there is something wrong with the
server hard disk!

On the other hand, many file viruses can survive the Netware login
process, or become active when already logged onto the network, and
infect files on either the local disks, or on the file server.

Virus Propagation in a Network.

File viruses are usually categorized as direct action viruses and memory
resident viruses. Some memory resident viruses are also known as "fast
infectors" or piggybackers. All three terms refer to the propagation
mechanism of file viruses. Direct action viruses infect additional
file(s) every time an infected file is executed. Since the virus is not
memory resident then the infection of more files will not occur on the
execution of a program that is not actually infected. The criteria and
pattern upon which additional files become infected can be anything:
i.e. infecting files in the current directory, down the directories
tree, along the DOS search path, at random etc.

Memory resident viruses usually load into the workstation's memory, when
the first infected file is executed. It doesn't matter where from it is
executed, either from the local disk, or from the remote disk of the
file server. From then on, any file that will be executed and fits the
infection criteria of the particular virus (that is now
memory-resident), will become infected itself. Many memory resident
viruses have a direct action mode of infection too, in addition to the
memory resident infection mode, as described above.

Piggybackers are memory resident viruses that will infect any file that
is "opened" or "closed" by the operating system. The programs that are
the most likely to become carriers of fast infectors are virus scanners
of all sort, as these programs are the only ones that "open" and "close"
every single program on a drive, while scanning them! It is thus
essential that antivirus scanning programs, whether scanners or
integrity checkers, be equipped with anti piggybacking features. For the
moment, only InVircible has this ability. 

It's reasonable to assume that all programs that were loaded to a file
server were clean from viruses at the time they were loaded. Then how
come that later on, some of these programs become infected? The answer
is simple: An infection that originated from one of the workstations
found its way to an application on the file server. If another
workstation called and executed the infected program on the file server,
then that station's memory - and eventually its hard disk - will become
an additional source for the spreading of the virus. Later on, the newly
infected station will infect additional applications on the server.

The most common pattern of how massive infections occur on file servers,
and spread across the network to all workstations, is because of unaware
network supervisors and the excessive use of virus scanners! the
classical scenario is as follows: A new virus manages to infect a
workstation. Most network managers unjustifiably rely on their
scanner(s), anti virus TSR and on antivirus NLM. Being misled by a false
sense of security, they overlook and reject the possibility that the
scanner itself may be the source of an infection. Over self-confidence
and ignorance are usually the excuse for not implementing better
antivirus means than NLM scanners and TSR. Sooner or later, the
supervisor will log-in with full read-write rights (supervisor or not
?!) and scan for viruses with a piggybacked scanner. The results are
obvious.

The lessons to be learned are:

1.      Since virus infections in network always start from a
workstation, then workstations should be checked for virus presence
prior to connecting to the network. Especially those PC that have local
hard disk, as their chances to become infected are infinitely higher
than those that boot from a network startup floppy, or from ROM-DOS.
Antivirus that are initialized from the network, upon login, are stupid,
insufficient, and worthless. The same applies to NLM too.

2.      Virus scanning of file servers should be run sparingly and with
utmost precautions. Since piggybacking cannot be sensed on file servers,
for technical reasons, then scanners should always be tested first on a
local hard disk (never from a floppy) to give a piggybacker the
opportunity to disclose its own presence. Only piggybacking resistant
scanners should be used on file servers, unfortunately there is only a
single such product on the market - IVSCAN from the InVircible package.

Antivirus Protection in a Networked System.

The strategy of how to protect a networked system from virus attacks
consists of a few simple steps.

First, have InVircible installed on all stations that have a hard disk.
This way, every such station will be verified before the station has a
chance to connect to the network and can contaminate the server. To
facilitate the task, InVircible can be installed directly from the file
server, to workstations having a hard disk. IV is provided with the
IVLOGIN.EXE program. All that the supervisor need to do is to install IV
into a dedicated directory on the server and invoke the IVLOGIN program
from within the users login script. The following explains how to do it
in a Novell network, every LAN manager knows how to adapt it to his own
network brand. Suppose IV was installed to F:\PUBLIC\IV. Run SYSCON and
select "Supervisor Options" from the menu, then select "User LOGIN
Script". Add the following line into the script:

	# F:\PUBLIC\IV\IVLOGIN.EXE

Rejecting the Login of an Infected Workstation

IVTEST can be used to verify at login whether a workstation is virus
free and accept or reject its logging in. IVTEST will exit with an
errorlevel equal to zero only if nothing viral was found. The network
administrator can use IVTEST in the system, or in the user login script.
In Netware systems, add a command line as follows:

	# F:\PUBLIC\IV\IVLOGIN.EXE
	# C:\IV\IVTEST.EXE /Q
	# IF ERRORLEVEL 1 GOTO ... 

The first line assures there is an installation of InVircible on the
hard drive, as in the former paragraph. Next, IVTEST is invoked from the
hard disk, in the quiet mode (no display to screen, unless there is a
finding), and finally the exit code is compared to 1. If affirmative,
then the system administrator can branch the script to wherever he
likes, for example: Report the infected station, alert the Help-desk,
issue a printed report, issue e-mail to users, and refuse logon.

Daily Inspection of the File Server

Instead of virus scanning, better is to secure and verify the file
server content with IVB, the integrity analyzer and generic restorer.
This can be done by issuing the command:

IVB F: DAILY

It is recommended to run InVircible's Off-line Backup periodically, once
a week, or twice a month. The Off-line Backup will produce a copy of the
directories tree on floppy, with their respective signatures files, in
case these were lost or tampered with. See elsewhere in this manual for
how to run the off-line signature's tree backup.

Cleaning a File Server from a Virus Attack.

Whenever a virus is detected in a network, then act in an orderly way.

While the virus is still active, try to obtain good virus samples on
your local disk. Start by making sure that the COMSPEC points to the
local disk (type SET to verify where to the COMSPEC variable points).
Correct if necessary by typing SET COMSPEC=C:\COMMAND.COM. Run C:
\IV\IVTEST, from the local disk. If lucky, IVTEST will generate two
samples: Vir-Code and Virusam.ple. These will be valuable later,
especially if the infection was caused by a variant or a new virus.

Now proceed with the disinfection of the local disk. Use the rescue
diskette if necessary. Try to locate the source of the infection on your
own local disk by correlating with IVX. Consult the IV documentation if
needed. During the disinfection of the local disk, learn the
characteristics of the virus. If known by IVSCAN, then it's simple. If
new or unknown to IVSCAN, then use IVB and note which type of files it
infects (COM, EXE, SYS, OVL etc.), and what's the virus size. With IVX
and the virus samples, find out what are the best correlation parameters
to easily find all infected files, eliminating "noise" (detection
threshold, correlation to Vir-Code and Virusam.ple, level of
correlation, relative weight of statistical fitness, crypto model and
string matching).

When the local disk is totally clean, login to the network manually
(execute the login batch line by line). Avoid the execution of any file
from the server itself. Now assess the extent of the virus spread on the
server by using IVSCAN (for viruses contained in its database), IVB and
IVX. Before cleaning the server, shutdown all workstations in an orderly
manner. All stations should be switched off, since the virus might still
be memory resident. All the stations with hard disk should be
disinfected individually before hooking them again to the network. 

The file server should be restored and cleaned in the following order.
First use IVB/R for the fastest and best restoration of affected
programs (provided they were secured beforehand). Next use IVSCAN /R, if
the virus is known to IV, to restore those files missed by IVB (no
signatures). If the virus is unknown to IVSCAN, then correlate with IVX
to find out all files missed by IVB. Either rename the suspected files
or delete them. Both options exist in IVX. Print the IVB/IVSCAN/IVX
reports after each step. You may need to delete a few files that IVB
could not restore, by using IVB/D.

Replace the files that were renamed or deleted by IVB/IVSCAN/IVX (as in
the reports' printout). Restart the network and resume operation.

The methods described above should let you to resume network operation
even after severe virus incidents, within half an hour to a couple of
hours, while it could take a couple of days to a couple of weeks by
other means.

======================================================
-------------------------------------------------------------------------
Zvi Netiv, author InVircible NetZ Computing Ltd, Israel Fax +972 3 532
5325 email: netz@actcom.co.il antivir@netcom.com CompuServe `GO
InVircible' ftp.datasrv.co.il/pub/usr/netz/
ftp.netcom.com/pub/an/antivir/invircible/
-------------------------------------------------------------------------