                 1. ТЕХНОЛОГИЯ ЗАЩИТЫ ОТ ВИРУСОВ

     Проблема "вирус-средства защиты" аналогична проблеме  "оружие
нападения-оружие  защиты":  появление  средств  защиты стимулирует
разработку более  совершенных средств  нападения. Когда  появились
первые вирусы, антивирусные средства как таковые, естественно,  не
существовали и авторам вирусов  было ни к чему  применять какие-то
сложные методы маскировки и обхода антивирусных средств. Однако  в
настоящее время  вирусы должны  приспособиться к  среде, в которой
установлены различного рода антивирусные средства, и как результат
техно-крысы стали применять при написании вирусов различные  трюки
для обхода наиболее популярных антивируcных средств. В целом можно
констатировать, что  совершенствование средств защиты идет  парал-
лельно с  совершенствование вирусов.  Эта ситуация в какой-то мере
напоминает естественный отбор, в ходе которого, как известно,  вы-
живают наиболее приспособленные. Поэтому любая система защиты дол-
жна постоянно совершенствоваться с учетом изменения "вирусной  об-
становки" и состоять из комплекса различных средств,  взаимодопол-
няющих и "перекрывающих" друг друга, делая тем самым "прорыв"  ка-
кого-то одного метода или средства защиты недостаточным для прони-
кновения вируса в систему.

            1.1. Дискета-дрозофила как универсальный
                   тест на заражение вирусами

     При обнаружении каких-то аномальных явлений в поведении  ком-
пьютера  у  большинства  пользователей  сразу возникает гипотеза о
том, что компьютер заражен вирусом. И такая настороженность  явля-
ется вполне оправданной, если  только не переходит в  вирусофобию.
Для выявления  вируса рекомендуется  использовать способ,  который
можно назвать "ловля вируса на дискету-дрозофилу".
     Дискетой-дрозофилой будем называть копию некоторой  эталонной
дискеты с исполняемыми программами, специально предназначенную для
заражения вирусом. Основное преимущество дискеты-дрозофилы состоит
в том, что исследовать дискету гораздо проще, чем винчестер. Таким
образом вирус как бы "вытаскивается на свет". Например, место, ку-
да вирус записал свое тело, легко определяется путем сравнения за-
раженной дискеты с эталонной.
     Все известные сейчас компьютерные вирусы вирусы заражают дис-
кеты. Поэтому дискета-дрозофила  является одним из  самых надежных
тестов на вирус, особенно если ее сочетать с перезагрузками компь-
ютера искусственно ускоренным календарем и другими мерами "пробуж-
дения" вируса (см. ниже).
     В качестве дискеты-дрозофилы проще всего использовать эталон-
ную дискету с MS DOS. Она удобна тем, что заклеенный эталон для ее
создания и сравнения всегда под рукой. Это, конечно, не  исключает
создание специальной  дискеты путем  дополнительно записи  на нее,
скажем, некоторых антивирусных  программ. Сняв копию,  нужно вста-
вить дискету-дрозофилу в "подозрительный" компьютер и запустить  с
нее  несколько  программ,  например  COMMAND.COM,  XCOPY,   Norton
Cоmmander. Можно скопировать одну из программ на винчестер и обра-
тно (но только одну, так как иначе может измениться структура  со-
ответствующего каталога, что вызовет ложное срабатывание при срав-
нении с эталоном).
     После нескольких попыток заражения дискеты-дрозофилы  следует
перегрузить  компьютер  с  эталонной  дискеты с помощью "холодной"
(клавишей RESET или  выключением питания) перезагрузки  и сравнить
дискету-дрозофилу с эталоном. Операцию сравнения дискет удобно вы-
полнять с помощью PC Tools. В случае обнаружения различий гипотеза
о наличии вируса получает серьезное подтверждение. Если же, несмо-
тря на все усилия, дискета-дрозофила остается идентичной  эталону,
то причину наблюдаемых аномалий следует искать в другом. Благодаря
объективности процедуры тестирования, эксперимент с  дискетой-дро-
зофилой является весьма удобным способом борьбы с вирусофобией.

             1.2. Обзор методов защиты от вирусов

     Существует целый спектр методов и средств защиты. Методика их
применения будет рассмотрена несколько позднее. Введем необходимые
термины и приведем их краткую классификацию.
     Архивирование: резервирование  таблицы FAT  с помощью  утилит
Image или  Mirror при  каждой перезагрузке  компьютера, ежедневное
ведение архивов измененных файлов с помощью Fastback Plus или дру-
гого архиватора. Это самый важный, основной метод защиты от  виру-
сов. Остальные методы не могут заменить ежедневное  архивирование,
хотя и повышают общий уровень защиты.
     Сегментация: использование  Advanced Disk  Manager (ADM)  или
Disk Manager (в сочетании с Protect Д.Гуртяка) для разбиения диска
на "непотопляемые  отсеки" -  зоны с  установленным атрибутом READ
ONLY. Использование для хранения ценной информации разделов, отли-
чных от C или D. Хранение исполняемых программ и баз данных в раз-
ных разделах винчестера. Свертка неиспользуемых каталогов в  архи-
вы, что позволяет также сэкономить значительное место на винчесте-
ре.
     Ревизия: ежедневный контроль целостности исполняемых файлов и
системных блоков с помощью Adinf или аналогичного ревизора.
     Входной контроль: проверка поступающих программ батареей  де-
текторов и фагов, проверка соответствия длины и контрольных сумм в
сертификате длинам и контрольным суммам полученных программ.
     Профилактика: систематическое использование Vformat для  раз-
метки дискет; профилактическое вакцинирование поступающих дискет с
помощью VitaminB; работа на "чужих" компьютерах с дискетами, защи-
щенными от  записи, минимизация  периодов доступности  дискеты для
записи, разделение "общих" дискет между конкретными пользователями
и разделение передаваемых и поступающих дискет, раздельное  хране-
ние вновь полученных программ и эксплуатировавшихся ранее,  хране-
ние неиспользуемых программ на "винчестере" в архивированном виде.
     Карантин: каждая новая программа, полученная без  контрольных
сумм, должна проходить карантин, т.е. проверяться на известные ви-
ды компьютерных вирусов, и в течение определенного времени за  ней
должно быть организовано  наблюдение. Рекомендуется создание  Bat-
файла, в котором после вызова программы стоит вызов программ-лову-
шек В.В.Волынского (см. прил.3). Использование специального разде-
ла для хранения вновь  поступивших программ в сочетании  со специ-
альным именем пользователя в  ADM (Advanced Disk Manager),  причем
для этого пользователя все остальные разделы должны быть либо  не-
видимы, либо иметь статус READ ONLY.
     Фильтрация: применение программ-сторожей для обнаружения  по-
пыток выполнить несанкционированные действия. Использование  атри-
бута READ ONLY для всех исполняемых файлов в сочетании с  соответ-
ствующим резидентным "усилителем" этого атрибута.
     Вакцинирование: специальная обработка файлов, дисков, катало-
гов, запуск резидентных программ-вакцин, имитирующих сочетание ус-
ловий, которые используются  данным типом вируса  для определения,
заражена уже программа, диск, компьютер или нет, т.е. обманывающих
вирус.
     Автоконтроль  целостности:  применение  резидентных  программ
подсчета контрольных сумм перед запуском программ, использование в
программе специальных алгоритмов,  позволяющих после запуска  про-
граммы определить, были внесены изменения в файл, из которого  за-
гружена программа, или нет.
     Терапия: дезактивация  конкретного вируса  в зараженных  про-
граммах специальной программой-антибиотиком или восстановление пе-
рвоначального состояния программ путем "выкусывания" всех  экземп-
ляров вируса из каждого зараженного файла или диска с помощью про-
граммыфага.

                1.3. Многоуровневая схема защиты

     Проблему защиты от вирусов целесообразно рассматривать в  об-
