Как известно, вакцинирование домашних животных и человека, от-
крытое Л.Пастером, является одним из фундаментальных открытий 20
века. Учитывая аналогию между компьютерными и биологическими виру-
сами, следовало бы ожидать соответствующей эффективности "киберне-
тических вакцин", которые изменяют среду функционирования вируса
таким образом, что он теряет способность к размножению. Однако на
сегодняшний день этот тип антивирусных программ особого распрост-
ранения не получил.
В настоящее время используются два основных типа вакцин: осно-
ванные на инактивированном теле вируса и основанные на имитации
действий, обеспечивающих положительный ответ на проверку вирусом в
запускаемой программе инсталлированной в памяти копии. Инактивиро-
ванная вакцина может быть получена из тела вируса гораздо быстрее,
чем написан соответствующий фаг. Поэтому этот тип вакцин можно ре-
комендовать как временную меру после обнаружения какого-то нового
вируса. Недостатком такого подхода является необходимость рабочего
знания языка ассемблера. Первая вакцина, основанная на инактивиро-
ванном вирусе, была разработана Л.И.Обуховым для вируса RCE-1813
(СП 1-2) и применялась в Киеве при борьбе с эпидемией указанного
вируса. Наиболее мощная поливакцина была разработана студентом
КИИГА В.В.Пономаренко (СП 2-7) и получила название NEATVAC. Суще-
ствующая версия NEATVAC обеспечивает защиту от более чем десятка
резидентных вирусов и особенно удобна для вузовских машинных за-
лов, где чаще обычного приходится сталкиваться с зараженными про-
граммами. В то же время вакцины, как и любые дополнительные рези-
дентные программы, не лишены побочных эффектов, которые могут быть
связаны с перехватом прерываний, используемых помимо вируса и ка-
кой-нибудь "нормальной" резидентной программой.
10.4.7. Критерии оценки качества антивирусных программ
Общим критерием оценки любой антивирусной программы является на-
личие самотестирования на заражение и отсутствие ложных срабатыва-
ний на самом себе. Другим важным критерием є выдача более или ме-
нее подробного отчета. В настоящее время это является слабым
местом для большинства как бесплатно распространяемых, так и ком-
мерческих программ. Например для фага такой отчет должен включать
помимо имени файла и типа заражения хотя бы длину файла до и после
выкусывания. Кроме того, в случае обнаружения каких-то аномалий
фаг должен выдавать соответствующию информацию и предупреждающие
сообщения, а не "резать молча".
Наличие качественной документации также является несомненным
преимуществом, поскольку встречается крайне редко. Конечно, наши
программисты, как никто другой, приспособились обходиться без до-
кументации, однако этой их способностью нельзя злоупотреблять.
возможность управления областью поиска (глобальный, в поддереве,
в одном каталоге, в одном файле);
управление суффиксами обрабатываемых файлов;
качество интерфейса
качество диагностических сообщений;
качество выдаваемых сообщений
качество параметризации
качество документации
самотестирование на заражение;
возможность обработки файлов с атрибутами HIDDEN;
качество выдаваемого протокола;
качество документации;
размер в К;
скорость поиска.
оригинальность оформления (видео и звуковое сопровождение).
10.4.7.1. Критерии оценки качества детекторов
Если попытаться перечислить критерии оценки качества детектора в
порядке убывания их важности то получится следующий список:
проверка оперативной памяти и нейтрализация резидентных частей
вируса;
количество одновременно детектируемых вирусов;
диагностирование многократно зараженных разнотипными вирусами
файлов;
степень параметризации, совместимость по параметрам со SCAN;
удобство ввода новых сигнатур для поиска;
возможность визуального просмотра дампа найденных файлов;
использование эвристических приемов детектирования (диагностиро-
вание "подозрительных" переходов до 4К от конца файла, специальных
последовательностей команд и др.);
наличие средств сокращение количества ложных срабатываний при
поиске (комбинирование сигнатур, использование регулярных выраже-
ний, определение точки входа и др.);
операции с найденными файлами (удаление копирование, переимено-
вание и т.д.)
диагностирование "спецслучаев" типа программ, сжатых LZEXE,
EXEPACK, программ c внутренней сегментацией и др.;
Первым критерием оценки качества детектора является наличие про-
верки оперативной памяти на сигнатуры вирусов. Дело в том, что хо-
тя детекторы не должны запускаться на машине, загруженной с вин-
честера (т.е. потенциально зараженной), полагаться на
добросовестность пользователей было бы опрометчиво. Качественный
детектор должен иметь режим выдачи протокола на принтер в виде от-
чета, а также режим просмотра дампа найденного файл на экране
дисплея. Лучшие из детекторов помимо поиска сигнатур используют
ряд эвристических приемов, позволяющих выявить потенциально опас-
ные программы. Одним из таких приемов является интерпретация пер-
вой команды в COM-файлах и определение расстояния от точки, в ко-
торую передается управление, до конца файла. В случае, если это
расстояние меньше, скажем 4K (вообще порог срабатывания следует
задавать как параметр), такую программу необходимо подвергнуть до-
полнительнуму анализу.
Следует иметь в виду, что сигнатуры, используемые в детекторах
часто являются весьма несовершенными, что приводит к многочислен-
ным ложным срабатываниям. При этом качество выдаваемых детекторами
диагностических сообщений часто крайне низко, а их текст настолько
непродуман, что вызывает "ложную тревогу" и различные недоразуме-
ния. Обычно, чем более прост детектор, тем категоричнее выдаваемые
им сообщения. Так, большинство детекторов, основанных на простом
поиске в файле определенной, характерной для данного вируса строки
(т.е. обладающие теми же возможностями диагностики, что и Norton
Utilities или PC Tools) в случаях, когда она найдена, выдают "са-
моуверенное" сообщение типа:
Файл XXXX заражен вирусом ZZZZ.
На самом деле текст должен выглядеть гораздо скромнее, например:
На расстоянии YYYY от конца файла XXXX найдена строка,
характерная для вируса ZZZZ.
В этом плане характерен пример весьма популярного в нашей стране
полидетектора SCAN фирмы McAfee Associates, который детектирует
наибольшее число известных вирусов. Этот весьма низкокачественный,
по сути любительский детектор дает много ложных срабатываний, в
частности, для вирусов RC-1701 и Fu Manchu. Тем не менее пользова-
тели упорно считают выдаваемую им диагностику "окончательным и не
подлежащим обжалованию приговором". Автору, как редактору бюллете-
ня СОФТПАНОРАМА, приходится отвечать на множество звонков, "сигна-
лизирующих" о наличии вирусов в той или иной программе, включенной
в очередной выпуск бюллетеня. На вопрос, "Как это Вам удалось ус-
тановить?", обычно следует стандартный ответ: "С помощью SCAN.".
Поэтому при входном контроле программного обеспечения рекомендует-
ся применять несколько детекторов ("батарею") и рассматривать вы-
данные сообщения как результаты голосования. В спорных случаях
следует провести визуальный анализ дампа с помощью таких средств
как Norton Commander, PC Shell или Norton Utilities.
Другой ошибкой, характерной для детекторов является пропуск за-
раженных вирусом программ (детектор обычно ориентирован на конк-
ретный набор характерных для вируса строк и не может учитывать
возможность появления новых штаммов). Например, тот же SCAN про-
пускает ряд распространяющихся в нашей стране вирусов. Поэтому вы-
даваемое детекторами в конце работы сообщение типа
Нет зараженных файлов
следует рассматривать под тем же углом, что и предыдущее сообще-
ние. Кроме того, пропуск зараженных программ детектором возможен
из-за "непродуманной оптимизации". Например, ряд детекторов для
повышения скорости работы сканируют не весь файл, а только его
последние несколько блоков. В случае, если вирус "аномально" сел в
середину файла, он будет таким детектором пропущен.
Следует также отметить, что неэффективен запуск программ-детек-
торов для проверки архивированных файлов (т.е. файлов с расширени-
ями .ZIP, .ARC, .ICE, .LZH и т.д.). Для проверки программ, находя-
щихся в архивированном виде, необходимо предварительно их разархи-
вировать, или использовать специальную оболочку, автоматически ра-
зархивирующую каждый файл перед передачей детектору. В противном
случае детектор не в состоянии проверить содержимое архива, пос-
кольку соответствующие сигнатуры искажены в процессе сжатия инфор-
мации.
Для проверки архивов c помощью SCAN удобно запускать его из обо-
лочки SHEZ (версии 5.5 и более поздние), которая позволяет автома-
тически разархивировать проверяемые файлы. Это означает, что сов-
местимость со SCAN по передаваемым параметрам обеспечивает важный
и удобный режим работы. Тем самым, такая совместимость становится
важным критерием оценки качества детектора (как, впрочем, и фага).
Рассмотренные выше ошибки были характерны как для детекторов,
так и для фагов, поскольку фаг обычно включает в себя детектор.
Теперь перейдем к ошибкам, характерным только для фагов.
10.4.7.2. Сравнительный анализ полифагов
Помимо критериев, приведенных выше для полидетекторов, полифаги
можно оценивать по следующим критериям:
количество обрабатываемых вирусов;
обработка многократно зараженных файлов;
возможность управления временем создания файла (например, сброс
и установка 62 с. для заданных файлов);
самовосстановление при заражении вирусами (включая неизвестные);
лечение многократно зараженных вирусом программ (например, RCE-
1813);
выдача предупреждений при обнаружении файлов аномальной структу-
ры или нестандартных случаев заражения (типа заражения FOXBASE ви-
русом RCE-1813);
В настоящее время большинство полифагов ориентированы на фикси-
рованный набор вирусов и неэффективны против всех остальных типов.
Поэтому качество фага прежде всего связано с количеством вирусов,
которые он обрабатывает и правильностью его работы. Наряду с этим
показателем немаловажное значение имеет удобство интерфейса и вы-
дача более или менее подробного отчета. Такой отчет должен позво-
лять контролировать результаты "лечения" и включать помимо имени
файла и типа заражения хотя бы длину файла до и после "выкусыва-
ния". Кроме того, обнаружив какие-либо аномалии, фаг должен выда-
вать предупреждающие сообщения, а не "резать лишь бы резать". На-
личие качественной документации также является несомненным
достоинством, но, к сожалению, среди некоммерческих программ
встречается редко.
Как уже указывалось, по выполняемым действиям фаги, особенно
сканирующие всю файловую структуру, являются потенциально опасными
программами. Например, некоторые фаги проверяют тип файла не по
его первым байтам, а по расширению, что ведет к плачевным резуль-
татам при лечении EXE-программ с расширением COM или COMпрограмм с
расширением ЕXE. Поэтому применять новый, неопробованный фаг, сле-
дует только приняв необходимые меры предосторожности, в частности,
предварительно отделив зараженные программы от остальных и сняв
справки до и после лечения. Кроме того, встречаются фаги, заражен-
ные вирусами (часто другого типа) или даже вирусы, замаскированные
под фаги (на одной из первых дискет с антивирусными программами,
распространявшейся по стране, имелись две программы - ANTI86 и
ANTI87, которые представляли собой вирус С-648 с добавленными к
нему для камуфляжа сообщениями).
Подобно любой другой часто используемой программе, фаг может со-
держать троянскую компоненту. Например, если рассматривать пакет
антивирусных программ В.Бончева, то учитывая тот факт, что им
