OS/2 Shareware BBS: Security/Security.zip/tbos707.zip/TBAV.FAQ

Text File | 1997-01-10 | 13KB | 248 lines

This is a list with Frequently Asked Questions.

If you have a question about our product, or want to know why our product
differs from some competitive products, please check out the questions
below.

Design philosophy
-----------------

Why does TbSetup create an Anti-Vir.Dat file in every directory,
instead of generating just ONE reference file for the entire system?

        1) It is more intuitive. For a user it is much easier to see
        whether a directory is already processed by the checksummer or
        not. You can see in one glance what the last time was you
        modified the Anti-Vir.Dat file, and whether this matches with
        the most recent timestamp of the executable files.

        2) Maintenance. If you delete an entire directory, the checksum
        base will be gone too. Automatically! With a single file
        approach, you will have to run an update utility or to accept
        that the database file will continue to grow for ever. The same
        applies if you move a directory to another disk or
        subdirectory: don't worry about the checksum files. They will
        travel automatically wherever the executable files go!

        3) Security. If a company decides to introduce a new software
        product, they can make a backup of the diskette, scan it for
        viruses, and put the checksum file on the diskette, and
        multiply it and distribute it within the company. Now, whoever
        gets this diskette, the checksum file will already be there.
        The user won't have to bother with it himself. The new checksum
        file with not interfere with the already existing ones.

        4) Networks. In a LAN, different users may have access to a
        directory via another path. One user may see the directory
        F:\JOHN, while someone with more access rights may refer to the
        same directory as G:\USERS\JOHN. With a single database
        approach, you will have to create a separate database for every
        user. With the checksum-file-per-directory approach, the
        supervisor just creates ONE checksum base per directory, and no
        matter the access rights or mappings of a specific user, if he
        has access to that directory, he automatically has access to
        the checksum file. So, if the supervisor updates a product on
        the network, he just creates a new checksum file for that
        directory, and EVERY user on the network immediately has the
        correct checksum information.


Why does TbScanX not scan a file if I rename it, or when I move it to
another directory?

        If you rename an executable file to another executable file, you
        actually do not introduce a new file on your system. The file
        was originally already there, and should have been checked by
        TbScanX already when the file was introduced on your system.

        If you rename a non-executable file to an executable file, you
        actually introduce a new executable file on the system. This
        quite unusual way to introduce a new executable file on the
        system is detected by TbFile (attempt to rename a non-executable
        file to an executable file).

        If you move a file to another directory, using the 'move'
        command, the file doesn't get actually copied when the
        destination drive is the same as the original drive. What
        happens is that the file gets 'renamed' to a different
        directory, i.e. the file remains physically where it is, but
        just the name reference is moved from one directory to the
        other. TbScanX does not scan the file in this case, because the
        file was already there, and has been checked when it got
        introduced to your system, and doesn't need to be checked again
        just because it is moved to another directory.


Why does TbScanX, unlike some other products, not scan a bootsector if
you press Ctrl-Alt-Del?

        First of all, TbScanX scans a bootsector immediately if you try
        to access a diskette. Most people insert a diskette because
        they need a file from it, or want to copy something on it, or
        just look into the directory. TbScanX will then check the
        bootsector, long time before you press Ctrl-Alt-Del. So there
        is not much need for TbScanX to check it when you reboot, the
        job has already been done.

        A second reason is that it can be dangerous to scan a diskette
        while trying to reboot. You usually don't reboot just for fun!
        In many cases, you reboot because the system became instable,
        or because a program instructed you to reboot the system, after
        it changed some vital information on the harddisk. If the
        system became instable, you can damage data by accessing a
        disk, and it is quite questionable anyway whether an instable
        system is still able to perform a reliable disk scan. If a
        program asks you to reboot, the reboot is often necessary
        because the system is not aware of some changes in the
        configuration, and it is dangerous to continue accessing the
        disks, without - for example - the appropriate drivers.

        A third reason is that it could cause people to believe that
        rebooting with a diskette inserted into the drive is OK,
        because the diskette will be scanned anyway. Unfortunately,
        checking a diskette can only be done before a SOFT boot, and
        not when you hit the reset button. It is only a partial
        solution. For many people, the difference between a hard and a
        soft boot is not clear, and they will just assume that rebooting
        with a diskette inserted is now always safe.

        So, it is dangerous, unreliable, confusing, and unnecessary in
        most cases. Therefor we decided not to scan a diskette after
        pressing Ctrl-Alt-Del.