щем контексте проблемы  защиты информации от  несанкционированного
доступа. По данной проблеме  опубликован ряд монографий (см.,  на-
пример [Сяо82, Хоффман80].  Основной принцип, который  должен быть
положен в основу разработки технологии защиты от вирусов,  состоит
в создании многоуровневой распределенной системы защиты,  включаю-
щей как регламентацию операций на ЭВМ, так и специальные программ-
ные и аппаратные средства.  При этом обязательно должно  существо-
вать несколько уровней защиты, причем их количество может варьиро-
ваться в зависимости от ценности информации, которая обрабатывает-
ся на конкретной ЭВM.
     Как уже указывалось, важным преимуществом многоуровневой  за-
щиты является то, что наличие нескольких уровней позволяет компен-
сировать недостатки, присущие  тому или иному  отдельному средству
защиты. Автор рекомендует схему, включающую следующие этапы:
     - архивирование по схеме неделя-месяц-год с тремя независимы-
ми комплектами архивных дискет;
     - сплошной входной контроль новых программных средств.  Пред-
варительная вакцинация всех получаемых дискет с помощью VitaminB;
     - сегментация информации на винчестере, с помощью специально-
го дискового драйвера  (Advanced Disk Manager  или Disk Manager  в
сочетании с  Protect Д.Гуртяка),  обеспечивающая защиту  системных
блоков MS DOS (MBR, бут-сектор, FAT) от уничтожения при срабатыва-
нии вируса или троянской программы, а наиболее часто  используемые
программы и компоненты MS DOS от заражения. Пользователям,  разме-
тившим винчестер с помощью Fdisk, рекомендуется использовать  дис-
ковый кэш Dcache канадской фирмы Datamorphics Limited;
     - систематический запуск при перезагрузке или раз в сутки ре-
визора (например, Adinf) для контроля целостности информации.
     Как видно из приведенного выше, предлагаемая схема  предпола-
гает возведение нескольких "барьеров" на пути проникновения вируса
в компьютер. Если попытаться наметить иерархию этих "барьеров"  по
их вкладу в безопасность, то несомненно, что на первом месте  идет
архивирование по схеме неделя-месяц-год.

               1.3.1. Организация входного контроля
                 нового программного обеспечения

     Первым и весьма важным  уровнем защиты является входной  кон-
троль поступающих программ и  дискет. Подобно тому как  первые за-
хваты авиалайнеров изменили отношение к проблемам досмотра  пасса-
жиров, случаи заражения вирусами должны изменить отношение к вход-
ному контролю программ и  дискет, который, к сожалению,  часто еще
рассматривается как необязательный.  Следует отдавать себе  отчет,
что фактически мы столкнулись с еще одной разновидностью террориз-
ма и борьба с ним  требует перехода к сплошному входному  контролю
поступающих программ  и дискет.  При этом  "фирменные" дискеты  не
должны составлять исключение, так как имелись случаи поставки  за-
раженных программ на  дистрибутивных дискетах. Это  особенно отно-
сится к дистрибутивам, получаемым из Юго-Восточной Азии.  Конечно,
вероятность последнего случая существенно меньше, чем при  обычном
переписывании.
     Перед использованием полученной дискеты рекомендуется ее вак-
цинировать с помощью VitaminB. Это в большинстве случаев предохра-
няет от  заражения бутовым  вирусом при  случайной перезагрузке  с
"защелкнутой" дискетой.
     Подавляющее большинство известных файловых вирусов можно  вы-
явить уже  на этапе  входного контроля.  Такая процедура  отнимает
всего лишь  несколько минут,  сохраняя десятки  часов, потраченных
затем на дезинфекцию винчестера, сплошной контроль всех дискет или
восстановление уничтоженной информации. Для этой цели целесообраз-
но использовать специально подобранную батарею детекторов и фагов.
Можно рекомендовать  следующий состав  такой батареи  (приведенные
ниже фаги следует использовать в режиме детектирования): LD,  SOS,
Aidstest,  -V,  Scan,  Central  Point Antivirus, Norton Antivirus,
TNTVirus.
     Если анализируемые файлы  сжаты с помощью  архиватора Pklite,
Lzexe, Diet и др., то перед входным контролем их обязательно  сле-
дует  распаковать.  Большинство  детекторов  и фагов не распознают
имеющиеся форматы упаковки и проверяют упакованные файлы как обыч-
ные. Тем самым они не в состоянии обнаружить вирус, если  заражен-
ная программа затем сжата архиватором.
     Указанную батарею  можно запускать  как посредством  обычного
BAT-файла,  так  и  с  помощью оболочки типа антивирус-интегратора
(например, AVTP). В случае обнаружения вирусов полезно  отпечатать
и сохранить протокол проведенного контроля. При интерпретации  ре-
зультатов следует учитывать возможность ложного срабатывания одно-
го из  детекторов (в  особенности этим  грешит полидетектор Scan).
Подозрительные файлы следует просмотреть на экране(например, испо-
льзуя вьюер WPVIEW из Norton Commander). Вирусы, прикрепляющиеся в
конец файла часто хорошо видны визуально, поскольку для большинст-
во программ,  в особенности  написанных на  языке высокого  уровня
размещают сегмент данных  последним в загрузочном  модуле. Поэтому
если после блока текстовых данных, явно относящихся к  анализируе-
мой программе виден "слой"  команд, то это должно  настораживать.
Конечно, это может быть  какой-то упаковщик исполняемых файлов.  В
этом случае файл рекомендуется распаковать и контроль повторить.
     Поскольку при входном контроле дискет вирус находится в  пас-
сивном состоянии, а число анализируемых объектов невелико по срав-
нению с типичным содержимым винчестера, этот тип контроля предста-
вляется наиболее важным, позволяя полностью исключить случаи зара-
жения по меньшей мере уже известными вирусами (т.е. 99% случаев).
     Следует подчеркнуть важность проведения вакцинации бут-секто-
ра VitaminB как простого и надежного метода предохранения от буто-
вых вирусов.
     Развитие методов маскировки вирусов делает необходимым  поня-
тие достоверной дистрибутивной копии. Здесь возникает определенная
проблема, в случае  если распространяемое программное  обеспечение
относится к классу Freeware. Главным критерием достоверности  дис-
трибутивной копии является соответствие длины, даты и  контрольной
суммы файла значениям, приведенным в протоколе архивирования  раз-
работчика, если конечно, таковой  имеется, или в протоколе,  полу-
ченном с автоверифицируемой дистибутивной копии. Следует  подчерк-
нуть важность  эталонного протокола,  как своего  рода сертификата
подлинности передаваемого программного обеспечения.
     В настоящее время ряд архиваторов обеспечивает контроль цело-
стности компонент архива  при распаковке и  выдает соответствующее
сообщение в  протокол разархивирования  (автоверификация). Поэтому
многие зарубежные разработчики программного обеспечения, распрост-
раняемого как Freeware и, особенно, как Shareware поставляют  сей-
час свои продукты в виде архивов с автоверификацией. В этом случае
целостность содержимого архива проверяется в процессе  распаковки.
Это понижает  вероятность распространения  троянизированных каким-
нибудь  новым  вирусом  очередных  версий популярного программного
обеспечения. Вместе с тем,  и автоверифицируемый архив может  быть
подделан, поэтому хотя это средство существенно понижает,  вероят-
ность наличия вируса в программах, оно не исключает его полностью.
Следует подчеркнуть, что даже наличие файла с контрольными суммами
в составе дистрибутива существенно увеличивает вероятность обнару-
жения зараженных файлов и такая практика должна стать  стандартной
для отечественных разработчиков Freeware и Shareware.
     Рекомендуется визуально контролировать текстовые строки, име-
ющиеся в полученных программах, используя Labtest, Red, Edmsg  или
другую подходящую утилиту. Полезно убедиться, что полученное  про-
граммное обеспечение не содержит "подозрительных" текстовых  строк
типа  "COMMAND.COM",  "PATH=",  "*.COM",  "*.EXE",  "????????COM",
"Kill", "Stoned", "Virus", "Stupid",  и т.д. (см. прил.1-2).  В то
же время  многие вирусы  шифруют содержащиеся  в них  строки и они
становятся видны  только при  трассировке программы.  Поэтому если
при визуальном просмотре в последних 2-3К дампа нет ни одной текс-
товой строки, то это  должно настораживать. Если это  является ре-
зультатом упаковки EXE-файлов специальным упаковщиком,  распаковы-
вающим файл в оперативной памяти перед выполнением (Pklite, Lzexe,
Diet и  др.), то  необходимо предварительно  распаковать файл  для
анализа.
     Подозрительные файлы целесообразно просмотреть с помощью  от-
ладчика на специальном карантинном компьютере. Особенно удобен для
этой  цели  компьютер  без  винчестера.  Для  PC AT можно временно
отключить винчестер через процедуру SETUP.
     Для зараженных программ  управление вначале попадает  вирусу,
поэтому первые команды всех зараженных файлов, за исключением  мо-
жет быть первой команды перехода (иногда функцию команды  перехода
выполняют другие команды, чаще всего RET) одинаковы. Этих данных в
большинстве случаев достаточно, чтобы определить J-сигнатуру. Сле-
дует отметить, что для начального участка многих вирусов характер-
но наличие команд автобазирования т.е. команд вида:

       CALL XXX
  XXX: ...

     Некоторые отладчики (Periscope, Quaid Analizer) позволяют от-
слеживать выдаваемые программой прерывания. Такое прослеживание не
дает полной гарантии (изощренный вирус может "обмануть" отладчик),
однако его полезно предварительно перегрузившись с защищенной дис-
кеты выполнить хотя бы для части подозрительных программ на каран-
тинном компьютере. В  cлучае выявления попыток  поиска исполняемых
файлов, проверки и  снятия атрибутов READ  ONLY, перехода в  конец
файла и попытки дозаписи туда информации или прямой записи на диск
соответствующие участки программы рекомендуется  дизассемблировать
и пройти в пошаговом режиме.
     Отметим,  что  возникновение  различного  рода сложностей при
прохождении программы отладчиком,  например "уход из-под  отладчи-
ка", зависание  машины и  др., обычно  свидетельствует о  том, что
данную программу следует проанализировать более внимательно.  Воз-
можно, что это программа заражена вирусом или содержит "сломанную"
защиту.
     В случае, когда программное обеспечение получено без сертифи-
ката, из  сомнительного источника  или не  эксплуатировалось в том
месте, откуда оно было передано, первые несколько дней  эксплуата-
цию полученного программного  обеспечения полезно выполнять  в ка-
рантинном режиме. В этом режиме целесообразно использовать  искус-
ственно ускоренный календарь,  т.е. задавать при  каждом следующем
эксперименте новый месяц и  день недели. Это повышает  вероятность
обнаружения троянской компоненты, срабатывающей в определенный ме-
сяц или после истечения определенного календарного отрезка  време-
ни.
     Вообще говоря, лучше  всего иметь специально  выделенный "ка-
рантинный" компьютер  для подобного  рода экспериментов.  Сейчас с
уходом в тень  компьютеров типа PC  XT такая возможность  начинает
становиться реальностью и  в наших условиях,  по крайней мере  для
наиболее богатых  организаций. В  этом компьютере  все программное
обеспечение полезно обработать, дописав в конец каждого файла спе-
циальную строку, например, вида "***OK***" или "***NB <контрольная
сумма без маркера> ***". Дописывание таких концевых маркеров можно
выполнить автоматически, составив пакетный файл. Их наличие облег-
чает последующий анализ программ, поскольку граница между вирусом,
"севшим" в конец программы,  и файлом становится четко  определен-
ной.  Конечно,  это   не  исключает  необходимости   использования
"джентльменского" набора антивирусных средств, включающего  подхо-
дящий  ревизор,  сторож  и самоконтролирующиеся программы-ловушки.
Резидентные сторожа следует использовать лишь периодически, поско-
льку вирус может распознавать присутствие таких средств и соответ-
ствующим образом менять свое поведение (на "карантинном" компьюте-
ре стоит задача обнаружить  момент заражения, а не  препятствовать
размножению вируса).
     Очень полезными средствами периода карантина являются различ-
ные программы-ловушки,  контролирующие внесение  изменений в  свое
тело. Однако считывать для контроля свое тело они должны методами,
исключающими их "обман" со стороны вирусов. Автор рекомендует  ис-
пользование ловушек, разработанных В.В.Волынским, а также программ
Systest и AVB.
     Если выделить карантинный компьютер не представляется возмож-
ным, то целесообразно создать "карантинный режим" на одном из ком-
пьютеров, не содержащем особо ценных файлов или баз данных. Вход в
карантинный режим должен выполняться с помощью специального  имени
пользователя, которому для записи доступен лишь виртуальный диск и
специальный "карантинный" раздел винчестера, а большинство осталь-
ных скрыто, либо имеют статус READ ONLY. Для MS DOS 3.3 рекоменду-
ется сочетать блокировку с помощью драйвера (например, ADM) с бло-
кировкой с помощью кэша Dcache.
     Предварительно всех компонент операционной системы и  некото-
рых утилит, используемых как "приманка" для вируса, следует  запи-
сать в соответствующий файл контрольные суммы, вычисленные  подхо-
дящим ревизором (при его отсутствии для этой цели можно  использо-
вать любой архиватор, например Pkzip).

            1.3.2. Сегментация информации на винчестере

     Второй уровень защиты может быть основан на сегментации  вин-
честера с помощью специального драйвера, обеспечивающего  присвое-
ние  отдельным  логическим  дискам  (разделам винчестера) атрибута
READ ONLY, а также простейшую схему парольного доступа. В качестве
такого драйвера можно применять различные программы, в  частности,
ADM, который не только позволяет разбить диск на разделы, но и ор-
ганизовать несколько  вариантов доступа  к ним  с помощью паролей,
например при одном  пароле все диски,  кроме одного не  видны, при
другом имеют статус READ ONLY и т.д. Кроме того, уровень обеспечи-
ваемой им защиты от записи выше, чем других распространенных драй-
веров. Вместе с тем, ADM не является средством защиты от несанкци-
онированного доступа: имеется  ряд программ, позволяющих  переклю-
читься в статус суперпользователя или даже выдать на экран  список
всех паролей.
     Как и для  морских кораблей, схема  размещения "непотопляемых
отсеков" (разделов с установленным атрибутом READ ONLY) во  многом
определяет "живучесть" винчестера при внезапной атаке.  Винчестер,
содержащий  единственный  незащищенный  раздел  С, обычно "идет ко
дну" при первой же атаке вируса или троянской программы.
     Количество "непотопляемых отсеков" и их содержимое зависят от
решаемых задач и объема винчестера. Для наиболее  распространенных
винчестеров 40M можно использовать три-четыре раздела. При этом на
логическом диске С, с которого выполняется загрузка, следует оста-
вить    лишь    минимальное    количество   файлов  (AUTOEXEC.BAT,
COMMAND.COM, CONFIG.SYS, скрытые системные файлы и программы-лову-
шки, контролирующие свою  контрольную сумму. В  качестве последних
можно использовать  и антивирусных  программы, например  Aidstest,
изменив на всякий случай его имя на какое-нибудь нейтральное). Ос-
тальную часть  винчестера следует  разбить на  зону трансляторов и
системных утилит (раздел D со статусом READ ONLY) и несколько раз-
делов для отдельных пользователей (или типов данных) с  соответст-
вующими ограничениями доступа. Размер разделов рекомендуется выби-
рать с учетом удобства последующей архивации (см.ниже).
     Как и любая сегментация, сегментация винчестера снижает эффе-
ктивность использования дискового пространства, поэтому увлекаться
созданием мелких разделов не стоит. Минимальный размер раздела до-
лжен быть  около 8M.  Кстати, для  него можно  использовать размер
кластера, совпадающий с размером сектора (512 байт), что  повышает
степень использования дискового пространства примерно на 10%.
     Важным профилактическим средством в борьбе с файловыми  виру-
сами является "затруднение им жизни" путем исключения значительной
части загрузочных  модулей из  сферы их  досягаемости. Этот метод,
называемый сегментацией, был кратко рассмотрен в предыдущем разде-
ле. Однако применительно к самой операционной системе  сегментация
настолько важна, что на ней стоит остановиться отдельно. При  пра-
вильном размещении операционной системы и ряда утилит можно гаран-
тировать, что  после начальной  загрузки операционной  системы она
еще не заражена резидентным файловым вирусом. Это создает настоль-
ко значительные удобства и  преимущества, что для достижения  ука-
занной цели стоит потратить время и силы на соответствующую  пере-
компоновку винчестера. Первая задача, которую нужно выполнить  при
"вирусобезопасной" постановке операционной системы, - это  размес-
тить командный процессор и системные утилиты в защищенном от запи-
си разделе (например, в разделе D).
     Следует отметить, что логический диск с операционной системой
не должен быть слишком большим. Туда следует включать только  ука-
занную часть операционной системы и некоторые "стабильные" утилиты
(Norton Utilities, PC Shell и т.д.). Общий принцип состоит в  том,
чтобы скомпоновать раздел D так, чтобы необходимость входить в си-
стему с паролем, обеспечивающим возможность записи в этот  раздел,
возникала как можно реже. Кроме того, новые полученные утилиты не-
льзя включать в состав этого диска без предварительной  тщательной
проверки и прохождения "карантинного" режима хотя бы в течение ме-
сяца. Не стоит  впадать из одной  крайности в другую  и стремиться
"защитить  все  подряд"  -  это  существенно затрудняет работу и в
большинстве случаев  сводит на  нет защиту  из-за частой  работы в
"открытом" режиме. Оптимальное количество исполняемых файлов,  за-
щищенных от записи, вряд ли должно превышать 20-30% от общего  ко-
личества используемых программ. В качестве критериев можно исполь-
зовать  целесообразность  подключения  соответствующего каталога к
PATH, а также степень стабильности данного программного продукта.
     Помимо командного процессора, одними из первых обычно заража-
ются файлы, входящие в AUTOEXEC.BAT. Поэтому их тоже следует  раз-
мещать в разделе винчестера, имеющего статус READ ONLY. Иногда ви-
русы заражают файлы IBMBIO и IBMCOM. Хотя обычно при этом операци-
онная система теряет работоспособность, здесь есть нюанс,  состоя-
щий в том, что не рекомендуется (а с помощью DM и нельзя) присваи-
вать диску С статус READ ONLY. Поэтому для контроля файлов, разме-
щенных на диске С, целесообразно использовать ревизор, вставив его
вызов в AUTOEXEC.BAT.
     Поскольку  командный  процессор  является излюбленной мишенью
для атаки файловых вирусов,  то нужно одновременно оставить  его в
качестве мишени и в то  же время не допустить использования  зара-
женного командного процессора при перезагрузке системы.  Очевидно,
что эти требования выглядят как взаимоисключающие. Однако им можно
удовлетворить, если "оригинал" командного процессора разместить на
защищенном от записи диске, а после начальной загрузки скопировать
его на виртуальный диск и установить соответствующее значение  пе-
ременной COMSPEC.  Для того  чтобы командный  процессор в процессе
начальной загрузки считывался из защищенного раздела в CONFIG.SYS,
следует включить строку вида:

  SHELL = D:\DOS\COMMAND.COM

или

  SHELL = D:\4DOS\4DOS.COM @C:\4DOS.DAT

     Последняя строка предполагает использование "альтернативного"
командного  процессора  4DOS,  разработанного  американской фирмой
J.P. Software и распространяемого как Shareware (как  коммерческий
продукт этот процессор включен в  6 версию утилит Нортона под  на-
званием NDOS). Этот командный процессор довольно удобен для  поль-
зователей, работающих на PC AT или PS/2, имеющих объем оперативной
памяти  1М   и  более.   Его  использование   вместо  стандартного
COMMAND.COM обеспечивает  дополнительную степень  индивидуализации
операционной системы (как известно,  имеется по меньшей мере  один
вирус - Lehigh,  ориентированный на заражение  именно стандартного
COMMAND.COM). Он предоставляет  ряд дополнительных удобств,  среди
которых отметим существенно расширенный командный язык, значитель-
но облегчающий программирование BAT-файлов. Кстати, удобный диало-
говый HELP от 4DOS  можно использовать и со  стандартным командным
процессором. Как и COMMAND.COM, командный процессор 4DOS.COM  сег-
ментирован и состоит из небольшой резидентной части 4DOS.COM, раз-
мером около 11К (в памяти остается всего 2,5K - меньше, чем у  ре-
зидентной части COMMAND.COM) и оверлея 4DOS286.EXE, размером около
64К. Шансы, что вирусу  удастся заразить этот командный  процессор
тем же методом, что и стандартный COMMAND.COM, сравнительно  неве-
лики. Вместе с тем, не только вирусы, но и программы,  привязанные
к стандартному COMMAND.COM, могут оказаться неработоспособными при
использовании 4DOS. Поэтому целесообразность использования указан-
ного командного процессора во многом зависит от решаемых задач.
  Запись командного процессора на виртуальный диск и  переназначе-
ние переменной  COMSPEC для  стандартного COMMAND.COM  выполняются
путем включения в качестве первых строк AUTOEXEC.BAT двух  следую-
щих строк:

  set comspec=h:\command.com
  copy d:\dos\command.com h:

     В приведенных строках  предполагается, что логический  диск H
является виртуальным. Использование виртуального диска для  хране-
ния командного процессора (в сочетании с заданием соответствующего
значения параметра COMSPEC) не только превращает его в своего рода
дрозофилу (заражение  которой легко  контролировать, а  удаление с
диска обеспечивается автоматически при перезагрузке MS DOS), но  и
ускоряет  работу   с  некоторыми   оболочками  (например,   Norton
Commander). При этом можно создать специальный BAT-файл для  срав-
нения COMMAND.COM с эталоном, например:

  copy h:command.com f:\work\shell.tmp
  fc d:\dos\shell.etl f:\work\shell.tmp

     Пользователи оболочки Norton Commander могут определить  кла-
вишу в пользовательском меню для запуска указанной выше команды.
     Вместо пофайлового копирования на виртуальный диск командного
процессора,  BAT-файлов  и  наиболее  часто  выполняемых  программ
(Pkzip, Norton  Commander и  т.д.) быстрее  и удобнее использовать
загрузку виртуального диска "целиком" из предварительно созданного
файла(образа  диска).  Для  этой  цели удобно использовать утилиту
Dfcopy, разработанной И.А.Свиридовым (см. Софтпанорама, 1991. Т.3.
N 2). Перед созданием образа виртуального диска рекомендуется  оп-
тимизировать его содержимое с помощью SpeedDisk. Другим достоинст-
вом рассматриваемого способа является то, что можно иметь несколь-
ко образов виртуального диска,  в зависимости от решаемых  задач и
оперативно менять его содержимое в процессе работы.
     Связывание длинной цепочки каталогов по PATH создает  очевид-
ные удобства при работе. В то  же время такое решение имеет и  два
существенных недостатка. Во-первых, замедляется поиск  запускаемой
программы (если отсутствует кэш), а во-вторых, наличие  соответст-
вующей строки  PATH облегчает  файловым вирусам  поиск исполняемых
файлов. Поэтому рекомендуется  компромиссное решение: указывать  в
PATH только каталоги, расположенные на защищенных от записи  логи-
ческих дисках, а также корневой каталог и один дополнительный  ка-
талог с BAT-файлами. В последний удобно занести файлы, указывающие
путь для исполняемой  программы, расположенной на  незащищенных от
записи логических дисках. При  этом для каждой часто  используемой
программы удобно  составить отдельный  BAT-файл, в  котором обычно
удается предусмотреть некоторые дополнительные удобства в виде ус-
тановки каких-то типовых режимов, сокращенного набора групп  пара-
метров и другой сервис,  уровень которого зависит от  вашей собст-
венной изобретательности. Это существенно упрощает и ускоряет про-
цесс работы, поскольку  типовые параметры набирать  не приходится,
время на просмотр длинной  цепочки каталогов при поиске  программы
не теряется. В то  же время, такое решение  повышает безопасность,
не давая вирусам легко и просто определять путь к жертвам по PATH.

1.3.3. Архивирование

    Наиболее надежным  методом защиты  ценной информации  является
архивирование. При  наличии ежедневных  копий максимум,  что может
сделать вирус, это уничтожить результаты последнего дня вашей  ра-
боты. Следует отметить, что при разрушении важной информации в ор-
ганизации часто возникает паника результаты которой зачастую  ока-
зываются разрушительнее, чем действия вируса.
    Психологически состояние программиста, который за одну секунду
потерял содержимое винчестера, является типичным примером стрессо-
вого состояния. Только что машина работала, все файлы были на мес-
те. А сейчас информация, на создание которой было потрачено столь-
ко труда, исчезла, и резервной копии вообще нет. Поэтому очевидно,
что создание архива - это  далеко не та вещь, которую  можно отло-
жить на потом. В сущности, это такая же часть работы пользователя,
как программирование или ведение базы данных. В то же время  реко-
мендации по  этому вопросу  в литературе  практически отсутствуют.
Ниже приводятся некоторые рекомендации, основанные на опыте  авто-
ра.
    Для компьютера PC  AT важным аспектом  является резервирование
содержимого CMOS памяти, установленного с помощью процедуры SETUP.
Это проще всего  выполнить с помощью  DiskTool из версии  6 утилит
Нортона, СMOSER или SAVECMOS А.Водяника (Софтпанорама, 1990. Т.2 N
3). Для некоторых типов  BIOS содержимое отдельных байтов  CMOS не
выдается на экран, однако важно для правильной работы машины.  Эти
меры связаны с  тем, что рано  или поздно элемент,  обеспечивающий
питание CMOS-памяти, выйдет из строя. Кроме того, известно  неcко-
лько троянских программ, которые  при запуске портят CMOS.  Иногда
содержимое CMOS уничтожается из-за ошибки в "нормальной"  програм-
ме. Хотя элемент питания рассчитан на несколько лет, опыт  показы-
вает, что средняя продолжительность жизни CMOS обычно не превышает
нескольких месяцев. Если содержимое CMOS потеряно, то при отсутст-
вии точных данных о  типе установленного винчестера возникает  ряд
очень неприятных проблем, когда значение некоторых параметров при-
ходится устанавливать экспериментально. Это особенно трудно, когда
на машине установлен сравнительно редкий тип винчестера.
     Поскольку FAT и  главный каталог являются  наиболее уязвимыми
управляющими блоками MS DOS,  необходимо предпринимать меры по  их
дополнительному резервированию. Такую возможность обеспечивает,  в
частности, программа Image из версии 6 утилит П.Нортона, вызов ко-
торой следует вставить в AUTOEXEC.BAT. Наряду с Image можно  испо-
льзовать более программу  Mirror, входящую в  пакет PC Shell.  Она
записывает копии указанных секторов в конец винчестера.
     Резервирование MBR, бут-сектора, FAT и каталогов важно не то-
лько в плане защиты от вирусов, но и как метод страховки на случай
непредвиденного стечения обстоятельств или чьих-то (в том числе  и
собственных) действий. Периодически рекомендуется выгружать файлы,
создаваемые этими утилитами на специальную дискету из "горячей ко-
робки" (см. ниже). Это особенно важно, если при сжатии диска  ути-
литой Norton Speed Disk  задан режим перенесения всех  каталогов в
начало логического диска.
     Если имеется возможность, то желательно иметь несколько  ком-
плектов дискет для архива винчестера и вести циклическую запись на
эти комплекты  (например, для  трех комплектов  можно использовать
"классический" принцип неделя-месяц-год). В этом случае  различают
главный архив, в котором хранится полный объем используемой инфор-
мации и программного обеспечения, и текущие архивы, в которые  за-
носятся только последние программные продукты и файлы. Текущих ар-
хивов может быть несколько, в зависимости от периодичности их  об-
новления. Главный архив целесообразно обновлять примерно раз в ме-
сяц, а текущие архивы - по крайней мере раз в неделю.  Откорректи-
рованные текстовые файлы и базы данных необходимо архивировать  на
дискету в конце каждого рабочего дня.
     Для создания главного архива рекомендуется использовать  про-
грамму FastBack Plus (версию 2.1 или более позднюю). Она позволяет
выгрузить винчестер 20М на 35-40  дискет по 360K или 12-15  дискет
по 1,2M примерно за 20  мин. Следует отметить, что если  на машине
установлен дисковод 1,2M, то использование дискет 360K для  созда-
ния архива  неоправданно. Рекомендуется  использовать как  минимум
формат 730K, а лучше формат 800K (80 треков, 10 секторов на трек).
Обычные дискеты DS/DD работают при такой разметке достаточно наде-
жно. Однако по возможности  используйте дискеты 1,2M, поскольку  в
этом случае создание архива выполняется значительно проще и  быст-
рее, чем на дискетах 730K. С учетом отсутствия на большинстве оте-
чественных машин стриммеров рекомендуемый размер раздела винчесте-
ра должен соответствовать определенному количеству коробок  дискет
архива. Например, раздел 20M  очень удобен при создании  архива на
дискетах 1,2M, поскольку 12-15 дискет помещаются в одну коробку, и
неудобен при создании архива на дискетах 730K (требуется  примерно
18 дискет). После создания главного архива рекомендуется  провести
оптимизацию винчестера, например, с  помощью Norton Speed Disk  из
версии 6 утилит Нортона.
     Для создания недельного архива рекомендуется использовать ар-
хиватор Arj (версию 2.0 или более позднюю). При этом каждый  архив
в  главном  каталоге  диска  рекомендуется сворачивать в отдельный
файл. Если размер  файла на дискете  превышает размер дискеты,  то
архив выгружается  на несколько  последовательных дискет.  Другим,
менее удобным вариантом является создание архива на винчестере,  а
затем "резка" его на отдельные фрагменты утилитой SplitB или  ана-
логичной. В недельный архив следует включать только каталоги,  из-
мененные за прошедшую неделю.
     И наконец, ежедневный  архив включает все  тексты, измененные
за рабочий день.
     Если какой-то каталог на винчестере используется лишь  эпизо-
дически или  только определенным  пользователем, то  после каждого
использования желательно все программы в нем сворачивать архивато-
ром, поскольку заразить программу, находящуюся в архиве, практиче-
ски невозможно и кроме того экономится место на винчестере.
     Поскольку  дискеты  часто  являются  дефицитом, то для дискет
DS/DD  наиболее  подходящим  форматом  для записи архивов является
формат 812K, (80 треков, 10 секторов на трек, 2 блока главного ка-
талога), который  достаточно надежен  и позволяет  вдвое уменьшить
количество используемых дискет. Для дискет HD рекомендуется  испо-
льзовать формат  1.44M (80  треков, 18  секторов на  трек, 2 блока
главного каталога).

1.9. Классификация и методика применения средств защиты

     Операционная система MS DOS, отличающаяся практически  полным
отсутствием защиты от несанкционированных действий, облегчает раз-
работку компьютерных вирусов.  Однако важно понимать,  что компью-
терные вирусы  не являются  программами, использующими  ошибки или
недостатки конкретной операционной системы. Для обеспечения своего
функционирования вирусу достаточно лишь нескольких вполне  обычных
операций, используемых  большинством нормальных  программ. Поэтому
принципиально не может существовать универсальный метод,  защищаю-
щий операционную систему от распространения любого вируса. Тем  не
менее можно существенно затруднить задачу создания вируса,  приме-
няя специальные методы как в самой операционной системе, так и ис-
пользуя дополнительные резидентные и нерезидентные средства  защи-
ты.
     Простейшим средством защиты от вируса является программа, по-
зволяющая составить список зараженных программ. Мы будем  называть
такую программу детектором.  В качестве детектора  могут использо-
ваться и имеющиеся программы,  способные выполнять поиск строки  в
файле или, желательно, в файлах на заданном диске или каталоге (PC
Tools, Norton Disk Editor и др.). Детектор может быть и  резидент-
ным. В этом случае после загрузки программы он проверяет ее на за-
раженность и, только если вирус не обнаружен, передает ей управле-
ние.
     Вторым и наиболее распространенным средством защиты от  виру-
сов являются так называемые фаги - программы, "выкусывающие" вирус
из зараженной программы и  тем самым восстанавливающие ее  в виде,
близком к первоначальному. Обычно фаги рассчитаны на несколько ти-
пов вируса (полифаги).  Последние умеют распознавать  и выкусывать
вирусы информация о которых в них заложена, т.е. уже  обнаруженные
и преданные разработчику полифага вирусы. Поэтому теоретически по-
лифаги всегда на шаг отстают от текущей ситуации. Однако поскольку
скорость распространения полифага может быть выше скорости распро-
странения вируса этот недостаток на практике оказывается не  столь
существенным. Наиболее популярными отечественными полифагами явля-
ются SOS  Е.Н.Сусликова и  Aidstest Д.Н.Лозинского.  Следует отме-
тить, что фаги, как и любые программы, содержат ошибки и  операция
"выкусывания" не всегда бывает успешной. Фаги также могут быть ре-
зидентными,  однако  из-за  значительного  объема резидентные фаги
встречаются редко.
     Третьим типом антивирусных программ являются резидентные про-
граммы,  контролирующие  подозрительные  действия запускаемых про-
грамм (например попытку  записи в определенный  раздел или файл  с
расширением COM или EXE и блокирующие их либо "молча", либо  выда-
вая сообщение пользователю,  который может разрешить  действие или
запретить  (в  последнем  случае  программа, предпринявшая опасное
действие, скорее всего  будет завершена аварийно).  Будем называть
такие  программы  сторожами.  Из  этого класса программ наибольший
практический интерес представляют дисковые драйверы,  обеспечиваю-
щие возможность  сегментации винчестера  и присваивания  отдельным
разделам статуса  READ ONLY.  Они могут  также выполнять некоторые
полезные дополнительные функции.  Например, драйвер ADM  (Advanced
Disk Manager) блокирует доступ к первой дорожке, содержащей MBR  и
бут-сектор, а также позволяет регламентировать для каждого пользо-
вателя  доступ  к  тем  или  иным разделам (это чисто антивирусное
средство и его нельзя использовать для разграничения доступа к ин-
формации,  поскольку  существует  несколько  программ для "взлома"
этой защиты).
     Четвертый тип - это программы-ревизоры, которые  подсчитывают
контрольные суммы и другие параметры файлов и сравнивают их с эта-
лонными. Последние  обычно хранятся  в отдельном  файле. Этот  вид
контроля представляется наиболее надежным, т.к. аккуратно написан-
ный ревизор (например Adinf) даже при наличии в оперативной памяти
резидентного компьютерного вируса позволяет выявить все измененные
программы несмотря на то,  что вирус может пытаться  эти изменения
замаскировать (стелс-вирус).
     Подобно остальным типам программ ревизоры могут быть резиден-
тными.  Последние  загружают  в  память программу, подсчитывают ее
контрольную сумму и если она совпадает с записанной в  специальном
поле файла или элемента каталога данного файла, то передают ей уп-
равление. В противном случае выдается предупреждающее сообщение  и
выполнение программы блокируется.
     Следует  подчеркнуть,  что  между  учебными программами этого
класса, например ревизором,  опубликованным в книге  Фигурнова[Фи-
гурнов90]  и  профессионально-написанными  программами  (например,
Adinf) существует принципиальные различия в методах доступа к фай-
лам. Учебные программы  можно запускать только  предварительно за-
грузившись с эталонной, защищенной от записи дискеты.
     И, наконец, наиболее  изощренным типом антивирусных  программ
являются так называемые вакцины. Подобно естественным вакцинам они
изменяют среду функционирования вируса таким образом, что он теря-
ет способность к размножению. Вакцины могут быть пассивные или ак-
тивные.
     Пассивная вакцина представляет собой пакетную программу,  ко-
торая за один вызов обрабатывает специальным образом файл или  все
файлы на диске либо в каталоге. Обычно при такой обработке проста-
вляется признак, который вирус использует для того, чтобы отличить
зараженные программы от  незараженных. Например, некоторые  вирусы
дописывают в конец зараженных файлов определенную строку  (скажем,
"MsDos"). Если  искусственно дописать  в конец  всех программ  эту
строку, то такие программы не будут заражаться вирусом,  поскольку
он будет считать, что они уже заражены. Обработанная таким образом
программа является вакцинированной  против данного вируса,  причем
операция вакцинации является обратимой: когда опасность  заражения
будет ликвидирована, строку можно из файла удалить. Другие  вирусы
проставляют в поле даты заражаемых программ значение секунд,  рав-
ное 62 (MS DOS допускает запись такого явно нереального значения).
Вакцина может проставить этот признак у всех выполняемых программ,
которые тем самым будут защищены от заражения данным типом вируса.
В этом  случае вакцинирование  является необратимым  в том смысле,
что восстановить первоначальное  значение секунд не  удастся, хотя
они, конечно, могут быть сброшены.
     Активные вакцины являются резидентными программами,  действие
которых основано на имитации присутствия вируса в оперативной  па-
мяти. Поэтому они  обычно применяются против  резидентных вирусов.
Если такая вакцина находится в памяти, то, когда при запуске зара-
женной программы вирус проверяет,  находится ли уже в  оперативной
памяти его копия, вакцина  имитирует наличие копии. В  этом случае
вирус просто передает управление программе-хозяину и его инсталля-
ция не происходит. Простейшие вакцины представляют собой  выделен-
ный и слегка модифицированный (лишенный способности к размножению)
вирус. Поэтому  они могут  быть оперативно  изготовлены - быстрее,
чем программы-фаги. Более сложные вакцины (поливакцины)  имитируют
наличие в оперативной памяти нескольких вирусов.
     Конечно, приведенный список не исчерпывает всего многообразия
антивирусных программ, хотя и охватывает основные их  разновиднос-
ти. Каждая из антивирусных  программ подобна узкому специалисту  в
определенной области, поэтому  оптимальной тактикой является  ком-
плексное применение нескольких типов антивирусных средств.  Список
популярных  отечественных  антивирусных  средств, распространяемых
бесплатно и  опубликованных в  бюллетене Софтпанорама,  приведен в
прил. 3.
     Спектр отношения пользователей к антивирусным программам  ко-
леблется от полного  равнодушия до страстного  коллекционирования.
Однако наличие антивирусных  программ является только  необходимым
условием. Важно не только иметь последние версии антивирусных про-
грамм, но и систематически ими пользоваться. К новым  антивирусным
средствам, полученным "обычным" путем, следует относиться с  такой
же осторожностью, как и ко всем остальным программам. Антивирусные
средства, не снабженные средствами самоконтроля целостности, могут
оказаться зараженными. Кроме  того, изредка встречаются  троянские
версии антивирусных средств. Ранее уже упоминались троянские  вер-
сии сторожа FluShot и полифага Aidstest.


1.4.1. Сканирующие антивирусные программы

     Программы, в ходе своей работы просматривающие дерево катало-
гов,  часто  называют  сканирующими.  Для сканирующих антивирусных
программ важным критерием является работа через BIOS для  считыва-
ния управляющих  блоков и  другой контролируемой  информации, а не
использование  для  считывания  функций  операционной системы типа
FindFirst, FindNext. Это требование связано с тем, что резидентный
вирус может перехватить эти прерывания и "подсунуть"  антивирусной
программе "туфту" вместо записанной на диске информации.
     Вторым общим критерием  оценки сканирующих антивирусных  про-
грамм является наличие  автотестирования на заражение.  Программы,
не обладающие данным свойством, применять не рекомендуется.
     Серьезной проблемой использования сканирующих программ  явля-
ется наличие целого ряда способов хранения информации на винчесте-
ре. В частности,  важно понимать, что  сканирующие программы не  в
состоянии выявить вирусы, хранящиеся в архивированных файлах.  Для
проверки такого  рода файлов  удобно запускать  их через  оболочку
Shez, создав оболочку с именем Scan.exe c соответствующими параме-
трами, единственной функцией которой будет преобразование парамет-
ров и  вызов соответствующей  программы (Shez  рассчитан только на
запуск через него полидетектора Scan). Другим подводным камнем яв-
ляется существование динамически разархивируемого формата EXE-фай-
лов (наиболее  популярными являются  форматы Lzexe  и Pklite, хотя
они не являются единственно  используемыми). В случае, если  зара-
женный файл был сжат этим архиватором, сканирующая программа не  в
состоянии определить его зараженность без динамически  выполняемой
распаковки. Поэтому на этапе входного контроля рекомендуется  рас-
паковывать  файлы,  предварительно  упакованные  с  помощью Lzexe,
Pklite, Diet и аналогичных им программ.
     Сканирующие программы должны каким-то образом пытаться  опре-
делить наличие в памяти  резидентных вирусов, поскольку при  рези-
дентном  вирусе  процесс  сканирования  может привести к заражению
всех "проверенных" файлов. Причем, если заражение выполняется  при
закрытии файла, никакой диагностики выдано не будет. Эта  проблема
особенно актуальна для ревизоров, которые должны иметь режим наст-
ройки на определенное состояние оперативной памяти (при запуске  в
AUTOEXEC.BAT), как это реализовано в ревизоре Adinf.
     Важным критерием оценки антивирусных программ является  испо-
льзование ими различного рода эвристических приемов, типа  выявле-
ния команд автобазирования  (впервые реализовано Е.Н.Сусликовым  в
его известном детекторе LD), диагностирования значения 62 с в поле
даты и т.д. Это повышает вероятность обнаружения новых вирусов.
     Другим важным критерием -  выдача более или менее  подробного
отчета. В настоящее время это является слабым местом для  большин-
ства как бесплатно распространяемых, так и коммерческих  программ.
Например, для фага такой отчет должен включать помимо имени  файла
и типа заражения,  хотя бы длину  файла до и  после выкусывания, а
также разницу длин. Кроме того, в случае обнаружения каких-то ано-
малий фаг должен выдавать соответствующую информацию и  предупреж-
дающие сообщения, а не "резать молча".
     Общими  критериями  оценки  сканирующих антивирусных программ
являются:
     - автотестирование на заражение;
     - возможность управления областью поиска (глобальный поиск по
всем дискам, по одному диску, в поддереве, в одном каталоге, в од-
ном файле);
     - управление суффиксами обрабатываемых файлов;
     - качество интерфейса (избыточный интерфейс c "лишними  окна-
ми" и навязчивым музыкальным сопровождением так же плох как и  не-
достаточный типа реализованного в полидетекторе Scan);
     - качество диагностических сообщений;
     - качество помощи, если таковая предусмотрена;
     - качество параметризации;
     - качество документации;
     - возможность обработки файлов с атрибутами HIDDEN;
     - качество выдаваемого протокола;
     - размер в К;
     - скорость поиска;
     - оригинальность оформления (видео и звуковое сопровождение).

                            Ревизоры

     Программы-ревизоры являются  самым надежным  средством защиты
от вирусов и должны входить в арсенал каждого пользователя.  Реви-
зоры это единственное средство, позволяющее следить за  целостнос-
тью системных файлов и изменениями в используемых каталогах.  Сле-
дует отметить, что получаемая с помощью ревизоров информация суще-
ственно облегчает ориентировку в лабиринте каталогов и "нововведе-
ниях" среди трансляторов и используемых утилит. Поэтому их  нельзя
рассматривать только в контексте  защиты от вирусов -  в настоящее
время они должны являться рабочим инструментом каждого  уважающего
свой труд программиста.
     Существуют  два  основных  типа  программ-ревизоров: пакетные
(например, Adinf Д.Ю.Мостового) и резидентные. Сначала мы рассмот-
рим пакетные ревизоры. В связи с распространенностью стелс-вирусов
современные пакетные ревизоры  обычно сканируют файловую  систему,
не используя  прерывания 21h  (операций файловой  системы MS DOS).
Ревизоры, использующие при работе прерывание 21h или в  документа-
ции к которым этот вопрос не оговорен, использовать не  рекоменду-
ется. Это, в частности, относится к учебным программам,  публикуе-
мых в популярных учебниках по MS DOS. Пакетные ревизоры рекоменду-
ется запускать по меньшей мере  раз в день, перед началом  первого
сеанса работы  с ЭВМ.  Для этой  цели их  рекомендуется вызывать в
AUTOEXEC.BAT. Помимо универсальных ревизоров, сканирующих как фай-
ловую систему, так  и системные блоки  (MBR и бут-сектор)  имеются
специализированные ревизоры,  рассчитанные только  на сканирование
системных блоков (AVB или Systest).
     Использование пакетных ревизоров особенно важно при работе на
"персональных ЭВМ коллективного пользования", которые в СССР  сей-
час явно  преобладают. В  этих условиях  необходимо, чтобы ревизор
создавал отдельный файл с контрольными суммами, который можно было
бы записать на  дискету или в  собственный каталог, а  затем перед
началом следующего сеанса  работы, выявить происшедшие  изменения.
Такое использование ревизоров должно сочетаться с "тотальной" про-
веркой целостности файлов, которую желательно проводить  централи-
зованно, не реже  одного раза в  месяц, причем протоколы  проверки
целесообразно записать на специальную дискету.
     Следует отметить, что для контроля отдельных "подозрительных"
или "странно ведущих себя"  файлов можно использовать сравнение  с
дистрибутивной  копией  (если  конечно  заведомо известно, что это
именно дистрибутивная копия). Это прежде всего относится к  компо-
нентам MS DOS, трансляторам, командным оболочкам. Сравнение (толь-
ко перегрузившись с эталонной  дискеты) можно выполнить с  помощью
обычных программы  сравнения файлов,  например входящие  в MS  DOS
программы FC и COMP.
     Из других свойств  пакетного ревизора, которые  могут служить
критерием оценки его качества при выборе, отметим следующие:
     - возможность записи результатов ревизии в отдельный файл или
распределения по проведенным файлам в виде специальной маркировки;
     - возможность сохранять первые байты программы;
     - качество алгоритма подсчета контрольной суммы;
     - возможность выдачи стандартной контрольной суммы  (соответ-
ствующей выдаваемой архиваторами Pkzip, Lha и др.);
     - диагностика аномалий в дате создания файла (например 62  с,
13-й месяц, год из следующего столетия и т.д.);
     - возможность выдачи данных ревизии в виде отчета, с указани-
ем размера и даты  создания, значения первых выполняемых  команд и
т.д.;
     -  возможность  маркировки  файлов  перед передачей на другой
компьютер и последующего снятия маркера.

                            Детекторы

     Детекторы,  рассчитанные  на  конкретные  вирусы, также можно
рассматривать как  специализированные программы-ревизоры,  однако,
как правило, они способны обнаруживать только ранее известные  ви-
русы. Следует отметить, что наиболее удобны детекторы, обнаружива-
ющие не один, а  целый ряд распространенных вирусов  (полидетекто-
ры). Как уже указывалось,  программы этого типа представляют  наи-
больший интерес как средство входного контроля нового программного
обеспечения, в особенности, поступающего без контрольных сумм.
     Будучи  простыми  программами  детекторы  могут давать ложные
срабатывания и выдаваемая ими диагностика должна  контролироваться
другими методами.  В частности,  если детектор  находит всего один
зараженный вирусом файл, то возможно это просто ложное  срабатыва-
ние и желательно просмотреть с помощью трассировки начальный учас-
ток этой программы отладчиком. Если сигнатура по которой  детектор
ищет вирус известна, то следует определить, в какой части програм-
мы она обнаружена и соответствует ли эта часть месту  прикрепления
к программе данного вируса.
     Имеются три основных типа полидетекторов: с фиксированным на-
бором сигнатур, с переменным набором и эвристические детекторы.
     Детекторы с фиксированным набором "зашитых внутрь"  сигнатур,
в общем случае, сканируют быстрее полидетекторов с переменным  на-
бором. Обычно такие специализированные детекторы являются  состав-
ной частью полифагов. Важным их достоинством является то, что  все
они сканируют  оперативную память  и при  обнаружении резидентного
вируса либо  нейтрализуют его  в памяти  либо (что  более надежно)
предлагают перегрузиться с защищенной дискеты. Среди отечественных
полифагов  наиболее  мощными  детекторами  обладают  полифаги  SOS
E.H.Сусликова, -V Е.Н.Касперского и Aidstest Д.Н.Лозинского.
     Режим детектирования, обеспечиваемый полифагом SOS Е.Н.Сусли-
кова, обеспечивает высокую  скорость просмотра диска  (вдвое более
высокую, чем Aidstest), а при заражении SOS новым, неизвестным  ей
вирусом сигнатура этого вируса автоматически заносится в библиоте-
ку, а сам фаг самоизлечивается. Полифаг -V, работает медленнее ос-
тальных и дает больше ложных срабатываний, однако удобен тем,  что
позволяет  просмотреть  дамп  памяти  и дизассемблировать заданные
участки. В нем также реализован ряд эвристических приемов,  позво-
ляющих выявлять "подозрительные" программы, многие из которых  за-
имствованы у эвристического детектора LD Е.Н.Сусликова (см. ниже).
     Среди полидетекторов, входящих в зарубежные полифаги, следует
отметить детектор, встроенный в полифаг TNTVirus. В отличие от по-
лифага, являющегося коммерческим продуктом, полидетектор входит  в
распространяемую бесплатно демонстрационную версию. Эта громоздкая
(более 100К) программа имеет неплохой турбоинтерфейс и по количес-
тву детектируемых вирусов конкурирует с соответствующими  версиями
Scan. Качество детектирования следует оценить как среднее (в боль-
шинстве случаев используется обычный контекстный поиск). Некоторые
из  используемых  сигнатур  приведены  в  прил.1  и 2. Как и Scan,
TNTVirus уступает лучшим отечественным программам (SOS,  Aidstest)
по количеству ложных срабатываний и качеству распознавания  наибо-
лее распространенных в нашей стране вирусов.
     Второй тип полидетекторов - полидетекторы с переменным  набо-
ром сигнатур  можно рассматривать  как своего  рода системные про-
граммы общего  применения. Теоретически  их можно  использовать не
только для поиска вирусов, но и во всех случаях, когда нужно найти
все файлы, содержащие  хотя бы одно  из заданной группы  текстовых
строк (ключевых слов). Однако обычно режим поиска в них  несколько
специализирован и для поиска  в текстовых файлах они  не пригодны.
Наиболее известным среди программ этой группы является  полидетек-
тор Scan фирмы "Макафи Ассошиэйтс", в котором (для версии 80)  бо-
лее 300 "базовых" сигнатур известных вирусов "зашито наглухо",  но
пользователю  предоставлена  возможность  включать новые сигнатуры
самостоятельно.  Качество  детектирования  сравнительно  невысокое
(наблюдаются ложные срабатывания), поэтому к выдаваемым сообщениям
следует относиться критически.  В ранних версиях  Scan возможность
добавлять сигнатуры новых вирусов к "базовому набору" отсутствова-
ла и эта программа представляла один из немногих "чистых"  полиде-
текторов  с  фиксированным  набором  сигнатур. Имеется резидентная
версия Scan, проверяющая файлы при загрузке - Scanres. Однако  она
широкого распространения не получила из-за большого объема занима-
емой оперативной памяти. Некоторые из используемых данным  полиде-
тектором сигнатур приведены в прил.1 и 2.
     Как правило в этом  типе полидетекторов можно задавать  режим
сплошного поиска и набор расширений файлов, в которых будет выпол-
няться поиск. Набор сигнатур  обычно задается в виде  специального
файла. Этот  тип полидетекторов  наиболее полезен  при обнаружении
какого-то нового, еще неизвестного, вируса. Из отечественных  про-
граммы этого типа отметим полидетектор VL А.Л.Шеховцова  (прил.3).
Он обеспечивает поиск в поддереве или файле до 50 строк длиной  до
15 символов. Строки задаются пользователем в текстовом или 16-рич-
ном формате. Дамп программы, в которой найдена строка, можно  про-
смотреть на экране. В последних версиях добавлен встроенный дизас-
семблер. Недостатком полидетектора является то, что он не сканиру-
ет оперативную память.
     Эвристические полидетекторы в настоящее время находятся  лишь
в начальной стадии разработки. Пионером в этом направлении  безус-
ловно  является  Е.Н.Сусликов,  реализовавший первый отечественный
эвристический полидетектор LD.
     Программа LD Е.Н.Сусликова (Софтпанорама, 1991. Т.3. N 4) со-
четает возможности поиска вирусов по заданным сигнатурам с поиском
эвристических признаков зараженности файла. Название программы яв-
ляется сокращением  от английских  слов Lie  Detector -  "детектор
лжи". Используемые LD сигнатуры сгруппированы в два списка: список
вирусов и список исключений, вместе образующих библиотеку  LD.BIT.
Список исключений содержит сигнатуры программ, не содержащих виру-
сов, однако в теле которых встречаются сочетания используемых  эв-
ристических признаков. К  такого рода "вирусоподобным"  программам
относятся, например, программы защиты от копирования.
     Алгоритм  сканирования  LD  ориентирован  на  наиболее  часто
встречающиеся  методы  имплантации  вируса  в тело программы: если
файл начинается с команды перехода, LD сканирует хвост файла, если
нет -  сканируются как  начало файла,  так и  конец (это связано с
тем, что существует множество способов "незаметно" передать управ-
ление в конец файла).
     Если сигнатуры, содержащиеся в списке вирусов и списке исклю-
чений, в файле не найдены, то LD ищет в файле строки, которые  мо-
гут быть интерпретированы как последовательностями команд, исполь-
зуемые вирусами для размножения, например, открытие файла в режиме
записи. Конечно, такие последовательности могут содержать не толь-
ко зараженные, но и  "вполне нормальные" программы, однако  если в
программе встречается несколько характерных для вируса  признаков,
то степень правдоподобия гипотезы о зараженности данной  программы
вирусом увеличивается. Первым и самым важным из эвристических при-
знаков является наличие автобазирования. Если на начальном участке
программы LD находит строку типа:

                  CALL METKA
          METKA: POP BX

то он  считает, что  найден новый  представитель "подозрительного"
класса. Среди других используемых LD эвристических признаков отме-
тим следующие:
     - найдена текстовые строки "*.СOM", "*.EXE" или "*.*";
     - найдены строки, которые можно интерпретировать как  команды
INT 26h или INT 13h
     - то же для вызова функций MS DOS для считывания и  изменения
атрибутов файла (обычно используется вирусами для снятия  атрибута
READ ONLY);
     - то же для функций изменения даты создания файла;
     - то же для функций, передвигающих указатель чтения/записи на
конец файла;
     - то для открытия файла в режиме записи;
     - найдена сигнатура "MZ" или "ZM" в теле файла.
     Если  типичные  для  выполняемых  программ последовательности
байтов в теле программы не встречаются, то LD считает, что это за-
шифрованный код и выдает соответствующее сообщение.
     Степень правдоподобия  гипотезы о  том, что  данная программа
заражена, оценивается  по линейной  шкале и  при обнаружении более
трех эвристических признаков LD предлагает пользователю  запомнить
16-байтовую J-сигнатуру в списке вирусов.
     Конечно, не  исключены ложные  срабатывания. Такие  сигнатуры
пользователь может перенести в список исключений. В дальнейшем ни-
каких сообщений при их обнаружении  LD в обычном режиме работы  не
выдает (имеется  специальный режим  при котором  список исключений
рассматривается как часть списка вирусов).
     Теперь перейдем к критериям оценки детекторов. Если попытать-
ся перечислить критерии оценки качества детектора в порядке убыва-
ния их важности то получится следующий список:
     - проверка оперативной памяти и блокирование дальнейшей рабо-
ты при обнаружении резидентных частей вируса;
     - гибкость  и удобство  ввода сигнатур.  Наличие спецсимволов
типа "?" ("любой байт"), "*"("пропустить байты до появления следу-
ющего  символа"),  "%<целое>"  ("пропустить  заданное   количество
байт";
     -  степень  параметризации,  совместимость  по  параметрам со
Scan;
     - скорость работы;
     - возможность визуального просмотра дампа памяти и  найденных
файлов;
     - использование эвристических приемов детектирования (диагно-
стирование "подозрительных" переходов до 4К от конца файла, специ-
альных последовательностей команд и др.);
     - наличие средств  сокращения количества ложных  срабатываний
при поиске (комбинирование сигнатур, использование регулярных  вы-
ражений, определение точки входа и др.);
     - возможность выполнения операций с найденными файлами  (уда-
ление копирование, переименование и т.д.);
     - возможность привязки сигнатур к зоне файла (голова заданно-
го размера, хвост заданного размера и т.д.), типам файлов (COM или
EXE) и списку расширений;
     -  диагностирование  "спецслучаев"   типа  программ,   сжатых
Pklite, Lzexe, Diet, Exepack и др., программ c внутренней  сегмен-
тацией.
     Поясним приведенные требования. Первым критерием оценки каче-
ства детектора является наличие проверки оперативной памяти на си-
гнатуры вирусов. Дело в том,  что хотя детекторы не должны  запус-
каться на машине, загруженной с винчестера (т.е. потенциально  за-
раженной), полагаться  на добросовестность  пользователей было  бы
опрометчиво. Качественный детектор должен иметь режим выдачи  про-
токола в файл или на принтер в виде отчета, а также режим просмот-
ра дампа найденного файла на экране дисплея. Лучшие из  детекторов
(например, LD) помимо поиска сигнатур используют ряд эвристических
приемов, позволяющих выявить потенциально опасные программы. Одним
из таких приемов является интерпретация первого линейного  участка
в COM-файлах и определение расстояния от точки, в которую  переда-
ется управление,  до конца  файла. В  случае, если  это расстояние
меньше, скажем, 8K (вообще порог срабатывания следует задавать как
параметр), такую программу необходимо подвергнуть  дополнительному
анализу.
     Следует иметь в виду, что сигнатуры, используемые в  детекто-
рах часто являются весьма несовершенными, что приводит к многочис-
ленным ложным срабатываниям. При этом качество выдаваемых детекто-
рами диагностических сообщений обычно  довольно низко, а их  текст
настолько непродуман,  что вызывает  "ложную тревогу"  и различные
недоразумения. Обычно, чем более прост детектор, тем  категоричнее
выдаваемые им сообщения.  Так, большинство детекторов,  основанных
на простом поиске в файле заданных сигнатур (т.е. обладающие  теми
же  возможностями  диагностики,  что  и  Norton  Utilities  или PC
Tools), в случаях, когда она найдена, выдают сообщение типа  "Файл
XXXX заражен вирусом ZZZZ", хотя на самом деле текст должен выгля-
деть гораздо скромнее, например:

     На расстоянии YYYY от конца файла XXXX найдена строка,
                  характерная для вируса ZZZZ.

     В этом  плане характерен  пример весьма  популярного в  нашей
стране полидетектора Scan, который детектирует, пожалуй,  наиболь-
шее число известных вирусов. Этот детектор дает много ложных  сра-
батываний, причем с каждой новой версий они изменяются, но не  ис-
чезают (это легко проверить, запустив "батарею" из, скажем, десяти
последних версий Scan на один и тот же диск). Тем не менее  многие
пользователи упорно считают выдаваемую им диагностику "окончатель-
ным и не подлежащим обжалованию приговором". Автору, как редактору
бюллетеня Софтпанорама, приходится отвечать на множество  звонков,
"сигнализирующих"  о  наличии  вирусов  в  той или иной программе,
включенной в очередной выпуск  бюллетеня. На вопрос: "Как  это Вам
удалось установить?", обычно следует стандартный ответ: "С помощью
Scan". Поэтому при входном контроле программного обеспечения реко-
мендуется применять несколько детекторов ("батарею") и  рассматри-
вать выданные сообщения как результаты голосования. В спорных слу-
чаях следует  провести визуальный  анализ дампа  и трассировку на-
чального участка программы с помощью отладчика.
     Другой ошибкой, характерной  для детекторов является  пропуск
зараженных вирусом программ. Большинство детекторов (за исключени-
ем LD и детектора,  встроенного в полифаг -V)  обычно ориентирован
на конкретный набор  сигнатур и не  способны выявить новые  вирусы
или штаммы). Например, тот же Scan пропускает ряд весьма распрост-
раненных в нашей стране вирусов. Поэтому выдаваемое детекторами  в
конце работы сообщение типа

                       Нет зараженных файлов

следует рассматривать под тем  же углом, что и  предыдущее сообще-
ние. Кроме того,  пропуск зараженных программ  детектором возможен
из-за "непродуманной  оптимизации". Например,  ряд детекторов  для
повышения скорости работы сканируют не весь файл, а только его по-
следние несколько блоков или начиная с точки входа. В случае, если
вирус "аномально" сел в середину файла, он будет таким  детектором
пропущен.
     Следует также отметить, что неэффективен запуск  программ-де-
текторов для проверки архивированных файлов (т.е. файлов с  расши-
рениями .ZIP, .ARC, .ICE, .LZH и т.д.), а также сжатых  динамичес-
кими архиваторами типа Pklite, Lzexe, Diet и др. Для проверки про-
грамм, находящихся в архивированном виде, необходимо предваритель-
но их разархивировать или использовать специальную оболочку, авто-
матически разархивирующую каждый файл перед передачей детектору. В
противном случае детектор не в состоянии проверить содержимое  ар-
хива, поскольку соответствующие сигнатуры искажены в процессе сжа-
тия информации.
     Для проверки архивов c  помощью Scan удобно запускать  его из
оболочки Shez (версии 6.5 и более поздние), которая позволяет  ав-
томатически разархивировать  проверяемые файлы.  Впрочем, при  ин-
сталляции Shez вместо Scan указать любую другую антивирусную  про-
грамму (например, SOS).
     Рассмотренные выше ошибки были характерны как для детекторов,
так и для фагов, поскольку фаг обычно включает в себя детектор.
     Как  уже  указывалось,  обеспечиваемая  PC  Tools  и   Norton
Utilities возможность  выполнения контекстного  поиска как  по от-
дельным файлам, так и по диску в целом, является полезным и весьма
надежным инструментом выявления  зараженных файлов. В  особенности
полезна возможность выполнения глобального контекстного поиска  по
диску в  целом. Следует  отметить, что  Norton Utilities выполняет
контекстный поиск быстрее, чем PC Tools.

                              Фаги

     Следует отметить, что программы-фаги, обеспечивающие  возмож-
ность восстановления исходного состояния программы, зараженной ви-
русом, хотя и являются наиболее популярным типом антивирусных про-
грамм, не являются основным средством защиты от вирусов. Наблюдае-
мая сейчас  повсеместная погоня  за последними  версиями фагов  не
совсем оправдана. Основные усилия должны быть направлены на преду-
преждение  заражения  (грамм  профилактики  стоит  килограмма  ле-
карств).
     Отметим, что программы, которые мы для краткости называем фа-
гами, по сути представляют  собой комбинацию типа детектор  + фаг.
Концептуально полифаги обладают недостатком, связанным с тем,  что
жесткая привязка фага к конкретному "встроенному" детектору делает
его "заложником" качества последнего, а отсутствие параметров  на-
стройки на вирус - нечувствительным к мутациям вируса, не затраги-
вающим используемую сигнатуру. Поэтому неверное "выкусывание"  ви-
руса из зараженной программы  ("больной умер на операционном  сто-
ле") может  быть обусловлено  ложным срабатыванием  детектора (это
чаще всего случается на штаммах одного из распознаваемых  вирусов)
или недостаточным учетом возможных вариантов заражения  программы.
При этом фаг уничтожает работоспособную программу (хотя с этим ут-
верждением можно не соглашаться,  но, по мнению автора  зараженная
программа все же лучше,  чем никакая). Если не  предпринять специ-
альных мер, то обнаружение того факта, что, скажем, "доктор"  Кас-
перский в вашем конкретном случае оказался "костоломом" может ока-
заться весьма неприятным сюрпризом. При включении в фаг очередного
вируса разработчик может пропустить некоторые детали его  функцио-
нирования. При этом допущенные ошибки будут исправлены только  для
вирусов, получивших значительное распространение. Для экзотических
вирусов вероятность исправления ошибки существенно меньше.
     Поэтому при применении фагов для файловых вирусов целесообра-
зно разделять  процессы диагностирования  и "лечения",  по крайней
мере для  тех программ,  резервные копии  которых по  тем или иным
причинам отсутствуют. Можно рекомендовать следующие этапы  указан-
ного процесса:
     - загрузиться с защищенной от записи дискеты, используя  "хо-
лодную" (кнопкой  RESET или  выключением питания),  а не  "теплую"
(нажатием клавиш CTRL-ALT-DEL) перезагрузку;
     - найти хотя бы  одну зараженную программу с  помощью батареи
детекторов;
     - проверить правильность идентификации типа вируса, визуально
просмотрев дамп зараженной программы;
     - составить список зараженных программ, выгрузить их на  дис-
кету и обработать фагом;
     - проверить работоспособность "вылеченных" программ и  загру-
зить их обратно на винчестер.
     Следует отметить, что предложенные шаги в полном объеме необ-
ходимы только при работе с новым, еще недостаточно изученным виру-
сом или "самодельным" фагом.  Для хорошо изученных вирусов,  боль-
шинство из этих шагов можно опустить.
     Помимо критериев, приведенных выше для полидетекторов,  поли-
фаги можно оценивать по следующим критериям:
     - количество обрабатываемых вирусов;
     - обработка  выполняемых файлов,  сжатых Pklite,  Lzexe и  их
аналогами;
     - возможность управления  временем создания файла  (например,
сброс значения 62 с. для "излеченных" файлов);
     - самовосстановление при заражении вирусами (включая неизвес-
тные);
     - лечение многократно зараженных одним вирусом программ  (на-
пример, RCE-1813) или программ зараженных одновременно несколькими
вирусами;
     -  выдача  предупреждений  при  обнаружении файлов аномальной
структуры  или  нестандартных  случаев  заражения  (типа заражения
FOXBASE вирусом RCE-1813).
     Поясним приведенные требования. В настоящее время большинство
полифагов ориентированы на фиксированный набор вирусов и  неэффек-
тивны против  всех остальных  типов. Поэтому  качество фага прежде
всего связано  с количеством  вирусов, которые  он обрабатывает  и
правильностью его работы.  Наряду с этим  показателем немаловажное
значение имеет удобство  интерфейса и выдача  более или менее  по-
дробного отчета. Такой  отчет должен позволять  контролировать ре-
зультаты "лечения" и включать,  помимо имени файла и  типа зараже-
ния, хотя бы длину файла до и после "выкусывания". Кроме того, об-
наружив какие-либо аномалии,  фаг должен выдавать  предупреждающие
сообщения, а не "резать лишь бы резать". Наличие качественной  до-
кументации также является несомненным достоинством, но, к  сожале-
нию, среди некоммерческих программ встречается редко.
     Как уже указывалось, по выполняемым действиям фаги,  особенно
сканирующие всю файловую структуру, являются потенциально опасными
программами. Например,  некоторые фаги  проверяют тип  файла не по
его первым байтам, а по расширению, что ведет к плачевным  резуль-
татам при лечении EXE-программ с расширением COM или  COM-программ
с расширением  ЕXE. Поэтому  применять новый,  неопробованный фаг,
следует только приняв необходимые меры предосторожности, в частно-
сти  предварительно  отделив  зараженные  программы от остальных и
сняв справки до и после лечения. Кроме того, встречаются фаги, за-
раженные вирусами (часто другого типа), или даже вирусы,  замаски-
рованные под фаги (на одной из первых дискет с антивирусными  про-
граммами, распространявшейся  по стране,  имелись две  программы -
ANTI86 и ANTI87, которые  представляли собой вирус С-648  с добав-
ленными к нему для камуфляжа сообщениями).
     Подобно любой другой часто используемой программе, фаг  может
содержать троянскую  компоненту. Это,  впрочем, относится  к любой
антивирусной программе, полученной из неизвестного или  сомнитель-
ного источника. Например, на Западе в одной из сетей распространя-
лась троянская программа,  которая имитировала заставку  FluShot3,
представляясь ее новой версией  - FluShot4. При запуске  этой про-
граммы на экране появлялась заставка с запросом "Желаете ли вы ин-
сталлировать программу в систему?". Независимо от ответа пользова-
теля программа уничтожала  системные блоки винчестера  и разрушала
нулевой сектор на всех доступных дискетах.

                  1.4.2. Резидентные программы

     Большинство алгоритмов используемых в пакетных разновидностях
рассмотренных типов  антивирусных программ  можно реализовать  и в
резидентном варианте. И такие попытки делались и делаются.  Вместе
с тем резидентные программы имеют свою специфику. Главным критери-
ем для них является  объем занимаемой оперативной памяти,  степень
наводимых помех пользователю и интерференция с другими  программа-
ми.
     Что касается  объема занимаемой  памяти, то  по мнению автора
антивирусные резидентные программы, занимающие более 10% имеющейся
оперативной памяти "слишком много на себя берут". Степень  наводи-
мых помех зависит от методов контроля за обстановкой и варьируется
для различных типов программ от минимальной (дисковый драйвер, за-
щищающий отдельные  разделы и  первый трек  винчестера), до значи-
тельной (Anti4us2 и аналоги). Интерференция с другими  программами
неизбежна. Наиболее вероятна интерференция с резидентными програм-
мами. Обычно она возрастает с увеличением количества перехватывае-
мых прерываний и минимальна для антивирусных программ,  работающих
по типу драйвера.

                    Дисковые драйверы и кэши

     Некоторые дисковые драйверы и кэши помимо выполнения базисных
функций имеют дополнительные возможности, обеспечивающие  повышен-
ный уровень защиты от вирусов. К таким средствам прежде всего  от-
носится  возможность  присваивания  логическим разделам винчестера
статуса READ ONLY, что является абсолютно необходимым средством  в
современной обстановке,  в особенности  если специальный  дисковый
драйвер не используется.  Примером такого кэша  является программа
Dcache фирмы "Дейтаморфик" (Канада).

                      Резидентные детекторы

     Существует целый ряд программ этого класса и все, в общем-то,
неудачные. Как правило объем занимаемой ими оперативной памяти  не
оправдывает получаемые преимущества и такой тип программ использо-
вать не рекомендуется. В особенности не рекомендуется использовать
резидентные  детекторы,  написанные   на  языке  высокого   уровня
(SCANRES и ему подобные). Их легко обманывают стелс-вирусы.

                      Резидентные ревизоры

     В отличие от пакетных резидентные ревизоры выполняют  подсчет
контрольных сумм "на лету", т.е. при загрузке программ на выполне-
ние. Если такой ревизор не хочет быть обманут резидентным вирусом,
то он должен сам считывать в память и настраивать файл, т.е.  дуб-
лировать функции стандартного загрузчика (подсчет контрольной сум-
мы программы, загруженной в память стандартными средствами, ничего
не дает, т.к.  резидентный вирус может  "вылечить" файл перед  его
загрузкой). Поэтому этот тип антивирусных программ распространения
не получил.

                       Резидентные вакцины

     Как известно,  вакцинирование домашних  животных и  человека,
открытое Л.Пастером, является одним из фундаментальных открытий XX
века. Учитывая аналогию между компьютерными и биологическими виру-
сами, следовало бы ожидать соответствующей эффективности "киберне-
тических вакцин", которые  изменяют среду функционирования  вируса
таким образом, что он теряет способность к размножению. На  сегод-
няшний день этот тип  антивирусных программ особенно эффективен  в
обстановке учебных  компьютерных залов  и для  борьбы с  "эффектом
оседания".
     Как  уже  указывалось,  в  случае большого парка компьютеров,
эксплуатируемых  пользователями-непрофессионалами  наблюдается так
называемый "эффект оседания". Этот эффект связан с тем, что  после
уничтожения вируса на всех компьютерах, через некоторое время про-
исходит повторное заражение. Эффект оседания связан с тем, что по-
льзователи перезаражают компьютеры, переписывая, а затем  запуская
зараженные программы с  собственных дискет. Следует  отметить, что
добиться "тотальной" проверки  дискет очень сложно,  поскольку это
сопряжено с значительной работой по распаковке архивов,  определе-
нию, распаковке проверке и повторной запаковке сжатых  загрузочных
модулей и другими трудоемкими работами. Поэтому требуется длитель-
ная компания убеждения, помощь системных программистов пользовате-
лям в проверке, т.е. комплекс работ, растягивающийся на длительное
время, часто месяцы. Поскольку здесь речь идет о конкретном  виру-
се, вакцины являются оптимальным методом ликвидации повторных  за-
ражений на весь длительный период такой проверки.
     В настоящее время используются два основных типа  резидентных
вакцин: основанные на инактивированном теле вируса и основанные на
имитации действий, обеспечивающих положительный ответ на  проверку
вирусом в запускаемой  программе инсталлированной в  памяти копии.
Инактивированная вакцина может быть получена из тела вируса гораз-
до быстрее, чем написан соответствующий фаг. Поэтому этот тип вак-
цин можно рекомендовать как временную меру после обнаружения како-
го-то нового вируса. Недостатком такого подхода является необходи-
мость рабочего знания языка ассемблера. Первая вакцина, основанная
на инактивированном вирусе, была разработана Л.И.Обуховым для  ви-
руса RCE-1813 (Софтпанорама, 1991. Т.1. N 2) и применялась в Киеве
при борьбе с эпидемией указанного вируса. Наиболее мощная поливак-
цина NEATVAC с 1990 г. разрабатывается В.В.Пономаренко. Существую-
щая версия NEATVAC (Софтпанорама, 1991. Т.3. N 6) обеспечивает за-
щиту от более чем трех десятков наиболее распространенных  вирусов
и особенно удобна для вузовских машинных залов, где чаще  обычного
приходится сталкиваться с зараженными  программами. В то же  время
вакцины, как и любые дополнительные резидентные программы, не  ли-
шены побочных  эффектов, которые  могут быть  связаны с перехватом
прерываний, используемых, помимо вируса, и какой-нибудь  "нормаль-
ной" резидентной программой.
     Если говорить  о критериях  оценки поливакцин  (на самом деле
выбора здесь практически нет), то стоит отметить следующие:
     - количество обрабатываемых вирусов;
     - автотестирование на заражение;
     - нейтрализация резидентных вирусов или блокирование  запуска
на зараженной машине;
     - диагностирование зараженной программы;
     - степень наводимых помех при работе.

                         Бутовые вакцины

     В отличие от  вакцин против файловых  вирусов, представляется
возможным создать универсальную  вакцину против бутовых  вирусов и
такая  вакцина  действительно  была  создана. Она была разработана
А.В.Сессой в 1990 г.  и впервые представлена на  первой Всесоюзной
конференции "Методы  и средства  защиты от  вирусов в операционной
системе MS DOS". В дальнейшем вакцина прошла ряд версий, в 1991 г.
появился  специальная  программа  форматирования дискет (Vformat),
обеспечивающая  вакцирирование  дискет  при форматировании, однако
внедрение вакцины  шло довольно  медленными темпами.  Значительный
сдвиг был достигнут после перехода редакции бюллетеня Софтпанорама
на указанную программу форматирования для подготовки дискет с  вы-
пусками бюллетеня. В настоящее время "вакцина Сессы" получила  ши-
рокую известность и популярна практически на всей территории СССР.
     Как и файловые вакцины, универсальная бутовая вакцина  эффек-
тивна для борьбы с эффектом оседания бутовых вирусов. Вакцинирова-
ние дискет должно  быть одним из  первых мероприятий при  массовом
заражении компьютеров бутовым вирусом.

                       Pезидентные сторожа

     Современные программы-сторожа - резидентные программы,  выяв-
ляющие запуск зараженной программы и/или блокирующие предпринимае-
мые  вирусом  несанкционированные  действия,  такие, как IWP, MVT,
Inspector, File Defender и др., эффективны против большинства  из-
вестных файловых вирусов.
     Сторож  MVT  разработан  Мартиншом  Купчсом (Рига) и является
очень эффективным и удобным резидентным сторожем. Он  работоспосо-
бен для всех широко используемых версий MS DOS (MS DOS 3.30, 4.01,
5.0, DR-DOS 5.0). После запуска MVT контролирует свою  контрольную
сумму в памяти и длину файла MVT.COM на диске.
     В случае изменения контрольной суммы MVT предупреждает  поль-
зователя выдачей звукового сигнала и сообщением: ' MVT is  Damaged
! Aborted !' и прекращает работу. При обнаружении изменения  длины
файла на диске на экран выводиться сообщение : ' Invalid Lenght  +
Nh', где Nh - приращение  файла в шестнадцатиричном виде и  запрос
на создание своей незараженной копии.
     Если проверка контрольной  суммы завершилась успешно,  то MVT
определяет значение некоторых системных параметров,  просматривает
карту распределения ОЗУ, проверяет, нет ли в системе активного ви-
руса (при наличии в памяти вируса программа выдает название  виру-
са, если таковой известен, либо ' Unknown Resident Virus ').
     Если вирус не найден и при запуске указан ключ /R MVT  стано-
вится резидентным и начинает контролировать системные вызовы с це-
лью обнаружения вызова, источником которого является вирус.  Кроме
того, на каждый системный вызов  и один раз в секунду  проверяется
карту распределения  ОЗУ, что  позволяет выявлять  появление неле-
гальных резидентных программ.
     Если в потоке  системных вызовов обнаружен  "вирусный вызов",
MVT печатает на  экран краткое название  вируса и запрос  "Нажмите
ESC". После нажатия оператором ESC, MVT передает управление опера-
ционной системе или перезагружает систему.
     Сторож Inspector рассчитан только на MS DOS 3.3 и, как  пишет
автор, блокирует работу 95% всех файловых вирусов. По сравнению  с
другими сторожами  Inspector весьма  "молчалив". В  частности, нет
ложных срабатываний при операциях копирования. При  подозрительной
операции записи в COM или EXE-файл на экран выдается окошко с  со-
общением, содержащем имя файла и через какую функцию DOS  выполня-
ется запись. Для  функции 40h сообщается  также место записи(  0 -
начало, 1 -  середина, 2 -  за конец файла)  и длина записываемого
фрагмента. Нажатием ESC можно запретить запись, нажатие любой дру-
гой клавиши запись разрешает. Inspector имеют две опции: /U и /D .
Первая предназначена для деинсталляции, а вторая включает контроль
форматирования или прямой  записи на винчестер  (INT 13, INT  26).
При наличии кэша этот режим  дает много ложных срабатываний и  его
использовать не рекомендуется. Inspector занимает порядка 1K  опе-
ративной памяти, являясь  самым маленьким из  полезных резидентных
сторожей.
     Устаревшими, но все еще распространенными сторожами  являются
MaceVaccine и ANTI4US2. Возможности этих программ уже не  соответ-
ствуют уровню написания современных файловых вирусов, наличие их в
памяти создает значительные  помехи при работе,  поэтому постоянно
запускать их через AUTOEXEC.BAT не рекомендуется. Их полезно испо-
льзовать эти сторожа при первых запусках нового программного обес-
печения, когда возможно не  только заражение вирусом, но  и немед-
ленное срабатывание троянской компоненты. Следует подчеркнуть, что
наиболее  эффективно  кратковременное  применение  сторожей   типа
FluShot Plus, MaceVaccine, ANTI4US2: непрерывные ответы на  запро-
сы, выдаваемые сторожами, не только снижают эффективность  работы,
но и подрывают саму обеспечиваемую ими защиту.
     Частая выдача  запросов на  разрешение тех  или иных действий
неизбежно приводит к тому,  что пользователь начинает отвечать  на
них механически, тем самым сводя на нет обеспечиваемую ими степень
защиты. Одним из возможных путей преодоления этого недостатка  яв-
ляется использование "таблицы свойств" программы, позволяющей бло-
кировать выдачу запросов  на разрешение тех  или иных операций  от
соответствующих программ. Например, если программа FORMAT пытается
выполнять форматирование  диска С,  то запрос  на разрешение этого
действия следует блокировать. Степень обеспечиваемой сторожами за-
щиты не стоит переоценивать. Некоторые типы вирусов обходят сторо-
жей, непосредственно обращаясь к BIOS или используя сплайсинг  для
получения управления по прерыванию 21h. Поэтому их применение дол-
жно сочетаться  с применением  других средств  защиты, в частности
ревизоров. Теоретически вирус может обойти любой метод  блокирова-
ния записи, за исключением аппаратных (из упомянутых выше резиден-
тных сторожей только IWP может работать в сочетании со специальной
аппаратной платой - Port Watch Card). Однако практически сложность
вируса ограничена, и большинство техно-крыс предпочитают  "быстрые
и грязные" методы, основанные на недокументированных  особенностях
MS DOS. Это создает  хорошие предпосылки создания достаточно  уни-
версальных сторожей, создающих минимум помех при работе.
     Важным подклассом сторожей являются сторожа, использующие ме-
тод "усиления атрибута READ ONLY". Наиболее удачным представителем
этого класса сторожей является FileDefender И.А.Свиридова (Софтпа-
норама, 1991, Т.3, N.8).
     Следует отметить, что сторожа могут вызывать ложные  срабаты-
вание фагов, проверяющих содержимое оперативной памяти.  Последние
часто принимают сторожа за вирусы.
     Если говорить о критериях оценки сторожей, то наиболее важны-
ми представляются следующие:
     - степень помех при работе;
     -  блокирование  несанкционированных  попыток  записи на диск
(включая форматирование);
     - блокирование изменений в бут-секторе и MBR;
     - блокирование несанкционированной постановки программы в ре-
зидент;
     - наличие средств ведения протокола;
     - наличие звукового сигнала и возможность управления им.

   1.9.3. Типичные ошибки при применении антивирусных средств

     Как уже указывалось, самой грубой и распространенной  ошибкой
при  использовании  персональных  компьютеров  является отсутствие
надлежащей системы архивирования информации. Никакие средства  за-
щиты не заменят надлежащей организации ведения архивов.
     Другой столь  же грубой  и столь  же распространенной ошибкой
является запуск только что  полученной программы без ее  предвари-
тельного анализа на зараженность и без установки максимального ре-
жима защиты винчестера с помощью ADM и запуска резидентного сторо-
жа. Запуск  программы является  в современных  условиях далеко  не
безопасной  операцией,  и  рисковать  содержимым  винчестера из-за
чрезмерного любопытства, наверное,  не стоит. Следует  также обра-
тить внимание на ситуацию, характерную для школ и вузов. Поскольку
у студентов обычно мало дискет, то им приходится запускать отдель-
ные программы  (например, игровые)  с дискет  своих товарищей. Эта
ситуация  особенно  характерна  для  вузовских "залов персональных
ЭВМ". При  этом может  произойти заражение  одной из  программ или
бут-сектора, если  соответствующий компьютер  оказался зараженным.
Поэтому следует всегда защищать дискеты от записи, если они  испо-
льзуются для считывания  программ на нескольких  компьютерах. Сни-
мать защиту от записи стоит только на время, необходимое для обно-
вления содержимого дискеты. Новые программы по возможности следует
записывать на новые дискеты, не смешивая их со старыми,  проверен-
ными программами.
     При неправильном или неумелом использовании антивирусные про-
граммы могут сами в  ряде случаев становиться источником  проблем.
Имеется  несколько  типичных  ошибок  при  применении антивирусных
средств.
     Наиболее грубой и распространенной из них является запуск ан-
тивирусных программ (чаще  всего фагов) на  зараженном резидентным
вирусом компьютере. Конечно, сейчас создатели большинства  качест-
венных антивирусных  средств предусматривают  такую возможность  и
анализируют память компьютера  перед началом работы,  однако такая
методика эффективна,  в основном,  против уже  известных вирусов и
может не сработать на  каком-то новом. Поэтому следует  особо под-
черкнуть основной  "гигиенический" принцип  компьютерной вирусоло-
гии: все действия по исследованию "подозрительного" или зараженно-
го компьютера следует выполнять только на предварительно загружен-
ной с защищенной от записи эталонной операционной системы и  испо-
льзуя только программы, хранящиеся на защищенных от записи  диске-
тах.
     Выполнение действий по анализу и восстановлению файловой сис-
темы  при  наличии  в  памяти  резидентного вируса является грубой
ошибкой и может  иметь катастрофические последствия.  В частности,
при этом могут быть заражены остальные, еще незараженные, програм-
мы. Например, при резидентном вирусе RCE-1800.DAV запуск фага,  не
рассчитанного на данный вирус, приведет к заражению всех проверяв-
шихся фагом загрузочных модулей, поскольку вирус RCE-1800.DAV  пе-
рехватывает прерывание по  открытию и чтению  файлов и при  работе
фага будет заражать каждый проверяемый фагом файл.
     Другой типичной  ошибкой является  чрезмерная доверчивость  к
разработчикам антивирусных средств. Хотя разработкой  антивирусных
средств обычно занимаются высококвалифицированные программисты, не
следует думать, что созданные ими программы безупречны. Как и вся-
кие программы, они  содержат ошибки, причем  ситуация усугубляется
тем, что те  их части, которые  относятся к самым  новым вирусам и
тем самым представляют наибольшую ценность, часто бывают  написаны
наспех, в условиях  острейшего дефицита времени.  Поскольку вирусы
сильно различаются по степени своей распространенности, то отладка
будет выполняться лишь для наиболее распространенных вирусов (т.е.
примерно для 20% от общего количества "выкусываемых" вирусов). Для
остальных вирусов шанс на исправление допущенной при написании фа-
га ошибки невелик. Поэтому  следует считать, что на  вашей системе
выполняется отладка этих новых  частей, которая, как и  всякая от-
ладка, может иметь негативные  последствия как для отдельных  фай-
лов, так и для  файловой системы в целом.  Если у вас нет  свежего
архива, то запуск любой антивирусной программы на всю файловую си-
стему становится  потенциально опасной  операцией. Это  относится,
прежде всего, к фагам, выполняющим "хирургическое вмешательство" в
программы. Известны случаи, когда фаг принимал один вирус за  дру-
гой и все "вылеченные" программы оказывались неработоспособными.
