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/ -------------------------------------------------------------------------