Why does TbClean not clean ALL files at once?

        Let's look what happens if your system is infected by a virus,
        and you run an 'automatic' cleaner on it. With one and the same
        virus, every executable file will be in one of the following
        states after the cleaning is terminated:

        1) Files that have not been affected by the virus at all.
        2) Files which were infected but have been successfully cleaned.
        3) Files that have been damaged (not infected!) by the virus and
        can not be 'cleaned' because they have been deleted or are
        overwritten.
        4) Files from which the cleaner says that they have been
        successfully cleaned but still don't work anymore (because of
        copy protections or various other reasons).
        5) Files from which the cleaner says that it failed to clean and
        thus are still infected and need replacement.

        Now, are you going to sort things out after the cleaner is done?
        A much better approach is to work through the files on a one by
        one approach. Clean one file, judge the result, test the file,
        and proceed with the next one. Tedious? Yes, an even better
        approach is to take that backup tape, and restore all executable
        files.

        Remember, viruses are not written to be bug free, and to be
        compatible with all the complex configurations we are using
        these days. No cleaner can repair the files incorrectly infected
        by a buggy virus. Automatic cleaning is an illusion. If you
        really insist on using a cleaner, you have the best chances if
        you work through your files one by one.

        Remember also that even viruses that are known not to damage
        data still very often damage data because of interference with
        disk caches, Windows, or other system software for which the
        virus was not written for or properly tested against.


I have seen on Internet some information how to fool TbScan. What are you
going to do about it?

        This is nothing to worry about. We know that it is possible to
        fool heuristics. We know that it is possible to design a virus
        that TbScan can not yet detect. We have seen many examples of
        this in the past.
        Encrypted viruses have been invented to make signature scanning
        useless, until the AV industry invented signature wildcards and
        entry point tracers. Polymorphic viruses have been invented to
        make signature scanning completely impossible, until the
        anti-virus industry invented generic decryption.
        It is an endless battle. Some strategics are involved as well.
        Sometimes it is better to leave an easy to close door open,
        and let a virus writer spend weeks to write something
        that exploits this 'loophole' and then just slam this door
        without any trouble and any damage, than to attempt to foresee all
        possible future virus-writing-developments and to close all
        doors in advance, and let someone discover something that is much
        more difficult to solve. Someone who wants to attac a specific
        anti-virus product will finally discover something that can be
        used. This applies to all anti-virus products, no matter how
        clever they are. That's why all serious anti-virus products have
        to be frequently updated.

        If a virus is able to escape heuristic detection, we will find it
        with a signature. If some information leads to a virus that indeed
        succeeds to remain unspotted, we will do something about it. We have
        been doing so dozens of times in the past, and we will keep doing so.
        So far, there is no reason to believe that virus writers will
        finally come up with something that we can't handle.


Why is your scanner not scanning .DLL files?

        So far, we have been following the approach that we don't scan
        something if there are no viruses yet to infect it. We could have
        scanned for macro viruses for years, but it didn't make sense
        until someone actually created a macro virus. Technically, it is
        possible to infect a .DLL file, but there are no viruses which
        are doing this. As soon as there is a virus that infects .DLL
        files, we will have to create a signature for that virus anyway,
        and this is the right time to include the .DLL extension in the
        default scan list as well.

        Granted, there are a few viruses which think a .DLL file is a DOS
        executable, since it contains an EXE header. They might add their
        virus code to the .DLL file. But since you are never going to
        execute the .DLL file from the DOS command prompt, you are not
        going to introduce a virus on your system this way. The virus
        won't get activated when you use the .DLL file in a Windows
        environment. Of course, if you have a standard executable file
        (.EXE or .COM) which is infected by a virus, this virus may
        'infect' the .DLL file, so once you have a virus, it is a good
        idea to include the /allfiles option.


Network related questions
-------------------------

We have TBAV installed on a server, and we use TbScan with option 'once'.
However, if we turn on the machines in the morning, TbScan only scans
one workstation, and skips on the other workstations.

        If TbScan uses the 'once' option, information will be written to
        TbScan.Exe. The first PC scans, and updates the information in
        TbScan.Exe. The next PC's will conclude that TbScan has already
        been used this day, and proceed without scanning.

        To avoid this problem, you can specify a filename behind option
        'once'. Instead of putting the information in the TbScan.Exe
        program, TbScan now records the information in the specified file.
        Use, for instance, 'TbScan once=c:\config.sys' to make sure that
        every PC maintains its own 'last time scanned' record. Note:
        TbScan does not alter the contents of the specified file, but
        records the information in a different way. Therefor you can
        specify any existing file.


We have TBAV installed on a server, and we use TbScan with option
'once'. However, if we boot the machines multiple times a day, TbScan
always scan the workstations, instead of only once.

        The users probably don't have write access rights to the
        directory where TbScan.Exe resides. Excellent! Use the method
        as described in the previous question.


Is it possible for the supervisor to receive messages about viral
activities anywhere within the network?

        Not with the standard TBAV utilities. There is a special network
        version available which features centralized anti-virus control.
        Contact your local vendor for more information.