Жанр: Учеба
Компьютерная вирусология ч. 1
...основу разработки технологии защиты от вирусов, состоит в создании
многоуровневой распределенной системы защиты, включающей как
регламентацию операций на ЭВМ, так и специальные программные и аппаратные
средства. При этом обязательно должно существовать несколько
уровней защиты, причем их количество может варьироваться в
зависимости от ценности информации, которая обрабатывается на конкретной
ЭВМ.
Как и в большинстве других случаев организации защиты, важным
преимуществом многоуровневой защиты является то, что наличие нескольких
уровней позволяет компенсировать недостатки, присущие тому
или иному отдельному средству защиты. Если вирус обойдет один
вид защиты, то он может "споткнуться" на другом. Автор рекомендует
схему, включающую следующие этапы:
входной контроль новых программных средств;
сегментацию информации на винчестере;
защиту 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). Методика их использования будет рассмотрена
во второй части данной работы. В случае выявления "подозрительных"
последовательностей прерываний соответствующие участки
программы следует дизассемблировать и пройти в пошаговом режиме.
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. Используйте систему "неделя-месяц-год"
Если имеется возможность, то желательно иметь несколько комплектов
дискет для архива винчестера и вести циклическую запись на эти
комплекты (например, для трех комплектов можно использовать "классический"
принцип "неделя-месяц-год"). В этом случае различают
главный архив, в котором хранится полный объем используемой информации
и программного обеспечения, и текущие архивы, в которые заносятся
только последние программные продукты и файлы. Текущих архивов
может быть несколько, в зависимости от пер
...Закладка в соц.сетях
