Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Вирусы и средства борьбы с ними КАСПЕРСКИЙ
1.История вопроса
В лекции рассказывается как и когда появились первые вирусы, их первоначальное назначение, дальнейшее развитие, мутации, принципы действия, дается перечень и краткое описание глобальных эпидемий.
2.
Теоретические сведения о компьютерных вирусах
Когда говорят о компьютерных вирусах, всегда подразумевают некий класс программ,
|
[0.0.1] Первые вирусы [0.0.2] Первые вирусные эпидемии [0.0.3] 1990 — 1998 [0.0.4] 1999 — 2000 [0.0.5] 2001 — 2005 [0.0.6] 2005 — … [0.0.7] Заключение [0.0.8] Введение [0.0.9] Результат Фреда Коэна [0.0.10] Результат Д. Чесса и С. Вайта [0.0.10.1] Основные положения [0.0.10.2] Обнаружение вирусов [0.0.10.3] Слабое определение обнаружения [0.0.10.4] Сравнение с результатом Ф. Коэна [0.0.10.5] Практические следствия [0.0.11] Формализм Ф. Лейтольда [0.0.11.1] Вычислительные модели [0.0.11.2] RASPM с присоединенным вспомогательным хранилищем [0.0.11.3] Моделирование операционных систем [0.0.11.4] Вирусы в RASPM с ABS [0.0.11.5] Проблема обнаружения вирусов [0.0.12] Результат Леонарда Адельмана [0.0.12.1] Принятые обозначения [0.0.12.2] Классификация вирусов [0.0.12.3] Обнаружение компьютерных вирусов [0.0.13] Заключение [0.0.14] Общие сведения [0.0.15] Практическое определение вируса [0.0.16] Вирусы [0.0.16.1] Жизненный цикл [0.0.16.2] Проникновение [0.0.16.3] Активация [0.0.16.4] Поиск жертв [0.0.16.5] Подготовка вирусных копий [0.0.16.6] Внедрение [0.0.17] Черви [0.0.17.1] Жизненный цикл [0.0.17.2] Каналы распространения [0.0.17.3] Способы активации [0.0.17.4] Поиск "жертв" [0.0.17.5] Подготовка копий для распространения [0.0.18] Трояны [0.0.18.1] Жизненный цикл [0.0.18.2] Способы проникновения [0.0.18.3] Активация [0.0.18.4] Выполняемые функции [0.0.18.5] Ущерб от вредоносных программ [0.0.19] Угрозы безопасности информации [0.0.19.1] Угроза нарушения конфиденциальности [0.0.19.2] Угроза нарушения целостности [0.0.19.3] Угроза нарушения доступности [0.0.20] Заключение [0.0.21] Технологии обнаружения вирусов [0.0.22] Режимы работы антивирусов [0.0.23] Антивирусный комплекс [0.0.23.1] Антивирусный комплекс для защиты рабочих станций [0.0.23.2] Антивирусный комплекс для защиты файловых серверов [0.0.23.3] Антивирусный комплекс для защиты почтовых систем [0.0.23.4] Антивирусный комплекс для защиты шлюзов [0.0.24] Комплексная система защиты информации [0.0.24.1] Организационные меры [0.0.24.2] Правовые меры [0.0.24.3] Программные средства [0.0.24.4] Этапность работ [0.0.24.5] Выбор антивирусных комплексов [0.0.25] Общие сведения [0.0.26] Возможные схемы защиты [0.0.26.1] Универсальные антивирусы для шлюзов [0.0.26.2] Антивирусы для шлюзов, основанные на интеграции [0.0.26.3] Другие реализации [0.0.27] Требования к антивирусам для шлюзов [0.0.28] Угрозы и методы защиты от них [0.0.28.1] Особенности архитектуры [0.0.28.2] Предотвращаемые угрозы [0.0.29] Эксплуатационные характеристики [0.0.29.1] Управление [0.0.29.2] Обновление [0.0.29.3] Диагностика [0.0.29.4] Производительность [0.0.30] Заключение [0.0.31] Методические указания к лабораторной работе [0.0.31.1] Состав приложения [0.0.31.2] Поддерживаемые операционные системы [0.0.31.3] Установка [0.0.31.4] Результат установки [0.0.31.5] Принципы работы [0.0.31.6] Настройка диагностики работы приложения [0.0.31.7] Обновление антивирусных баз [0.0.31.8] Настройка уведомлений пользователей [0.0.31.9] Сбор и просмотр статистической информации [0.0.31.10] Уведомление администратора посредством ISA Server Alerts [0.0.31.11] Управление лицензионными ключами [0.0.32] Задание [0.0.33] Контрольные вопросы [0.0.34] Рекомендуемая литература [0.0.35] Общие сведения [0.0.36] Возможные схемы защиты [0.0.37] Требования к антивирусному комплексу для проверки почтового потока [0.0.38] Microsoft Exchange [0.0.38.1] MAPI [0.0.38.2] ESE [0.0.38.3] VS API 1.0 [0.0.38.4] VS API 2.0 [0.0.38.5] VS API 2.5 [0.0.38.6] Заключение [0.0.39] Unix-системы [0.0.39.1] Sendmail [0.0.39.2] Postfix [0.0.40] Методические указания к лабораторной работе [0.0.40.1] Состав и принцип работы [0.0.40.2] Поддерживаемые операционные системы [0.0.41] Заключение [0.0.42] Методические указания к лабораторной работе [0.0.42.1] Состав и принцип работы [0.0.42.2] Поддерживаемые операционные системы [0.0.42.3] Установка [0.0.42.4] Результаты установки [0.0.42.5] Принципы работы [0.0.42.6] Настройка диагностики работы приложения [0.0.42.7] Обновления антивирусных баз. Источники обновлений [0.0.42.8] Работа с инфицированными и подозрительными объектами [0.0.42.9] Уведомления [0.0.42.10] Контроль вирусной активности [0.0.42.11] Отчеты об антивирусной проверке [0.0.43] Задание [0.0.44] Контрольные вопросы [0.0.45] Рекомендуемая литература [0.0.46] Общие сведения [0.0.46.1] Вопросы терминологии [0.0.46.2] Структура уровня [0.0.47] Защита рабочих станций [0.0.47.1] Классы рабочих станций [0.0.47.2] Специфические угрозы и технологии противодействия [0.0.47.3] Эксплуатационные требования и соответствующие им решения [0.0.47.4] Требования к антивирусам для рабочих станций [0.0.48] Защита серверов [0.0.48.1] Специфические угрозы и способы противодействия [0.0.48.2] Эксплуатационные требования и характеристики [0.0.48.3] Требование к антивирусам для серверов [0.0.49] Система администрирования [0.0.49.1] Цели и задачи [0.0.49.2] Структура системы администрирования [0.0.49.3] Основные требования к системе администрирования [0.0.49.4] Подсистема управления [0.0.49.5] Подсистема обновления [0.0.49.6] Подсистема диагностики [0.0.49.7] Средства внедрения [0.0.50] Заключение [0.0.51] Методические указания к лабораторной работе [0.0.51.1] Установка [0.0.51.2] Результат установки [0.0.51.3] Принципы работы программы [0.0.51.4] Проверка по требованию [0.0.51.5] Файловый антивирус [0.0.51.6] Почтовый антивирус [0.0.51.7] Веб-Антивирус [0.0.51.8] Проактивная защита [0.0.51.9] Анти-Шпион [0.0.51.10] Анти-Хакер [0.0.51.11] Анти-Спам [0.0.51.12] Технологии iChecker(tm) и iSwift(tm) [0.0.51.13] Обновления сигнатур угроз и модулей приложения [0.0.51.14] Обновляемые компоненты [0.0.51.15] Откат обновления антивирусных баз [0.0.51.16] Работа с инфицированными и подозрительными объектами [0.0.52] Задание [0.0.53] Контрольные вопросы [0.0.54] Рекомендуемая литература [0.0.55] Методические указания к лабораторной работе [0.0.55.1] Состав и структурная схема [0.0.55.2] Установка Сервера администрирования [0.0.55.3] Подключение к Серверу Администрирования [0.0.55.4] Первое подключение к Серверу администрирования [0.0.55.5] Логическая сеть [0.0.55.6] Контейнеры узла Сервера администрирования [0.0.55.7] Структура контейнера Сеть [0.0.55.8] Добавление нового инсталляционного пакета [0.0.55.9] Создание задачи удаленной установки [0.0.55.10] Создание задачи проверки по требованию [0.0.55.11] Выполнение задачи проверки по требованию [0.0.55.12] Создание задачи получения обновлений Сервером администрирования [0.0.55.13] Задача обновления клиентов [0.0.55.14] Контейнер Обновления [0.0.55.15] Смена Сервера администрирования [0.0.56] Задание [0.0.57] Контрольные вопросы [0.0.58] Рекомендуемая литература [0.0.59] Методические указания к лабораторной работе [0.0.59.1] Узел Сервера администрирования [0.0.59.2] Политики Антивируса Касперского [0.0.59.3] Иерархическое действие групповых задач [0.0.59.4] Получение сведений о лицензионных ключах [0.0.59.5] Резервное копирование базы Сервера администрирования [0.0.60] Задание [0.0.61] Контрольные вопросы [0.0.62] Рекомендуемая литература [0.0.63] Методические указания к лабораторной работе [0.0.63.1] Вирусы [0.0.63.2] Сетевые черви [0.0.63.3] Трояны [0.0.63.4] Жизненный цикл вредоносных программ [0.0.63.5] Основные пути проникновения в систему и активации [0.0.63.6] Устранение последствий заражения [0.0.64] Задание [0.0.65] Контрольные вопросы [0.0.66] Рекомендуемая литература |
1. Лекция: История вопроса
Основная отличительная характеристика компьютерного вируса — способность к самораспространению. Подобно биологическому вирусу для жизни и размножения он активно использует внешнюю среду - память компьютера, операционную систему.
Увеличение скорости передачи информации, объемов и значимости обрабатываемых в вычислительных сетях данных открывает перед вирусописателями все более широкие возможности - распространение по всему миру написанных программ занимает считанные дни или даже часы. Сотни мегабайт оперативной памяти позволяют выполнять практически любые действия незаметно от пользователя. Спектр возможных целей, таких как пароли, карточные счета, ресурсы удаленных компьютеров представляет огромное поле для деятельности. Усложнение операционных систем ведет к появлению все новых дыр, которые могут быть использованы для проникновения на удаленный компьютер.
Однако изначально компьютерные вирусы были придуманы с совершенно иной целью.
История начинается в 1983 году, когда американский ученый Фред Коэн (Fred Cohen) в своей диссертационной работе1), посвященной исследованию самовоспроизводящихся компьютерных программ впервые ввел термин компьютерный вирус. Известна даже точная дата - 3 ноября 1983 года, когда на еженедельном семинаре по компьютерной безопасности в Университете Южной Калифорнии (США) был предложен проект по созданию самораспространяющейся программы, которую тут же окрестили вирусом. Для ее отладки потребовалось 8 часов компьютерного времени на машине VAX 11/750 под управлением операционной системы Unix и ровно через неделю, 10 ноября состоялась первая демонстрация. Фредом Коэном по результатам этих исследований была опубликована работа "Computer Viruses: theory and experiments"2) с подробным описанием проблемы.
Теоретические же основы самораспространяющихся программ были заложены в 40-х годах прошлого столетия в трудах по изучению самовоспроизводящихся математических автоматов американского ученого Джона фон Неймана (John von Neumann), который также известен как автор базовых принципов работы современного компьютера. В 1951 году фон Нейманом был разработан метод, который демонстрировал возможность создания таких автоматов, а в 1959 журнал "Scientific American" опубликовал статью Л. С. Пенроуза (L. S. Penrose) "Self-Reproducing Machines", посвященную самовоспроизводящимся механическим структурам. В отличие от ранее известных работ, здесь была описана простейшая двумерная модель подобных структур, способных к активации, размножению, мутациям, захвату. Позднее, по следам этой статьи другой ученый Ф. Ж. Шталь (F. G. Stahl) реализовал модель на практике с помощью машинного кода на IBM 650.
Первые самораспространяющиеся программы не были вредоносными в понимаемом ныне смысле. Это были скорее программы-шутки либо последствия ошибок в программном коде, написанном в исследовательских целях. Сложно представить, что они были созданы с какой-то конкретной вредоносной целью.
Pervading Animal (конец 60-х - начало 70-х) — так назывался первый известный вирус-игра для машины Univac 1108. С помощью наводящих вопросов программа пыталась определить имя животного, задуманного играющим. Благодаря наличию функции добавления новых вопросов, когда модифицированная игра записывалась поверх старой версии плюс копировалась в другие директории, через некоторое время диск становился переполненным.
Первый сетевой вирус Creeper появился в начале 70-х в военной компьютерной сети Arpanet3), прототипе Интернет. Программа была в состоянии самостоятельно выйти в сеть через модем и сохранить свою копию на удаленной машине. На зараженных системах вирус обнаруживал себя сообщением: "I'M THE CREEPER : CATCH ME IF YOU CAN". Для удаления назойливого, но в целом безобидного вируса неизвестным была создана программа Reaper. По сути это был вирус, выполнявший некоторые функции, свойственные антивирусу: он распространялся по вычислительной сети и в случае обнаружения тела вируса Creeper уничтожал его.
Возможности первых вирусов были сильно ограничены малой функциональностью существующих на тот момент вычислительных машин. Только в конце семидесятых, вслед за выпуском нового поколения персональных компьютеров Apple (Apple II) и впоследствии IBM Personal Computer (1981 год), стали возможны вирусные эпидемии. Появление BBS (Bulletin Board System) обеспечило быстрый обмен информацией между даже самыми отдаленными точками планеты.
Elk Cloner (1981 год) изначально использовал для распространения пиратских копий компьютерных игр. Поскольку жестких дисков тогда еще не было, он записывался в загрузочные сектора дискет и проявлял себя переворачиванием изображения на экране и выводом текста:
ELK CLONER:
THE PROGRAM WITH A PERSONALITY
IT WILL GET ON ALL YOUR DISKS
IT WILL INFILTRATE YOUR CHIPS
YES, IT'S CLONER
IT WILL STICK TO YOU LIKE GLUE
IT WILL MODIFY RAM, TOO
SEND IN THE CLONER!
Первые антивирусные утилиты (1984 год) были написаны Анди Хопкинсом (Andy Hopkins). Программы CHK4BOMB и BOMBSQAD позволяли производить анализ загрузочного модуля с помощью контекстного поиска и перехватывать операции записи и форматирования, выполняемые через BIOS. На то время они были очень эффективны и быстро завоевали популярность.
Brain (1986 год) — первый вирус для IBM-совместимых компьютеров, вызвавший глобальную эпидемию. Он был написан двумя братьями-программистами Баситом Фарук и Амжадом Алви (Basit Farooq Alvi и Amjad Alvi) из Пакистана с целью определения уровня пиратства у себя в стране: вирус заражал загрузочные сектора, менял метку диска на "(c) Brain" и оставлял сообщение с именами, адресом и телефоном авторов. Отличительной чертой его была функция подмены в момент обращения к нему зараженного сектора незараженным оригиналом. Это дает право назвать Brain первым известным стелс-вирусом. В течение нескольких месяцев программа вышла за пределы Пакистана и к лету 1987 года эпидемия достигла глобальных масштабов. Ничего деструктивного вирус не делал.
В этом же году произошло еще одно знаменательное событие. Немецкий программист Ральф Бюргер (Ralf Burger) открыл возможность создания программой своих копий путем добавления своего кода к выполняемым DOS-файлам формата COM. Опытный образец программы, получившей название Virdem, был продемонстрирован на форуме компьютерного андеграунда - Chaos Computer Club (декабрь 1986 года, Гамбург, ФРГ). По результатами исследований Бюргер выпустил книгу "Computer Viruses. The Disease of High Technologies", послужившую толчком к написанию тысяч компьютерных вирусов, частично или полностью использовавших описанные автором идеи.
Lehigh (1987 год) — первый по-настоящему вредоносный вирус, вызвавший эпидемию в Лехайском университете (США), где в то время работал Фред Коэн. Он заражал только системные файлы COMMAND.COM и был запрограммирован на удаление всей информации на текущем диске. В течение нескольких дней было уничтожено содержимое сотен дискет из библиотеки университета и личных дискет студентов. Всего за время эпидемии было заражено около четырех тысяч компьютеров. Однако за пределы университета Lehigh не вышел.
Семейство резидентных файловых вирусов Suriv (1987 год) — творение неизвестного программиста из Израиля. Самая известная модификация, Jerusalem, стала причиной глобальной вирусной эпидемии, первой настоящей пандемией, вызванной MS-DOS-вирусом.
Действие вирусов Suriv сводилось к загрузке кода в память компьютера, перехватывании файловых операций и заражении запускаемых пользователем COM- и/или EXE-файлов. Это обстоятельство обеспечивало практически мгновенное распространение вируса по мобильным носителям. Jerusalem отличался от своих предшественников дополнительной деструктивной функцией - уничтожением всех запускаемых программ в пятницу, 13. Такой черной датой стало 13 мая 1988 года, когда в одночасье перестали работать компьютеры многих коммерческих фирм, государственных организаций и учебных заведений, в первую очередь Америки, Европы и Ближнего Востока.
Примечательно, что в том же 1988 году известный программист Питер Нортон (Peter Norton) высказался резко против существования вирусов. Он официально объявил их несуществующим мифом и сравнил со сказками о крокодилах, живущих в канализации Нью-Йорка. Это показывает сколь низка была культура антивирусной безопасности в то время.
Mike RoChenle — псевдоним автора первой известной вирусной мистификации. В октябре 1988 года он разослал на станции BBS большое количество сообщений о вирусе, который передается от модема к модему со скоростью 2400 бит/с. В качестве панацеи предлагалось перейти на использование модемов со скоростью 1200 бит/с. Как это ни смешно, многие пользователи действительно последовали этому совету.
Червь Морриса (ноябрь 1988) — с ним связана первая эпидемия, вызванная сетевым червем. 60000-байтная программа, написанная 23-летним студентом Корнельского университета (США) Робертом Моррисом, использовала ошибки в системе безопасности операционной системы Unix для платформ VAX и Sun Microsystems. С целью незаметного проникновения в вычислительные системы, связанные с сетью Arpanet, использовался подбор паролей (из списка, содержащего 481 вариант). Это позволяло маскироваться под задачу легальных пользователей системы. Однако из-за ошибок в коде безвредная по замыслу программа неограниченно рассылала свои копии по другим компьютерам сети, запускала их на выполнение и таким образом забирала под себя все сетевые ресурсы.
Червь Морриса заразил по разным оценкам от 6000 до 9000 компьютеров в США (включая Исследовательский центр NASA) и практически парализовал их работу на срок до пяти суток. Общие убытки были оценены в минимум 8 миллионов часов потери доступа и свыше миллиона часов прямых потерь на восстановление работоспособности систем. Общая стоимость этих затрат оценивается в 96 миллионов долларов. Ущерб был бы гораздо больше, если бы червь изначально создавался с разрушительными целями.
4 мая 1990 года впервые в истории состоялся суд над автором компьютерного вируса, который приговорил Роберта Морриса к 3 годам условно, 400 часам общественных работ и штрафу в 10 тысяч долларов США.
Эпидемия червя Морриса стала причиной создания организации CERT (Computer Emergency Response Team), в функции которой входит оказание содействия пользователям в предотвращении и расследовании компьютерных инцидентов, имеющих отношение к информационным ресурсам. На сайте этой организации (http://www.cert.org) оперативно публикуются самые последние сведения о новых вредоносных программах, обнаруженных уязвимостях в ПО, методах защиты корпоративных сетей, аналитические статьи, а также результаты различных исследований в области компьютерной безопасности.
Dr. Solomon's Anti-Virus Toolkit (1988) — первая широко известная антивирусная программа. Созданная английским программистом Аланом Соломоном (Alan Solomon), она завоевала огромную популярность и просуществовала до 1998 года, когда компания Dr. Solomon была поглощена другим производителем антивирусов - американской Network Associates (NAI).
Кроме официального переименования Arpanet в Интернет, следующий год ознаменовался выходом в свет первого номера Virus Bulletin (июль 1989) — самого популярного на сегодняшний день издания, содержащего последние новости в сфере вирусных и антивирусных технологий: подробную информацию о новых вредоносных программах, методах защиты от вирусов и устранения последствий заражения. Основателями журнала выступили руководители английской антивирусной компании Sophos Ян Храске (Jan Hruska), Питер Лэммер (Peter Lammer) и Эд Уайлдинг (Ed Wilding). Впоследствии редакция Virus Bulletin (1991) начала проводить ежегодные конференции для антивирусных экспертов, где корпоративные заказчики имеют возможность напрямую общаться с ведущими специалистами в этой области. В январе 1998 года была учреждена награда VB 100%, присуждаемая антивирусным программам по результатам проводимого редакцией Virus Bulletin тестирования. Количество наград VB 100%, полученных в результате тестирования сегодня зачастую является одним из основных критериев в выборе средств антивирусной защиты.
В качестве ответа через пару месяцев Dr. Solomon's запустила свой собственный издательский проект - Virus Fax International, впоследствии переименованный в Secure Computing. Сегодня этот журнал является одним из наиболее популярных изданий в области защиты информации, специализируясь на анализе не только антивирусных программ, но также всего спектра программных и аппаратных средств, применяемых для обеспечения компьютерной безопасности.
Datacrime (1989) — вирус, который несмотря на сравнительно небольшое распространение, вызвал повальную истерию в мировых средствах массовой информации. Он отличался тем, что с 13 октября по 31 декабря инициировал низкоуровневое форматирование нулевого цилиндра жесткого диска, что приводило к уничтожению таблицы размещения файлов (FAT) и безвозвратной потере данных.
В ответ корпорация IBM выпустила (4 октября 1989 года) коммерческий антивирус Virscan для MS-DOS, позволяющий искать характерные для ряда известных вирусов строки в файловой системе. Стоимость программы составила всего 35 долларов США.
Aids Information Diskette (декабрь 1989) — первая эпидемия троянской программы. Ее автор разослал около 20000 дискет с вирусом по адресам в Европе, Африке и Австралии, похищенным из баз данных Организации всемирного здравоохранения и журнала PC Business World. После запуска вредоносная программа автоматически внедрялась в систему, создавала свои собственные скрытые файлы и директории и модифицировала системные файлы. Через 90 загрузок операционной системы все файлы на диске становились недоступными, кроме одного - с сообщением, предлагавшим прислать $189 на указанный адрес. Автор троянца, Джозеф Попп (Joseph Popp), признанный позднее невменяемым, был задержан в момент обналичивания чека и осужден за вымогательство. Фактически, Aids Information Diskette - это первый и единственный вирус, для массовой рассылки использовавший настоящую почту.
Cascade (1989) — резидентный зашифрованный вирус, вызывающий характерный видеоэффект - осыпание букв на экране. Примечателен тем, что послужил толчком для профессиональной переориентации Евгения Касперского на создание программ-антивирусов, будучи обнаруженным на его рабочем компьютере. Уже через месяц второй инцидент (вирус Vacsina) был закрыт при помощи первой версии антивируса — V, который несколькими годами позже был переименован в AVP — AntiViral Toolkit Pro.
Eddie (также известен как Dark Avenger, 1989 год) — первый вирус, противодействующий антивирусному программному обеспечению: он заражает новые файлы, пока антивирус проверяет жесткий диск компьютера. Это достигалось применением особой технологии, позволяющей заражать не только COM/EXE- программы в момент их запуска, но и любые файлы при попытке прочтения.
Начиная с 1990 года проблема вирусов окончательно утрачивает связь с научными кругами и становится достоянием рядовых программистов, преследующих личные цели.
В Болгарии открывается первая BBS (VX BBS), ориентированная на обмен вирусами и информацией для вирусописателей. Чуть позже начинают появляться конференции Usenet по вопросам написания вирусов.
Chameleon (начало 1990 года) — первый полиморфный вирус. Его автор, Марк Уошбурн (Mark Washburn) за основу для написания программы взял сведения о вирусе Vienna из книги Ральфа Бюргера "Computer Viruses. The Disease of High Technologies" и добавил к ним усовершенствованные принципы самошифрации вируса Cascade - свойство изменять внешний вид как тела вируса, так и самого расшифровщика. Только в 1992 году был изобретен достаточно эффективный способ нейтрализации полиморфных вирусов - эмулятор процессора для дешифрации кодов. Эта технология является неотъемлемым атрибутом каждого современного антивирусного продукта.
DiskKiller (январь 1989 года — июль 1990 года) — этим вирусом была заражена дискета бесплатного приложения к английскому компьютерному журналу PC Today. В июле 1990 года подписчикам разошлось около 50000 экземпляров. Действие DiskKiller сводилось к уничтожению всей информации на жестком диске.
В это же время впервые были обнаружены и первые российские вирусы — Peterburg, Voronezh и ростовский LoveChild.
EICAR (European Institute for Computer Anti-virus Research) — в декабре 1990 года в Гамбурге (Германия) был основан Европейский институт компьютерных антивирусных исследований. Заплатив организационный взнос, его членом может стать любой человек, государственная или частная структура и в течение срока подписки получать оперативную информацию о ситуации в области антивирусной защиты и компьютерной безопасности в целом, а также консультации известных специалистов. Широкому кругу пользователей эта организация известна по созданному ею файлу eicar.com, который детектируется всеми известными антивирусными программами как вирус - например, с именем EICAR-Test-File. Однако никакого вреда он не приносит и служит лишь как средство проверки работоспособности антивируса. Загрузить eicar.com можно с eicar.org или же написать лично, следуя рекомендациям, размещенным на этом сайте.
Несмотря на громкое заявление Питера Нортона, прозвучавшее двумя годами ранее и где он авторитетно заявлял о надуманности проблемы вирусов, в конце 1990 года вышла первая версия антивирусной программы Norton AntiVirus.
Dir_II (лето 1991 года) — вирус, использовавший принципиально новый способ заражения — link-технологию. На сегодняшний день он остается единственным представителем этого класса, который был обнаружен в диком виде.
MtE (MuTation Engine, 1991 год) — первый известный полиморфик-генератор. Его главное предназначение — возможность интеграции в другие вирусы для обеспечения их полиморфизма. MtE поставлялся в виде готового объектного модуля и сопровождался подробной документацией.
Годом позднее, в июле 1992 года появился первый конструктор вирусов VCL (Virus Creation Laboratory), представляющий собой графическую среду для разработки вирусов и различных троянских программ для MS DOS. Начиная с этого момента, любой человек мог легко сформировать и написать вирус.
Win.Vir (конец 1992 года) — первый вирус, поражающий исполняемые файлы Microsoft Windows 3.1. Эпидемии не вызвал и его появление осталось практически незаметным. Однако именно Win.Vir положил начало эпохи вирусов для Windows.
Далее события начинают развиваться с невероятной скоростью.
Shifter (январь 1994) — первый вирус, заражающий объектные модули (OBJ-файлы).
SrcVir (апрель 1994) — семейство вирусов, заражающих исходные тексты программ (C и Pascal).
OneHalf (июнь 1994) — очень сложный резидентный файлово-загрузочный полиморфный вирус, вызвавший глобальную эпидемию во всем мире, в том числе в России. OneHalf заражал загрузочные сектора дисков и COM/EXE-файлы, увеличивая их размер на 3544, 3577 или 3518 байта, в зависимости от модификации. При каждой перезагрузке зараженного компьютера зашифровывались два последних незашифрованных ранее цилиндра жесткого диска. Это продолжалось до тех пор, пока весь винчестер не оказывался зашифрованным. Встроенная стелс-процедура позволяла вирусу при запросе зашифрованной информации производить расшифровку на лету - следовательно, пользователь долгое время пребывал в неведении. Единственным визуальным проявлением вируса было сообщение "Dis is one half. Press any key to continue...", выводившееся в момент достижения количеством зашифрованных цилиндров диска половины от их общего числа. Однако при первой же попытке лечения, после вылечивания загрузочных секторов диска, вся информация на винчестере становилась недоступной, без возможности восстановления. Популярности этого вируса в России поспособствовала компания Доктор Веб, которая выпустила новую версию своего антивируса, анонсировав его как средство от OneHalf. Однако на практике после лечения загрузочных секторов от этого вируса, Dr.Web забывал расшифровать информацию на диске и восстановить ее было уже невозможно.
Следующий год запомнился инцидентом в корпорации Microsoft. В феврале 1995 года, в преддверии выпуска новой операционной системы Windows 95 была разослана демонстрационная дискета, зараженная загрузочным вирусом Form. Копии этого диска получили 160 бета-тестеров, один из которых не поленился провести антивирусную проверку.
Вслед за Microsoft отличились журналы PC Magazine (английская редакция) и Computer Life, которые разослали своим подписчикам дискеты, зараженные загрузочными вирусами Sampo и Parity_Boot соответственно.
Concept (август 1995) — первый макровирус, поражавший документы Microsoft Word.
Green Stripe (1995) — первый вирус для AmiPro, популярного в то время текстового редактора. Исходный код Green Stripe был бесплатным приложением к полуподпольному изданию Марка Людвига (Mark Ludwig) "Underground Technology Review".
15 ноября 1995 года Кристофер Пайл (Christopher Pile), известный под псевдонимом Black Baron, автор вирусов Queeg и Pathogen и полиморфик-генератора SMEG был приговорен к 18 месяцам тюремного заключения.
Boza (январь 1996) — первый вирус для операционной системы Microsoft Windows 95.
Win.Tentacle (март 1996) — вызвал первую эпидемию среди пользователей Microsoft Windows 3.х.
Wazzu — вирус, ставший причиной очередного вирусного инцидента в Microsoft. Он был обнаружен в одном из документов Word на веб-сайте корпорации. Позднее Wazzu был найден также на компакт-дисках, распространенных Microsoft на выставке компьютерных технологий Orbit (г. Базель, Швейцария), а в сентябре - на компакт-дисках Microsoft Solution Provider.
Win95.Punch (декабрь 1996) — первый резидентный вирус для Windows 95. Он загружался в систему как VxD-драйвер, перехватывал обращения к файлам и заражал их.
Linux.Bliss (февраль 1997) — первый вирус для операционной системы Linux.
ShareFun (март 1997) — первый макро-вирус для MS Word 6/7, использующий для своего распространения возможности электронной почты, в частности, почтовую программу MS Mail.
Homer (апрель 1997) — первый сетевой вирус-червь, использующий протокол передачи данных File Transfer Protocol (FTP).
В декабре 1997 года, вскоре после разработки технологии IRC (Internet Relay Chat), образовался новый класс вредоносных программ — IRC-черви.
Win95.HPS и Win95.Marburg (февраль 1998) — первые полиморфные Windows32-вирусы. Marburg известен также тем, что им были заражены компакт-диски, сопровождавшие английскую, словенскую, шведскую и итальянскую редакции журнала PC Gamer.
В июне 1998 года был обнаружен вирус тайваньского происхождения Win95.CIH, содержащий логическую бомбу на уничтожение всей информации на жестких дисках и порчу содержимого BIOS на некоторых материнских платах. Дата срабатывания программы (26 апреля) совпадала с датой аварии на Чернобыльской атомной электростанции, вследствие чего вирус получил второе имя — Чернобыль (Chernobyl). Масштабность эпидемии выяснилась 26 апреля 1999 года, когда по различным оценкам пострадало около полумиллиона компьютеров по всему миру, а общий ущерб составил сотни миллионов долларов США. Центром эпидемии стала Южная Корея, где было заражено более 300 тысяч компьютеров. В России Win95.CIH поразил не менее 100 тысяч машин.
BackOrifice, Backdoor.BO (август 1998) — первая известная утилита скрытого администрирования удаленных компьютеров. Единственное отличие этого трояна от обычных программ для удаленного управления - несанкционированная установка и запуск. Действие утилиты сводилось к скрытому слежению за системой: ссылка на троянца отсутствовала в списке активных приложений, но при этом зараженный компьютер был открыт для удаленного доступа. Фактически, открывался свободный вход на зараженные компьютеры для других вредоносных программ - впоследствии возник целый класс червей, размножение которых базировалось на оставленных BackOrifice дырах.
Во второй половине 1998 года вирусы активно начинают осваивать новые технологии: Java.StangeBrew — первый вирус, который заражал выполняемые модули Java, VBScript.Rabbit — скрипты Visual Basic (VBS-файлы), HTML.Internal — первый HTML-вирус.
Следующий период вирусной истории прошел под знаменем массовых рассылок по электронной почте.
Happy99 (также известный как Ska, январь 1999 года) — первый интернет-червь, использовавший для своего распространения программу MS Outlook.
26 марта 1999 года началась глобальная эпидемия вируса Melissa — первого макро-вируса для MS Word, сочетавшего в себе также и функциональность интернет-червя. Сразу же после заражения системы он считывал адресную книгу почтовой программы MS Outlook и рассылал по первым 50 найденным адресам свои копии. Подобно Happy99 вирус Melissa делал это абсолютно незаметно для пользователя и, что самое страшное, от его имени. Microsoft, Intel, Lockheed Martin были вынуждены временно отключить свои корпоративные службы электронной почты. По разным оценкам совокупный ущерб от вируса варьировался от нескольких миллионов до десятков миллионов долларов США.
Через некоторое время был обнаружен и арестован автор вируса Melissa, Дэвид Л. Смит (David L. Smith). 9 декабря он был признан виновным и осужден на 10 лет тюремного заключения и к штрафу в размере 400000 долларов США.
ZippedFiles (также известный как ExploreZip, июнь 1999 года) — первый упакованный интернет-червь. Его тело было упаковано утилитой сжатия Neolite, обращаться с которой в то время антивирусные продукты не умели, что привело к эпидемии.
Bubbleboy (ноябрь 1999) — первый вирус из поколения червей-невидимок, распространявшихся по электронной почте без использования вложенных файлов и проникавших на компьютеры сразу же после прочтения зараженного письма. Все вирусы этого типа используют различные уязвимости в системе безопасности Internet Explorer.
Babylonia (декабрь 1999) — первый вирус-червь, который имел функции удаленного самообновления: он ежеминутно пытался соединиться с сервером, находящемся в Японии и загрузить оттуда список вирусных модулей.
LoveLetter — скрипт-вирус, 5 мая 2000 года побивший рекорд вируса Melissa по скорости распространения. Всего в течение нескольких часов были поражены миллионы компьютеров - LoveLetter попал в Книгу Рекордов Гиннеса. Успех гарантировали методы социальной инженерии: электронное сообщение имело тему "I love you" и интригующий текст, призывающий открыть вложенный файл с вирусом.
Liberty (август 2000) — первая вредоносная программа класса троянский конь для операционной системы PalmOS карманных компьютеров Palm Pilot.
Stream (сентябрь 2000) — первый известный вирус, способный манипулировать дополнительными потоками (ADS) файловой системы NTFS.
Pirus (октябрь 2000) — первый вирус, написанный на скрипт-языке PHP.
Fable (октябрь 2000) — первый вирус, скрывающийся в информационных файлах PIF.
Hybris (ноябрь 2000) — опасный и технологически совершенный вирус, главным нововведением которого было использование как веб-сайтов, так и электронных конференций (в частности alt.comp.virus) для загрузки новых модулей вируса на зараженные компьютеры. Кроме того, для идентификации настоящих вирусных модулей, т. е. действительно выпущенных автором, Hybris использовал 128-битных электронный ключ RSA для их шифрования.
Самые известные вирусы этой эпохи, такие как CodeRed или Nimda, продемонстрировали сочетание способности к практически мгновенному распространению и существенно усложненную, многоуровневую структуру. Фактически, можно выделить такие тенденции: расширение спектра путей и методов проникновения, использование новых платформ и технологий, обновление вирусных кодов через Интернет, новые вредоносные функции и активное противодействие антивирусным программам.
Ramen (январь 2001) — вирус, за считанные дни поразивший большое количество крупных корпоративных систем на базе операционной системы Linux.
Sadmind (май 2001) — первый известный интернет-червь, заражающий компьютеры Sun Sparc с операционной системой Solaris/SunOS. Для размножения использовалась брешь в службе системного администрирования /usr/sbin/sadmind. Червь также атаковал HTTP-серверы с установленным Microsoft Internet Information Server (IIS).
CodeRed (12 июля 2001 года) — представитель нового типа вредоносных кодов, способных активно распространяться и работать на зараженных компьютерах без использования файлов. В процессе работы такие программы существуют исключительно в системной памяти, а при передаче на другие компьютеры - в виде специальных пакетов данных. Для проникновения на удаленные компьютеры CodeRed использовал брешь в системе безопасности IIS, которая позволяет злоумышленникам запускать на удаленных серверах посторонний программный код. 18 июня 2001 года Microsoft выпустила соответствующую заплатку, однако подавляющее большинство пользователей не успело вовремя обновить свое программное обеспечение.
CodeRed вызвал эпидемию, заразив около 12000 (по другим данным - до 200000) серверов по всему миру и провел крупномасштабную DDoS1) атаку на веб-сервер Белого дома, вызвав нарушение его нормальной работы.
Через неделю, 19 июля появилась новая модификация CodeRed, показавшая чудеса распространения - более 350000 машин за 14 часов (до 2000 компьютеров в минуту). Однако по замыслу автора 20 июля вирус прекратил свое распространение.
Следующая версия, CodeRed.c (CodeRed II) была обнаружена 4 августа 2001 года. После заражения (использовалась все та же брешь в системе безопасности IIS) вирус ничем не выдавал свое присутствие один-два дня, после чего перезагружал компьютер и начинал активные попытки распространения, продолжавшиеся 24 часа (или 48, в случае использования китайской раскладки). Червь также устанавливал троянскую программу explorer.exe и использовал встроенную бекдор-процедуру (Backdoor).
В это же время был обнаружен почтовый червь Sircam (12 июля 2001 года). Этот вирус отличала необычная процедура выбора имени зараженного вложения. Для этого случайным образом на диске выбирался документ, к имени которого добавлялось расширение .pif, .lnk, .bat или .com. Полученная конструкция вида mydiary.doc.com служила темой рассылаемых писем и именем новой копии программы: к отобранному файлу и дописывался код червя - таким образом Sircam мог привести к утечке конфиденциальной информации. При рассылке использовался собственный SMTP-клиент, в поле От указывался один из адресов, найденных на зараженном компьютере, а сообщение содержало текст вида "Hi! How are you? I send you this file in order to have your advice. See you later. Thanks." Кроме этого, в определенный момент времени (в зависимости от системного времени и модификации вируса) на зараженном компьютере удалялись все файлы на системном диске.
Nimda (18 сентября 2001 года) — вирус-червь, в течение 12 часов поразивший до 450000 компьютеров. Для распространения были задействованы пять методов: электронная почта (брешь в системе безопасности Internet Explorer, позволяющая автоматически выполнять вложенный исполняемый файл), по локальной сети, внедрение на IIS-серверы, заражение браузеров через javascript, а также с помощью бекдор-процедур, оставленных CodeRed.c и Sadmind. После заражения Nimda добавлял в группу Администраторы пользователя под именем Guest и открывал локальные диски на полный доступ для всех желающих.
Klez (октябрь 2001) — почтовый червь, модификации которого на протяжении следующих нескольких лет занимали первые строки в рейтингах популярности. Программа проникала на компьютер по сети или через электронную почту, используя брешь в защите IFrame браузера Internet Explorer, которая допускала автоматический запуск вложенного файла. Также вирус имел встроенную функцию поиска и подавления антивирусного программного обеспечения. Klez дописывал свой код к одному из документов на зараженной машине и начинал массовую рассылку. В поле От подставлялся любой адрес, найденный на компьютере или же случайно сгенерированный. При этом список всех обнаруженных на зараженном компьютере адресов электронной почты также присоединялся к вложению. Кроме рассылки своих копий, червь обнаруживал себя по 13-м числам четных месяцев или шестым нечетных, в зависимости от модификации: в такой день все файлы на зараженных компьютерах заполнялись случайным содержимым.
Tanatos/Bugbear (октябрь 2001) — почтовый червь, устанавливающий бекдор-процедуру (Backdoor) и троян — клавиатурный шпион. Процедура распространения практически списана с Klez - копирование по сети, массовая рассылка с зараженным документом во вложении, использование уязвимости IFrame в Internet Explorer, подавление антивирусных программ. Кроме увеличения трафика, вирус проявлял себя спонтанной печатью разнообразного мусора на сетевых принтерах.
В январе 2003 года грянула эпидемия интернет-червя Slammer, заражающего сервера под управлением Microsoft SQL Server 2000. Вирус использовал брешь в системе безопасности SQL Server, заплата к которой вышла в июле 2002. После проникновения червь начинает в бесконечном цикле посылать свой код на случайно выбранные адреса в сети - только за первые 10 минут было поражено около 90% (120 000 единиц) всех уязвимых серверов, при этом пять из тринадцати главных DNS-серверов сети Интернет вышли из строя.
Slammer имел крайне небольшой размер - всего 376 байт (CodeRed - 4 КБ, Nimda - 60 КБ) и присутствовал только в памяти зараженных компьютеров. Более того, при работе червя никакие файлы не создавались, и червь никак не проявлял себя (помимо сетевой активности зараженного компьютера). Это означает, что лечение заключается только в перезагрузке сервера, а антивирусы в данной ситуации бессильны.
В августе 2003 года около 8 миллионов компьютеров во всем мире оказались заражены интернет-червем Lovesan/Blaster. Для размножения использовалась очередная брешь - на этот раз в службе DCOM RPC Microsoft Windows. Кроме того, вирус включал в себя функцию DDoS-атаки на сервер с обновлениями для Windows.
Неделей позже новый вирус, Sobig.f, установил новый рекорд по скорости - доля зараженных им писем доходила до 10 % от всей корреспонденции. Это достигалось использованием спамерских технологий. Sobig.f также инициировал цепную реакцию: каждый новый вариант червя создавал сеть инфицированных компьютеров, которая позднее использовалась в качестве платформы для новой эпидемии. Однако конец эпидемии запрограммировал сам автор - 10 сентября 2003 года Sobig.f прекратил размножение.
Swen (также известный как Gibe, сентябрь 2003) — яркий пример удачного использования методов социальной инженерии. Этот вирус-червь распространялся по электронной почте в виде письма якобы от Microsoft Corporation Security Center и с темой "Internet Security Update". Во вложении находился файл с именем q216309.exe, а в самом сообщении говорилось о необходимости срочной установки вложенной заплатки.
Следующий год принес популярность новой технологии распространения вредоносных программ - путем рассылки, по электронной почте или с помощью интернет-пейджера, сообщения со ссылкой, ведущей на сайт с трояном.
Mitglieder (январь 2004 года) — троянский proxy-сервер, ссылка на зараженный этой программой сайт была разослана злоумышленником на тысячи адресов ICQ. Mitglieder проникал на компьютер через уязвимость в Microsoft Internet Explorer, позволявшую установить и запустить proxy-сервер на зараженной машине без ведома пользователя. После заражения открывался порт, используемый для рассылки спама. Таким образом, зараженные машины образовывали сеть машин-зомби (ботнет), которыми можно удаленно управлять, чем вскоре и воспользовались авторы новых вредоносных программ.
Буквально через месяц, в феврале 2004 года появился Bizex (также известный как Exploit) — первый ICQ-червь. Для распространения использовалась массовая несанкционированная рассылка по ICQ сообщения "http://www.jokeworld.biz/index.html :)) LOL". Получив от знакомого человека такую ссылку, ничего не подозревающая жертва открывала указанную страницу и в случае, если использовался браузер Internet Explorer с незакрытой уязвимостью, на компьютер загружались файлы червя и в некоторых случаях сопутствующего трояна. После установки в систему, Bizex закрывал запущенный ICQ-клиент и подключившись к серверу ICQ с данными зараженного пользователя начинал рассылку по найденным на компьютере спискам контактов. Одновременно происходила кража конфиденциальной информации - банковские данные, различные логины и пароли.
В этом же 2004 году разразилась так называемая война вирусописателей. Несколько преступных группировок, известных по вирусам Bagle, Mydoom и Netsky выпускали новые модификации своих программ буквально каждый час. Каждая новая программа несла в себе очередное послание к противостоящей группировке, изобилующее нецензурными выражениями, а Netsky даже удалял любые обнаруженные экземпляры вирусов Mydoom и Bagle.
Почтовый червь Bagle впервые был обнаружен 18 января 2004 года. Для распространения он использовал собственный SMTP-клиент, код вируса пересылался во вложении с произвольным именем и расширением .exe. Рассылка производилась на адреса, найденные на зараженном компьютере. Также Bagle содержал встроенную backdoor-процедуру, открывающую порт 6777 на запуск команд и загрузку любых файлов. Следующие модификации содержали процедуры распространения через P2P-сети, методы социальной инженерии, активно противодействовали антивирусному программному обеспечению.
Mydoom известен прежде всего массированной 12-дневной DDoS-атакой на веб-сайт компании SCO, начавшейся 1 февраля 2004 года. За пару часов работа сервера была полностью парализована и вернуться в нормальный режим www.sco.com смог только 5 марта. В ответ руководители SCO объявили награду в размере 250 тысяч долларов США за информацию об авторе червя.
Для распространения Mydoom использовал почтовую рассылку через собственный SMTP-клиент, а также P2P-сети (Kazaa).
Первая модификация почтового червя NetSky (также известен как Moodown) была обнаружена 16 февраля. Кроме электронной почты, для распространения были задействованы P2P и локальные сети. Вторая модификация NetSky отличилась тем, что в силу человеческого фактора ею были заражены тысячи писем, отправленных известным финским производителем антивирусного ПО - компанией F-Secure своим клиентам.
Sasser (май 2004) — поразил более 8 млн. компьютеров, убытки от этого червя оцениваются в 979 млн. долларов США. Для проникновения Sasser использовал уязвимость в службе LSASS Microsoft Windows.
Cabir (июнь 2004) — первый сетевой червь, распространяющийся через протокол Bluetooth и заражающий мобильные телефоны, работающие под управлением OS Symbian. При каждом включении зараженного телефона вирус получал управление и начинал сканировать список активных Bluetooth-соединений. Затем выбирал первое доступное соединение и пытался передать туда свой основной файл caribe.sis. Ничего деструктивного Cabir не делал - только снижал стабильность работы телефона за счет постоянных попыток сканирования активных Bluetooth-устройств.
Вскоре (август 2004) появились и вирусы для PocketPC — классический вирус Duts и троянская программа Brador.
Однако вредоносные программы — это не только вирусы и трояны. К этому классу в полной мере можно отнести и adware — программы, которые отображают на экране рекламу без ведома и согласия пользователя, и pornware — программы, самостоятельно инициирующие соединения с платными порнографическими сайтами. Начиная с 2004 отмечается широкое распространение использования вирусных технологий для установки adware/pornware на целевые компьютеры.
Этот год также запомнился масштабными арестами вирусописателей - было осуждено около 100 хакеров, причем трое из них находились в двадцатке самых разыскиваемых ФБР преступников.
В 2005 году наметился некоторый спад активности почтовых червей. Фактически, после Mydoom, NetSky и Bagle до середины лета 2005 года не наблюдалось ни одной сколько-нибудь значительной эпидемии. Это может свидетельствовать об успешности новых технологий распространения вредоносных программ на фоне значительных достижений антивирусных компаний.
Поэтому пальму первенства перехватили сетевые черви и программы, использующие для распространения различные интернет-пейджеры (прежде всего MSN Messenger). Первые активно используют бреши в операционных системах Microsoft Windows - чаще всего это уязвимости в службах RPC DCOM и LSASS, а также дыры, оставленные прошедшими ранее эпидемиями: это позволяет создавать ботнеты, включающий тысячи компьютеров-зомби. Вторые - пользуются некомпетентностью и отсутствием опыта создателей программ обмена сообщениями в упреждении вирусных инцидентов.
Однако, глобальных эпидемий в первой половине 2005 зафиксировано не было. Это не означает уменьшение числа вирусов - наоборот, с каждым днем их появляется все больше. Но при этом можно отметить увеличение избирательности вредоносных программ - становятся популярны черви, главной целью которых является похищение определенной информации. Кроме уже ставших привычными краж номеров кредитных карт, участились случаи воровства персональных данных игроков различных онлайновых игр - Ultima Online, Legend of Mir, Lineage, Gamania. В России также зафиксированы случаи с игрой "Бойцовский клуб", где реальная стоимость некоторых предметов на аукционах достигает тысяч долларов США.
Развитие получили и вирусные технологии для мобильных устройств. Созданы вирусы всех трех типов - классические вирусы, черви и троянские программы. В качестве пути проникновения используются не только Bluetooth-устройства, но и обычные MMS-сообщения (червь ComWar).
Отличие ученого от вирусописателя состоит в целях, которые преследует автор программы. Вирусы могут не только воровать кредитные карты и рассылать от чужого имени спам. С помощью самораспространяющих программ возможно моделирование в компьютерных системах искусственной жизни, воспроизведение поведения взаимодействующих друг с другом и эволюционирующих живых организмов.
Придуманный Фредом Коэном термин вирус изначально не нес негативной нагрузки. Однако с появлением первых вредоносных программ сформировалось общественное мнение, что вирус - значит плохо. Это практически поставило крест на исследованиях, посвященных разработке таких вирусов, которые вместо вреда приносили бы некоторую пользу - в этом случае получив некоторую выгоду, пользователь предоставлял бы возможность программе свободно развиваться и эволюционировать. Но по состоянию на сегодняшний день, можно уверенно констатировать: встречающиеся в живом виде вирусы несут угрозу нормальному функционированию компьютерных систем.
Подтверждением этому может служить статистика - в современном Интернет в среднем каждое тридцатое письмо заражено почтовым червем, около 70% всей корреспонденции - нежелательна. С ростом сети Интернет увеличивается количество потенциальных жертв вирусописателей, выход новых систем и платформ влечет за собой расширение спектра возможных путей проникновения в систему и вариантов возможной вредоносной нагрузки для вирусов. Современный пользователь компьютера не может чувствовать себя в безопасности перед угрозой стать объектом чей-то злой шутки - например, уничтожения информации на винчестере - результатов долгой и кропотливой работы, или кражи пароля на почтовую систему. Точно так же неприятно обнаружить себя жертвой массовой рассылки конфиденциальных файлов или ссылки на порно-сайт. Поэтому при выявлении антивирусным комплексом вируса можно однозначно сказать, что это - вредоносная программа.
Цель данного курса состоит в изложении основ антивирусной защиты, которая за последние десятилетия не отставала в развитии от эволюции вредоносных программ. За это время были разработаны эффективные методики построения комплексов антивирусной безопасности, позволяющие снизить вероятность заражения компьютерной сети каким-либо вирусом или другой вредоносной программой практически до нуля. Однако стопроцентную безопасность не может гарантировать никто. Поэтому для сведения возможности заражения к минимуму необходимо четко понимать принципы работы антивирусного программного обеспечения и неукоснительно следовать всем правилам и рекомендациям.
2. Лекция: Теоретические сведения о компьютерных вирусах
Когда говорят о компьютерных вирусах, всегда подразумевают некий класс программ, обладающих определенными свойствами. Кроме того, для каждого нового вируса существует некая процедура согласно которой антивирусные эксперты решают - вирус это или нет, прежде чем вносить его сигнатуру в вирусную базу.
В связи с этим возникает вопрос о возможности формализовать эту процедуру выяснения относится ли программа к классу вирусов. Этой проблемой занимались многие исследователи еще с первой половины 80-х годов XX века. И самым первым из них был Фред Коэн.
В 1984 г. в своей работе "Computer Viruses - Theory and Experiments" Фред Коэн показал, что задача обнаружения компьютерных вирусов является неразрешимой. При этом он руководствовался следующими рассуждениями.
Отправной точкой был выбор определения вируса:
Определение 2.1. Компьютерным вирусом является программа, способная заражать другие программы изменяя их таким образом, чтобы они включали возможно измененную копию вируса.
Следовательно, чтобы определить, является ли программа P вирусом, необходимо выяснить заражает ли она другие программы. Предположим, существует процедура D, позволяющая по любой программе P сказать вирус это или нет. Но тогда можно составить программу V, которая будет включать процедуру D и будет заражать другие программы только в том случае, когда D не определит V как вирус и не будет заражать в противном случае.
Соответственно, если процедура D, будучи примененной к программе V, скажет, что это вирус, программа V на самом деле не будет заражать файлы и не будет вирусом согласно определению. И наоборот, если согласно процедуре D программа V не является вирусом, на самом деле она будет заражать другие программы, а значит будет вирусом.
Таким образом, гипотетическая процедура D оказывается противоречивой и, следовательно, не существует.
Основные положения
В работе "An Undetectable Computer Virus" Дэвид Чесс и Стив Вайт попытались развить идеи Коэна и показать, что задача обнаружения вирусов остается неразрешимой и при более слабых допущениях. Этой работой они попытались охватить класс полиморфных вирусов.
Рассмотрим множество программ. Множеством значений каждой из программ является одна или несколько других программ. При каждом выполнении программа производит одну программу из своего множества значений (в зависимости от входных данных). Пусть при этом выполнялась программа p, а результатом ее работы стала программа q. В этом случае будем говорить, что p производит q. Будем также говорить, что p со временем производит q, если p производит q либо непосредственно, либо после конечного числа итераций, когда сперва выполняется программа p, затем ее результат и т. д. Отношение "со временем производит" является транзитивным замыканием отношения "производит".
Определение 2.2. Множество V называется вирусным, если это максимальное множество удовлетворяющее условию:
Максимальность понимается в том смысле, что не существует такой программы r V, чтобы при ее добавлении к множеству V все еще выполнялось указанное условие.
Далее в рамках изложения условимся отождествлять множество V с компьютерным вирусом. Программа p будет называться экземпляром вируса V или же будет говориться, что она заражена вирусом V, т.к. p V.
Программа p будет называться просто зараженной, если: (V - вирус) [p V].
Будем говорить, что программа p размножается, если она производит новый экземпляр вируса (новый в смысле еще один, а не в смысле отличный от предыдущих).
Простейший вирус представляет собой множество из одного элемента и всегда производит сам себя. Более сложные множества соответствуют полиморфным вирусам, которые могут иметь несколько отличающихся форм, каждая из которых в процессе эволюции способна со временем произвести все остальные.
Предложенный формализм соответствует перезаписывающим вирусам, которые заменяют собой другие программы, принимая их имена, либо некоторым видам сетевых червей, которые распространяются создавая свои копии и рассылая их по сетевым каналам. Для описания вирусов в классическом определении Коэна необходимо усложнять модель. Однако основные результаты, которые будут получены ниже, могут быть распространены и на классические "паразитирующие" вирусы.
Обнаружение вирусов
Определение 2.3.
Алгоритм A обнаруживает вирус V для любой программы p: A(p) завершает работу и печатает 1 p V.
Аналогично, алгоритм A обнаруживает множество вирусов S для любой программы p: A(p) завершает работу и печатает 1 p V S
По сути это то же определение обнаружения, что и использованное Ф. Коэном в его дебютной работе.
Полученный Ф. Коэном результат, о том, что не существует алгоритма A, способного обнаруживать множество всех возможных компьютерных вирусов, можно расширить и вывести, что даже имея один из экземпляров вируса V, нельзя создать алгоритм, способный обнаруживать все экземпляры вируса V.
Доказательство этого факта строится по той же схеме, что и доказательство Ф. Коэна. Рассмотрим такой полиморфный вирус, что для любого реализуемого алгоритма X программа p:
Очевидно, не существует алгоритма B, который был бы способен обнаруживать все экземпляры такого вируса, поскольку для любого алгоритма B, претендующего на роль детектора, существует программа q:
Возникает вопрос о существовании подобного полиморфного вируса и ответ на этот вопрос положительный. Рассмотрим следующий вирус W одним из экземпляров которого является r:
если Sub1(r), то завершить работу, иначе {
заменить текст подпрограммы Sub1 текстом произвольной программы;
размножаться;
завершить работу;
}
Sub1:
Вернуть 0;
Для любого алгоритма C, претендующего на обнаружение всех экземпляров вируса W, найдется программа s:
если Sub1(s), то завершить работу, иначе {
заменить текст подпрограммы Sub1 текстом произвольной программы;
размножаться;
завершить работу;
}
Sub1:
Вернуть С(аргумент);
для которой алгоритм С возвращает ошибочный результат. Если С(s) возвращает 1, значит s всегда просто завершает свою работу и не является экземпляром вируса W или любого другого вируса. Если же C(s) возвращает 0, значит s является экземпляром W. Соответственно, не существует алгоритма C, способного безошибочно определять все экземпляры вируса W и только их.
Слабое определение обнаружения
Можно в некотором роде ослабить определение обнаружения, сохранив полученный выше результат в силе. В частности можно допустить, чтобы алгоритм, претендующий на обнаружение вируса V, возвращал 1 не только на экземплярах этого вируса, но и на некоторых других программах, при условии, что они тоже являются экземплярами (других) вирусов.
Определение 2.4. Будем говорить, что алгоритм A слабо обнаруживает вирус V для любой программы p, A(p) завершает работу и возвращает 1, если p V, и возвращает отличный от 1 результат, если p не является экземпляром никакого вируса. При этом на экземплярах других вирусов алгоритм может возвращать любой результат
Вполне очевидно, что для сконструированного вируса W не существует алгоритма, который мог бы слабо обнаруживать этот вирус, поскольку такой алгоритм будет либо возвращать 1 на программе, которая просто завершает свою работу, либо будет возвращать не 1 для программы, являющейся экземпляром W.
Сравнение с результатом Ф. Коэна
Полученный результат является дополнением результата Ф. Коэна. Действительно, результат Ф. Коэна можно кратко записать в виде:
Результат Д. Чесса и С. Вайта может быть по аналогии представлен как:
Практические следствия
На практике вирус W не представляет такой уж большой опасности и это связано с тем, что, как правило, не расценивается проблемой ложное срабатывание на программах вида:
если D(t), то завершить работу, иначе размножаться
или
если Sub1(u), то завершить работу, иначе {
заменить текст подпрограммы Sub1 текстом произвольной программы;
размножаться;
завершить работу;
}
Sub1:
вернуть D(аргумент);
Несмотря на то, что такие программы никогда не размножаются, их существование тесно связано с существованием определенных вирусов.
Здесь важно понимать значение полученного результата. Вывод Ф. Коэна важен в первую очередь тем, что можно без особых разбирательств отметать любые заявления о создании алгоритма точно детектирующего вирусы и только их. Точно так же на основании результата Д. Чесса и С. Вайта можно отметать заявления о создании алгоритма, способного обнаруживать без ложных срабатываний все экземпляры полиморфного вируса по одному его экземпляру.
В реальной жизни антивирусная программа считается качественной, если она обнаруживает все жизнеспособные экземпляры вируса, желательно также его нежизнеспособные ответвления, и при этом характеризуется сравнительно небольшим числом ложных срабатываний. Следует избегать лишь тех ложных срабатываний, которые затрагивают существующие программы, используемые в повседневной работе различными пользователями. Ложные срабатывания на искусственных примерах, появление которых на компьютерах пользователей близко к нулю, вполне допустимы.
В 2000-м году венгерский исследователь Ференц Лейтольд попытался дать новый импульс развитию математической теории компьютерных вирусов путем более точного моделирования вычислительной среды - компьютеров и операционных систем. Попутно он вывел некую общую классификацию вирусов и также, как Д. Чесс и С. Вайт, рассмотрел в рамках предложенного формализма феномен полиморфных вирусов.
Вычислительные модели
Вычислительная машина с произвольной выборкой
Для моделирования компьютерной среды Ф. Лейтольд отталкивался от вычислительной машины с произвольной выборкой (Random Access Machine, RAM), определение которой представлено ниже.
Вычислительная машина с произвольной выборкой состоит из следующих компонентов:
Как следует из определения, после того как ячейка была прочитана или записана, она не может быть прочитана или записана еще раз. Неизменяемость программы означает в том числе и то, что программа не может менять себя в процессе выполнения. Фактический набор используемых в программе инструкций большого значения не имеет, поскольку вычислительная сложность алгоритма реализованного в разных (разумных) наборах инструкций асимптотически будет совпадать. Один из возможных вариантов инструкций для вычислительной машины с произвольной выборкой представлен в таблице:
|
Инструкция |
Параметр |
Описание |
|
LOAD |
Операнд |
Загружает в память значение, определяемое операндом |
|
STORE |
Операнд |
Копирует значение аккумулятора в ячейку памяти (регистр) определяемый операндом |
|
ADD |
Операнд |
Добавляет к аккумулятору значение, определяемое операндом |
|
SUB |
Операнд |
Вычитает из аккумулятора значение, определяемое операндом |
|
MULT |
Операнд |
Умножает аккумулятор на значение, определяемое операндом |
|
DIV |
Операнд |
Делит аккумулятор на значение, определяемое операндом |
|
READ |
Операнд |
Считывает значение с входящей ленты в регистр, определяемый операндом |
|
WRITE |
Операнд |
Записывает на выходную ленту значение, определяемое операндом |
|
JUMP |
Метка |
Присваивает счетчику инструкций значение метки |
|
JGTZ |
Метка |
Присваивает счетчику инструкций значение метки, если аккумулятор содержит положительное число |
|
JZERO |
Метка |
Присваивает счетчику инструкций значение метки, если аккумулятор равен нулю |
|
HALT |
Завершает работу машины |
Допускается три вида операндов:
По умолчанию (см. также определение) значение всех регистров равно нулю, счетчик инструкций указывает на первую инструкцию программы и выходная лента пуста. После выполнения k-й инструкции счетчик либо автоматически увеличивается на единицу и указывает на (k+1)-ю инструкцию, либо, если была выполнена инструкция JUMP или выполнены условия инструкций JGTZ или JZERO, принимает значение метки, либо, если была выполнена инструкция HALT, машина прекращает свою работу.
Вычислительная машина с хранением программ в памяти с произвольной выборкой
Развитием формализма вычислительной машины с произвольной выборкой является вычислительная машина с хранением программ в памяти с произвольной выборкой (Random Access Stored Program Machine, RASPM), отличие которой состоит только в том, что программа сохраняется в памяти, а значит может изменять сама себя в процессе выполнения.
Набор инструкций для RASPM в общем случае может не отличаться от набора инструкций RAM. Впрочем, некоторые инструкции могут быть упрощены. Так, вместо непрямой адресации можно использовать возможность модификации инструкций программы для получения того же эффекта.
Известно, что имеют место две теоремы:
Теорема 2.1. Если стоимость инструкции является величиной постоянной или находится в логарифмической зависимости от длины операнда, то для любой программы RAM, имеющей сложность T(n), найдется константа k и эквивалентная программа RASPM, сложность которой будет не больше kT(n).
Теорема 2.2. Если стоимость инструкции является величиной постоянной или находится в логарифмической зависимости от длины операнда, то для любой программы RASPM, имеющей сложность T(n), найдется константа k и эквивалентная программа RAM, сложность которой будет не больше kT(n).
Машина Тьюринга
Большинство теоретических результатов относительно вычислительной способности различных автоматов (к которым относятся RAM и RASPM) получено для Машины Тьюринга. Следовательно, для применения к RASPM уже известных результатов, необходимо установить отношение между этими формальными системами.
Определение 2.5. Машина Тьюринга с одной лентой может быть определена как совокупность семи элементов:
где Q - множество состояний Машины Тьюринга, S - множество символов, которые могут быть записаны на ленте, I - множество символов входящей последовательности, I S, b S | I - пустой символ, q0 - начальное состояние Машины Тьюринга, qf - конечное состояние Машины Тьюринга, d: Q × S Q × S × {l, r, s} - множество функций перехода, которые состоянию и символу ленты ставят в соответствие новое состояние, новый символ и перемещение по ленте: на шаг влево, на шаг вправо, остаться на месте
Машина начинает свою работу в состоянии q0 и в дальнейшем меняет состояния согласно функциям перехода в зависимости от текущего состояния и значения ячейки ленты. Попутно ячейки ленты перезаписываются новыми значениями согласно тем же функциям перехода.
Машина Тьюринга может содержать и большее количество лент, но вычислительная способность такой машины будет находиться в полиномиальной зависимости от вычислительной способности Машины Тьюринга с одной лентой. Помимо этого имеют место следующая теорема:
Теорема 2.3. Вычислительные способности Машины Тьюринга и RASPM эквивалентны, а их затраты на вычисление полиноминально сравнимы, если стоимость выполнения инструкции является величиной постоянной или находится в логарифмической зависимости от длины операнда
Кроме того доказан фундаментальный результат.
Теорема 2.4. Не существует такой Машины Тьюринга, которая сможет определить остановится ли произвольная Машина Тьюринга на произвольном входе (проблема остановки)
RASPM с присоединенным вспомогательным хранилищем
Дальнейшее приближение модели к реальным компьютерам и операционным системам основывается на идее присоединенных внешних хранилищ (данных и программ).
Описанные в предыдущем пункте модели ограничены тем, что в чистом виде пригодны только для анализа отдельного алгоритма или программы. Для анализа взаимодействия алгоритмов потребовались бы значительные усилия. Чтобы упростить анализ таких ситуаций имеет смысл ввести в модель вычислительной машины специальную область или ленту, на которой будут храниться данные других программ. Назовем эту область присоединенным вспомогательным хранилищем (Attached Background Storage, ABS). Кроме этого имеет смысл потребовать, чтобы любая выполняющаяся программа имела полный доступ (чтение и запись) к этому хранилищу.
Определение 2.6. Вычислительная машина G с хранением программ в памяти с произвольной выборкой и с присоединенным вспомогательным хранилищем (RASPM с ABS) определяется шестью элементами:
где V - алфавит, состоящий из входных символов, выходных символов, а также символов, которые могут быть записаны на присоединенном вспомогательном устройстве и в ячейках памяти (регистрах), U - непустое конечное подмножество кодов инструкций, U V, T- непустое множество возможных действий процессора, f - однозначная функция f: UT, ставящая в соответствие различным кодам инструкций различные действия процессора, действие процессора f(x), соответствующее коду инструкции xU будет называться командой, q - стартовое значение счетчика операций, M - стартовое наполнение памяти
Без потери общности можно допустить, что существует взаимно однозначное кодирование символов алфавита V целыми числами. При этом каждая инструкция должна сопровождаться значением операнда, таким образом каждая команда задается двумя ячейками: код инструкции в одной ячейке и значение операнда в следующей ячейке. Один из вариантов кодирования инструкций представлен в таблице:
|
Инструкция |
Параметр |
Код инструкции |
Значение |
|
LOAD |
Операнд |
10 |
Загружает в аккумулятор значение, определяемое операндом |
|
STORE |
Операнд |
20 |
Копирует значение аккумулятора в ячейку, определяемую операндом |
|
ADD |
Операнд |
30 |
Прибавляет к аккумулятору значение, определяемое операндом |
|
SUB |
Операнд |
40 |
Вычитает из аккумулятора значение, определяемое операндом |
|
MULT |
Операнд |
50 |
Умножает аккумулятор на значение, определяемое операндом |
|
DIV |
Операнд |
60 |
Делит аккумулятор на значение, определяемое операндом |
|
AND |
Операнд |
70 |
Выполняет побитовую операцию "И" между аккумулятором и значением, определяемым операндом |
|
OR |
Операнд |
80 |
Выполняет побитовую операцию "ИЛИ" между аккумулятором и значением, определяемым операндом |
|
XOR |
Операнд |
90 |
Выполняет побитовую операцию "исключающее ИЛИ" между аккумулятором и значением, определяемым операндом |
|
READ |
Операнд |
A0 |
Считывает значение с входной ленты в ячейку, определяемую операндом |
|
WRITE |
Операнд |
B0 |
Записывает на выходную ленту значение ячейки, определяемой операндом |
|
GET |
Операнд |
C0 |
Считывает значение с вспомогательного хранилища в ячейку, определяемую операндом |
|
PUT |
Операнд |
D0 |
Записывает на вспомогательное хранилище значение ячейки, определяемой операндом |
|
SEEK |
Операнд |
E0 |
Перемещает считывающую/записывающую головку вспомогательного хранилища в позицию, определяемую операндом |
|
JUMP |
Метка |
FC |
Присваивает счетчику инструкций значение метки |
|
JGTZ |
Метка |
FD |
Присваивает счетчику инструкций значение метки, если аккумулятор содержит положительное число |
|
JZERO |
Метка |
FE |
Присваивает счетчику инструкций значение метки, если аккумулятор равен нулю |
Обозначим значение i-й ячейки памяти как c(i), где i - целое число. Допустимые коды операндов в таком случае представлены в таблице.
|
Операнд |
Код операнда |
Значение |
|
i |
1 |
i |
|
[i] |
2 |
c(i) |
|
[[i]] |
3 |
c(c(i)) |
Полный код команды в этом случае будет складываться (в буквальном смысле) из кода инструкции и кода операнда. Например, команда ADD [i] будет иметь код 32, а команда GET [[i]] - код C3.
Поскольку программа в случае RASPM способна изменять себя в процессе выполнения, многие команды, в частности, команды с операндом [[i]] могут быть эмулированы через другие команды.
Также нужно понимать, что не любой операнд подходит к каждой инструкции. Например, инструкция READ может иметь только операнды типов [i] и [[i]], поскольку записывает значение из ленты в память.
При включении RASPM с ABS счетчик инструкций принимает начальное значение q и процессор немедленно выполняет команду, расположенную по адресу, указанному в q. Дальнейшее выполнение программы определяется командами, записанными в памяти и таким образом полностью определяется начальным содержанием памяти. Завершение работы машины происходит в следующих случаях:
Таким образом, в отличие от RAM специальная команда для завершения работы машины не используется.
При каждом включении машины содержимое памяти приводится к исходному значению M, а при каждом выключении обнуляется. Содержимое вспомогательного хранилища, напротив, сохраняется от выключения к включению. Можно также допустить, что вспомогательное хранилище разрешается отсоединять от одной машины и присоединять к другой. Естественным расширением RASPM с ABS выглядит возможность одновременного подключения нескольких вспомогательных хранилищ к одной машине. Следовательно можно определить RASPM с несколькими ABS следующим образом.
Определение 2.7. Вычислительная машина с хранением программ в памяти с произвольной выборкой и с несколькими присоединенными вспомогательными хранилищами (Random Access Stored Program Machine with Several Attached Background Storages, RASPM с SABS) определяется так же как и RASPM с ABS, но с некоторыми допущениями:
|
Инструкция |
Параметр |
Код инструкции |
Значение |
|
SETDRIVE |
операнд |
FO |
Устанавливает активным вспомогательным хранилищем ленту, определяемую операндом |
Теорема 2.5. RASPM с SABS эквивалентна RASPM с ABS, в том смысле, что каждая из машин может быть проэмулирована другой
Доказательство. Достаточно показать, что RASPM с SABS может быть проэмулирована RASPM с ABS, поскольку симметричное утверждение доказывается тривиально.
Для эмуляции N вспомогательных хранилищ одним хранилищем воспользуемся следующим принципом: пронумеруем ленты вспомогательных хранилищ от 0 до N-1. Перенесем j-й символ i-й ленты в (Nj+i)-ю позицию новой ленты. Кроме этого изменим структуру памяти эмулирующей машины следующим образом:
Команды эмулируемой машины переносятся в память эмулирующей машины без изменений за исключением следующих случаев:
Построенная таким образом симулирующая машина требует не более 7 операций на каждую операцию исходной программы, а значит сложность эмулирующей программы будет не больше 7T(n), где T(n) - сложность эмулируемой программы. Теорема доказана.
Следовательно увеличение количества вспомогательных хранилищ не увеличивает вычислительной способности машины RASPM с ABS. Осознавая этот факт, несложно понять, что вычислительная способность RASPM с ABS не превышает вычислительной способности RASPM, что и утверждается соответствующей теоремой.
Теорема 2.6. Любая машина RASPM с ABS может быть проэмулирована машиной RASPM, и затраты на операции будут отличаться не более чем на постоянный множитель
Доказательство. По аналогии с доказательством предыдущей теоремы можно скомбинировать содержимое памяти и вспомогательного хранилища эмулируемой машины в памяти эмулирующей машины и получить RASPM - машину без вспомогательного хранилища. Основная разница при комбинировании будет заключаться в том, что смешиваться будут не отдельные ячейки, а их блоки, поскольку отрывать значение операнда от кода инструкции нельзя. Также следует учитывать, что для сохранения связности программы потребуется добавить после каждой команды оригинальной программы команду JUMP, чтобы пропустить ячейки памяти относящиеся к виртуальной вспомогательной ленте. В остальном принципы комбинирования остаются теми же, за тем исключением, что нет необходимости использовать несколько регистров для нескольких лент и отдельный регистр для номера ленты - достаточно будет ограничиться только регистром для хранения номера позиции на ленте. На этом неформальное доказательство можно считать законченным. Приводить формальное доказательство смысла нет из-за его относительной громоздкости.
Прямым следствием из теоремы будет следующая теорема:
Теорема 2.7. Вычислительная способность Машины Тьюринга и RASPM с ABS эквивалентны, а их затраты на вычисления находятся в полиномиальной зависимости
Доказательство. Этот результат получается из сопоставления результатов теорем 2.1, 2.2, 2.3 и 2.6.
Моделирование операционных систем
Естественным желанием является использовать RASPM с ABS и RASPM с SABS для запуска программ. Компоненты V, U, T и f машины G= V, U, T, f, q, M были определены ранее. Теперь, задав определенным образом M и q можно получить программу, которая и будет определять характер функционирования машины. Разумно потребовать, чтобы файлы программ и данных хранились на вспомогательном(ых) хранилище(ах), порядок выполнения программ определялся входной лентой, и чтобы выполняемая программа могла модифицировать как данные, так и программы на вспомогательном хранилище. Соответственно необходима программа-оболочка, способная работать с файлами данных и программ и выполнять другие программы.
Определение 2.8. Под операционной системой (ОС) понимается система программ, способная работать с файлами данных и программ и выполнять другие программы.
Операционная система может быть частью начального состояния памяти M или же может быть расположена на вспомогательном хранилище. Во втором случае, начальное состояние памяти должно содержать специальную программу, которая будет загружать операционную систему и запускать ее. Такая служебная программа не будет считаться частью операционной системы.
Определение 2.9. Если операционная система входит в состав начального состояния памяти M машины, то такая операционная система будет называться машинозависимой.
Это означает, что определив машину RASPM с ABS, мы определим также и операционную систему, т. к. M является частью определения машины.
Определение 2.10. Если операционная система расположена на вспомогательном хранилище, такая операционная система будет называться машиннонезависимой.
В таком случае операционную систему можно будет поменять вместе с вспомогательным хранилищем.
На ту же ситуацию можно взглянуть и с обратной стороны.
Определение 2.11. Если начальное состояние памяти M машины RASPM с ABS включает операционную систему, то такая машина будет называться ОС-зависимой машиной.
Т. е. машина может использовать только свою собственную операционную систему, хотя возможно создание программы, которая будет эмулировать какую-нибудь другую операционную систему.
Определение 2.12. Если операционная система машины RASPM с ABS расположена на вспомогательном хранилище, то такая машина будет называться ОС-независимой машиной.
Из определений непосредственно следуют следующие теоремы.
Теорема 2.8. Если O - машинозависимая операционная система машины G, то G - ОС зависимая машина.
Теорема 2.9. Если O - машиннонезависимая операционная система машины G, то G - ОС независимая машина.
Для исследования общей задачи модификации одними программами других программ годится операционная система любого типа. Если же поставить задачу исследования также и программ, способных изменять код операционной системы, необходимо использовать модель с машиннонезависимыми операционными системами.
Вирусы в RASPM с ABS
С учетом данного ранее определения операционной системы можно сформулировать определение вируса.
Определение 2.13. Компьютерный вирус определяется как часть программы, присоединенная к области программы и способная присоединять себя к областям других программ. Компьютерный вирус выполняется при выполнении программы, к области которой он присоединен.
В общем случае присоединение вируса к области программы не должно оставлять неизменным результат выполнения программы (без учета действий вируса), однако такой способ присоединения часто используется вирусами для маскировки своего присутствия в системе (в области программы).
Способы размножения вирусов
Как известно из практики, вирус может присоединяться к программе используя различные технологии. Формы присоединения вирусов к различным программным областям будут называться способами размножения. Один и тот же вирус может обладать несколькими способами размножения.
Определение 2.14. Способ размножения вируса называется машинозависимым, если для использования этого способа вирусу требуется машина, обладающая определенными характеристиками или свойствами. В противном случае, когда характеристики и свойства машины не влияют на размножение вируса определенным способом, способ размножения называется машиннонезависимым.
Аналогичным образом можно рассмотреть и зависимость способов размножения от операционных систем.
Определение 2.15. Способ размножения вируса называется ОС зависимым, если для использования этого способа вирусу требуется операционная система, обладающая определенными характеристиками или свойствами. В противном случае, когда характеристики и свойства операционной системы не влияют на размножение вируса определенным способом, способ размножения называется ОС независимым.
Рассматривая совокупность способов размножения, можно распространить понятия машинозависимости и ОС зависимости на вирусы.
Определение 2.16. Вирус называется машинозависимым, если все его способы размножения машинозависимы. Аналогично, вирус называется машиннонезависимым, если все его способы размножения машиннонезависимы.
Определение 2.17. Вирус называется ОС зависимым, если все его способы размножения ОС зависимы. Аналогично, вирус называется ОС независимым, если все его способы размножения ОС независимы.
В некоторых случаях вирусы могут присоединять себя не к программной области а к файлу данных. Например, к исходному коду какой-либо программы. В этом случае для запуска вируса требуется, чтобы файл данных был преобразован третьей программой (компилятором) в файл программы. Дадим определение и такого способа размножения.
Определение 2.18. Способ размножения называется непосредственным, если вирус присоединяет себя непосредственно к программной области. Способ размножения называется косвенным, если вирус присоединяет себя к файлу данных.
Олигоморфные и полиморфные вирусы
Везде ранее подразумевалось, что вирус никак не меняется при размножении, т. е. присоединенная вирусная часть одинакова при каждом заражении. Тем не менее, многие вирусы не обладают таким свойством и способны меняться при размножении.
Определение 2.19. Способ распространения называется полиморфным если можно найти две программы зараженные с использованием одного способа распространения одного вируса, такие что последовательности инструкций зараженных частей этих программ будут отличаться.
Определение 2.20. Вирус называется полиморфным, если он обладает полиморфным способом распространения.
Определение 2.21. Способ распространения называется олигоморфным, если можно найти две программы зараженные с использованием одного способа распространения одного вируса, такие что последовательности инструкций зараженных частей этих программ будут одинаковы (для любой пары), но хотя бы одна часть вирусного кода будет зашифрована с разными ключами.
Определение 2.22. Вирус называется олигоморфным, если он обладает олигоморфным способом распространения.
На практике выделяют также подвиды полиморфных и олигоморфных вирусов.
Определение 2.23. Вирус называется медленным полиморфным, если он обладает полиморфным способом распространения, но применяет этот способ очень редко.
Определение 2.24. Вирус называется медленным олигоморфным, если он обладает олигоморфным способом распространения, но ключ шифрования меняет очень редко.
Проблема обнаружения вирусов
Вместе с выделением класса вирусов возникает и проблема обнаружения вирусов.
Определение 2.25. Проблема обнаружения вирусов является задачей теории алгоритмов: существует ли алгоритм, с помощью которого для любой программы можно было бы определить содержит она вирус, способный к распространению, или нет.
Предполагается, что все данные о структуре программы и машины, на которой она выполняется доступны. Неизвестными являются только данные о вирусе.
Общая проблема обнаружения вирусов
Согласно тезису Тьюринга-Черча, если бы существовал алгоритм обнаружения вирусов, можно было бы создать Машину Тьюринга, которая бы выполняла этот алгоритм. Покажем, что такой Машины Тьюринга не существует.
Теорема 2.10. Не существует Машины Тьюринга, которая могла бы определять наличие вируса в произвольной программе для машины RASPM с ABS.
Доказательство. Согласно теореме 2.7 вместо Машины Тьюринга можно использовать эквивалентную ей RASPM или RASPM с ABS. Рассмотрим программу P, которая эмулирует работу Машины Тьюринга (произвольной). Программа P печатает на выходе 1, если эмулируемая Машина Тьюринга завершает свою работу.
Построим простой вирус, который сперва запускает программу P на случайном, но фиксированном (для данного вируса) входе B, после чего начинает выполнять собственно вирусную часть. При заражении вирус копирует целиком программу P, последовательность B и вирусную часть.
Используя эту конструкцию можно создать программу V в RASPM с ABS для любой Машины Тьюринга, и эта программа будет вирусом в том случае, если она сможет размножаться, т. е. в том случае, когда Машина Тьюринга завершает свою работу на фиксированном для программы V входе или, что тоже самое, если программа P печатает единицу для данной Машины Тьюринга и данного входа.
Предположим, что существует Машина Тьюринга, способная обнаруживать все вирусы, т. е. такая Машина Тьюринга T, которая читает код программы RASPM с ABS и печатает 1, если в коде этой программы содержится вирус, и печатает 0, если вируса нет. Применим машину T к программе V. Если T печатает 1, значит программа P и соответствующая ей Машина Тьюринга завершают свою работу на некотором входе B. Если T печатает 0, значит программа P и соответствующая ей Машина Тьюринга никогда не завершит свою работу на некотором входе B. Учитывая, что вход B и эмулируемая программой P Машина Тьюринга могут быть любыми, получаем, что Машина Тьюринга T способна для любой Машины Тьюринга и любого входа определить, завершит ли данная Машина Тьюринга работу на данном входе. Однако мы знаем, что это невозможно.
Полученное противоречие доказывает теорему.
Оценка сложности сигнатурного метода
Далее в своей работе Ф. Лейтольд обращается к проблеме обнаружения не всех возможных вирусов, а некоторого подмножества "известных" вирусов.
Для этого предлагается сигнатурный метод - обнаружение вируса по строке или подстроке его кода. Естественно, таким образом невозможно обнаружить полиморфные вирусы. Но для обнаружения обычных или олигоморфных вирусов такой способ годится: олигоморфные вирусы могут обнаруживаться по строке или подстроке кода расшифровщика.
В случаях, когда обнаружение осуществляется по подстроке вирусного кода (либо даже по полному коду распаковщика для олигоморфных вирусов) возможны ложные срабатывания. Ф. Лейтольд приводит оценку вероятности ложных обнаружений при следующих допущениях:
В этом случае оценка количества ложных обнаружений будет примерно равна:
Можно также подсчитать вычислительную сложность алгоритма, выполняющего поиск вирусов по сигнатуре. Для выполнения поиска требуется последовательно сравнить все ячейки анализируемой строки данных с первыми ячейками сигнатур. В общем случае это L·M сравнений. Далее, при обнаружении совпадения потребуется провести сравнение со второй ячейкой сигнатуры. Учитывая вероятность совпадения значения первой ячейки, количество сравнений второй ячейки будет . Аналогично, третьей - и т. д. Общее количество сравнений составит:
В худшем сценарии, когда все сигнатуры полностью различны, а n и N достаточно велики, количество сравнений составит s = L·M·N.
Следовательно, сигнатурный поиск может быть выполнен за полиномиальное время.
Необходимо понимать, что полученные оценки приблизительны и соответствуют худшему варианту поиска случайной подпоследовательности в случайной последовательности. На практике код программы и код вируса не являются случайными последовательностями и с учетом знания их структуры алгоритм поиска может быть существенно оптимизирован, оценка времени - уменьшена.
Леонард Адельман, известный математик, обладатель премии Тьюринга, участвовавший в свое время разработке криптосистемы RSA (буква A в аббревиатуре) для исследования феномена вирусов решил использовать другой формализм теории алгоритмов - не формализм машин Тьюринга, а формализм рекурсивных функций.
Теория машин Тьюринга и теория рекурсивных функций в некотором смысле эквиваленты - алгоритмы, вычислимые в одной теории будут вычислимыми в другой, и наоборот. Этот факт в совокупности с тезисом Тьюринга-Черча, означает, что полученные Л. Адельманом результаты в той же степени применимы к современным реалиям, что и результаты Ф. Коэна, Д. Чесса, С. Вайта, Ф. Лейтольда и других исследователей опиравшихся в своих работах на теорию машин Тьюринга.
Принятые обозначения
В дальнейшем изложении будет считаться, что данные и программы, во-первых, различимы, как это обычно и бывает в компьютерных системах, а во-вторых, могут быть закодированы натуральными числами. Поскольку и данные и программы всегда имеют ограниченный размер и ограниченный алфавит для их представления, принципиальная возможность взаимно однозначного кодирования натуральными числами сомнений не вызывает.
Исходя из сказанного, состояние некой вычислительной системы с точки зрения выполняющейся программы, может быть описано как набор доступных программе данных и других программ, что может быть выражено как наборы или последовательности натуральных чисел. Действие любой программы заключается в том, чтобы из одного набора данных и программ получить другой набор данных и программ.
Ниже везде неявно подразумевается описанная интерпретация вычислительной системы.
Нотация предназначена для обозначения состояния системы и фактически является кодом этого состояния, представленным натуральным числом.
Определение 2.26. Для всех частичных функций выполняется одно из условий:
Определение служит для уточнения понятия тождественности программ, представленных в виде частичных функций.
Определение 2.27. для всех частичных функций : :
Если раньше для обозначения действия программы на систему использовались коды состояний, то в этом определении используется детализированное описание состояния и по сути вводится отношение между чистым и зараженным состоянием системы. Зараженное состояние характеризуется тем, что при прочих равных в нем некоторые программы изменены вирусом (функция h).
Определение 2.28. Для всех частичных функций , , и
В этом определении уточняется введенное ранее отношение для состояний, получаемых в результате действия двух функций. Результатом действия функции f на состояние системы является натуральное число, которое можно однозначно интерпретировать как новое состояние . Точно так же . Соответственно, запись обозначает, что обе программы завершают свою работу при запуске из состояния и результат их выполнения будет отличаться фактом заражения некоторых программ: .
Определение 2.29. Для всех частичных функций , или
Введенное обозначение призвано отразить тот факт, что зараженная программа не всегда выполняет заражение - в некоторых состояниях зараженная программа может выполнять ровно те же действия, что и незараженная, т. е. результат ее действия при некоторых состояниях системы будут точно таким же как и у незараженной программы.
Определение 2.30. Для всех геделевских нумераций частичных рекурсивных функций , общерекурсивная функция v будет вирусом по отношению к выполняется либо:
В данном определении выбор переменных d и p в явном виде указывает на их природу - данные (информация не подверженная заражению) и программы (информация подверженная заражению).
Здесь необходимы комментарии:
Классификация вирусов
Определение 2.31. Для всех геделевских нумераций частичных рекурсивных функций , для всех вирусов v по отношению к :
Существует состояние системы, при котором зараженная вирусом v программа j выполняет вредоносную функцию, т.е. результат действия зараженной программы не ограничивается заражением (появлением новых зараженных программ).
Существует состояние системы, при котором зараженная вирусом v программа j выполняет функцию размножения - в результате ее действия в системе появляются новые зараженные программы.
Троян способен только к выполнению вредоносных функций и не может размножаться.
Переносчик является антиподом трояна: он только размножается и не содержит вредоносных функций.
Вирус - наиболее универсальный тип вредоносных программ, способный как к размножению, так и к выполнению вредоносных действий.
В тех случаях когда существует единственная j такая, что (т.е. когда v инъективна) и i является вредоносной (заразной, безобидной, трояном, переносчиком, вирусом) по отношению к v и j, ссылка на j будет опускаться и i будет называться вредоносной (заразной, безобидной, трояном, переносчиком, вирусом) по отношению к v.
Таким образом, если по отношению к какому-либо вирусу инфицированная программа является безобидной, это значит что она выполняет в точности те же действия, что и исходная неинфицированная программа и никаких других. Если она является трояном, значит она не может заражать другие программы, а может только имитировать их действия или наносить вред. Если программа является переносчиком, значит она не способна наносить вред, но при определенных обстоятельствах может заражать другие программы.
Определение 2.32. Для всех геделевских нумераций частичных рекурсивных функций , для всех вирусов v по отношению к :
Следующая теорема отмечает ряд простых свойств, присущих различным типам вирусов.
Теорема 2.11. Для всех геделевских нумераций частичных рекурсивных функций , для всех вирусов v по отношению к :
Доказательство. Первое свойство непосредственно следует из первой теоремы о рекурсии (теоремы о неподвижной точке).
Остальные свойства следует непосредственно из определений.
Обнаружение компьютерных вирусов
После определения компьютерного вируса естественным образом возникает вопрос об обнаружении такого рода программ, или о разрешимости множества компьютерных вирусов. Л. Адельман доказал следующую теорему.
Теорема 2.12. Для всех геделевских нумераций частичных рекурсивных функций : - полное множество
Теорема приводится без доказательства.
Здесь - класс множеств в арифметической классификации. Известно, что классы множеств с индексом 1 и выше являются неразрешимыми. Следовательно и множество вирусов является неразрешимым.
Из вышеизложенного видно, что разные исследователи в разное время используя различный математический аппарат получили эквивалентный вывод. Класс вирусов является неразрешимым, т.е. не существует алгоритма, который бы позволил однозначно определить является программа зараженной (вирусом) или нет. Речь идет даже не о нехватке ресурсов, а о принципиальной невозможности создать подобный алгоритм.
В связи с этим проблема естественным образом переходит из теоретической области в практическую, где применяются частные решения для решения частных задач обнаружения вирусов. В частности решаются задачи определения вирусов по сигнатурам, или вероятностного определения вирусов. О подклассах вредоносных программ и практических методах борьбы с ними и пойдет речь в последующих главах.
3. Лекция: Классификация вирусов
Поскольку теоретическая задача обнаружения вирусов неразрешима, на практике приходится решать частные задачи по борьбе с частными случаями вредоносных программ.
В зависимости от характерных свойств вирусов для их обнаружения и нейтрализации могут применяться различные методы. В связи с этим возникает вопрос о классификации вредоносных программ, чему и посвящена эта глава.
Необходимо отметить, что на практике классификации, принятые различными производителями антивирусных продуктов, отличаются, хотя и построены на близких принципах. Поэтому в ходе изложения будут формулироваться в первую очередь принципы, и уже потом примеры из классификации, используемой в Лаборатории Касперского.
Определение компьютерного вируса — исторически проблемный вопрос, поскольку достаточно сложно дать четкое определение вируса, очертив при этом свойства, присущие только вирусам и не касающиеся других программных систем. Наоборот, давая жесткое определение вируса как программы, обладающей определенными свойствами, практически сразу же можно найти пример вируса, таковыми свойствами не обладающего.
Приведем несколько формулировок определения:
Хронологически наиболее раннее определение от Евгения Касперского (книга "Компьютерные вирусы"):
Определение 3.1а. ОБЯЗАТЕЛЬНЫМ (НЕОБХОДИМЫМ) СВОЙСТВОМ КОМПЬЮТЕРНОГО ВИРУСА является возможность создавать свои дубликаты (не обязательно совпадающие с оригиналом) и внедрять их в вычислительные сети и/или файлы, системные области компьютера и прочие выполняемые объекты. При этом дубликаты сохраняют способность к дальнейшему распространению.
Определение по ГОСТ Р 51188-98:
Определение 3.1б. Вирус — программа, способная создавать свои копии (необязательно совпадающие с оригиналом) и внедрять их в файлы, системные области компьютера, компьютерных сетей, а также осуществлять иные деструктивные действия. При этом копии сохраняют способность дальнейшего распространения. Компьютерный вирус относится к вредоносным программам.
Легко заметить, что определение в ГОСТ практически полностью повторяет определение Е. Касперского.
Определения 3.1а и 3.1б в большой степени повторяют определение Ф. Коэна или уточнение, предложенное Д. Чессом и С. Вайтом, что позволяет распространить на них (определения) вывод о невозможности создать алгоритм, обнаруживающий все такие программы или даже все "инкарнации" одного из вирусов. Тем не менее, на практике оказывается, что все известные вирусы могут быть обнаружены антивирусными программами. Результат достигается в частности еще и за счет того, что поврежденные или неудачные экземпляры вирусов, неспособные к созданию и внедрению своих копий, обнаруживаются и классифицируются наравне со всеми остальными "полноценными" вирусами. Следовательно, с практической точки зрения, т. е. с точки зрения алгоритмов поиска, способность к размножению вовсе не является обязательной для причисления программы к вирусам.
Другая проблема, связанная с определением компьютерного вируса кроется в том, что сегодня под вирусом чаще всего понимается не "традиционный" вирус, а практически любая вредоносная программа. Это приводит к путанице в терминологии, осложненной еще и тем, что практически все современные антивирусы способны выявлять указанные типы вредоносных программ, таким образом ассоциация "вредоносная программа-вирус" становится все более устойчивой.
Исходя из этого, а также из назначения антивирусных средств, в дальнейшем, если это не будет оговорено отдельно, под вирусами будут подразумеваться именно вредоносные программы.
Определение 3.2. Вредоносная программа — компьютерная программа или переносной код, предназначенный для реализации угроз информации, хранящейся в КС, либо для скрытого нецелевого использования ресурсов КС, либо иного воздействия, препятствующего нормальному функционированию КС. К вредоносным программам относятся компьютерные вирусы, трояны, сетевые черви и др.
Компьютерные вирусы, трояны и черви являются основными типами вредоносных программ.
Классические определения компьютерного вируса приведены выше.
Жизненный цикл
Поскольку отличительной особенностью вирусов в традиционном смысле является способность к размножению в рамках одного компьютера, деление вирусов на типы происходит в соответствии со способами размножения.
Сам процесс размножения может быть условно разделен на несколько стадий:
Особенности реализации каждой стадии порождают атрибуты, набор которых фактически и определяет класс вируса.
Проникновение
Вирусы проникают на компьютер вместе с зараженными файлами или другими объектами (загрузочными секторами дискет), никак, в отличие от червей, не влияя на процесс проникновения. Следовательно, возможности проникновения полностью определяются возможностями заражения и классифицировать вирусы по этим стадиям жизненного цикла отдельно смысла нет.
Активация
Для активации вируса необходимо, чтобы зараженный объект получил управление. На данной стадии деление вирусов происходит по типам объектов, которые могут быть заражены:
Примеры. Вредоносная программа Virus.Boot.Snow.a записывает свой код в MBR жесткого диска или в загрузочные сектора дискет. При этом оригинальные загрузочные сектора шифруются вирусом. После получения управления вирус остается в памяти компьютера (резидентность) и перехватывает прерывания INT 10h, 1Ch и 13h. Иногда вирус проявляет себя визуальным эффектом - на экране компьютера начинает падать снег.
Другой загрузочный вирус Virus.Boot.DiskFiller также заражает MBR винчестера или загрузочные сектора дискет, остается в памяти и перехватывает прерывания - INT 13h, 1Ch и 21h. При этом, заражая дискеты, вирус форматирует дополнительную дорожку с номером 40 или 80 (в зависимости от объема дискеты он может иметь 40 либо 80 дорожек с номерами 0-39 или 0-79 соответственно). Именно на эту нестандартную дорожку вне поля обычной видимости вирус записывает свой код, добавляя в загрузочный сектор лишь небольшой фрагмент - головную часть вируса.
При заражении винчестера Virus.Boot.DiskFiller располагает свой код непосредственно за MBR, а в самом MBR меняет ссылку на активный загрузочный сектор, указывая адрес сектора где он расположен.
Примеры. Самый известный файловый вирус всех времен и народов — Virus.Win9x.CIH, известный также как "Чернобыль". Имея небольшой размер - около 1 кб - вирус заражает PE-файлы (Portable Executable) на компьютерах под управлением операционных систем Windows 95/98 таким образом, что размер зараженных файлов не меняется. Для достижения этого эффекта вирус ищет в файлах "пустые" участки, возникающие из-за выравнивания начала каждой секции файла под кратные значения байт. После получения управления вирус перехватывает IFS API, отслеживая вызовы функции обращения к файлам и заражая исполняемые файлы. 26 апреля срабатывает деструктивная функция вируса, которая заключается в стирании Flash BIOS и начальных секторов жестких дисков. Результатом является неспособность компьютера загружаться вообще (в случае успешной попытки стереть Flash BIOS) либо потеря данных на всех жестких дисках компьютера.
Из последних вредоносных программ, обладающих вирусной функциональностью, можно отметить Email-Worm.Win32.Bagle.p (а также его модификации .q и .r). Являясь в первую очередь червем с основным каналом распространения через электронную почту, Bagle.p содержит также функцию заражения EXE-файлов путем дописывания в их конец полиморфного кода вируса
Примеры. Одними из наиболее разрушительных макровирусов являются представители семейства Macro.Word97.Thus. Эти вирусы содержат три процедуры Document_Open, Document_Close и Document_New, которыми подменяет стандартные макросы, выполняющиеся при открытии, закрытии и создании документа, тем самым обеспечивая заражение других документов. 13 декабря срабатывает деструктивная функция вируса - он удаляет все файлы на диске C:, включая каталоги и подкаталоги.
Модификация Macro.Word97.Thus.aa кроме указанных действий при открытии каждого зараженного документа выбирает на локальном диске случайный файл и шифрует первые 32 байта этого файла, постепенно приводя систему в неработоспособное состояние.
Макро-вирусы способны заражать не только документы Microsoft Word и Excel. Существуют вредоносные программы ориентированные и на другие типы документов: Macro.Visio.Radiant заражает файлы известной программы для построения диаграмм -Visio, Virus.Acad.Pobresito - документы AutoCAD, Macro.AmiPro.Green - документы популярного раньше текстового процессора Ami Pro.
Примеры. Virus.VBS.Sling написан на языке VBScript (Visual Basic Script). При запуске он ищет файлы с расширениями .VBS или .VBE и заражает их. При наступлении 16-го июня или июля вирус при запуске удаляет все файлы с расширениями .VBS и .VBE, включая самого себя.
Virus.WinHLP.Pluma.a - вирус, заражающий файлы помощи Windows. При открытии зараженного файла помощи выполняется вирусный скрипт, который используя нетривиальный метод (по сути, уязвимость в обработке скриптов) запускает на выполнение уже как обычный файл Windows определенную строку кода, содержащеюся в скрипте. Запущенный код производит поиск файлов справки на диске и внедряет в их область System скрипт автозапуска.
В эпоху вирусов для DOS часто встречались гибридные файлово-загрузочные вирусы. После массового перехода на операционные системы семейства Windows практически исчезли как сами загрузочные вирусы, так и упомянутые гибриды.
Отдельно стоит отметить тот факт, что вирусы, рассчитанные для работы в среде определенной ОС или приложения, оказываются неработоспособными в среде других ОС и приложений. Поэтому как отдельный атрибут вируса выделяется среда, в которой он способен выполняться. Для файловых вирусов это DOS, Windows, Linux, MacOS, OS/2. Для макровирусов - Word, Excel, PowerPoint, Office. Иногда вирусу требуется для корректной работы какая-то определенная версия ОС или приложения, тогда атрибут указывается более узко: Win9x, Excel97.
Поиск жертв
На стадии поиска объектов для заражения встречается два способа поведения вирусов.
Пример. Обычно при освоении новой платформы сначала появляются вирусы именно этого типа. Так было при появлении вирусов под DOS, под Windows 9x, под Windows NT, под Linux.
Например, таким вирусом является Virus.Multi.Pelf.2132 — один из немногих представителей мультиплатформенных вирусов. Этот вирус способен заражать как PE-файлы, так и файлы в формате ELF (формат исполняемых файлов под Linux). При запуске вирус производит в текущем (под обеими операционными системами) и вышестоящих каталогах (под Windows) файлов заражаемых форматов (PE и ELF), определяя действительный формат файла по его структуре. После заражения найденных файлов вирус завершает работу и возвращает управление запущенному файлу.
Пример. Virus.DOS.Anarchy.6093 также является мультиплатформенным в том смысле, что он способен заражать DOS COM- и EXE-файлы, а также документы Microsoft Word 6/7. При этом вирус может активироваться при запуске как в среде DOS, так и в среде Windows 95. После запуска вирус перехватывает прерывание INT 21h, а в среде Windows дополнительно вносит изменения в драйвер VMM32.VXD (Virtual Memory Manager) с целью перехвата обращений к файлам. При запуске или открытии COM-, EXE и DOC -файла вирус заражает его. Помимо этого, в файловом варианте вирус является полиморфным (см. ниже), и в любом варианте обладает stealth-функциональностью (см. ниже)
Вирусы второго типа во времена однозадачной DOS было принято называть резидентными. С переходом на Windows проблема остаться в памяти перестала быть актуальной: практически все вирусы, исполняемые в среде Windows, равно как и в среде приложений MS Office, являются вирусами второго типа. И напротив, скрипт-вирусы являются вирусами первого типа. Соответственно, атрибут резидентный применим только к файловым DOS вирусам. Существование нерезидентных Windows вирусов возможно, но на практике они являются редким исключением.
Отдельно имеет смысл рассмотреть так называемые stealth-вирусы - вирусы, которые находясь постоянно в памяти, перехватывают обращения к зараженному файлу и на ходу удаляют из него вирусный код, передавая в ответ на запрос неизмененную версию файла. Таким образом эти вирусы маскируют свое присутствие в системе. Для их обнаружения антивирусным средствам требуется возможность прямого обращения к диску в обход средств операционной системы. Наибольшее распространение Stealth-вирусы получили во времена DOS.
Подготовка вирусных копий
Определение 3.3. Сигнатура вируса — в широком смысле, информация, позволяющая однозначно определить наличие данного вируса в файле или ином коде. Примерами сигнатур являются: уникальная последовательность байт, присутствующая в данном вирусе и не встречающаяся в других программах; контрольная сумма такой последовательности.
Процесс подготовки копий для распространения может существенно отличаться от простого копирования. Авторы наиболее сложных в технологическом плане вирусов стараются сделать разные копии максимально непохожими для усложнения их обнаружения антивирусными средствами. Как следствие, составление сигнатуры для такого вируса крайне затруднено либо вовсе невозможно.
При создании копий для маскировки могут применяться следующие технологии:
Сочетание этих двух технологий приводит к появлению следующих типов вирусов.
Полиморфные вирусы можно делить на классы по уровню полиморфизма, желающие подробнее познакомиться с этим вопросом могут найти полезную информацию в [1].
Пик популярности полиморфных вирусов пришелся на времена DOS, тем не менее, и позднее полиморфизм использовался во множестве вирусов, продолжает использоваться полиморфизм и сегодня.
Примеры. Упомянутый выше Email-Worm.Win32.Bagle.p является полиморфным вирусом.
Одним из наиболее сложных и относительно поздних полиморфных вирусов является Virus.Win32.Etap. При заражении файла вирус перестраивает и шифрует собственный код, записывает его в одну из секций заражаемого файла, после чего ищет в коде файла вызов функции ExitProcess и заменяет его на вызов вирусного кода. Таким образом, вирус получает управление не перед выполнением исходного кода зараженного файла, а после него.
Внедрение
Внедрение вирусных копий может осуществляться двумя принципиально разными методами:
Для вирусов характерным является преимущественно первый метод. Второй метод намного чаще используется червями и троянами, а точнее троянскими компонентами червей, поскольку трояны сами по себе не распространяются.
Пример. Один из немногих почтовых червей, распространяющихся по почтовой книге The Bat! - Email-Worm.Win32.Stator.a, помимо всего прочего заражает некоторые файлы Windows по принципу вируса-компаньона. В частности, к заражаемым файлам относятся: mplayer.exe, winhlp32.exe, notepad.exe, control.exe, scanregw.exe. При заражении файлы переименовываются в расширение .VXD, а вирус создает свои копии под оригинальными именами заражаемых файлов. После получения управления вирус запускает соответствующий переименованный оригинальный файл.
В качестве варианта второго метода, во времена DOS применялся следующий прием. При наборе имени исполняемого файла без указания расширения, DOS ищет по порядку сперва BAT, затем COM, и в конце концов EXE-файл. Соответственно, вирусная копия создавалась в одном каталоге с EXE-файлом, дублируя его имя и принимая расширение COM. Таким образом, при попытке запустить данный EXE-файл без явного указания расширения сначала запускался вирус.
Аналогичный прием может использоваться и в Windows-системах, но поскольку основная масса пользователей Windows редко пользуются запуском файлов из командной строки, эффективность этого метода будет низкой.
К сожалению, определение червя отсутствует в государственных стандартах и распорядительных документах, поэтому здесь приведено лишь интуитивное определение, дающее представление о принципах работы и выполняемых функциях этого типа вредоносных программ.
Определение 3.4. Червь (сетевой червь) — тип вредоносных программ, распространяющихся по сетевым каналам, способных к автономному преодолению систем защиты автоматизированных и компьютерных сетей, а также к созданию и дальнейшему распространению своих копий, не всегда совпадающих с оригиналом, и осуществлению иного вредоносного воздействия.
Жизненный цикл
Так же как для вирусов, жизненный цикл червей можно разделить на определенные стадии:
Стадии 1 и 5, вообще говоря, симметричны и характеризуются в первую очередь используемыми протоколами и приложениями.
Стадия 4 — Подготовка копий — практически ничем не отличается от аналогичной стадии в процессе размножения вирусов. Сказанное о подготовке копий вирусов без изменений применимо и к червям.
Каналы распространения
На этапе проникновения в систему черви делятся преимущественно по типам используемых протоколов:
Примеры. Классическими сетевыми червями являются представители семейства Net-Worm.Win32.Sasser. Эти черви используют уязвимость в службе LSASS Microsoft Windows. При размножении, червь запускает FTP-службу на TCP-порту 5554, после чего выбирает IP-адрес для атаки и отсылает запрос на порт 445 по этому адресу, проверяя, запущена ли служба LSASS. Если атакуемый компьютер отвечает на запрос, червь посылает на этот же порт эксплойт уязвимости в службе LSASS, в результате успешного выполнения которого на удаленном компьютере запускается командная оболочка на TCP-порту 9996. Через эту оболочку червь удаленно выполняет загрузку копии червя по протоколу FTP с запущенного ранее сервера и удаленно же запускает себя, завершая процесс проникновения и активации.
В качестве примера почтового червя можно рассмотреть Email-Worm.Win32.Zafi.d. Зараженное сообщение включает в себя выбираемые из некоторого списка тему и текст, содержанием которых является поздравление с праздником (большая часть - с Рождеством) и предложение ознакомиться с поздравительной открыткой во вложении. Поздравления могут быть на разных языках. Имя находящегося во вложении файла червя состоит из слова postcard на языке, соответствующем поздравлению, и произвольного набора символов. Расширение файла червя случайным образом выбирается из списка .BAT, .COM, .EXE, .PIF, .ZIP. Для рассылки червь использует адреса электронной почты, найденные на зараженном компьютере. Чтобы получить управление, червь должен быть запущен пользователем.
IRC-Worm.Win32.Golember.a является, как следует из названия IRC-червем. При запуске он сохраняет себя в каталоге Windows под именем trlmsn.exe и добавляет в раздел автозапуска реестра Windows параметр со строкой запуска этого файла. Кроме этого червь сохраняет на диск свою копию в виде архива Janey2002.zip и файл-изображение Janey.jpg. Затем червь подключается к произвольным IRC-каналам под различными именами и начинает слать определенные текстовые строки, имитируя активность обычного пользователя. Параллельно всем пользователям этих каналов отсылается заархивированная копия червя.
Функциональностью распространения через P2P-каналы обладают многие сетевые и почтовые черви. Например, Email-Worm.Win32.Netsky.q для размножения через файлообменные сети ищет на локальном диске каталоги, содержащие названия наиболее популярных сетей или же слово "shared", после чего кладет в эти каталоги свои копии под различными названиями.
IM-черви редко пересылают зараженные файлы непосредственно между клиентами. Вместо этого они рассылают ссылки на зараженные веб-страницы. Так червь IM-Worm.Win32.Kelvir.k посылает через MSN Messenger сообщения, содержащие текст "its you" и ссылку "http://www.malignancy.us/[removed]/pictures.php?email=[email]", по указанному в которой адресу расположен файл червя.
Сегодня наиболее многочисленную группу составляют почтовые черви. Сетевые черви также являются заметным явлением, но не столько из-за количества, сколько из-за качества: эпидемии, вызванные сетевыми червями зачастую отличаются высокой скоростью распространения и большими масштабами. IRC-, P2P- и IM-черви встречаются достаточно редко, чаще IRC, P2P и IM служат альтернативными каналами распространения для почтовых и сетевых червей.
Способы активации
На этапе активации черви делятся на две большие группы, отличающиеся как по технологиям, так и по срокам жизни:
Под пассивным участием пользователя во второй группе понимается, например, просмотр писем в почтовом клиенте, при котором пользователь не открывает вложенные файлы, но его компьютер, тем не менее, оказывается зараженным.
Отличие в этих подходах глубже, чем может показаться на первый взгляд. Активация сетевого червя без участия пользователя всегда означает, что червь использует бреши в безопасности программного обеспечении компьютера. Это приводит к очень быстрому распространению червя внутри корпоративной сети с большим числом станций, существенно увеличивает загрузку каналов связи и может полностью парализовать сеть. Именно этот метод активации использовали черви Lovesan и Sasser. В результате вызванной таким сетевым червем эпидемии, используемая брешь закрывается администраторами либо пользователями, и по мере уменьшения компьютеров с открытой брешью эпидемия завершается. Для повторения эпидемии разработчикам вирусов приходится эксплуатировать другую брешь. В итоге, эпидемии, вызванные активными червями, существеннее влияют на работу сети в целом, однако случаются значительно реже, чем эпидемии пассивных сетевых червей. Обязательной мерой защиты от таких эпидемий является своевременная установка заплат безопасности. Отметим также, что особенно уязвимыми для этого типа червей являются операционные системы с заложенными возможностями удаленного управления или запуска программ - это семейство Microsoft Windows NT/2000/XP/2003.
Пример. Уязвимость в службе LSASS, впервые использованная в черве MyDoom в начале 2004 года, продолжала успешно применяться и спустя полтора года. Так Net-Worm.Win32.Mytob.be обнаруженный в июне 2005 все еще использовал эту уязвимость как один из способов распространения, в дополнение к распространению через электронную почту.
С другой стороны, активное участие пользователя в активации червя означает, что пользователь был введен в заблуждение методами социальной инженерии. В большинстве случаев основным фактором служит форма подачи инфицированного сообщения: оно может имитировать письмо от знакомого человека (включая электронный адрес, если знакомый уже заражен), служебное сообщение от почтовой системы или же что-либо подобное, столь же часто встречающееся в потоке обычной корреспонденции. Пользователь в суматохе просто не отличает обычное письмо от зараженного и производит запуск автоматически.
Защититься заплатами от такого рода червей невозможно. Даже внесение сигнатуры сетевого червя в вирусную базу данных не решает проблему до конца. Разработчикам вируса достаточно изменить исполняемый файл так, чтобы антивирус его не обнаруживал, и незначительно поменять текст сообщения, используя в том числе и технологии спам-рассылок, применяемые для обхода фильтров.
В результате, эпидемии, вызванные пассивными сетевыми червями, могут быть гораздо продолжительнее и порождать целые семейства однотипных сетевых червей.
В последнее время наметилась тенденция к совмещению в червях обоих способов распространения. Многие представители семейства Mytob обладают функциями распространения через электронную почту и через уязвимость в службе LSASS.
Поиск "жертв"
Способ поиска компьютера-жертвы полностью базируется на используемых протоколах и приложениях. В частности, если речь идет о почтовом черве, производится сканирование файлов компьютера на предмет наличия в них адресов электронной почты, по которым в результате и производится рассылка копий червя.
Точно так же Интернет-черви сканируют диапазон IP адресов в поисках уязвимых компьютеров, а P2P черви кладут свои копии в общедоступные каталоги клиентов пиринговых сетей. Некоторые черви способны эксплуатировать списки контактов интернет-пейджеров, таких как ICQ, AIM, MSN Messenger, Yahoo! Messenger и др.
Подготовка копий для распространения
Сказанное ранее о подготовке копий для распространения вирусов, применимо и для червей.
Наиболее часто среди червей встречаются упрощенные реализации метаморфизма. Некоторые черви способны рассылать свои копии в письмах, как с внедрением скрипта приводящего к автоматической активации червя, так и без внедрения. Такое поведение червя обусловлено двумя факторами: скрипт автоматической активации повышает вероятность запуска червя на компьютере пользователя, но при этом уменьшает вероятность проскочить антивирусные фильтры на почтовых серверах.
Аналогично, черви могут менять тему и текст инфицированного сообщения, имя, расширение и даже формат вложенного файла - исполняемый модуль может быть приложен как есть или в заархивированном виде. Все это нельзя считать мета- или полиморфизмом, но определенной долей изменчивости черви, безусловно, обладают.
Приведем интуитивное определение троянской программы или трояна.
Определение 3.6. Троян (троянский конь) — тип вредоносных программ, основной целью которых является вредоносное воздействие по отношению к компьютерной системе. Трояны отличаются отсутствием механизма создания собственных копий. Некоторые трояны способны к автономному преодолению систем защиты КС, с целью проникновения и заражения системы. В общем случае, троян попадает в систему вместе с вирусом либо червем, в результате неосмотрительных действий пользователя или же активных действий злоумышленника.
Жизненный цикл
В силу отсутствия у троянов функций размножения и распространения, их жизненный цикл крайне короток - всего три стадии:
Это, само собой, не означает малого времени жизни троянов. Напротив, троян может длительное время незаметно находиться в памяти компьютера, никак не выдавая своего присутствия, до тех пор, пока не будет обнаружен антивирусными средствами.
Способы проникновения
Задачу проникновения на компьютер пользователя трояны решают обычно одним из двух следующих методов.
Пример. Trojan.SymbOS.Hobble.a является архивом для операционной системы Symbian (SIS-архивом). При этом он маскируется под антивирус Symantec и носит имя symantec.sis. После запуска на смартфоне троян подменяет оригинальный файл оболочки FExplorer.app на поврежденный файл. В результате при следующей загрузке операционной системы большинство функций смартфона оказываются недоступными
Одним из вариантов маскировки может быть также внедрение злоумышленником троянского кода в код другого приложения. В этом случае распознать троян еще сложнее, так как зараженное приложение может открыто выполнять какие-либо полезные действия, но при этом тайком наносить ущерб за счет троянских функций.
Распространен также способ внедрения троянов на компьютеры пользователей через веб-сайты. При этом используется либо вредоносный скрипт, загружающий и запускающий троянскую программу на компьютере пользователя, используя уязвимость в веб-браузере, либо методы социальной инженерии - наполнение и оформление веб-сайта провоцирует пользователя к самостоятельной загрузке трояна. При таком методе внедрения может использоваться не одна копия трояна, а полиморфный генератор, создающий новую копию при каждой загрузке. Применяемые в таких генераторах технологии полиморфизма обычно не отличаются от вирусных полиморфных технологий.
Пример. Используя backdoor-функционал червей семейства Bagle, автор червя проводил скрытую инсталляцию трояна SpamTool.Win32.Small.b, который собирал и отсылал на определенный адрес адреса электронной почты, имевшиеся в файлах на зараженном компьютере.
Нередко наблюдается кооперация червей с вирусами, когда червь обеспечивает транспортировку вируса между компьютерами, а вирус распространяется по компьютеру, заражая файлы.
Пример. Известный в прошлом червь Email-Worm.Win32.Klez.h при заражении компьютера также запускал на нем вирус Virus.Win32.Elkern.c. Зачем это было сделано, сказать тяжело, поскольку вирус сам по себе, кроме заражения и связанных с ошибками в коде вредоносных проявлений (явно выраженных вредоносных процедур в нем нет), никаких действий не выполняет, т. е. не является "усилением" червя в каком бы то ни было смысле.
Активация
Здесь приемы те же, что и у червей: ожидание запуска файла пользователем, либо использование уязвимостей для автоматического запуска.
Выполняемые функции
В отличие от вирусов и червей, деление которых на типы производится по способам размножения/распространения, трояны делятся на типы по характеру выполняемых ими вредоносных действий. Наиболее распространены следующие виды троянов.
Пример. В прошлом, буквально пару лет назад еще встречались клавиатурные шпионы, которые фиксировали все нажатия клавиш и записывали их в отдельный файл. Trojan-Spy.Win32.Small.b, например, в бесконечном цикле считывал коды нажимаемых клавиш и сохранял их в файле C:\SYS
Современные программы-шпионы оптимизированы для сбора информации, передаваемой пользователем в Интернет, поскольку среди этих данных могут встречаться логины и пароли к банковским счетам, PIN-коды кредитных карт и прочая конфиденциальная информация, относящаяся к финансовой деятельности пользователя. Trojan-Spy.Win32.Agent.fa отслеживает открытые окна Internet Explorer и сохраняет информацию с посещаемых пользователем сайтов, ввод клавиатуры в специально созданный файл servms.dll с системном каталоге Windows.
Пример. Trojan-PSW.Win32.LdPinch.kw собирает сведения о системе, а также логины и пароли для различных сервисов и прикладных программ - мессенджеров, почтовых клиентов, программ дозвона. Часто эти данные оказываются слабо защищены, что позволяет трояну их получить и отправить злоумышленнику по электронной почте
Пример. Backdoor.Win32.Netbus.170 предоставляет полный контроль над компьютером пользователя, включая выполнение любых файловых операций, загрузку и запуск других программ, получение снимков экрана и т. д.
Пример. В последнее время backdoor-функционал стал характерной чертой червей. Например, Email-Worm.Win32.Bagle.at использует порт 81 для получения удаленных команд или загрузки троянов, расширяющих функционал червя.
Есть и отдельные трояны типа backdoor. Троян Backdoor.win32.Wootbot.gen использует IRC-канал для получения команд от "хозяина". По команде троян может загружать и запускать на выполнение другие программы, сканировать другие компьютеры на наличие уязвимостей и устанавливать себя на компьютеры через обнаруженные уязвимости.
Пример. Трояны из семейства Trojan-Proxy.Win32.Mitglieder распространяются с различными версиями червей Bagle. Троян запускается червем, открывает на компьютере порт и отправляет автору вируса информацию об IP-адресе зараженного компьютера. После этого компьютер может использоваться для рассылки спама
Пример. Trojan.Win32.Dialer.a при запуске осуществляет дозвон в Интернет через платные почтовые службы. Никаких других действий не производит, в том числе не создает ключей в реестре, т. е. даже не регистрируется в качестве стандартной программы дозвона и не обеспечивает автозапуск.
Пример. Trojan-Clicker.JS.Pretty обычно содержится в html-страницах. Он открывает дополнительные окна с определенными веб-страницами и обновляет их с заданным интервалом
Пример. Virus.Win9x.CIH, Macro.Word97.Thus
Ущерб от вредоносных программ
Черви и вирусы могут осуществлять все те же действия, что и трояны (см.предыдущий пункт). На уровне реализации это могут быть как отдельные троянские компоненты, так и встроенные функции. Кроме этого, за счет массовости, для вирусов и червей характерны также другие формы вредоносных действий:
Наличие деструктивных действий вовсе не является обязательным критерием для классификации программного кода как вирусного. Следует также отметить, что одним только процессом саморазмножения вирус способен причинить колоссальный ущерб. Наиболее яркий пример - Net-Worm.Win32.Slammer.
Рассмотрим угрозы безопасности информации с точки зрения вирусов. Учитывая тот факт, что общее число вирусов по состоянию на сегодня превосходит 100000, проанализировать угрозы со стороны каждого из них является слишком трудоемкой и бесполезной задачей, поскольку ежедневно возрастает количество вирусов, а значит, необходимо ежедневно модифицировать полученный список. В этой работе мы будем считать, что вирус способен реализовать любую из угроз безопасности информации.
Существует множество способов классификации угроз безопасности информации, которая обрабатывается в автоматизированной системе. Наиболее часто используется классификация угроз по результату их влияния на информацию, а именно - нарушение конфиденциальности, целостности и доступности.
Для каждой угрозы существует несколько способов ее реализации со стороны вирусов.
Угроза нарушения конфиденциальности
Угроза нарушения целостности
Угроза нарушения доступности
Как несложно было убедиться, для каждого из приведенных выше способов реализации угроз можно привести конкретный пример вируса, реализующего один или одновременно несколько способов.
Вредоносные программы отличаются условиями существования, применяемыми технологиями на различных этапах жизненного цикла, собственно вредоносным воздействием - все эти факторы и являются основой для классификации. В результате по основному (с исторической точки зрения) признаку - размножению, вредоносные программы делятся на три типа: собственно вирусы, черви и трояны.
Независимо от типа, вредоносные программы способны наносить значительный ущерб, реализуя любые угрозы информации - угрозы нарушения целостности, конфиденциальности, доступности. В связи с этим при проектировании комплексных систем антивирусной защиты, и даже в более общем случае - комплексных системы защиты информации, необходимо проводить градацию и классифицировать объекты сети по важности обрабатываемой на них информации и по вероятности заражения этих узлов вирусами.
4. Лекция: Что такое антивирусы
Определение 4.1. Антивирус - программное средство, предназначенное для борьбы с вирусами.
Как следует из определения, основными задачами антивируса является:
Технологии, применяемые в антивирусах, можно разбить на две группы -
Определение 4.2. Сигнатурный анализ - метод обнаружения вирусов, заключающийся в проверке наличия в файлах сигнатур вирусов.
Сигнатурный анализ является наиболее известным методом обнаружения вирусов и используется практически во всех современных антивирусах. Для проведения проверки антивирусу необходим набор вирусных сигнатур, который хранится в антивирусной базе.
Определение 4.3. Антивирусная база - база данных, в которой хранятся сигнатуры вирусов.
Ввиду того, что сигнатурный анализ предполагает проверку файлов на наличие сигнатур вирусов, антивирусная база нуждается в периодическом обновлении для поддержания актуальности антивируса. Сам принцип работы сигнатурного анализа также определяет границы его функциональности - возможность обнаруживать лишь уже известные вирусы - против новых вирусов сигнатурный сканер бессилен.
С другой стороны, наличие сигнатур вирусов предполагает возможность лечения инфицированных файлов, обнаруженных при помощи сигнатурного анализа. Однако, лечение допустимо не для всех вирусов - трояны и большинство червей не поддаются лечению по своим конструктивным особенностям, поскольку являются цельными модулями, созданными для нанесения ущерба.
Грамотная реализация вирусной сигнатуры позволяет обнаруживать известные вирусы со стопроцентной вероятностью.
Технологии вероятностного анализа в свою очередь подразделяются на три категории:
Определение 4.4. Эвристический анализ - технология, основанная на вероятностных алгоритмах, результатом работы которых является выявление подозрительных объектов.
В процессе эвристического анализа проверяется структура файла, его соответствие вирусным шаблонам. Наиболее популярной эвристической технологией является проверка содержимого файла на предмет наличия модификаций уже известных сигнатур вирусов и их комбинаций. Это помогает определять гибриды и новые версии ранее известных вирусов без дополнительного обновления антивирусной базы.
Эвристический анализ применяется для обнаружения неизвестных вирусов, и, как следствие, не предполагает лечения.
Данная технология не способна на 100% определить вирус перед ней или нет, и как любой вероятностный алгоритм грешит ложными срабатываниями.
Определение 4.5. Поведенческий анализ - технология, в которой решение о характере проверяемого объекта принимается на основе анализа выполняемых им операций.
Поведенческий анализ весьма узко применим на практике, так как большинство действий, характерных для вирусов, могут выполняться и обычными приложениями. Наибольшую известность получили поведенческие анализаторы скриптов и макросов, поскольку соответствующие вирусы практически всегда выполняют ряд однотипных действий. Например, для внедрения в систему, почти каждый макровирус использует один и тот же алгоритм: в какой-нибудь стандартный макрос, автоматически запускаемый средой Microsoft Office при выполнении стандартных команд (например, "Save", "Save As", "Open", и т.д.), записывается код, заражающий основной файл шаблонов normal.dot и каждый вновь открываемый документ.
Средства защиты, вшиваемые в BIOS, также можно отнести к поведенческим анализаторам. При попытке внести изменения в MBR компьютера, анализатор блокирует действие и выводит соответствующее уведомление пользователю.
Помимо этого поведенческие анализаторы могут отслеживать попытки прямого доступа к файлам, внесение изменений в загрузочную запись дискет, форматирование жестких дисков и т. д.
Поведенческие анализаторы не используют для работы дополнительных объектов, подобных вирусным базам и, как следствие, неспособны различать известные и неизвестные вирусы - все подозрительные программы априори считаются неизвестными вирусами. Аналогично, особенности работы средств, реализующих технологии поведенческого анализа, не предполагают лечения.
Как и в предыдущем случае, возможно выделение действий, однозначно трактующихся как неправомерные - форматирование жестких дисков без запроса, удаление всех данных с логического диска, изменение загрузочной записи дискеты без соответствующих уведомлений и пр. Тем не менее, наличие действий неоднозначных - например, макрокоманда создания каталога на жестком диске, заставляет также задумываться о ложных срабатываниях и, зачастую, о тонкой ручной настройке поведенческого блокиратора.
Определение 4.6. Анализ контрольных сумм - это способ отслеживания изменений в объектах компьютерной системы. На основании анализа характера изменений - одновременность, массовость, идентичные изменения длин файлов - можно делать вывод о заражении системы.
Анализаторы контрольных сумм (также используется название "ревизоры изменений") как и поведенческие анализаторы не используют в работе дополнительные объекты и выдают вердикт о наличии вируса в системе исключительно методом экспертной оценки. Большая популярность анализа контрольных сумм связана с воспоминаниями об однозадачных операционных системах, когда количество вирусов было относительно небольшим, файлов было немного и менялись они редко. Сегодня ревизоры изменений утратили свои позиции и используются в антивирусах достаточно редко. Чаще подобные технологии применяются в сканерах при доступе - при первой проверке с файла снимается контрольная сумма и помещается в кэше, перед следующей проверкой того же файла сумма снимается еще раз, сравнивается, и в случае отсутствия изменений файл считается незараженным.
Подводя итоги обзора технологий, применяемых в антивирусах, отметим, что сегодня практически каждый антивирус использует несколько из перечисленных выше технологий, при этом использование сигнатурного и эвристического анализа для проверки файлов и именно в этом порядке является повсеместным. В дальнейшем средства, реализующие комбинацию сигнатурного и эвристического анализа, мы будем называть антивирусными сканерами.
Вторая группа технологий более разнородна, поскольку ни один из применяемых подходов не дает гарантии обнаружения неизвестных вирусов. Очевидно, что и совместное использование всех этих технологий не дает такой гарантии. На сегодняшний день лучшим способом борьбы с новыми угрозами является максимально быстрое реагирование разработчиков на появление новых экземпляров вирусов выпуском соответствующих сигнатур. Также, учитывая наличие активных вредоносных программ, необходимо не менее быстро реагировать на обнаружение новых уязвимостей в операционных системах и устанавливать соответствующие заплаты безопасности.
Помимо используемых технологий, антивирусы отличаются друг от друга условиями эксплуатации. Уже из анализа задач можно сделать вывод о том, что препятствование проникновению вредоносного кода должно осуществляться непрерывно, тогда как обнаружение вредоносного кода в существующей системе - скорее разовое мероприятие. Следовательно, средства, решающие эти две задачи должны функционировать по-разному.
Таким образом, антивирусы можно разделить на две большие категории:
Как показывает практика, предотвратить возникновение проблемы гораздо проще, чем пытаться впоследствии ее решить. Именно поэтому современные антивирусные комплексы в большинстве своем подразумевают непрерывный режим эксплуатации. Тем не менее, средства периодической проверки гораздо эффективнее при борьбе с последствиями заражения и поэтому не менее необходимы.
Определение 4.7. Антивирусное ядро - реализация механизма сигнатурного сканирования и эвристического анализа на основе имеющихся сигнатур вирусов.
Определение 4.8. Антивирусный комплекс - набор антивирусов, использующих одинаковое антивирусное ядро или ядра, предназначенный для решения практических проблем по обеспечению антивирусной безопасности компьютерных систем. В антивирусный комплекс также в обязательном порядке входят средства обновления антивирусных баз.
Помимо этого антивирусный комплекс дополнительно может включать в себя поведенческие анализаторы и ревизоры изменений, которые вовсе не используют антивирусное ядро.
В качестве вспомогательной утилиты антивирусный комплекс может содержать (и на практике обычно содержит) планировщик заданий.
Исходя из текущей необходимости в средствах защиты выделяют следующие типы антивирусных комплексов:
Антивирусный комплекс для защиты рабочих станций
Предназначен для обеспечения антивирусной защиты рабочей станции, на которой он установлен. Состоит, как и указывалось ранее из средств непрерывной работы и предназначенных для периодического запуска, а также средств обновления антивирусных баз.
К средствам непрерывной работы относятся:
Средства периодического запуска:
На практике антивирусный комплекс для рабочей станции зачастую включает еще и поведенческие блокираторы, также относящиеся к средствам непрерывной работы.
Антивирусный комплекс для защиты файловых серверов
Предназначен для обеспечения антивирусной защиты сервера, на котором установлен. Указание на файловый сервер в названии является скорее данью истории, корректней будет звучать термин "сетевой". Определение того, насколько нуждается в антивирусной защите сервер, осуществляется не только исходя из его назначения (является сервер файловым, почтовым, либо выполняет другую функцию), но и из используемой на нем платформы. Более того, зачастую именно платформа является определяющей характеристикой при выборе средств защиты сетевого сервера. Речь об этом пойдет ниже.
Отличия в составе антивирусного комплекса для файлового сервера, в сравнении с антивирусным комплексом для рабочей станции, происходят из различного назначения этих типовых узлов сети, а точнее из главного различия: рабочая станция обычно является АРМ сотрудника, тогда как сервер в качестве АРМ не используется.
Исходя из этого, антивирусный комплекс для защиты файловых серверов обычно состоит из двух ярко выраженных представителей средств непрерывного работы и периодического запуска:
а также средства обновления антивирусных баз.
Сканер локальной почтовой системы отсутствует по описанной выше причине.
Антивирусный комплекс для защиты почтовых систем
Еще один казус, связанный с общепринятой терминологией. Безусловно, антивирусный комплекс не предназначен для защиты почтовой системы от поражения вирусами, его назначение - препятствовать доставке зараженных сообщений пользователям сети. Как уже указывалось ранее, сегодня одним из главных средств доставки вирусов в локальную сеть является именно электронная почта. Поэтому, при наличии в локальной сети специализированного узла, обрабатывающего входящую и исходящую из сети почтовую корреспонденцию (почтового сервера), логично будет использовать средство централизованной проверки всего почтового потока на наличие вирусов. Тем не менее, термин "для защиты почтовых систем" является устоявшимся и повсеместно применяется при указании практических реализаций этого типа комплексов. Дабы не вводить читателя в противоречие с ежедневно потребляемой информацией, в дальнейшем здесь также будет использоваться приведенное выше название. Аналогичный комментарий, с поправкой на специфику работы, применим и к антивирусным комплексам для защиты шлюзов.
Антивирусный комплекс для защиты почтовых систем, как и другие антивирусные комплексы включает антивирусы обоих типов.
Средства непрерывной работы:
Средства периодического запуска:
Также, антивирусный комплекс для защиты почтовых систем обязательно включает средство обновления антивирусных баз. Дополнительно, для снижения нагрузки на сервер могут выделяться отдельные средства для проверки баз во время репликаций. Такие средства также относятся к средствам периодического запуска.
Антивирусный комплекс для защиты шлюзов
Антивирусный комплекс для защиты шлюза, как следует из названия, предназначен для проверки на наличие вирусов данных, через этот шлюз передаваемых.
На практике основными каналами доставки вирусов в локальную сеть являются SMTP, HTTP и FTP-потоки, следовательно, антивирусный комплекс для защиты шлюзов преимущественно включает средства непрерывной работы. Антивирусы периодического запуска используются редко, преимущественно для защиты файловой системы сервера, на котором установлен комплекс:
Естественно, как и в предыдущих случаях в комплекс в обязательном порядке входит средство для обновления антивирусных баз.
Задача защиты от вредоносных программ одного компьютера, рабочей станции, практически решается весьма просто - в этом случае необходимо регулярно устанавливать заплаты безопасности, выпускаемые производителем (обычно - Microsoft) для операционной системы, установить антивирусный комплекс для защиты рабочей станции и соблюдать общие правила безопасности. Такой подход логичен и оказывается эффективным и в случае двух, трех, и даже десяти станций. Защита сетей, пусть и не очень больших, является существенно более сложной задачей, описанный выше подход не является эффективным. Здесь необходимо учитывать множество дополнительных факторов, речь о которых пойдет далее в этой главе.
При организации защиты сети нужно принимать во внимание:
Проектирование системы антивирусной защиты сети предполагает наличие всех перечисленных ранее категорий пользователей. Это еще раз подчеркивает усложнение задачи, стоящей перед проектировщиком системы, а учитывая важность поставленной задачи заставляет говорить о необходимости создания комплексной системы антивирусной защиты.
Комплексная система антивирусной защиты — совокупность организационных, правовых и программно-аппаратных мер и средств, направленных на обеспечение эффективной антивирусной защиты информации в локальной сети. Комплексность системы антивирусной защиты достигается контролем всех информационных потоков протекающих в локальной сети и согласованием между собой разнородных методов и средств, обеспечивающих антивирусную защиту всех элементов локальной сети.
Организационные меры
Достижение безопасности информации невозможно без принятия надлежащих организационных мер. С одной стороны, эти меры должны быть направлены на обеспечение правильности и эффективности функционирования КСАЗ и выполняться администратором антивирусной безопасности. С другой стороны, руководство организации должно регламентировать правила автоматизированной обработки информации, включая и правила ее антивирусной защиты, а также установить меру ответственности за нарушение этих правил.
К организационным мерам антивирусной защиты можно отнести организационно-технические и организационно-правовые мероприятия, осуществляемые в процессе создания, внедрения и эксплуатации КСАЗ с целью обеспечения антивирусной защиты информации. Насколько важным являются организационные мероприятия в общем арсенале средств антивирусной защиты, говорит уже хотя бы тот факт, что ни одна автоматизированная система, в особенности система связанная с обеспечением защиты информации не может функционировать без участия обслуживающего персонала. А эффективность выполнения обслуживающим персоналом своих функций зависит не только от его профессиональных качеств, но и от того, насколько правильно и полно регламентированы его действия. Также это зависит от взаимодействия с другими подразделениями, обслуживающими локальную сеть, в штатных и особенно в нештатных ситуациях, которые могут возникать при эксплуатации КСАЗ.
Организационными мерами можно бороться и с некоторыми категориями пользователей. К примеру, введение штрафа за несанкционированную деинсталляцию антивирусного комплекса существенно уменьшит количество желающих это сделать.
Иными словами организационные меры играют важную роль как в регламентации работы всей комплексной системы антивирусной защиты, что является обязательным требованием для ее корректного функционирования, так и в воздействии на пользователей КСАЗ.
Правовые меры
Помимо внутренних документов, предусматривающих ответственность за халатное отношение к обязанностям либо за умышленный останов антивирусного комплекса, существуют также и общеправовые меры воздействия, предусмотренные Уголовным кодексом РФ.
Глава 28 УК РФ содержит следующие статьи, относящиеся к компьютерным вирусам:
Статья 272. Неправомерный доступ к компьютерной информации. Неправомерный доступ к охраняемой законом компьютерной информации, то есть информации на машинном носителе, в электронно-вычислительной машине (ЭВМ), системе ЭВМ или их сети, если это деяние повлекло уничтожение, блокирование, модификацию либо копирование информации, нарушение работы ЭВМ, системы ЭВМ или их сети, - наказывается штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев, либо исправительными работами на срок от шести месяцев до одного года, либо лишением свободы на срок до двух лет. Наказывается штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев, либо исправительными работами на срок от шести месяцев до одного года, либо лишением свободы на срок до двух лет. То же деяние, совершенное группой лиц по предварительному сговору или организованной группой либо лицом с использованием своего служебного положения, а равно имеющим доступ к ЭВМ, системе ЭВМ или их сети, - наказывается штрафом в размере от пятисот до восьмисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от пяти до восьми месяцев, либо исправительными работами на срок от одного года до двух лет, либо арестом на срок от трех до шести месяцев, либо лишением свободы на срок до пяти лет.
Статья 273. Создание, использование и распространение вредоносных программ для ЭВМ. Создание программ для ЭВМ или внесение изменений в существующие программы, заведомо приводящих к несанкционированному уничтожению, блокированию, модификации либо копированию информации, нарушению работы ЭВМ, системы ЭВМ или их сети, а равно использование либо распространение таких программ или машинных носителей с такими программами - наказываются лишением свободы на срок до трех лет со штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев. Те же деяния, повлекшие по неосторожности тяжкие последствия, - наказываются лишением свободы на срок от трех до семи лет.
Статья 274. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети. Нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети лицом, имеющим доступ к ЭВМ, системе ЭВМ или их сети, повлекшее уничтожение, блокирование или модификацию охраняемой законом информации ЭВМ, если это деяние причинило существенный вред, - наказывается лишением права занимать определенные должности или заниматься определенной деятельностью на срок до пяти лет, либо свободы на срок до двух лет. То же деяние, повлекшее по неосторожности тяжкие последствия, - наказывается лишением свободы на срок до четырех лет.
Отдельно, учитывая описанные ранее функции троянов, следует упомянуть и статью 138, посвященную нарушению тайны переписки.
Статья 138. Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений. Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений граждан - наказывается штрафом в размере от пятидесяти до ста минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период до одного месяца, либо обязательными работами на срок от ста двадцати до ста восьмидесяти часов, либо исправительными работами на срок до одного года. То же деяние, совершенное лицом с использованием своего служебного положения или специальных технических средств, предназначенных для негласного получения информации, - наказывается штрафом в размере от ста до трехсот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от одного до трех месяцев, либо лишением права занимать определенные должности или заниматься определенной деятельностью на срок от двух до пяти лет, либо арестом на срок от двух до четырех месяцев. Незаконные производство, сбыт или приобретение в целях сбыта специальных технических средств, предназначенных для негласного получения информации, - наказываются штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев, либо ограничением свободы на срок до трех лет, либо лишением свободы на срок до трех лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет.
Программные средства
Как видно из определения, КСАЗ должна контролировать и осуществлять проверку всех информационных потоков, циркулирующих в локальной сети и представляющих угрозу как потенциальный канал для распространения вирусов.
Следовательно, перед проектированием КСАЗ необходимо произвести анализ сети и циркулирующих в ней информационных потоков, определить защищаемые узлы и узлы, на которые будут установлены антивирусные комплексы.
Каждая сеть устроена по-своему и содержит особенности, однако мы можем говорить здесь о типовой локальной сети, типовых узлах и информационных потоках, которые между этими узлами циркулируют. При проектировании реальных систем к описанным далее компонентам будут добавлены новые, некоторые классы защищаемых узлов будут разделены на подклассы.
Итак, типовая локальная сеть содержит следующие типы узлов:
Рис. 4.1. Типовая локальная сеть
Файловые сервера следует понимать в описанном ранее широком смысле.
Рабочая станция принимает участие в следующих информационных потоках: пользователь имеет интерактивный доступ к ресурсам Интернет (http/ftp протоколы), работает с электронной почтой (smtp/pop/imap протоколы либо протокол передачи данных системы групповой работы), взаимодействует с файловыми серверами (как с файловыми хранилищами, так и с серверами баз данных), а также с другими станциями сети. Поток между станциями в штатном режиме работы сети не должен быть существенным, поскольку вся информация должна храниться на серверах, однако этот поток нельзя исключать по причине его важности для антивирусной защиты. Помимо перечисленных, рабочая станция содержит различные дисководы и возможно подключение к ней сменных носителей - дискет, компакт-дисков, flash-накопителей.
Файловый сервер в общем случае взаимодействует только с другими файловыми серверами и рабочими станциями. Достаточно редко, но также обязательно используются сменные носители.
Почтовый сервер принимает и отсылает напрямую либо через шлюз корреспонденцию (smtp-протокол), а также передает доставленные письма клиентам (pop/imap/другой протокол).
Наконец, через шлюз проходят запросы пользователей к внешним ресурсам при работе с Интернет (http/ftp) и почтовый поток к и от почтового сервера (smtp).
Схема потоков приведена на рис. 4.2.
увеличить изображение
Рис. 4.2. Схема информационных потоков в типовой локальной сети
Еще раз отметим, что все эти потоки являются типовыми, даже из уже перечисленных узлов рабочие станции могут не участвовать в некоторых потоках, например, станции, на которых обрабатывается информация с ограниченным доступом обычно не подключены к Интернет. В сети может быть произведено разделение на внешнюю и внутреннюю почтовую систему, тогда следует при классификации узлов необходимо учитывать к какой из систем либо к обеим подключена станция, возможно двухсегментное построение вообще всей сети и так далее. Исходя из характеристик узлов и информационных потоков, в которых эти узлы участвуют, и производится классификация узлов всей сети.
Для описанной выше типовой локальной сети, структурно КСАЗ можно разделить на следующие уровни:
Не следует забывать о том, что защита рабочих станций и файловых серверов подразумевает защиту и мобильных компьютеров, и, если по каким-то причинам это необходимо, удаленных компьютеров которые периодически подключаются к сети.
Каждый из уровней организуется при помощи описанных антивирусных комплексов. Дополнительные требования налагаются на комплекс для защиты рабочих станций и файловых серверов. Учитывая большое количество узлов таких типов и трудозатраты на обслуживание одного узла, а также в целях экономии Интернет-канала, комплекс для защиты рабочих станций и файловых серверов в дополнение должен содержать средство централизованного управления, позволяющее:
Этапность работ
Создание КСАЗ проводится в несколько этапов. На первом этапе разрабатываются документы, которые являются основой для проведения работ - Концепция и Политика антивирусной безопасности.
Концепция антивирусной безопасности - официально принятая организацией система взглядов на цели, задачи и принципы обеспечения антивирусной безопасности в своей локальной сети. В концепции определяются объекты антивирусной безопасности в локальной сети, возможные источники угрозы, методы предотвращения и нейтрализации этих угроз, а также основы согласованной политики в области антивирусной безопасности в локальной сети Заказчика.
Фактически, Концепция антивирусной безопасности является официальной позицией организации по отношению к вирусной угрозе. Утверждение Концепции помогает начать работы по созданию КСАЗ это - сигнал к тому, что руководство понимает важность задачи и готово ее решать.
Политика антивирусной безопасности определяет совокупность правил, задающих и ограничивающих виды деятельности объектов и участников, комплексной системы антивирусной защиты, ее основные цели и область ее применения.
Как правило, разработка политики проводится после обследования, которое заключается в выявлении и анализе информационных потоков, протекающих в организации, категорировании узлов сети по возможности реализации вирусной угрозы, составления матрицы - категория/возможность реализации для данного информационного потока. По результатам обследования составляется отчет.
На основании Политики антивирусной безопасности составляется Техническое задание на создание КСАЗ. Техническое задание - основной документ для выполнения работ по обеспечению антивирусной защиты информации. Определяет требования к функциональному составу и порядку внедрения программных средств, которые обеспечивают антивирусную защиту информации в процессе ее обработки в локальной сети. Именно на основе технического задания осуществляется разработка Технического проекта КСАЗ и приемка будущей системы в эксплуатацию.
Технический проект - документ, содержащий подробное описание проектируемой КСАЗ, состав и назначение подсистем, схему их взаимодействия, способы организации обновлений подсистем, схему управления КСАЗ, требования к персоналу, устанавливающему и обслуживающему систему.
Иными словами, технический проект это ответ на вопрос как будет реализовываться система, затребованная в техническом задании.
Помимо проектной (а все описанные документы относятся к проектной документации), также должна быть разработана документация эксплуатационная. К эксплуатационной документации относятся инструкции администратора и пользователя КСАЗ.
Инструкция пользователя - документ, регламентирующий действия пользователей локальной сети по отношению к КСАЗ.
Инструкция администратора - документ, регламентирующий типовые действия администратора по поддержанию работоспособности КСАЗ.
Разработанная система должны быть внедрена, следовательно, следующий этап - Внедрение.
Внедрение комплексной системы антивирусной защиты в любой существующей сети процесс кропотливый и достаточно трудоемкий, требующий значительных затрат ресурсов, впрочем, как и внедрение любой автоматизированной системы. Значительные затраты ресурсов связаны с тем, что работы по внедрению и развертыванию КСАЗ должны проводиться в максимально короткие сроки, чтобы свести к минимуму возможность заражения незащищенных элементов локальной сети. Также стоит отметить тот факт, что внедрение КСАЗ в большинстве случаев выявляет необходимость проведения работ по установке заплат безопасности к операционным системам. Отсутствие заплат существенно понижает, а в ряде случаев сводит на нет эффективность антивирусной защиты.
Внедрение комплексной системы антивирусной защиты включает в себя следующие этапы:
Выбор антивирусных комплексов
На практике помимо схемы построения и разработки проектной и эксплуатационной документации возникает вопрос выбора производителя антивирусных комплексов, которые будут использоваться в рамках КСАЗ.
Существует два подхода к выбору - одновендорный и многовендорный. В первом случае на всех уровнях КСАЗ используются средства одного производителя, в другом - различных. Оба подхода имеют преимущества и недостатки.
Преимущества и недостатки одновендорных систем
Преимущества
Главное преимущество одновендорных систем состоит в единообразии решений. Практическими следствиями из этого единообразия являются:
Недостатки
Основных недостатка у одновендорной системы два:
Преимущества и недостатки мультивендорных систем
Преимущества и недостатки мультивендорных систем в целом симметричны недостаткам и преимуществам одновендорных.
Преимущества
Основные преимущества мультивендорных систем в их большей гибкости, а также в естественной неоднородности, что в ряде случаев дает заметный выигрыш в защищенности по сравнению с одновендорными системами. Если же говорить более подробно, преимущества мультивендорных систем таковы:
Недостатки
Недостатки мультивендорной системы антивирусной защиты по понятным причинам лежат в тех же плоскостях, что и преимущества одновендорных:
Может показаться, что у одновендорных систем больше преимуществ и меньше недостатков в сравнении с мультивендорными. При защите небольших и несложных по структуре систем, как правило, так и есть. Но как только речь заходит о сложной гетерогенной сети в силу вступает целый ряд факторов:
Кроме того, на практике одновендорные системы нередко обладают многими недостатками мультивендорных:
5. Лекция: Защита шлюзов
Как известно из предыдущего материала первый уровень комплексной системы антивирусной защиты - это уровень защиты шлюзов.
В этом названии кроется неточность, которая может ввести в заблуждение. Формулировка "уровень защиты шлюзов" способна навести на мысль, что основной задачей антивирусов, предназначенных для использования на этом уровне, является защита самого шлюза от воздействия вредоносных программ. Это не так. Ни операционную систему шлюза, ни программное обеспечение, выполняющее шлюзовые функции антивирус для шлюзов не защищает.
Задача антивируса установленного на шлюзе в другом — не допустить проникновения вирусов вовнутрь сети через поток данных Интернет.
Здесь может возникнуть вопрос — зачем нужен антивирус, который, по сути, ничего не защищает? Ведь есть антивирусы для файловых серверов и рабочих станций, которые установлены непосредственно на компьютерах сети и призваны защищать от всех существующих вирусных угроз.
Дело в том, что ни одна защита не бывает абсолютной. Это связано даже не с фундаментальными результатами математиков, а с тем что надежность и эффективность антивирусного средства зависит от множества факторов - программного окружения, действий пользователя, настроек и т. д. Можно описать целый ряд ситуаций, при которых однажды установленный на компьютер антивирус оказывается частично или полностью неэффективным в борьбе с вредоносными программами:
Можно сказать, что каждый из приведенных сценариев маловероятен. Но если рассматривать достаточно большую сеть, то вероятность того, что хотя бы один из компьютеров в какой-то из моментов времени окажется незащищенным существенно возрастает и с ней уже приходится считаться. И если ничто не будет мешать проникновению вредоносных программ из Интернет, это будет означать, что существует немалая вероятность заражения одного из компьютеров сети.
Поэтому кроме обеспечения защиты самих компьютеров, крайне важно максимально ограничить количество проникающих в сеть вредоносных программ, чтобы временная неэффективность защиты на отдельных узлах не превращалась в серьезную угрозу безопасности.
Здесь можно отметить, что все перечисленные ситуации, при которых оказывается отключенным антивирус или не обновленными - антивирусные базы, действительно способны представлять угрозу только в больших сетях. Во-первых, вероятность реализации каждой из описанных возможностей достаточно мала и становится существенной только на фоне большого количества компьютеров, в малых сетях эти вероятности так и остаются несущественными.
Во-вторых, возникновение подобных ситуаций должно отслеживаться администратором антивирусной безопасности. В крупных сетях хотя бы на то, чтобы добраться до проблемного компьютера, может потребоваться значительное время, в течение которого уровень защиты сети не может считаться приемлемым. В малых сетях, напротив, все компьютеры на виду и легко доступны, что позволяет администратору антивирусной безопасности вовремя реагировать на возникающие проблемы.
Таким образом, антивирус для шлюза - это первый уровень защиты на пути проникновения вирусов в сеть организации, основная задача антивируса - помешать проникновению вирусов вовнутрь сети, снижая вероятность заражения компьютеров. Антивирус для шлюзов более эффективен и даже необходим при защите крупных сетей. В малых сетях его относительная полезность в обеспечении общей безопасности несколько ниже.
Впрочем, принимая во внимание, что в малых сетях далеко не всегда есть не то что администратор антивирусной безопасности, а штатный администратор вообще, использование антивируса на шлюзе будет не лишним и в этом случае.
Далее в этой главе будут рассмотрены:
Прежде чем говорить о том, с какими угрозами способен справиться обобщенный антивирус на шлюзе, необходимо остановиться на имеющихся реализациях подобных антивирусов, поскольку из ограничений реализации будут следовать и ограничения на защиту от разного рода угроз.
Понятно, что антивирус для шлюза должен так или иначе перехватывать данные, передаваемые из Интернет, анализировать эти данные и блокировать их поступление на компьютер пользователя, если они представляют угрозу.
Решать такую задачу можно двумя путями. Первый путь - разрабатывать с нуля систему обработки сетевых потоков, анализа пакетов, чтобы можно было к этой системе применить уже готовое антивирусное ядро и организовать проверку проходящего трафика. Этот путь требует значительных затрат на пути реализации.
В то же время, существует достаточное количество решений, предназначенных исключительно для обработки трафика, анализа и маршрутизации пакетов - это брандмауэры и прокси-сервера. Поэтому второй путь состоит в интеграции антивирусного решения с брандмауэром или прокси-сервером для проверки проходящего трафика.
Вкратце, преимущества первого пути в том, что антивирусное решение может быть использовано в сетях любой архитектуры, независимо от того, какие еще программные решения применяются для обработки сетевых потоков. Достаточно установить дополнительный сервер антивирусной проверки на пути потока данных из Интернет: как правило, непосредственно перед или непосредственно после основного шлюза. Преимущество второго подхода: возможность организовать антивирусную защиту не изменяя структуру сети, т. е. не вводя дополнительных серверов.
Имеет смысл более подробно остановиться на преимуществах, недостатках и особенностях реализации универсальных антивирусных решений для шлюзов и решений, построенных на интеграции с брандмауэрами и прокси-серверами.
Универсальные антивирусы для шлюзов
Универсальное антивирусное решение для шлюзов - это такое решение, которое может быть внедрено в сети независимо от того, какие уже решения уровня шлюзов в ней используются, без необходимости менять ПО брандмауэров и прокси-серверов на какое-либо другое. Фактически это означает, что антивирус не требует для работы наличия каких-то конкретных решений, с которыми ему необходимо интегрироваться. Соответственно, такой антивирус обладает функциями обработки трафика в объеме, достаточном для выполнения антивирусной проверки и прозрачного прохождения через антивирус всех потоков, не содержащих вредоносного кода.
Учитывая, что основной задачей антивируса для шлюзов является все же не обработка сетевых потоков, а антивирусная проверка, функции маршрутизации в нем существенно ограничены. Так, универсальный антивирус для шлюзов, не может быть использован как полноценный брандмауэр, прокси-сервер или межсетевой экран.
В силу указанной ограниченности функционала по обработке трафика, как правило, невозможно просто заменить имеющийся прокси-сервер или брандмауэр на антивирус для шлюзов. Вместо этого необходимо вводить дополнительный сервер, на котором будет установлено антивирусное решение, и который будет служить простым шлюзом, т. е. просто передавать данные от одного сервера на другой. В свою очередь, добавление антивирусного сервера требует изменения в настройках маршрутизации и, возможно, DNS, что нельзя назвать преимуществом.
Существующие реализации универсальных антивирусов для шлюзов позволяют проверять данные, поступающие по следующим протоколам:
Это связано во-первых с тем, что перечисленные протоколы являются наиболее часто используемыми при обмене данными с Интернет. С другой стороны, поддержка остальных протоколов, которые могут использоваться для передачи инфицированных файлов (например, NNTP), несущественно увеличивает уровень защиты и рассматривается производителями антивирусов как экономически неоправданная.
Стоит отметить, что из поддерживаемых протоколов только HTTP и FTP относятся к классу, который принято называть "протоколами Интернет". Тогда как SMTP (Simple Mail Transfer Protocol) - является почтовым протоколом. В этом смысле антивирусные решения для шлюзов нередко располагаются не только на первом уровне КСАЗ, но захватывают и часть второго уровня, выполняя антивирусную проверку почты, поступающей по протоколу SMTP на почтовые сервера организации.
С точки зрения возможных топологий сети с использованием универсального антивирусного решения для шлюзов, можно выделить следующие варианты. При этом проверку SMTP-протокола и протоколов Интернет удобно рассмотреть отдельно.
Проверка протоколов Интернет
При проверке протоколов Интернет, сервер антивирусной проверки наиболее оптимально устанавливать перед прокси-сервером, но за брандмауэром, если смотреть со стороны защищаемой сети. Впрочем, брандмауэр может и отсутствовать. В этом случае антивирус получает на вход тот же поток, который до этого получал прокси-сервер, выполняет проверку поступающих данных на наличие вредоносного кода и передает уже проверенные данные на прокси-сервер.
Рис. 5.1. Установка сервера антивирусной проверки перед прокси-сервером (Схема № 1)
Преимущества такого способа подключения заключаются в том, что нет необходимости менять настройки ни брандмауэра, ни прокси-сервера, и при этом не страдает функциональность шлюза. Кроме этого, данные, находящиеся в кэше прокси-сервера проверяются только один раз. Проверка выполняется полностью прозрачно для всех прочих программ и тем более для пользователей.
Допускается и обратный вариант подключения, когда сервер антивирусной проверки устанавливается после прокси-сервера. В этом случае антивирус получает данные, уже обработанные прокси-сервером и предназначенные для передачи пользователям, выполняет проверку этих данных и передает данные пользователям самостоятельно.
Рис. 5.2. Установка сервера антивирусной проверки за прокси-сервером (Схема № 2)
По сравнению с предыдущим способом недостатка три:
Можно также установить антивирус непосредственно на прокси-сервер. При этом логически антивирус может находиться как перед, так и за прокси-сервером с точки зрения пользователей сети. С точки зрения порядка обработки данных, такой способ включения будет эквивалентным одному из предыдущих.
Рис. 5.3. Установка антивируса на прокси-сервер (Схема № 3)
Преимуществом такого подхода является отсутствие необходимости в использовании дополнительного сервера для антивирусной проверки. Недостатком - необходимость перенастройки портов либо на ПО прокси-сервера, либо на антивирусе, либо на клиентских компьютерах для того, чтобы данные корректно обрабатывались. Кроме того, использование антивируса и прокси-сервера на одном компьютере создает дополнительную нагрузку на этот компьютер - в некоторых случаях может потребоваться замена сервера на более производительный.
Наконец, если антивирус обладает минимальным функционалом для маршрутизации данных между клиентами внутри сети, как в схеме 2, его можно использовать вместо штатного прокси-сервера. В этом случае данные, которые должны были поступать на прокси-сервер, поступают на сервер антивирусной проверки, проверяются, и им же передаются на клиентские компьютеры.
Рис. 5.4. Замена прокси-сервера на антивирусный сервер с функциями прокси (Схема № 4)
Преимущество такого способа — использование одного сервера. Недостаток — потеря в функциональности шлюза.
Проверка почты SMTP
При проверке данных, передаваемых по протоколу SMTP, в целом, допустимы те же способы подключения, что и при проверке Интернет-потока. За исключением того, что антивирусы для шлюзов если изредка и обладают функциональностью прокси-сервера, то функциональностью доставки почты в ящики пользователей, как правило, не обладают. Этот факт отсекает варианты подключения по схеме 2 и 4.
Если же по каким-то причинам необходимо установить антивирусный сервер перед почтовым (глядя со стороны сети), то применяется следующий прием: почтовые сервера устанавливаются с обеих сторон антивирусного сервера. Таким образом один почтовый сервер принимает почту из Интернет и передает ее на сервер антивирусной проверки. Там почта проверяется и пересылается на второй почтовый сервер, который уже и доставляет ее в ящики пользователей.
Рис. 5.5. Установка сервера антивирусной проверки между почтовыми серверами
Побудительными мотивами для такой организации обработки трафика SMTP может быть тот факт, что почтовые сервера злоумышленники нередко пытаются использовать для несанкционированной рассылки спама. Для защиты от подобных действий разработан ряд технологий, которые не всегда бывают реализованы в антивирусе для шлюзов. Вследствие этого, антивирус для шлюзов априори более уязвим, чем полноценный почтовый сервер, и с точки зрения безопасности правильнее, чтобы именно почтовый сервер был непосредственно доступен из Интернет.
Антивирусы для шлюзов, основанные на интеграции
Рассматривая интеграцию антивирусов с брандмауэрами нельзя абстрагироваться от того, какие это брандмауэры, поскольку возможности интеграции и соответственно часть функционала антивирусного решения будут зависеть от возможностей самого брандмауэра.
Можно априори предположить, что далеко не для всех брандмауэров существуют антивирусные решения. Более того, можно предположить, что такие решения имеются только для наиболее широко используемых брандмауэров. Так оно и есть на самом деле. Из всех антивирусов, интегрирующихся с брандмауэрами, можно выделить два класса программ:
Их имеет смысл рассмотреть отдельно.
Антивирусы для Microsoft ISA Server
В том, что многие производители антивирусов выпускают продукты для Microsoft ISA Server ничего удивительно быть не может. Решения компании Microsoft традиционно являются наиболее широко используемыми на платформе Microsoft.
Как правило, когда речь идет об интеграции, базовое приложение обладает определенными инструментами для взаимодействия со сторонними программами. Так же ситуация обстоит и с Microsoft ISA Server, в котором предусмотрен механизм плагинов, с помощью которых антивирусы и интегрируются в продукт. Такой способ интеграции подразумевает, что антивирусное решение устанавливается на тот же компьютер, что и Microsoft ISA Server. С одной стороны это означает меньшую гибкость решения, с другой - большую простоту в установке и настройке.
Как и универсальные антивирусы для шлюзов, антивирусы для Microsoft ISA Server могут проверять данные, передаваемые по таким протоколам, как:
При этом разные производители отдают предпочтение различным протоколам. Есть решения которые предназначены только для проверки HTTP-трафика. Есть предназначенные для проверки данных по протоколам HTTP и SMTP.
Пример. Антивирус Касперского для Microsoft ISA Server способен проверять данные, поступающие на сервер по протоколам HTTP и FTP. Функций проверки почтового трафика продукт не имеет.
Другим важным аспектом совместного функционирования Microsoft ISA Server и антивируса является зависимость от режима использования Microsoft ISA Server. Как известно, Microsoft ISA Server может быть установлен в одном из трех режимов:
Соответственно в различных режимах интеграция с Microsoft ISA Server происходит по разному и возможности антивирусной проверки также будут разными.
Пример. В Антивирусе Касперского для Microsoft ISA Server реализовано три фильтра для проверки обрабатываемых на шлюзе данных:
Первые два фильтра ориентированы на интеграцию с Microsoft ISA Server в режиме Firewall, веб-фильтр предназначен для проверки данных, передаваемых через Microsoft ISA Server в режиме Cache. Исходя из назначения фильтров, их использование в различных режимах работы Microsoft ISA Server будет следующим:
|
Фильтр / Режим |
Cache |
Firewall |
Integrated |
|
HTTP-фильтр |
- |
+ |
- |
|
FTP- фильтр |
- |
+ |
+ |
|
Веб-фильтр |
+ |
+* |
+ |
* По умолчанию в режиме Firewall веб-фильтр отключен, т. к. считается, что клиенты не используют ISA-сервер в качестве прокси и веб-трафик проверяется HTTP-фильтром. Если же в настройках Интернет-агентов (браузеров) на клиентах в качестве прокси-сервера указан адрес ISA-сервера, веб-фильтр можно включить. При этом желательно отключить использование HTTP-фильтра во избежание двойной проверки.
Отсутствие HTTP-фильтра в режиме Integrated объясняется тем же - нежелательностью двойной проверки.
Антивирусы для CheckPoint Firewall
Большое количество антивирусов для CheckPoint Firewall объясняется с одной стороны тем, что этот брандмауэр является одним из наиболее распространенных, а с другой стороны тем, что компания CheckPoint, осознавая важность антивирусной защиты, пошла навстречу производителям антивирусов и разработала протокол CVP (Content Vectoring Protocol), позволяющий передавать на проверку объекты, проходящие через брандмауэр CheckPoint Firewall в составе Интернет-трафика.
В связи с тем, что для интеграции функций проверки используются не плагины - модули, встраивающиеся в продукт, а протокол передачи данных, антивирус может устанавливаться на любой сервер, а не обязательно на сам брандмауэр. Такой подход позволяет существенно повысить гибкость решения, а также, в некоторых случаях, и производительность.
Как и все рассмотренные ранее виды антивирусов для шлюзов, антивирусы для CheckPoint Firewall могут проверять данные, передаваемые по трем протоколам:
Для проверки каждого из потоков, создается правило на сервере CheckPoint Firewall, в котором указывается тип трафика и адрес сервера выполняющего проверку. При этом, в разных правилах можно указывать разные сервера проверки.
Такой принцип интеграции позволяет построить различные схемы проверки трафика.
В общем случае антивирус устанавливается на отдельный сервер и принимает от брандмауэра Firewall-1 перенаправленные потоки, проверяет их, и возвращает назад на брандмауэр.
Рис. 5.6. Использование параллельно установленного сервера антивирусной проверки
Такой подход позволяет абстрагироваться от используемой на сервере Firewall-1 операционной системы.
Пример. Антивирус Касперского для CheckPoint Firewall устанавливается только на компьютеры под управлением Microsoft Windows NT-подобных ОС, тогда как CheckPoint Firewall-1 может быть установлен также и на ОС Linux и Solaris. Передача данных для проверки на другой сервер позволяет интегрировать антивирусную проверку в CheckPoint Firewall-1, установленный на любой платформе
Если же CheckPoint Firewall-1 установлен на ОС Windows NT/2000, то антивирус можно будет установить на этот же сервер. Принцип интеграции остается тот же - брандмауэр пересылает данные на CVP-порт, используемый антивирусом для приема данных. Разница лишь в том, что поток данных не выходит за пределы сервера, что безусловно повышает нагрузку на сервер, но позволяет обойтись без дополнительных компьютеров.
Рис. 5.7. Установка антивируса на сервер брандмауэра
Если в организации используется несколько брандмауэров CheckPoint Firewall-1 (например, чтобы защитить нескольких независимых каналов доступа в Интернет), для проверки проходящего через них трафика не обязательно использовать такое же количество антивирусных серверов - все брандмауэры могут быть настроены на использование общего сервера антивирусной проверки.
Рис. 5.8. Использование одного антивирусного сервера для проверки потоков от нескольких брандмауэров
Разумеется, при использовании одного антивирусного сервера для проверки трафика, поступающего от нескольких брандмауэров, этому серверу потребуется выделить дополнительные аппаратные ресурсы.
В качестве альтернативы увеличения мощности сервера антивирусной проверки, можно использовать различные сервера для проверки различных типов трафика - HTTP, FTP, SMTP. Для этого достаточно указать на брандмауэре в настройках правил пересылки FTP, HTTP и SMTP данных различные антивирусные сервера.
Рис. 5.9. Использование различных антивирусных серверов для проверки различных потоков
Преимущество такой организации проверки - распределение нагрузки между антивирусными серверами. Недостаток - необходимость в использовании нескольких серверов для антивирусной проверки.
Другие реализации
На рынке антивирусных систем защиты для шлюзов кроме программных систем встречаются также и аппаратные. Впрочем, при ближайшем рассмотрении оказывается, что предлагаемое компанией-производителем аппаратное решение является ничем иным, как программным решением этого же производителя, предустановленным на стандартный сервер.
Преимущество таких систем в том, что они поставляются фактически в конфигурации "под ключ", нуждаясь только в детализации данных о сетевом окружении. Стандартное же программное решение является, по сути, комплектом "сделай сам" и может быть подвержено проблемам совместимости, невыполнения системных требований, некорректной установки.
Требования к любому антивирусному комплексу естественным образом можно разделить на несколько категорий. Антивирус для шлюзов в этом смысле исключением не является.
Пример. Как уже говорилось выше, Антивирус Касперского для CheckPoint Firewall позволяет проверять все указанные потоки данных.
Исходя из основного требования, следует ряд уточнений, касающихся особенностей проверки, обнаружения и блокирования вирусов:
Пример. Антивирус Касперского для Microsoft ISA Server позволяет проверять все указанные типы составных файлов, поддерживая при этом рекордное для индустрии количество форматов, впрочем, как и все остальные антивирусные продукты Лаборатории Касперского, основанные на том же ядре
Пример. Лаборатория Касперского выпускает обновления антивирусных баз каждый час и является мировым лидером по этому показателю
Особенности архитектуры
С самого начала нужно отметить одну особенность реализации большинства (во всяком случае, всех наиболее распространенных) антивирусов для шлюзов - они используют то же антивирусное ядро, что и другие антивирусные продукты тех же производителей. Иными словами - технология проверки на шлюзе ничем не отличается от технологии проверки на рабочей станции или файловом сервере - применяются те же алгоритмы и антивирусные базы.
Это означает, что проверяемыми объектами в антивирусе для шлюзов будут файлы. Сперва эти файлы вычленяются из потока данных, затем они проверяются, и по результатам проверки поток либо пропускается дальше, либо блокируется. Некоторые антивирусы обладают возможностью самостоятельно генерировать поток для того, чтобы заменить поток с зараженным файлом на поток с вылеченным файлом, т. е. такие антивирусы поддерживают лечение.
Преимущества использования универсального (общего для всех продуктов) ядра очевидны. Для производителя это сокращение времени на разработку новых баз и как следствие возможность выпускать их чаще, что повышает скорость реакции на новые угрозы. Для пользователя - возможность сократить трафик обновления и возможность косвенной проверки антивирусного решения: если вирус обнаруживается антивирусом для рабочих станций, он будет обнаруживаться антивирусом для шлюзов, и наоборот.
Впрочем, есть и существенные недостатки. Как известно, не все вирусы распространяются в виде файлов. Ряд очень известных эпидемий был вызван вирусами, которые вообще не существуют в форме файлов: CodeRed и Slammer распространялись (а Slammer и по сей день относится к категории живых, "in the wild", вирусов) путем прямой атаки на переполнение буфера в уязвимых службах, код этих вирусов хранился в специально сформированных пакетах данных. Ко всему прочему эти пакеты не являлись HTTP, FTP или SMTP пакетами, а относились к более низким уровням иерархии протоколов.
Таким образом, против "бестелесных" червей типа Slammer антивирусы для шлюзов бессильны. Аналогично и попытки заражения червями типа Lovesan и Sasser останутся незамеченными многими антивирусами для шлюзов, так как используют прямые атаки на службы Windows и эти атаки идут не по протоколам HTTP, FTP, SMTP. В дальнейшем, правда, для загрузки собственных файлов на атакуемый компьютеров, указанные черви и им подобные используют FTP протокол, который проверяется далеко не всеми антивирусами для шлюзов. Имеющийся архитектурный недостаток не превращается в серьезную проблему только потому, что существование шлюза само по себе ограждает рабочие станции сети от прямых вирусных атак извне - при любой мало-мальски разумной организации шлюза прямой доступ к внутренним станциям из Интернета запрещен.
Есть у "файлоцентричности" проверки и другие недостатки. В частности, чтобы проверить загружаемый пользователем файл, антивирусу потребуется дождаться окончания загрузки файла, выполнить проверку и после этого отдать (или не отдать) файл пользователю. Отдавать файл до окончания проверки, очевидно, нельзя - это полностью нивелирует факт наличия антивируса на шлюзе. Однако проверка (да и ожидание загрузки) файла происходит не мгновенно и из-за этого Интернет-агент пользователя (браузер, менеджер загрузок, почтовый клиент) может выдать ошибку превышения ожидания. Вероятность возникновения такой ошибки весьма велика, что означает заметные неудобства для пользователей при работе с Интернет. Для решения этой проблемы в антивирусах для шлюзов применяют специальные приемы.
Пример. В Антивирусе Касперского для Microsoft ISA Server и в Антивирусе Касперского для CheckPoint Firewall, с целью избежать ошибки превышения времени ожидания на клиентах, применяется технология удержания не файла целиком, а лишь его части. Таким образом, по мере ожидания полной загрузки файла на шлюз, антивирус до определенного момента передает пользователю части этого файла. После чего прекращает передачу, дожидается загрузки окончания файла, и если файл чистый, продолжает передачу, в противном случае - разрывает соединение.
При этом, естественно, существует опасность, что загруженная пользователем часть файла вмещает достаточное количество данных для того, чтобы быть запущенной и выполнить вредоносный код. Например, в удержанной антивирусом части файла могут быть только ресурсы программы, которые не необходимы для запуска и используются на более поздних этапах работы загружаемой программы.
Понятно, что чем большая часть файла будет удержана, тем меньше вероятность того, что вирус будет активирован, и тем большая - того, на клиенте возникнет ошибка превышения времени ожидания. В связи с этим величина удерживаемой части не является жестко заданной и может быть изменена в настройках. Поиск оптимального компромисса между удобством работы и качеством защиты возлагается на администратора антивирусной безопасности.
Второй важный момент, связанный с работой антивирусов для шлюзов, состоит в том, что для проверки файла, он должен быть загружен на шлюз целиком, причем в рамках одного соединения. Ни брандмауэр, ни антивирус для шлюзов не производят анализ [возможно] разнесенных во времени потоков данных на предмет - не содержат ли они разные части одного и того же файла. Таким образом, для того, чтобы вирус в файле был обнаружен, передаваемая в рамках одного соединения часть этого файла должна содержать вирус целиком.
Из указанного требования к условиям обнаружения вируса непосредственно следует, что существует вероятность проникновения вируса на компьютер, если зараженный файл загружается в несколько этапов либо в несколько потоков и при этом вирус не оказался целиком ни в одной из частей файла.
Пример. Зная об описанной уязвимости, в Антивирусе Касперского для CheckPoint Firewall по умолчанию отключена поддержка загрузки файлов по частям. В связи с этим у пользователей могут возникнуть неудобства, т.к. загрузка файлов в несколько потоков и даже просто дозагрузка файла в случае обрыва соединения будут невозможны. Поиск баланса между удобством и безопасностью, как и прежде, является задачей администратора
Некоторые антивирусы для шлюзов и вовсе не поддерживают возможность загрузки файлов по частям, полностью устраняя уязвимость, но гарантированно создавая неудобства.
Других серьезных архитектурных недостатков у антивирусов для шлюзов нет. А из архитектурных особенностей важно отметить тот факт, что для проверки используются только антивирусное ядро и антивирусные базы, что подразумевает применение только сигнатурного и эвристического анализа для поиска вредоносных программ. Метод поведенческого анализа не используется.
Также стоит упомянуть, что по понятным причинам защищенный трафик (HTTPS) антивирусом для шлюзов проверен быть не может. Если бы это было не так, HTTPS-трафик с трудом можно было бы считать защищенным.
Предотвращаемые угрозы
Угрозы, с которыми антивирусы для шлюзов справляются плохо или не справляются вовсе, выяснены. С какими же угрозами антивирусы для шлюзов справляются хорошо?
Во-первых, антивирус для шлюза способен предотвратить загрузку зараженного файла с FTP-севера или веб-сайта. Уже давно не новой является технология распространения червей или троянов, когда пользователь получает сообщение (по почте или по другим каналам), содержащее не сам вредоносный файл, а ссылку на веб-сайт, где этот файл расположен. Антивирус на шлюзе предотвращает загрузку вредоносных файлов, как санкционированную, так и нет.
Пример. При этом есть и ограничения. В частности, если загружается архив, защищенный паролем, антивирус на шлюзе не сможет проверить такой архив. Кроме этого, проверка архивов и вообще составных файлов, как правило, занимает относительно большое время, увеличивая вероятность ошибки превышения времени ожидания на клиенте. Тем не менее, в связи с растущей тенденцией распространения червей в заархивированном виде, отключать проверку архивов на уровне шлюзов не рекомендуется
В контексте архивов есть смысл еще раз вспомнить о проблеме частичного (а не полного) удержания файла на сервере проверки. Если исполняемый модуль, загруженный не полностью, все же редко остается работоспособным, то из неполного архива очень часто можно извлечь часть файлов. В связи с этим, вероятность пропустить вирус в архиве гораздо выше, чем в исполняемом файле.
Нередко в веб-страницы сайтов бывают внедрены опасные скрипты, использующие уязвимости в браузерах для несанкционированной загрузки файлов или для изменения настроек: стартовой страницы, страницы поиска. Эти скрипты также проверяются на антивирусе для шлюзов, и их загрузка на компьютеры пользователей блокируется.
Пример. Как будет рассказано в дальнейшем, Антивирус Касперского для Windows Workstations обладает встроенным модулем, предназначенным для проверки скриптов. И в связи с этим необходимо отметить важный факт. Антивирус для шлюзов (в частности, Антивирус Касперского для Microsoft ISA Server и Антивирус Касперского для CheckPoint Firewall) при проверке скриптов применяет только технологии сигнатурного и эвристического анализа. В отличие от него, модуль проверки скриптов на рабочей станции следит за выполнением скрипта на компьютере пользователя и блокирует потенциально опасные действия, применяя тем самым технологию поведенческого анализа. Таким образом можно говорить, что средства проверки скриптов на уровне шлюза и на уровне рабочей станции не дублируют, а дополняют друг друга.
Используя SMTP-фильтр, Антивирус для шлюзов защищает также от вредоносных программ, распространяющихся через почту. Правда, только в том случае, если в организации используется почтовый сервер, получающий сообщения по протоколу SMTP. Если почта доставляется по другому протоколу или если пользователи обращаются за почтой на сервер за пределами сети организации, письма проверены не будут.
Необходимо отдельно отметить тот факт, что антивирус для шлюзов защищает от вирусов при работе с веб-почтой. В этом случае и сами почтовые сообщения и вложения к ним пользователь получает по протоколу HTTP, что и позволяет шлюзовому антивирусу осуществлять проверку. Примечателен тот факт, что антивирусы для почтовых систем при таком режиме работы с почтовыми сообщениями (веб-почта) неэффективны.
Как и любая программа, помимо профилирующих характеристик, антивирусный комплекс для шлюза должен удовлетворять определенным требованиям к условиям эксплуатации. В частности, в контексте антивирусов, важными являются такие характеристики как:
Управление
Способы управления универсальными антивирусами для шлюзов и теми, которые построены на принципах интеграции, обычно несколько отличаются.
Универсальные антивирусы в силу своей специфики должны обладать полностью самостоятельными средствами управления. При этом локального интерфейса для таких антивирусов недостаточно. Далеко не всегда рабочее место администратора расположено в непосредственной близости от шлюза. Нередко все сервера сосредоточены в отдельном помещении с ограниченным физическим доступом. Поэтому антивирусу для шлюзов необходим также и удаленный интерфейс управления.
Чаще всего для удаленного управления применяется веб-интерфейс. Для этого в составе антивируса имеется встроенный веб-сервер. Иногда используется штатный веб-сервер для операционной системы, на которой установлен антивирус: например, Internet Information Server на Windows NT/2000/2003.
Особо изощренных средств разграничения доступа к веб-интерфейсу в антивирусах этого класса обычно нет. Используется аутентификация при помощи пароля. В качестве идентификатора может выступать IP- адрес, если используется ограничение на IP-адреса, с которых разрешено управление.
Что касается локального интерфейса, то в универсальных антивирусах для шлюзов он, как правило, стандартен для той операционной системы, на которой антивирус установлен. В случае Windows это либо специально разработанный оконный интерфейс, либо оснастка для MMC (Microsoft Management Console) - стандартного интерфейса управления под Windows. В случае Unix-систем, в качестве интерфейса управления выступают конфигурационные файлы и командная строка.
Если же речь идет об антивирусах, интегрирующихся с брандмауэрами, то и средства управления для них обычно выполнены в виде модулей, интегрирующихся в средства управления брандмауэром.
Пример. Антивирус Касперского для Microsoft ISA Server управляется через встраиваемый модуль в программе управления ISA-сервером - ISA Management, которая в свою очередь является оснасткой для MMC. Поскольку ISA Management может использоваться как для локального, так и для удаленного управления, аналогичными свойствами обладает и система управления Антивирусом Касперского для Microsoft ISA Server. Для доступа к системе управления необходимо обладать правами администратора на компьютере с установленным ISA-сервером.
Еще одним подходом к управлению антивирусами для шлюзов является использование централизованной системы управления. Основной задачей такой системы является управление антивирусами, установленными на рабочих станциях и серверах Windows. При этом в рамках унификации управления, через централизованную систему могут управляться и другие антивирусные продукты того же производителя.
Пример. Для удаленного изменения параметров проверки в Антивирусе Касперского для CheckPoint Firewall используется система управления Kaspersky Administration Kit 4.5, тогда как параметры передачи трафика на проверку настраиваются при помощи средств управления брандмауэром.
Отдельного рассмотрения заслуживает управление антивирусами для шлюзов, установленных на нескольких Microsoft ISA Server, объединенных в массив (Array).
Пример. Антивирус Касперского для Microsoft ISA Server сегодня является единственным антивирусом для ISA-серверов, который поддерживает полную интеграцию с массивами ISA-серверов. При этом можно управлять настройками антивирусов, установленных на всех ISA-серверах массива, синхронно, т. е. точно так же, как настройками одного сервера. Альтернативно, можно задать для разных антивирусов разные настройки.
Обновление
Обновление антивируса для шлюзов осуществляется штатными средствами обновления и, как правило, поддерживает следующие источники:
Каких-либо особенностей здесь нет. Средства обновления во всех распространенных антивирусах для шлюзов обеспечивают необходимый минимум функций:
Поскольку антивирусы для шлюзов обычно являются обособленными средствами защиты, вопрос о какой-то специальной системе обновления для них не стоит. Тем не менее, если эти антивирусы включаются в централизованную систему администрирования, они могут использовать и централизованную систему обновления.
Немного особняком стоит вопрос об обновлении нескольких экземпляров антивирусов для Microsoft ISA Server, в случае установки на массив серверов.
Пример. Если Антивирус Касперского для Microsoft ISA Server установлен на массив серверов, то для обновления антивирусов на всех серверах массива можно использовать функцию ретрансляции. Для этого выбирается один из серверов массива, на котором антивирус будет обновляться через Интернет (или из другого источника) и распространять обновления на другие сервера массива. Для распространения обновлений штатно предусмотрен режим использования общей папки Windows
Диагностика
Основным средством диагностики шлюзового антивируса являются журналы работы. Как правило, это обычные текстовые файлы, куда записывается вся информация о происходящих событиях, в частности о проверенных объектах, результатах проверки и выполненных действиях. Журналы позволяют администратору антивирусной безопасности провести анализ событий и, например, выяснить источник и обстоятельства проникновения вируса в сеть, или же причины неполадок другого рода.
Кроме журналов событий, антивирус для шлюза должен иметь возможность уведомить пользователя и администратора о том, что имела место попытка загрузить зараженный объект. Для оповещения пользователей обычно используется подмена загружаемого объекта html-страницей с текстом уведомления. Для уведомления администратора используются сообщения электронной почты.
Наконец, часто есть необходимость выяснить причины низкой производительности антивируса для шлюзов. Для этого удобно использовать счетчики производительности, отображающие в реальном времени:
Реализация подобной функциональности обычно базируется на стандартном средстве мониторинга производительности в Windows NT-подобных системах - Performance Monitor.
Производительность
Для повышения производительности можно использовать различные схемы подключения, о которых речь шла ранее. Кроме этого, в некоторых случаях можно регулировать степень использования системных ресурсов.
Пример. В Антивирусе Касперского для CheckPoint Firewall можно использовать параллельно несколько антивирусных ядер для проверки объектов. Рекомендуется использовать четыре ядра на каждый физический процессор.
Принимая во внимание все вышесказанное, можно сделать вывод о том, что антивирусы для шлюзов не позволяют полностью предотвратить проникновение вирусов через Интернет-каналы. Используя шифрование, архивы с паролем, загрузку файлов по частям, можно создать условия для проникновения вредоносных программ. Следовательно, даже при наличии антивируса на шлюзе, рабочие станции и сервера, находящиеся внутри сети, по-прежнему нуждаются в локально установленном антивирусе.
Тем не менее, антивирусы для шлюзов позволяют существенно сократить поток вирусов из Интернет и снизить нагрузку на локальные антивирусные средства, что является крайне важным фактором при построении комплексной системы антивирусной защиты.
6. Лабораторная работа: Антивирус Касперского для Microsoft ISA Server. Установка, настройка, управление
Цель: ознакомиться с процессом инсталляции, принципами работы и управления Антивирусом Касперского для Microsoft ISA Server 20001).
Программное обеспечение:
На компьютере преподавателя должен быть установлен веб-сервер (например Internet Information Server) и открыта папка с общим доступом Test_virus_ISA с правами на чтение, доступ к тексту сценария, обзор, запуск сценария для всех пользователей локальной сети по протоколам HTTP и FTP.
Содержание работы:
Антивирус Касперского для Microsoft ISA Server 2000 - система антивирусного контроля над файлами, передаваемыми по протоколам HTTP и FTP через брандмауэр Microsoft Internet Security and Acceleration Server.
Антивирус Касперского для MS ISA-серверов выполняет функции фильтра, который перехватывает данные, передаваемые по протоколам HTTP и FTP, выделяет из них контролируемые объекты, анализирует их на наличие вирусов и блокирует проникновение в локальную сеть зараженных файлов и веб-документов.
Приложение обеспечивает выполнение следующих функций:
Антивирус Касперского поддерживает следующие протоколы передачи данных:
Состав приложения
В состав приложения входят следующие компоненты:
Поддерживаемые операционные системы
Антивирус Касперского функционирует совместно с продуктом Microsoft Internet Security and Acceleration Server 2000 с установленным Service Pack 2 или выше на следующих платформах:
Установка
В процессе установки приложения автоматически определяется режим работы ISA-сервера. В руководстве к ISA-серверам описаны три возможных режима работы:
В консоли MS ISA-сервера предусмотрен ряд стандартных фильтров, которые позволяют контролировать входящие потоки данных. Для протоколов HTTP это HTTP Redirector Filter. Протоколы FTP контролируются через FTP Access Filter (не используется в режиме Proxy). Антивирус Касперского для MS ISA-серверов использует настройки по умолчанию указанных фильтров, чтобы получать исходный поток данных для его последующей проверки.
Перед тем как устанавливать Антивирус Касперского для ISA-серверов, убедитесь, что стандартные фильтры HTTP Redirector Filter и FTP Access Filter не отключены или не перенаправляют потоки данных, минуя антивирусную фильтрацию. Это может привести к отключению антивирусной защиты сервера. Управление фильтрами потоков осуществляется через стандартное окно управления ISA Management.
Процедура установки Антивируса Касперского для Microsoft ISA Server на ISA-сервер выполняется стандартно, как для большинства приложений Windows. Можно выбрать как полную, так и выборочную установку продукта, а также восстановить некорректную установку Антивируса Касперского для Microsoft ISA Server.
Программа установки устанавливает Антивирус Касперского для Microsoft ISA Server в соответствии с текущим режимом работы ISA-сервера. Сразу же после установки приложение готово к запуску процесса проверки потоков данных, поскольку необходимые общие параметры уже заданы.
Средство управления - оснастка управления Антивирус Касперского для Microsoft ISA Server встраивается в ISA Management в секцию Extensions.
Добавление тех или иных фильтров зависит от режима ISA - сервера.
В установленном приложении автоматически создается пользователь default, группа пользователей default и политика default, так как наличие хотя бы одной группы пользователей и одной антивирусной политики, назначаемой этой группе, является необходимым условием для функционирования Антивируса Касперского.
Результат установки
Основные файлы Антивируса Касперского для Microsoft ISA Server помещаются в каталог, заданный при установке, по умолчанию - в папку Program Files\Kaspersky Lab\ Kaspersky Anti-Virus for ISA Server на системном диске. В этом каталоге также расположены служебные папки:
Принципы работы
Антивирус Касперского для Microsoft ISA Server производит антивирусную проверку трафика HTTP проходящего через ISA-сервер. Оптимизацию антивирусной проверки НТТР-трафика можно осуществить путем изменения следующих настроек:
Антивирус Касперского для Microsoft ISA Server производит антивирусную проверку трафика FTP проходящего через ISA сервер. Оптимизацию антивирусной проверки FТР можно проводить с помощью изменения настройки Количество данных, полученных сервером до того, как первый пакет с данными отправляется клиенту.
Также существует возможность общей настройки антивирусной проверки путем включения или выключения следующих параметров:
Управление группами клиентов
В каждую группу включены клиенты внутренней сети, к которым могут быть применены одинаковые политики. Каждый клиент может входить в одну или несколько групп.
К клиентам группы default автоматически относятся все клиенты ISA-сервера, не внесенные ни в какую другую группу.
Если клиент входит одновременно в несколько групп, то для него производится антивирусная проверка в соответствии с группой, обладающей наименее строгими условиями проверки.
Внедрение политик антивирусной проверки
Для каждой группы клиентов может быть задана своя политика. В политиках определяются дополнительные параметры фильтрации входящего потока данных, которые позволяют задавать различные правила для разных групп клиентов и, тем самым, могут ускорить процесс антивирусной проверки.
Каждой группе может соответствовать только одна политика. Например, если группе Администраторы назначена политика Администраторы, то ей не могут соответствовать другие политики.
Настройка диагностики работы приложения
Антивирус Касперского для ISA Server позволяет проводить полную диагностику своей работы для любого из MS ISA-серверов, на которых он установлен, и фиксировать ее результаты в следующих файлах журналов:
Для любой из классификаций сообщений можно выбрать уровень детализации:
По умолчанию для всех сообщений установлен минимальный уровень детализации.
Обновление антивирусных баз
Обновление антивирусных баз может выполняться автоматически с заданным периодом обновления или вручную администратором. Возможны два способа получения антивирусных баз:
Управление обновлением антивирусных баз осуществляется на закладке Обновление диалогового окна Свойства Антивируса Касперского для MS ISA-сервера.
Настройка уведомлений пользователей
Если приложение обнаруживает в потоке данных инфицированный файл, который невозможно вылечить, соединение разрывается, и пользователь, запросивший эти данные, получает HTML-страницу с сообщением об обнаружении вируса.
Сообщения формируются только в том случае, если вредоносный объект был обнаружен Web-фильтром Антивируса Касперского или HTTP-фильтром Антивируса Касперского
Можно отредактировать сообщения, направляемые пользователю, на закладке HTTP диалогового окна Свойства Антивируса Касперского для ISA-сервера. Максимальная длина сообщения 10240 байт. Кодовая страница win1251.
Сбор и просмотр статистической информации
Просмотр и управление сбором статистической информации о работе Антивируса Касперского осуществляется через стандартные счетчики производительности Windows, доступные через консоль Производительность (Пуск, Настройка, Панель управления, Администрирование, Системный монитор)
Оценка работы приложения проводится по следующим параметрам:
Чтобы выбрать, какие сведения будут отражаться в статистике, необходимо добавить соответствующие счетчики для объекта HTTP
Уведомление администратора посредством ISA Server Alerts
Встроенные средства ISA Server Alerts позволяют различными способами (запись в системный журнал, уведомление почтовым сообщением и т.д.) информировать администратора о критических событиях, возникающих при работе какого-либо из установленных на ISA-сервере приложений. Для Антивируса Касперского для ISA-сервера также предусмотрен ряд важных событий, возникновение которых требует немедленной реакции администратора системы, например, событие До истечения срока действия лицензии осталось 14 дней. Набор таких событий пополняет существующий список событий ISA-сервера сразу после установки приложения на сервер. Способ доставки уведомления для каждого из событий можно настроить самостоятельно.
Управление лицензионными ключами
Управление лицензионными ключами осуществляется на закладке Лицензирование диалогового окна Свойства Антивируса Касперского для ISA Server. Лицензионный ключ необходим для полнофункциональной работы Антивируса Касперского для ISA Server. Если лицензионный ключ отсутствует или не соответствует данному приложению, Антивирус Касперского для ISA Server не будет работать. По истечении срока действия лицензии, Антивирус Касперского для ISA Server сохраняет свою функциональность за исключением возможности обновления антивирусных баз. Потоки данных по-прежнему подвергаются антивирусной фильтрации.
Антивирус Касперского 5.5 для MS ISA Server 2000. Руководство Администратора.
7. Лекция: Защита почтовых систем
В силу того, что по разным оценкам от 80 до 95 процентов вирусов проникает в корпоративные сети через электронную почту, проверка почтового трафика является одной из важнейших задач обеспечения антивирусной безопасности организации. При этом под почтовым трафиком понимается SMTP-поток. Антивирусные комплексы для защиты почтовых систем не проверяют данные, передаваемые по протоколам IMAP и POP при обращении пользователей к своим персональным внешним по отношению к организации ящикам, поскольку это - задача антивирусного комплекса для защиты рабочих станций. Задачей антивирусного комплекса для почтовой системы является проверка всего потока писем, поступающих и исходящих из почтовой системы организации.
Использование антивирусных комплексов для почтовых систем необходимо для обеспечения безопасности информации, однако возникает вопрос какие комплексы и как должны быть использованы для защиты сетей. Практическое применение, естественно, зависит от схемы построения почтовой системы организации, а также используемых MTA (Mail Transfer Agent).
Выбор средств защиты почтовой системы опирается на выяснение двух ключевых факторов:
Возможно несколько схем работы почтовой системы, оказывающих влияние на построение подсистемы защиты почты. В общем случае организация может использовать либо не использовать средство групповой работы (Microsoft Exchange либо Lotus Notes/Domino), использовать либо не использовать релейный сервер (в Интернет выставляется не основной почтовый сервер организации, а дополнительный сервер, осуществляющий трансляционные функции между Интернет и внутренним почтовым сервером), почта может быть разделена на внешнюю и внутреннюю с различными схемами маршрутизации (выделяется два сервера либо один и тот же сервер обслуживает два различных домена). Дополнительные варианты налагает использование в сети двухсегментной структуры с жестким разделением между сегментами.
Наиболее часто задаваемым вопросом в этом случае является следующий: "Если в сети используется два и более почтовых серверов с выделенным релейным сервером, достаточно ли будет установить антивирусный комплекс на релейный сервер?"
Рассмотрим возможные последствия такого подхода. Действительно, установка антивирусного комплекса на релейный сервер поможет избежать проникновения вирусов во внутреннюю сеть организации. Более того, в большинстве случаев такой вариант поможет предотвратить утечку информации вовне при поражении одного из узлов вирусом, рассылающим свои копии электронной почтой. Крайне важно не выпустить такую рассылку за пределы организации - некоторые вирусы для введения пользователей в заблуждение прикрепляют к зараженному письму документы с зараженного компьютера. Это может привести к утечке конфиденциальной информации.
Вместе с тем, при наличии внутренних почтовых серверов без установленного антивирусного комплекса, поражение аналогичным червем одного из узлов сети приведет к возникновению рассылки в том числе и через внутренние почтовые сервера. Если на внутреннем почтовом сервере не будет установлен антивирусный комплекс, ящики пользователей будут переполнены зараженными письмами, что негативно скажется на функционировании сети. Если по каким-то причинам на некоторых узлах сети временно отключена постоянная проверка файловой системы и почты, эти узлы подвергаются дополнительному риску заражения, что в свою очередь еще сильнее увеличит нагрузку на внутреннюю почтовую систему - работая в автоматическом режиме червь способен рассылать десятки копий в минуту.
Поэтому, установка антивирусного комплекса только на релейный сервер не является достаточной для обеспечения антивирусной безопасности организации. Необходимо организовать проверку почтового потока таким образом, чтобы все сообщения, доставляемые пользователям, проходили как минимум однократную, а в случае доставки сообщений извне - двукратную и даже трехкратную проверку на наличие вирусов. Требование к проверке внешней корреспонденции обусловлено доминированием почтового потока в качестве средства доставки вирусов во внутреннюю сеть. Исходя из этих предпосылок и необходимо определять состав подсистемы защиты почты.
Вторым немаловажным фактором является схема работы самого антивирусного комплекса. Здесь возможны два варианта - антивирусный комплекс интегрируется с почтовой системой либо же встраивается в существующую систему в разрыв. Как правило, используется первый вариант, второй имеет смысл использовать либо если невозможно найти антивирусный комплекс, который интегрировался бы с почтовой системой (такое бывает, например, при использовании почтовой системы собственной разработки), либо при введении дополнительного релейного сервера между шлюзом и внутренним почтовым сервером для проверки всего поступающего из Интернет SMTP-потока.
Наиболее плохим, но тем не менее также используемым вариантом сегодня остается установка антивирусного комплекса для файлового сервера на сервер почтовый. В этом случае некоторые зараженные письма будут обнаружены, однако подобная практика вызывает множество конфликтов в работе обеих систем. Дополнительно необходимо помнить о том, что вложения в письма закодированы при помощи MIME, а также могут быть заархивированы. Сегодня немногие антивирусные комплексы для защиты рабочих станций и файловых серверов предоставляют такой функционал. Это связано с тем, что проверка архивов и закодированных сообщений существенно увеличивает нагрузку на сервер/рабочую станцию.
Требования к антивирусному комплексу для проверки почтового потока можно разделить на несколько категорий:
Примером такого комплекса может выступать сегодня практически любой антивирус для почтовой системы любого производителя, это же касается и других требований из разряда обязательных. Тем не менее, в силу технологических особенностей, проверка всего исходящего через Microsoft Exchange Server почтового потока стала возможной сравнительно недавно и только для одной версии этого продукта. Речь об этом пойдет ниже.
Пример. В Антивирусе Касперского для Unix Mail Server проверяются и тела сообщений, и вложения, при этом количество поддерживаемых форматов архивов и упаковщиков является рекордным.
Не считая приведенного ранее требования по возможности проверки архивов, а также вполне логичного общего пожелания - ловить как можно большее количество вирусов - существует еще одно особенно важное в случае почтового потока требование к производителю антивирусного комплекса.
Пример. Во всех антивирусных комплексах Лаборатории Касперского для проверки почты реализована функция лечения обнаруженных вирусов. Правда, на практике можно вылечить не более 1% обнаруживаемых вредоносных программ.
Помимо обязательных требований к антивирусному комплексу, существуют требования желательные, удовлетворение которых существенно упрощает задачу защиты организации от проникновения вирусов через почтовый поток. Такие требования, естественно, не могут относиться к основному функционалу.
Пример. В Антивирусе Касперского для Unix Mail Server имеется возможность помещать подозрительные, инфицированные и непроверенные объекты на карантин.
Пример. Такой функционал реализован в Антивирусе Касперского для Unix Mail Server. Группы проверки определяются как маски адресов отправителей и получателей. При получении письма, программа последовательно просматривает условия всех групп. При совпадении масок отправителя и получателя, письмо проверяется согласно настройкам группы. Если письмо может быть отнесено к нескольким группам, оно относится к первому встреченному совпадению. Если письмо не удовлетворяет требованиям ни одной из групп - оно проверяется на общих условиях
Пример. Антивирус Касперского для Microsoft Exchange Server позволяет модифицировать уведомления всем трем типам пользователей. Большое количество встроенных макросов позволяет сделать уведомление максимально детализированным.
Пример. Подобный функционал реализован в рамках продукта ScanMail for Microsoft Exchange компании Trend Micro. Вообще же следует отметить, что обнаружение вирусной атаки относится, скорее, в подсистеме защиты рабочих станций и серверов. Впрочем, лишний функционал лишним не бывает.
Далее в этой главе будут рассмотрены антивирусные комплексы для защиты наиболее часто встречающихся внешних и внутренних почтовых систем - Microsoft Exchange и MTA с открытым кодом для Unix - Sendmail и Postfix.
Острая необходимость в антивирусных комплексах, позволяющих проверять почтовые сообщения проходящие через сервер Microsoft Exchange, да и любой другой почтовый сервер, возникла в конце марта 1999 года. Melissa отлично продемонстрировала возможности электронной почты как средства распространения вирусов и определила важность задачи по созданию антивирусных комплексов для проверки почтового потока.
Текущей версией Microsoft Exchange была 5.5, однако попытки создания антивирусных комплексов для Microsoft Exchange проводились и ранее, в бытность версии 5.0.
Как уже говорилось выше, первоначально для проверки почтового потока применялись средства защиты файловых серверов. Понимая неудачность и неполноту таких решений, антивирусные компании продолжили исследования. Их результатом стали первые антивирусные комплексы для защиты Microsoft Exchange - MAPI-сканеры.
MAPI
В MAPI-сканерах для получения доступа к почтовым сообщениям либо документам в папках общего доступа использовался Messaging Application Program Interface (MAPI). При получении уведомления о поступлении нового сообщения в ящик пользователя или нового документа в общую папку программа выполняла MAPI вход в ящик пользователя/папку и осуществляла проверку на наличие вирусов.
Позитивными моментами в сравнении с использованием антивирусных комплексов для защиты файловых серверов являлись:
Однако, имелся и ряд серьезных недостатков:
Тем не менее, несмотря на большое количество ограничений, MAPI-сканеры были существенным шагом вперед, поскольку являлись специализированными средствами для проверки почтовых сообщений.
ESE
Осознавая необходимость коренных улучшений в антивирусных комплексах для Microsoft Exchange, и не получая в этом начинании поддержки от Microsoft, производители антивирусных средств были вынуждены искать другие пути решения проблемы. Таким путем стало использование Extensible Storage Engine (ESE) API. Впервые ESE сканер был разработан компанией Sybari. Изначально, ESE планировался как инструмент для производителей систем резервного копирования и предоставлял доступ ко всем объектам, доставляемым или извлекаемым из Information Store.
Это позволило снять множество ограничений и проблем, связанных с MAPI-сканерами - проблема увеличения нагрузки на сервер была решена за счет того что письмо проверялось, и проверялось единожды, еще до поступления в Information Store. Невозможность проверки исходящих сообщений также была решена в ESE-сканерах - все исходящие из IS почтовые сообщения могут быть проверены. Естественно, за счет иного подхода была решена и проблема с получением пользователем зараженного письма без проверки - непроверенные письма попросту не попадали в IS. Проверка по требованию также производилась при помощи ESE, таким образом оставляя все преимущества, предоставляемые Single Instance Storage.
Основными недостатками ESE сканеров были:
VS API 1.0
Осознав важность антивирусной защиты в обеспечении безопасности информации, Microsoft выпускает Service Pack 3 к Microsoft Exchange 5.5, в который впервые включен специальный API для подключения средств антивирусной проверки - AV API 1.0. Это революционное с точки зрения важности решение, тем не менее, на практике оказалось не столь удобным и хорошим.
AVAPI 1.0 позволял проверять на наличие вирусов вложения, хранящиеся в Information Store, двумя путями. Первый - фоновая проверка, сканер проходит по всем вложениям, хранящимся в IS с целью определить были ли они проверены последней версией антивирусных баз. При обнаружении непроверенного вложения оно направляется на проверку. По достижении последнего вложения проверка считается завершенной.
Вторым способом является проверка при доступе. Когда клиент запрашивает вложение либо пытается поместить вложение в IS, оно помещается в очередь на проверку. Для проверки используется только один поток.
Схема работы AVAPI 1.0 приведена на рисунке 7.1. В сравнении с MAPI AVAPI 1.0 обладает такими преимуществами как возможность заблокировать письмо до его проверки, использование Single Instance Storage, возможностью проверки исходящих сообщений, а также рядом других, менее важных. Вместе с тем, в AVAPI 1.0 были недостатки даже в сравнении с MAPI-подходом, связанные с тем, что API имел отношение только к вложениям:
Оба недостатка были весьма существенными и отсутствовали в MAPI-реализации, поэтому производители антивирусных средств начали выпускать комплексы, в которых оба метода обнаружения (MAPI и AVAPI) можно было использовать одновременно.
Большей популярностью, однако, пользовались ESE-сканеры, лишенные почти всех недостатков обеих технологий. AV API 1.0 использовался и в Microsoft Exchange 2000, однако после выпуска этой версии МТА Microsoft осознал проблемный характер своего API и в Service Pack 1 был включен новый API, VS API 2.0.
увеличить изображение
Рис. 7.1. Схема работы AVAPI 1.0
VS API 2.0
Новая, переименованная версия антивирусного API, содержит существенные улучшения в функционале. Общая схема работы VS API 2.0 приведена на рис. 7.2. В VS API 2.0 также поддерживаются фоновая проверка и проверка при доступе, в дополнение к ним введена упреждающая проверка. Фактически этот термин означает введение приоритезации в очереди на проверку. Если в AVAPI 1.0 вложения проверялись только при доступе к ним пользователя, в VS API 2.0 все поступающие в IS сообщения и вложения ставятся в очередь на проверку, получая при этом низкий приоритет. После того как ядро завершит проверку всех сообщений с высоким приоритетом, оно переходит к проверке сообщений с приоритетом низким. Если клиент обратится к какому-либо низкоприоритетному сообщению, находящемуся в очереди, то приоритет данного сообщения будет автоматически повышен. Очередь с низким приоритетом может содержать до тридцати элементов, обслуживаемых по принципу FIFO.
Изменения коснулись самого механизма проверки - в VS API 2.0 оно стало многопоточным, по умолчанию (и рекомендации Microsoft) количество сканирующих ядер равно 2*n +1, где n - количество процессоров сервера, на котором установлен Microsoft Exchange Server 2000.
Фоновая проверка также претерпела изменения, теперь по завершении проверки сканирующий поток не ожидает перезапуска Information Store, фоновую проверку можно запускать вновь.
API позволяет проверять на наличие вирусов как вложения, так и тела сообщений. Как следствие, также снята проблема с формированием уведомлений адресату и отправителю инфицированных писем, а также с наполнением уведомлений администратору. Помимо этого VS API 2.0 позволяет получать отчеты о работе средств антивирусной защиты.
Вместе с тем, и VS API 2.0 содержит некоторые ограничения. Первое из них - невозможность проверки исходящих сообщений, отправляемых не при помощи MAPI-совместимого почтового клиента, отправляемое сообщение не будет помещено в IS и, следовательно, проверено. Также недостатками являются сравнительно высокая нагрузка при проверке в фоновом режиме и, что важнее, невозможность полностью удалить инфицированное письмо, возможно лишь замещение инфицированного вложения на уведомление об обнаружении вируса.
увеличить изображение
Рис. 7.2. Схема работы VS API 2.0
AV API 1.0 и VS API 2.0 несовместимы, что не добавляет популярности подходу Microsoft к антивирусной защите, однако сам по себе VS API 2.0 обладает практически всем необходимым функционалом. Переход на Microsoft Exchange 2000 и выход VS API 2.0 позволили в большинстве случаев решить задачу защиты почтового потока через этот MTA, поскольку все основные производители средств антивирусной защиты достаточно быстро выпустили версию, поддерживающую новый VS API. Выпуском нового антивирусного API Microsoft нанесла серьезный удар по лидирующим позициям компаний, которые реализовали ESE механизм, поскольку VS API 2.0 лишен недостатков предшественника и предоставляет функционал, не меньший чем в случае использования ESE при существенно более низких трудозатратах на разработку самого продукта. После выпуска VS API 2.0 на первые роли в определении лучшего вновь вышли вторичный функционал продукта, надежность работы и, самое главное, скорость реакции производителя на выпуск новых вирусов.
VS API 2.5
Вместе с выходом Microsoft Exchange Server 2003 вышла и новая версия VS API - 2.5. Как и в предыдущей версии, в VS API 2.5 было реализовано три механизма проверки - при доступе, фоновая и упреждающая.
Вообще, изменений в VS API 2.5 в сравнении с 2.0 было существенно меньше, чем между 2.0 и 1.0, что объясняется в первую очередь удачностью версии 2.0.
Основная проблема - невозможность проверки сообщений, не поступающих в Information Store в версии 2.5 была решена. Это позволило полностью контролировать почтовый поток через Microsoft Exchange Server вне зависимости от выполняемой им функции - даже в случае если Exchange выполняет функцию релейного сервера, все проходящие сообщения могут быть проверены на наличие вирусов. К сожалению, VS API 2.5 может быть использован только в Microsoft Exchange 2003 Server.
Другим улучшением в сравнении с 2.0 стала возможность полного удаления (не замещения) инфицированных вложений либо всего зараженного письма, что позволяет вообще не информировать пользователей о приходе им зараженных писем. Такая возможность может быть особенно востребована в период вирусных эпидемий, когда поток инфицированных писем существенно доминирует даже над спамовыми рассылками.
Заключение
За четыре года средства антивирусной защиты для Microsoft Exchange прошли практически весь эволюционный путь. Улучшения в последующих версиях VS API будут носить все более и более косметический характер, поскольку основная часть функционала уже соответствует общим требованиям к продуктам такого типа. Выпуск Microsoft специализированного API для осуществления вирусной проверки обозначил признание этой компанией важности антивирусной защиты, что еще недавно было нетривиальным вопросом. Выпуск второй версии того же API поставил все компании, производящие антивирусные комплексы в равные условия в том смысле, что разработку продуктов для защиты Microsoft Exchange 2000 и выше все начинали с чистого листа. Использование ESE из доминирующей технологии превратилось в один из вариантов поддержки устаревшей версии продукта и не приносило такого успеха, как вначале.
Сегодня, осуществляя выбор антивирусного комплекса, который будет установлен на сервере Microsoft Exchange следует в первую очередь полагаться на скорость реакции производителя комплекса на появление новых вирусов и на надежность реализации самого комплекса, а также, в меньшей степени, на вторичный функционал. Интеграция с Microsoft Exchange сегодня одинакова для всех производителей.
Если Microsoft Exchange преимущественно используется в качестве внутренней почтовой системы и средства групповой работы, MTA с открытым кодом чаще всего выступают в роли релейного сервера, именно они принимают почту из Интернет, передают ее внутренней почтовой системе и наоборот.
Как правило, такие системы работают на серверах под управлением FreeBSD/Linux. Исторически разработкой антивирусных комплексов, работающих на этих операционных системах занимались только компании постсоветского пространства, Лаборатория Касперского и Доктор Веб. В последнее время, правда, к ним примкнули и некоторые западные разработчики - компании Trend Micro и Symantec также обратили свое внимание на Linux. К FreeBSD и вообще всему BSD-семейству это, правда, не относится.
Антивирусные комплексы для проверки почтового потока, интегрирующиеся с МТА с открытым кодом обычно работают по следующей схеме. Предусмотрено три основных модуля - модуль интеграции с МТА (разный для разных МТА, впрочем, возможна и универсализация), его задача - принять сообщение у почтового сервера и передать на проверку антивирусному модулю. Антивирусный модуль, постоянно пребывающий в оперативной памяти сервера (работающий в daemon-режиме), осуществляет проверку и возвращает модулю-перехватчику в зависимости от результатов проверки и возможностей конкретного продукта, либо вердикт, либо вылеченное вложение. Наконец, третий важный компонент осуществляет обновления антивирусных баз.
Sendmail
История антивирусов для Sendmail началась 29 марта 2000 года - в этот день Лаборатория Касперского анонсировала выход AVP для Sendmail. До этого интегрировать антивирусную проверку почтового потока с этим МТА можно было только с использованием сканеров при доступе, однако такая схема работы так сильно увеличивала нагрузку на почтовый сервер, что практически не применялась. Несколько позже, 28 апреля того же года Лаборатория Касперского, также первой в мире, выпустила продукт для другого МТА с открытым кодом - Qmail.
Говоря о практической реализации средств антивирусной защиты для Sendmail необходимо выделить несколько этапов.
Пионер в этой области - AVP для Sendmail, осуществлял проверку почтовых сообщений в двух режимах - локальном и глобальном. В локальном режиме проверялись письма, поступающие к пользователям почтового сервера. Исходящие письма, либо письма, передаваемые на другой сервер (при осуществлении релейных функций), на наличие вирусов не проверялись.
В локальном режиме проверка осуществлялась за счет подмены локального доставочного агента на почтовом сервере.
Работа в глобальном режиме подразумевала несколько иную схему, основанную на переписывании адресов. Каждому письму, поступившему на сервер, присваивался дополнительный доменный суффикс .avp, все письма, содержащие суффикс переправлялись на антивирусную проверку. После проверки суффикс убирался и письмо пересылалось дальше. Второй подход позволял проверять весь проходящий почтовый поток, однако вызывал и большое количество конфликтов, так как многие администраторы использовали возможность переписывания адресов для создания собственных фильтров.
Касательно функционала, выдвинутого в требованиях к продуктам для проверки почтового потока, Антивирус Касперского с самого начала удовлетворял всем необходимым требованиям, вопрос заключался лишь в изменении способа интеграции с Sendmail и введению некоторых второстепенных функций, таких как возможность лечения (не столь важная функция при проверке почтового потока), генерация списка проверяемых объектов и др.
Начиная с версии 8.11.6 в Sendmail был встроен Milter API, позволяющий передавать почтовые сообщения на проверку внешним фильтрам. Таким образом, необходимость в использовании других механизмов интеграции, как и в случае с VS API для Microsoft Exchange, отпала.
Тем не менее если по некоторым причинам использование Milter API невозможно (например, не удовлетворяет версия Sendmail) или нежелательно, возможна другая схема работы. Почтовое сообщение, поступив на сервер, перекладывается в специальную почтовую очередь, откуда уходит на проверку в антивирусный комплекс. После проверки, оно, в свою очередь, попадает в другую почтовую очередь, откуда и происходит его доставка по назначению. Можно проводить аналогии между схемой с переписыванием адресов и описанной схемой - в обоих случаях использованы нештатные механизмы перенаправления сообщений на проверку антивирусом. Вторая схема, однако, является более надежной, поскольку касается только маршрутизации почты и никак не задевает функционирование MTA.
Лаборатория Касперского сегодня является единственным производителем антивирусных комплексов, предоставляющим решения для проверки почтового потока в МТА Sendmail для обоих вариантов интеграции. Прочие производители ограничиваются поддержкой Milter API.
Postfix
В случае с Postfix отсутствовала первая историческая итерация - сам МТА изначально планировался способным передавать сообщения на проверку внешним фильтрам. Цель: ознакомиться с процессом инсталляции, принципами работы и управления Антивирусом Касперского 5.5 для MS Exchange Server.
Программное обеспечение:
На первом компьютере (почтовом сервере) необходимо создать папку с общим доступом KAV и учетные записи USER и USERADMIN.
Почтовый клиент на первом компьютере (почтовом сервере) должен быть настроен на обработку почты пользователя USERADMIN, на втором компьютере (рабочей станции) - пользователя USER, в обоих случаях будет использован протокол IMAP.
Содержание работы:
Антивирус Касперского для MS Exchange Server предназначен для антивирусной защиты почтовых ящиков и общих папок на Microsoft Exchange Server, а также для антивирусной проверки проходящего почтового трафика.
Исходя из назначения Антивирус Касперского для MS Exchange Server выполняет следующие основные функции:
Состав и принцип работы
Антивирус Касперского для MS Exchange Server состоит из следующих компонентов:
Архитектура Сервера безопасности
Сервер безопасности Антивируса Касперского для MS Exchange Server, состоит из следующих основных подсистем:
Поддерживаемые операционные системы
Антивирус Касперского для MS Exchange Server может быть интегрирован в следующие версии Microsoft Exchange Server:
Консоль управления Антивируса Касперского для Microsoft Exchange Server может быть установлена на следующие операционные системы:
Именно поэтому отсутствовали различия и в способах интеграции - предложенным механизмом воспользовались абсолютно все производители средств антивирусной защиты.
Средства защиты почтовых систем, как и средства защиты шлюзов, несут четко выраженную задачу по проверке определенного информационного потока в сети. Использование таких средств подразумевает важность решаемой задачи по обеспечению антивирусной безопасности. Тем не менее, эта важность не проецируется на требования к функционалу - здесь все достаточно просто и понятно. Учитывая небольшое количество объектов подобного типа в корпоративной сети, а также отсутствие доступа к ним у рядового персонала, нет необходимости в изобретении мощного комплекса средств администрирования и разграничения доступа. Вместе с тем, сбор статистических данных с антивирусных комплексов для защиты почтовых систем необходим для модернизации стратегии защиты компании. Также следует отметить, что несмотря на бытующее мнение о начале заката эры почтовых червей, именно электронная почта сегодня является и в ближайшем будущем будет являться основным средством доставки вредоносных программ в сеть.
8. Лабораторная работа: Антивирус Касперского 5.5 для MS Exchange Server. Установка, настройка, управление
Цель: ознакомиться с процессом инсталляции, принципами работы и управления Антивирусом Касперского 5.5 для MS Exchange Server.
Программное обеспечение:
На первом компьютере (почтовом сервере) необходимо создать папку с общим доступом KAV и учетные записи USER и USERADMIN.
Почтовый клиент на первом компьютере (почтовом сервере) должен быть настроен на обработку почты пользователя USERADMIN, на втором компьютере (рабочей станции) - пользователя USER, в обоих случаях будет использован протокол IMAP.
Содержание работы:
Антивирус Касперского для MS Exchange Server предназначен для антивирусной защиты почтовых ящиков и общих папок на Microsoft Exchange Server, а также для антивирусной проверки проходящего почтового трафика.
Исходя из назначения Антивирус Касперского для MS Exchange Server выполняет следующие основные функции:
Состав и принцип работы
Антивирус Касперского для MS Exchange Server состоит из следующих компонентов:
Архитектура Сервера безопасности
Сервер безопасности Антивируса Касперского для MS Exchange Server, состоит из следующих основных подсистем:
Поддерживаемые операционные системы
Антивирус Касперского для MS Exchange Server может быть интегрирован в следующие версии Microsoft Exchange Server:
Консоль управления Антивируса Касперского для Microsoft Exchange Server может быть установлена на следующие операционные системы:
Установка
Процесс инсталляции Антивируса Касперского для MS Exchange Server аналогичен процессу инсталляции продуктов Лаборатории Касперского для Microsoft Windows. Сразу после запуска дистрибутива запускается мастер установки приложения, с помощью которого производится пошаговая установка Антивируса Касперского для MS Exchange Server. В процессе установки пользователю предлагается: ознакомиться и согласиться с условиями лицензионного соглашения, осуществить выбор типа установки: полная или выборочная, а также установить лицензионный ключ к данному приложению. В случае выбора полной установки (по умолчанию) происходит установка Сервера безопасности и Консоли управления. Выборочная установка используется в случаях, когда необходимо установить только средство управления - Консоль управления.
Завешается работа мастера установки Антивируса Касперского для MS Exchange Server предложением включить антивирусную защиту сервера автоматически сразу после завершения установки, либо сделать это позже вручную - через Консоль управления Антивирусом. По умолчанию в качестве защищаемых хранилищ будут выбраны все сформированные на сервере хранилища. Если в установленном лицензионном ключе указано максимальное количество защищаемых почтовых ящиков меньшее, чем сформировано в хранилищах сервера, перед запуском антивирусной защиты необходимо снять защиту с части хранилищ.
Результаты установки
Основные файлы Антивируса Касперского для Microsoft Exchange Server помещаются в каталог, заданный при установке, по умолчанию - Program Files\Kaspersky Lab\Kaspersky Anti-Virus for Microsoft Exchange Server на системном диске, в этом каталоге также расположены служебные папки:
Принципы работы
Производительность антивирусной защиты
Антивирус Касперского для MS Exchange Server предоставляет возможность регулировать производительность работы приложения в зависимости от объема и характера проходящего через Exchange-сервер почтового трафика и системных характеристик компьютера: объема оперативной памяти, быстродействия, количества процессоров. Настройка параметров производительности может осуществляться как в автоматическом режиме, так и вручную
Фоновая проверка
Антивирус Касперского для MS Exchange Server осуществляет проверку хранящейся на сервере почты и содержимого общих папок. Проверяются все общие папки и защищаемые хранилища (mailbox storages). При этом обрабатываются сообщения, которые не были проверены с использованием текущей версии антивирусных баз. Программа проверяет тело сообщения и присоединенные к нему файлы в соответствии с общими параметрами антивирусной проверки. Если фоновая проверка хранилищ отключена, хранящиеся на сервере сообщения проверяются только при запросе их пользователем непосредственно перед доставкой.
Уровни защиты
В Антивирусе Касперского для Microsoft Exchange Server предусмотрены следующие уровни защиты:
Настройка диагностики работы приложения
Антивирус Касперского для MS Exchange Server позволяет проводить полную диагностику своей работы и регистрировать зафиксированные события в журнале приложений операционной системы Windows и в собственных журналах. Журналы событий Антивируса Касперского для MS Exchange Server ведутся в двух форматах и в зависимости от формата имеют следующую структуру имен:
Если в момент заполнения журнала он недоступен для записи, например, открыт администратором на редактирование, Антивирус Касперского сформирует новый файл с дополнительным постфиксом к его имени.
Объем и полнота информации, выводимой в журналы, зависит от установленных в параметрах приложения уровней диагностики для каждого из модулей программы. Если модуль состоит из нескольких компонентов, уровень диагностики устанавливается для каждого компонента отдельно.
Предусмотрены следующие уровни диагностики:
Обновления антивирусных баз. Источники обновлений
Источником обновлений могут выступать:
Загрузка обновлений происходит либо по расписанию, либо вручную. Настроить параметры доступа к сетевым HTTP/FTP ресурсам можно, нажав на гиперссылке Антивирусные обновления в панели результатов.
По нажатию открывается окно Настройка, в котором предлагается указать режим доступа к FTP ресурсам (пассивный либо активный), тайм-аут соединения (промежуток ожидания ответа на запрос к серверу), а также задать параметры настройки доступа к прокси-серверу.
Если управление работой установленных на компьютерах сети приложений Лаборатории Касперского осуществляется при помощи системы централизованного управления Kaspersky Administration Kit 5.0, то получаемые Сервером администрирования обновления антивирусных баз размещаются в папке общего доступа. В таком случае возможно использовать данную папку в качестве источника обновлений для Антивируса Касперского для MS Exchange Server.
Работа с инфицированными и подозрительными объектами
Во избежание потери важной информации, перед выполнением каких бы то ни было действий с зараженными объектами, будь то попытка лечения или удаление, они помещаются в специальное резервное хранилище, откуда при необходимости могут быть извлечены.
Уведомления
Приложение Антивирус Касперского для MS Exchange Server предоставляет возможность оповещать об обнаруженных при антивирусной проверке зараженных объектах.
Предусмотрено уведомление о событиях следующих типов:
Для каждого типа событий формируется уведомление соответствующего типа.
Контроль вирусной активности
Антивирус Касперского для Microsoft Exchange Server позволяет фиксировать степень вирусной активности в проверяемом почтовом трафике, почтовых ящиках и общих папках Microsoft Exchange Server с помощью счетчиков вирусной активности и уведомлять об этом администратора. Вирусная активность определяется на основании данных антивирусной защиты Microsoft Exchange Server и позволяет фиксировать события следующих типов:
При установке Сервера безопасности в объекте Счетчики вирусных эпидемий создается встроенный Счетчик вирусной эпидемии. Для реализации функции отсылки уведомлений Счетчика вирусных эпидемий устанавливается порог вирусной активности - максимально допустимое количество событий заданного типа (например, Обнаружен зараженный объект) в течение ограниченного временного интервала. Если вирусная активность превышает установленный порог, Сервер безопасности рассылает уведомление о данном событии на заданные почтовые адреса (обычно, на адрес администратора), с целью уведомления администратора о произошедшем событии.
Отчеты об антивирусной проверке
Отчет об антивирусной проверке проходящего почтового трафика, почтовых ящиков и общих папок Microsoft Exchange Server формируется автоматически, в соответствии с расписанием, или по запросу и может быть сохранен по умолчанию в каталоге Program Files\Kaspersky Lab\Kaspersky Anti-Virus for Microsoft Exchange Server\reports, а также отправлен по электронной почте.
При установке Сервера безопасности создается встроенный шаблон отчета. На основании этого шаблона - Отчет об антивирусной проверке - формируется отчет о результатах антивирусной проверки почтового сервера первого числа каждого месяца за прошедшие 30 дней.
Антивирус Касперского 5.5 для MS Exchange Server. Руководство Администратора.
9. Лекция: Защита серверов и рабочих станций
Вопросы терминологии
Третий уровень КСАЗ — это уровень защиты серверов и рабочих станций. Иногда для ясности говорят "файловых серверов и рабочих станций", чтобы не включать в категорию защищаемых объектов, например, почтовые сервера. Такая подмена не вполне оправдана.
Важно понимать, что два предыдущих уровня КСАЗ — уровень защиты шлюзов и уровень защиты почтовых систем - выполняют задачу перехвата вирусов на стадии распространения (проникновения) и никак не участвуют в защите от вредоносных программ на этапе их - программ - активации. Напротив, задача третьего уровня защиты, в первую очередь, - воспрепятствовать активации вируса и выполнения им заложенных функций.
В связи с этим отличаются и принципы, по которым определяется состав защищаемых на третьем уровне узлов. Если на уровнях защиты шлюзов и почтовых систем защищаемые узлы определялись по признаку назначения и выполняемых функций (обработка соответствующего потока информации), то на третьем уровне одним из основных признаком для включения узла в класс защищаемых является существование вредоносных программ, которые могут быть запущены (активированы) на узле.
Соответственно, третий уровень КСАЗ охватывает далеко не только сервера, выполняющие функции файловых хранилищ. К подлежащим защите на этом уровне вполне могут относиться номинальные почтовые сервера или сервера баз данных, если они используют операционную систему семейства Microsoft Windows.
Учитывая, что большинство современных вирусов попадают на компьютеры по сети, для обозначения третьего уровня КСАЗ используют также формулировку: уровень защиты сетевых серверов и рабочих станций. Несмотря на то, что такое определение уже гораздо точнее, оно тоже не является безупречным. Гипотетически можно предположить компьютер, использующий операционную систему серверного класса, предназначенный для обработки классифицированной информации и по этой причине отключенный от сети. Такой компьютер тоже необходимо защищать в рамках третьего уровня КСАЗ, поскольку поступающие через сменные носители непроверенные данные представляют собой угрозу с точки зрения вирусного заражения, а с учетом особой важности обрабатываемой информации, суммарный риск будет слишком большим, чтобы его игнорировать.
Впрочем, описанная гипотетическая ситуация достаточно редко встречается в реальных автоматизированных системах, и для практических целей можно было удовлетвориться формулировкой: третий уровень КСАЗ - это уровень защиты сетевых серверов и рабочих станций. Сетевых в данном случае означает - подключенных к сети.
Структура уровня
Уже глядя на название, можно сделать вывод о некоторой неоднородности третьего уровня КСАЗ с точки зрения используемых средств защиты. Если общность угроз позволяет объединить сетевые сервера и рабочие станции в один уровень, то существенно разные профили использования выражаются в различных требованиях к эксплуатационным характеристикам АПО. Как следствие, достаточно часто для защиты сетевых серверов и рабочих станций используются разные продукты.
Пример. В линейке продуктов Лаборатории Касперского для защиты рабочих станций и серверов Windows предназначены соответственно Антивирус Касперского для Windows Workstations и Антивирус Касперского для Windows File Servers. Аналогично для защиты серверов и станций под управлением Linux предназначены Антивирус Касперского для Linux Workstations и Антивирус Касперского для Linux File Servers. При этом в первом случае разделение более чем принципиально: невозможно установить продукт для защиты рабочих станций Windows на серверную операционную систему и наоборот.
Принимая во внимание вышесказанное, естественным выглядит выделение на третьем уровне КСАЗ двух подсистем:
Однако этими подсистемами уровень не исчерпывается. Сказывается тот факт, что сетевые сервера и рабочие станции - наиболее многочисленный класс узлов в сети: в крупных организациях их количество может составлять несколько сотен, тысяч или даже десятков тысяч узлов. Встречаются и еще более крупные сети. В связи с этим возникает проблема контроля и управления защитой всех этих узлов.
Как показывает практика, ничего лучше для решения указанной проблемы, чем создание отдельной подсистемы управления, пока придумать не удалось. Таким образом третий уровень КСАЗ - уровень защиты сетевых серверов и рабочих станций - в общем случае состоит из трех подсистем:
При этом чаще всего говорят не о подсистеме управления, а о системе управления. Связано это с тем, что на других уровнях КСАЗ подсистем аналогичного назначения нет: либо функции управления входят в состав антивирусных средств (это требование-минимум), либо система управления третьего уровня КСАЗ распространяется также на средства защиты шлюзов и почтовых систем.
Пример. В качестве решения, играющего роль подсистемы управления, в линейке продуктов Лаборатории Касперского выступает Kaspersky Administration Kit. Первоначально эта система охватывала только средства защиты серверов и рабочих станций Windows. В настоящее время в рамках Kaspersky Administration Kit реализовано управление Антивирусом Касперского для Microsoft Exchange Server. В планах развития - охватить единой системой управления все продукты Лаборатории Касперского.
Далее в главе будут отдельно рассмотрены средства защиты рабочих станций, средства защиты серверов и средства управления. Для каждой из подсистем сперва проводится обзор основных угроз, условий эксплуатации и применяемых в связи с этим технологий, после чего формулируются требования к программному обеспечению данного класса.
Классы рабочих станций
Как можно понять из приведенных ранее примеров, подсистема защиты рабочих станций также далеко не всегда оказывается однородной в смысле используемых средств защиты. Причина тому - неоднородность самих рабочих станций с точки зрения используемых операционных систем.
Сегодня рабочими станциями могут быть компьютеры, работающие под управлением таких операционных систем:
В силу существенных архитектурных различий рабочие станции Windows обычно делят на два дополнительных подкласса:
Прямым следствием такого положения дел является наличие различных - зачастую даже по антивирусному функционалу - средств защиты для каждого из классов рабочих станций.
Пример. Среди продуктов Лаборатории Касперского имеется два предназначенных для защиты рабочих станций - Антивирус Касперского для Windows Workstations и Антивирус Касперского для Linux Workstations. Кроме этого, продукт для защиты рабочих станций Windows может поставляться в различных дистрибутивах - для установки на Windows 98/ME и для установки на Windows NT/2000/XP. Между всеми этими продуктами есть функциональные различия.
Как уже говорилось выше, основной причиной введения системы управления на третьем уровне является необходимость управлять большим количеством антивирусных средств. Верно и обратное, когда количество защищаемых узлов невелико, система управления, как правило, не используется.
Поэтому существуют различные версии антивирусных средств защиты рабочих станций - предназначенные для взаимодействия с системой управления и не предназначенные. Первые называют по-разному, но чаще всего - сетевыми или корпоративными версиями, иногда - управляемыми. Для вторых устоялся единый термин - персональные версии.
Пример. Помимо корпоративной версии Антивируса Касперского для Windows Workstations, в линейке продуктов Лаборатории Касперского присутствуют две персональные версии - Антивирус Касперского Personal и Антивирус Касперского Personal Pro. Первый продукт ориентирован на массовую аудиторию и сделан максимально простым в использовании, второй предназначен для опытных пользователей и предоставляет больше возможностей для тонкой настройки. Аналогичные по позиционированию продукты есть у большинства антивирусных производителей.
Продукты для защиты рабочих станций Linux/Unix или MacOS нередко вовсе не имеют сетевых (корпоративных) вариаций. Причина та же - количество таких рабочих станций, как правило, невелико.
В последние годы ситуация начала меняться и сейчас нередко можно встретить институты или правительственные организации, полностью оснащенные рабочими станциями на базе Linux. Тем не менее, во-первых, количество вирусов для этой платформы ничтожно в сравнении с количеством вирусов для Windows, а во-вторых, новые вирусы для Linux появляются также крайне редко. Результатом такого положения вещей является низкая вероятность заражения и отсутствие насущной необходимости в постоянном контроле состояния системы защиты.
Пример. Антивирус Касперского для Linux Workstations не управляется при помощи системы Kaspersky Administration Kit. Такой подход является характерным для индустрии в целом. Тем не менее, с учетом роста популярности Linux-платформы, а также понимая важность унификации подходов, планы развития включают распространение системы Kaspersky Administration Kit на продукты под Linux.
Специфические угрозы и технологии противодействия
Как известно, большинство современных вредоносных программ являются ОС-ориентированными, т. е. могут запускаться только на некоторых типах родственных ОС (как правило, ОС Windows). Более того, способы распространения (проникновения) также во многих случаях являются ОС-ориентированными. По этой причине рассмотренные ранее в совокупности вирусные угрозы в различной степени относятся к разным классам рабочих станций.
Рабочие станции Windows
Большинство угроз, и это неудивительно, ориентированы на ОС семейства Windows. Под управлением ОС этого семейства функционирует львиная доля всех компьютеров в мире, что создает большой простор для деятельности авторов вирусов, на что бы эта деятельность ни была направлена - удовлетворение личных амбиций, приобретение известности, получение прибыли или всего вместе.
Для заражения компьютера под управлением Microsoft Windows применяются практически все способы проникновения и активизации. Используются всевозможные каналы проникновения, уязвимости в системных и прикладных программах, методы социальной инженерии. Соответственно, ПО для защиты рабочих станций Windows должно обладать средствами для противодействия по возможности всем видам угроз.
Файловая система
В конечном итоге, за редкими исключениями, чтобы запуститься, вирусу необходимо сохранить свой код на диске компьютера-жертвы в виде файла — зараженного файла, в случае чистого вируса, либо полностью вредоносной программы, в случаях червей и большинства троянов. Таковы особенности архитектуры ОС Microsoft Windows - поместить вирусный код непосредственно в память компьютера, не затрагивая файловую систему, можно только используя уязвимости в сетевых службах и программах, установленных на компьютере.
Соответственно, основные средства из состава антивирусного комплекса для рабочих станций Windows направлены на предотвращение записи вредоносного кода на диски компьютера, на предотвращение запуска вредоносных программ, а также на проверку хранящихся на дисках (постоянных, сменных, сетевых) файлов - нет ли в них вредоносного кода. Последняя функция нужна для того, чтобы при запуске (или сразу после установки) антивируса удостовериться в отсутствии вирусов на компьютере - функции предотвращения в последствии позволяют сохранить этот status quo.
Как уже отмечалось в классификации антивирусов, средства проверки файловой системы бывают двух видов:
Реализация подобных средств может быть различной. Это могут быть независимые модули, либо различные функции одного и того же модуля. Модуль проверки при доступе, который по понятным причинам должен постоянно находиться в памяти компьютера в зависимости от применяемых технологий может быть выполнен в виде приложения, службы или драйвера файловой системы. Эффективность при этом растет в порядке перечисления.
Пример. В текущей версии Антивируса Касперского перехват файловых операций осуществляет драйвер файловой системы, что позволяет обеспечить максимальную надежность и производительность. Проверка же выполняется антивирусной службой, причем как объектов, перехваченных драйвером, так и объектов указанных пользователем для проверки по требованию/расписанию. Это позволяет минимизировать используемые ресурсы памяти, поскольку все проверки выполняются одним процессом, в памяти хранится только одна копия антивирусной базы.
Кроме того, что на момент установки или запуска антивируса вредоносные программы могут находиться на дисках, они могут находиться также и в памяти компьютера. Соответственно, имеется необходимость в проверке памяти. Особенности архитектуры операционной системы Windows таковы, что отслеживать изменения в памяти на лету попросту невозможно. В связи с этим функции проверки памяти выполняются сканером по требованию.
С точки зрения применяемых технологий обнаружения вирусов, основной упор при проверке объектов памяти и файловой системы делается на сигнатурные методы и эвристический анализ. Это и понятно, ведь таким образом обеспечивается максимальная защита от уже известных вирусов, а также защита от новых, еще не известных. Метод поведенческого анализа и блокирования подозрительных действий применялся в прошлом, но показал себя неэффективным из-за большого числа ложных срабатываний: в большинстве случаев вредоносные программы не выполняют никаких особых команд или действий, не свойственных обычным утилитам или службам. Более того, одна и та же программа в зависимости от условий применения может расцениваться как вредоносная или вполне легальная.
Пример. Входящая в состав Windows XP утилита shutdown.exe может с пользой применяться для выключения компьютера по расписанию. Эта же утилита может использоваться в составе вредоносной программы для принудительной перезагрузки без уведомления пользователя. Например, помещение этой утилиты в автозапуск может надолго воспрепятствовать нормальной работе неискушенного пользователя.
Тем не менее, в некоторых специфических случаях применение поведенческого анализа не только оправдано, но и является более эффективным методом предотвращения запуска новых вирусов, чем эвристический анализ.
Пример. До сих пор во многих версиях BIOS можно встретить опцию защиты от вирусов, которая препятствует записи в критические области дисков - в загрузочные сектора и в сам BIOS. В данном случае ключевым является тот факт, что после непродолжительного периода настройки, необходимости в изменении структуры дисков и перепрошивке BIOS уже нет. В любом случае эти действия являются достаточно редкими и выполнение их без ведома пользователя должно по меньшей мере вызывать подозрения.
Стоит сказать, что современные вирусы крайне редко пытаются записать данные в загрузочные сектора или в BIOS. Эпоха загрузочных вирусов давно прошла. Вследствие этого, антивирусные функции также постепенно исчезают из BIOS.
Если в случае исполняемых файлов, подозрительные операции выделить достаточно сложно в силу очень большого разнообразия этих файлов и решаемых ими задач, то сфера применения макросов в документах Microsoft Office и других офисных пакетов, достаточно ограничена - чаще всего они используются для сокращения времени на выполнение рутинных операций или же для придания дополнительной функциональности документам. В большинстве случаев действие макроса распространяется только на документ, в состав которого он входит, а взаимодействие с другими документами чаще всего ограничивается операциями чтения. Следовательно, активные действия связанные с файловыми операциями или с записью в другие документы, могут вызывать обоснованные подозрения.
Пример. В Антивирусе Касперского для Windows Workstations имеется специальный модуль для защиты от макровирусов, который работает по принципу поведенческого блокиратора. Идея та же, что и в случае с функцией поведенческого анализа в BIOS: макровирусу для успешного размножения или выполнения серьезных деструктивных функций приходится использовать функции работы с внешними файлами, функции работы с макросами и другие функции, нечасто (если не сказать крайне редко) встречающиеся в обычных макросах, применяемых для автоматизации регулярно выполняемых действий. Соответственно, при обнаружении подозрительных макрокоманд Антивирус Касперского имеет возможность заблокировать их выполнение либо полностью прекратить работу макроса.
Нерассмотренным остался метод анализа изменений (контрольных сумм). Здесь необходимо отметить, что для обнаружения вирусов этот метод в современных условиях уже не годится. Даже в системном каталоге Windows количество файлов может достигать нескольких тысяч. При этом обновления ОС и ряда приложений регулярно приводят к изменениям в составе и версиях хранящихся там файлов. Анализ изменений на дисках в целом - задача еще более трудоемкая и плохо автоматизируемая.
Конечно, опытный специалист на основании данных об изменениях в файловой системе мог бы с большой вероятностью определить признаки заражения неизвестным вирусом. Но количество времени, необходимое на такой анализ, делают его с одной стороны невозможным в сколько-нибудь больших сетях, а с другой стороны нерентабельным в сетях небольшого размера или в единичных случаях - из-за стоимости услуг по привлечению высококвалифицированного специалиста.
Пример. В эпоху классических вирусов под Windows и еще раньше в эпоху вирусов под DOS были широко распространены так называемые программы-ревизоры, которые как раз и выполняли расчет и сравнение контрольных сумм файлов на дисках, а также выполняли простейший анализ зафиксированных изменений. Среди продуктов Лаборатории Касперского такой программой был Kaspersky Inspector. Несколько большей известностью пользовался AdInf производства компании "ДиалогНаука". В настоящее время подобные программы исчезли из линеек продуктов всех ведущих производителей.
Тем не менее, даже если анализ контрольных сумм не позволяет определить факт наличия вируса в системе, он позволяет определить факт отсутствия вирусов в файлах, контрольная сумма которых осталась неизменной. Об использовании метода сравнения контрольных сумм в таком качестве будет рассказано при рассмотрении эксплуатационных характеристик антивирусных продуктов.
Почта
Одним из наиболее часто используемых каналов проникновения вредоносных программ по прежнему остается электронная почта. И хотя для предотвращения пересылки зараженных писем имеются специализированные средства антивирусной защиты уровня почтовых систем, существует множество ситуаций, когда такие средства по тем или иным причинам не используются.
Пример. Домашние пользователи и небольшие компании практически никогда не имеют собственного почтового сервера, на который можно было бы установить антивирус для проверки почтовых сообщений. Услуги по доставке почтовых сообщений в таких случаях оказывает провайдер, у которого могут быть не установлены антивирусные средства на почтовых серверах - по причине большого количества подлежащих защите почтовых ящиков и, как следствие, высокой стоимости лицензии.
В связи с этим, антивирус для рабочих станций Windows должен обладать собственными средствами защиты от вирусов, приходящих по почте.
Нужно отметить, что с большинством таких вирусов вполне справляются стандартные средства проверки файловой системы, поскольку находящийся во вложении вирус, даже будучи запущенным пользователем, все равно сначала сохраняется на диск во временный каталог, и только потом загружается в память. В момент сохранения он будет обнаружен и обезврежен средством проверки при доступе.
Для чего же в таком случае нужны и нужны ли вообще дополнительные средства проверки почты? В первую очередь для повышения производительности и надежности. Не секрет, что наибольшее "замедление" работы компьютера связано именно с работой постоянной защиты файловой системы. По этой причине многие пользователи отключают эту защиту вовсе или неоправданно снижают уровень защиты в настройках. Модуль защиты почты серьезного влияния на производительность не оказывает и может работать едва ли не с максимальными настройками, перекрывая один из наиболее опасных, с точки зрения распространения вирусов, потоков.
Пример. В Антивирусе Касперского для Windows Workstations задача постоянной защиты файлов не проверяет архивы - с одной стороны для повышения производительности, а с другой, по описанной выше причине - файлы внутри архивов перед запуском все равно будут распакованы во временный каталог, обнаружены и обезврежены. Аналогичным образом построили защиту и другие производители антивирусных средств. Задача же постоянной защиты почты, напротив, по умолчанию архивы проверяет, а значит, учитывая тенденцию по распространению вредоносных программ в заархивированном виде, именно она обеспечит предотвращение проникновения вируса на компьютер.
В силу того, что задача постоянной защиты файлов не проверяет архивы, только задача постоянной защиты почты может помешать отправке письма с инфицированным вложением, что также немаловажно.
По сути, локальный модуль проверки почтовых сообщений играет роль отсутствующего антивируса на почтовом сервере - он снижает нагрузку на другие модули проверки и уменьшает общую вероятность заражения. Например, некоторые черви используют уязвимости в почтовых клиентах для автоматического запуска зараженного вложения. Если проверка файловой системы по каким-то причинам отключена, получение такого червя означало бы немедленное заражение, не будь в составе антивирусного комплекса модуля проверки почты.
Кроме этого, не следует забывать, что любой вирус, даже находящийся в архиве или почтовой базе, представляет собой потенциальную угрозу. Если вирус уже так или иначе проник на компьютер и ожидает, что пользователь сам его запустит, это рано или поздно может случиться. Полная проверка компьютера проводится, как правило, не так часто: раз в неделю, а то и реже, чтобы можно было быть уверенным в своевременном обнаружении и удалении вируса внутри архива и/или почтовой базы. А значит, есть шанс, что вирус будет запущен пользователем хотя бы по причине небрежности или случайной ошибки. Использование модуля проверки почты позволяет не допустить появления в почтовой базе зараженных объектов и предотвратить возникновение потенциально опасной ситуации.
Есть и еще одна опасность. Как известно, в ответ на то, что антивирусы стали проверять заархивированные вложения, многие вредоносные программы стали распространяться в защищенных паролем архивах, указывая пароль в теле сообщения. В отсутствие модуля проверки почты, такие письма будут беспрепятственно попадать в почтовый ящик с все тем же риском быть запущенными. Но в этом случае даже проверка по требованию может не обнаружить такие вирусы, если не включена или не реализована проверка в архивах, защищенных паролем.
Пример. В Антивирусе Касперского реализован автоматический механизм обнаружения паролей в теле письма, как при проверке почтовых сообщений на лету, так и при проверке почтового ящика по требованию (по расписанию).
С точки зрения технологий, используемых в модулях проверки почты, можно выделить два направления в которых ведутся разработки:
Преимущества первого способа состоят в том, что проверяются все почтовые сообщения, обрабатываемые почтовым клиентом, независимо от используемых протоколов. С другой стороны, обеспечить необходимую интеграцию со всеми возможными почтовыми клиентами - задача практически неразрешимая. Поэтому используется второй способ, когда модуль проверки перехватывает соединения по некоторым почтовым протоколам, вычленяет из потока данных объекты, которые могут быть заражены, и проверяет их.
Каждый из способов имеет свои преимущества и недостатки. Интеграция обычно поддерживается с очень ограниченным числом почтовых клиентов, например, только с клиентом Microsoft Outlook. С другой стороны, способ перехвата соединений также ограничен в числе поддерживаемых протоколов - как правило, это только протоколы SMTP и POP.
Пример. Учитывая ограничения каждого из способов реализации модуля проверки почтовых сообщений, в Антивирусе Касперского для Windows Workstations применяются одновременно оба способа: интеграция с Microsoft Outlook и перехват сообщений, отправляемых по протоколу SMTP и получаемых по протоколу POP v3.
Интернет
Наравне с почтой, и в последнее время особенно часто, для проникновения на компьютер вредоносные программы используют поток данных непосредственно из Интернет. Соответствующие угрозы можно разделить на несколько классов:
С угрозами первых двух типов успешно справляется средство проверки файловой системы при доступе - загруженный файл будет проверен в момент записи на диск. Кроме этого могут использоваться и другие технологии.
Так, большинство менеджеров загрузки обладают возможностью запускать антивирусную проверку всех загружаемых файлов. Для эффективного использования этой возможности антивирус должен поддерживать передачу объектов для проверки и параметров проверки через командную строку.
Пример. В Антивирусе Касперского для Windows Workstations имеется возможность запускать проверку по требованию через интерфейс командной строки, передавая параметры проверки при помощи ключей командной строки. Аналогичная возможность реализована и в других версиях Антивируса Касперского: Personal, Personal Pro, для Windows File Servers.
Для защиты от использования на веб-страницах вредоносных скриптов, инициирующих несанкционированную загрузку и выполнение программ может использоваться специальный компонент проверки скриптов. Как известно, для выполнения скриптов, написанных на языках VBScript и JavaScript в ОС семейства Windows используется специальный компонент - Windows Script Host, допускающий интеграцию внешних фильтров. В некоторых антивирусах реализован отдельный модуль, проверяющий все скрипты, выполняемые посредством Windows Script Host, обеспечивая защиту не только от веб-страниц, но также от содержащих скрипты писем в html-формате и просто от сохраненных на диске скриптов.
Пример. В Антивирусе Касперского для Windows Workstations (равно как и в персональных версиях, и в версии для серверов Windows) имеется аналогичный компонент для проверки скриптов. В нем реализованы две технологии - передача скриптов на проверку антивирусному ядру с использованием антивирусных баз (сигнатурный метод) и метод поведенческого анализа, оценивающий опасность скриптов по выполняемым ими действиям.
Удаленная атака на сетевые службы является более серьезной проблемой, которую стандартными антивирусными средствами решить не удается - постоянный контроль адресного пространства в ОС Windows невозможен. Для защиты от подобных атак в антивирусные средства интегрируется часть функций персональных брандмауэров либо полноценный персональный брандмауэр. Таким образом, антивирус превращается в более сложный и многофункциональный программный продукт, способный отслеживать сетевые соединения и блокировать атаки на переполнение буфера, которые чаще всего и используются для удаленного внедрения и выполнения кода.
Пример. В Антивирусе Касперского Personal реализован частичный функционал персонального брандмауэра - защита от сетевых атак, специально предназначенный для блокирования атак на известные уязвимости в службах ОС Windows. Кроме этого в линейке продуктов Лаборатории Касперского имеется специализированное решения для защиты от сетевых атак - Kaspersky Anti-Hacker и интегрированное решение, объединяющее в себе антивирус, персональный брандмауэр и персональное средство защиты от спама - Kaspersky Internet Security. Все эти средства являются персональными, т.к. Антивирус Касперского для Windows Workstations ориентирован на использование в корпоративных сетях, где прямой доступ из Интернет обычно контролируется межсетевым экраном и/или прокси-сервером.
В целом же защиту от атак на сетевые службы следует обеспечивать не антивирусными средствами, а установкой обновлений, устраняющих уязвимости. В крупных компаниях такой подход должен быть закреплен организационными мерами в рамках комплексного подхода к построению системы антивирусной защиты.
Рабочие станции под управлением других ОС
В отличие от рабочих станций Windows, вредоносных программ, угрожающих заражением непосредственно рабочим станциям под управлением Unix или MacOS крайне мало. В большинстве своем это либо так называемые proof-of-concept (доказательство возможности) вирусы, либо вирусы, использующие весьма специфические уязвимости. Первые не встречаются в "диком виде" и на практике опасности не представляют. Что касается вторых, то они способны поражать только системы с очень специфическим набором свойств (например, с установленным прикладным ПО определенной версии) и, как правило, не угрожают актуальным версиям ОС и соответствующих программ.
В связи с этим антивирусы для таких рабочих станций предназначены не столько для предотвращения заражения, сколько для недопущения распространения вредоносных программ. Зараженный файл, скопированный с Windows-машины на Unix-машину, не может нанести вреда Unix-машине, но остается зараженным и, будучи скопированным назад на Windows-машину (ту же или любую другую), представляет собой опасность.
Следовательно, антивирус для рабочих станций под управлением ОС, отличных от Microsoft Windows, не нуждается в большинстве модулей и технологий, применяемых для защиты рабочих станций Windows. Как правило, оказывается достаточно средства проверки по запросу, для регулярной проверки файловой системы или же для нерегулярной проверки отдельных файлов или папок.
Пример. В линейке антивирусных продуктов Лаборатории Касперского имеется Антивирус Касперского для Linux Workstations, в состав которого входит сканер по требованию, а также утилита обновления и средства управления. У других производителей имеющиеся продукты такого класса обладают близким функционалом.
Если же на Unix-машине имеется ресурс, активно используемый для хранения и передачи файлов пользователями рабочих станций Windows, это означает, что такая Unix-система относится к классу серверных и требует соответствующих назначению средств защиты.
Эксплуатационные требования и соответствующие им решения
Кроме того, что антивирус должен эффективно защищать компьютер от вирусных угроз, он также должен обеспечивать:
Обновление
Задача обновления — обеспечить связь между разработчиками и антивирусным продуктом. Специфика антивирусной защиты такова, что по мере обнаружения и изучения новых видов и типов угроз, антивирус постоянно нуждается в обновлениях, позволяющих ему эффективно противостоять этим угрозам. В основном это касается обновления сигнатур вирусов, но со временем эволюционируют и алгоритмы сигнатурного поиска, и эвристический анализатор, и модули поведенческого анализа.
Сегодня ежедневно появляется несколько десятков, а то и сотен новых вредоносных программ. Практически все они требуют внесения изменений в антивирусные базы, даже те, которые обнаруживаются при помощи эвристического анализа, поскольку обнаружение сигнатурным методом позволяет не только изолировать вирус, но и корректно нейтрализовать его, не рискуя потерять ценные данные. Высокая частота появления новых угроз диктует сравнимую частоту выпуска антивирусных баз. Следовательно, антивирусное средство должно позволять выполнять обновление с необходимой частотой.
Пример. Лаборатория Касперского на сегодняшний день выпускает обновления ежечасно (являясь в этом отношении лидером индустрии). Такой же интервал — 1 час — является минимальным и рекомендованным для выполнения задачи обновления Антивируса Касперского.
Никогда заранее неизвестно, в какой момент может появиться вредоносная программа, которая потребует внесения изменений в алгоритмическую часть антивируса, т. е. в антивирусное ядро. С другой стороны, когда она появляется, необходимо оперативно предоставить механизмы защиты всем пользователям, чтобы локализовать эпидемию - ждать выпуска новой версии нет времени. В связи с этим, механизм обновления должен подразумевать обновление как сигнатур - антивирусной базы, - так и антивирусного ядра.
Пример. В Антивирусе Касперского часть антивирусного ядра (т. е. модули, содержащие алгоритмы поиска вредоносного кода) вынесена в антивирусную базу и обновляется вместе с ней полностью автоматически, не прерывая работы антивируса.
Не стоит забывать и о том, что в модулях антивируса могут быть обнаружены ошибки, требующие устранения. В этом случае могут выпускаться специальные заплаты, устраняющие ошибки. Процесс загрузки заплат бывает автоматизированным или нет. Во втором случае пользователь должен самостоятельно загружать исправления с сайта производителя и устанавливать их. На практике это означает, что многие (если не большинство) пользователи заплату не установят, создавая тем самым предпосылки к возникновению эпидемий, т. к. заплата может устранять в том числе и уязвимости в самом антивирусе, открывающие лазейки для нейтрализации антивирусной защиты вредоносной программой. Следовательно, автоматическая загрузка и установка заплат является предпочтительной.
Пример. Исправления продуктов Лаборатории Касперского для защиты рабочих станций и серверов Windows могут быть загружены и установлены в процессе обычного обновления.
Обновления антивирусных баз и само антивирусное ядро могут быть как зависящими от операционной системы, так и не зависящими. В первом случае антивирусы одного производителя, установленные на разные платформы (Windows, Unix), будут загружать различные обновления. Во втором случае, обновления будут одинаковыми, что позволит сэкономить на объеме загружаемой из Интернет информации - достаточно будет один раз загрузить обновления с сайта производителя и поместить их в общедоступный ресурс внутри сети.
Пример. В Антивирусе Касперского используются одинаковые антивирусные базы для продуктов под Windows и под Unix.
Возможность размещения обновлений на общедоступном ресурсе внутри сети приводит к вопросу о допустимых способах организации этого ресурса. Стандартом де-факто в антивирусной индустрии является поддержка антивирусными средствами обновления из HTTP-, FTP- или локального (сетевого) ресурса.
Пример. Антивирус Касперского для Windows Workstations позволяет обновляться с одного из серверов Лаборатории Касперского либо из указанного HTTP-, FTP- или локального (сетевого) ресурса. Антивирус Касперского для Linux Workstations позволяет обновляться из тех же источников, в том числе и из общих папок Windows, если на рабочей станции Linux настроена поддержка сетей Microsoft (в последних версиях Linux такая поддержка имеется по умолчанию).
Управление
Реализация управления связана с двумя аспектами - структурой инструментов управления и организацией доступа к этим инструментам. К инструментам управления относятся настройки и задачи.
Настройки — это значения параметров, определяющих характер выполнения тех или иных действий
Задачи — это именованные действия, связанные с используемыми в антивирусе средствами и характеризующиеся индивидуальными настройками выполнения
Пример. В Антивирусе Касперского для Windows Workstations существуют следующие типы задач:
Количество создаваемых задач проверки по требованию не ограниченно. В то же время в Антивирусе Касперского для Linux Workstations задачи как инструмент отсутствуют. Есть только настройки выполнения обновления, проверки по требованию
С точки зрения доступа к инструментам управления выделяются следующие средства:
Можно отметить, что для антивирусов под Windows штатным способом управления является локальный - через графический интерфейс. Развитых средств удаленного доступа в ОС Windows нет, а точнее эти средства применяются преимущественно в серверных системах, а в пользовательских версиях Windows эти средства если и есть, то очень ограничены (речь идет об инструменте Remote Desktop).
В антивирусах для Unix-систем, напротив, используется преимущественно удаленный доступ: либо через веб-интерфейс, либо через telnet- или ssh-клиент.
Пример. В Антивирусе Касперского для Windows Workstations имеется графический интерфейс и интерфейс командной строки. Настройки продукта в целом и отдельных задач хранятся в xml-файлах, которые подписаны и не предназначены для непосредственного редактирования. В реестр Windows вынесены лишь некоторые настройки антивирусного ядра, не касающиеся антивирусных функций
В Антивирусе Касперского для Linux Workstations используются конфигурационные файлы, интерфейс командной строки и веб-интерфейс.
Диагностика
Диагностика состояния и результатов функционирования антивируса проявляется в двух плоскостях:
Уведомления бывают двух видов: локальные и сетевые. Локальные могут выражаться в виде информационных окон, всплывающих сообщений в системной панели, в виде изменения статуса антивируса (в той же системной панели или в окне интерфейса). В какой-то мере локальным уведомлением может считаться запись в журнал.
Сетевые уведомления предназначены для уведомления не пользователя, а администратора антивирусной безопасности, отвечающего за защиту сети в целом. Следовательно, сетевые уведомления могут быть реализованы только в сетевой (корпоративной) версии антивируса, в персональной версии сетевые уведомления не имеют смысла.
Наиболее распространенными способами доставки сетевых уведомлений являются электронная почта и служба оповещений Windows (имя службы - Оповещатель (Messenger)). Существуют и другие способы доставки, но они редко бывают реализованы непосредственно в антивирусе, поэтому о них речь пойдет позже при рассмотрении подсистемы диагностики в системе администрирования.
Стоит отметить, что наличие встроенных в корпоративный антивирус для рабочих станций возможностей уведомления по сети обычно характерно для тех производителей, у которых система администрирования не является бесплатной, а поставляется и лицензируется как отдельный продукт. У производителей, предлагающих систему администрирования бесплатно, сам по себе антивирус, как правило, сетевые уведомления отправлять не может.
Пример. Антивирус Касперского Personal и Personal Pro имеют только локальные возможности уведомления. Причем для различных событий используются различные инструменты: при обнаружении вируса на экране может отображаться диалоговое окно с выбором варианта действия, при смене состояния антивируса (устаревание баз, запуск задач и т.п.) отображаются всплывающие подсказки в системной панели и меняется статус антивируса в главном окне интерфейса.
Антивирус Касперского для Windows Workstations обладает теми же возможностями, что и персональные версии. Поскольку Kaspersky Administration Kit является бесплатным и обладает всеми необходимыми средствами для организации сетевых уведомлений, альтернативная реализация этой возможности в антивирусе для рабочих станций отсутствует.
Хотя журналы работы и можно рассматривать как один из вариантов уведомления, все же их функции несколько шире. Если уведомления - действия разовые, не оставляющие после себя никаких следов, то журналы остаются и могут быть проанализированы для выяснения причин заражения, сбоев, неполадок и других инцидентов.
Существуют различные подходы к ведению журналов:
Преимущества есть у обоих подходов, в первом случае упрощается анализ отдельного журнала, но возникает проблема поиска нужного, во втором - сразу понятно, где искать, но сам поиск по журналу может составить проблему.
Кроме этого возможны различия в форматах хранения журналов и, как следствие, способах работы с ними. Если журналы сохраняются в обычном текстовом формате с понятными описаниями событий, их можно анализировать в любом текстовом редакторе. Но нередко журналы хранятся в служебных нечитаемых форматах и для работы с ними нужно использовать встроенные в антивирус средства.
Пример. В Антивирусе Касперского для Windows Workstations отдельный журнал создается для каждой задачи. Формат журналов - служебный и нормальная работа с ними возможна только через интерфейс антивируса.
В Антивирусе Касперского для Linux Workstations журналы создаются для различных действий (фактически, для различных модулей) - журнал проверки, журнал обновлений. Анализировать эти журналы можно в любом текстовом редакторе.
Иногда в дополнение к событиям, в журналы записывается информация о настройках (задачи или антивируса) при которых это событие имело место. Что касается самих событий, то в них обязательно указывается дата и время, тип события, описание и перечисление важных для данного события параметров. Например, при обнаружении вируса должны указываться тип вируса и имя зараженного файла, а также предпринятое действие.
Надежность
Под надежностью понимается несколько аспектов работы антивируса. Во-первых, это способность противодействовать вредоносным программам, пытающимся отключить антивирусную защиту. Во-вторых, это инструменты для защиты от необдуманных или небезопасных действий пользователя. Наконец, в-третьих, это недопущение потери данных по вине антивирусного средства.
Защита от вредоносного кода
Последние годы вредоносные программы не только маскируются и стараются остаться незамеченными, но и активно противостоят антивирусным средствам путем выгрузки из памяти соответствующих модулей, удаления файлов с дисков компьютера, блокирования доступа к серверам обновления.
Среди технологий, призванных противостоять таким действиям вирусов, можно выделить несколько основных:
Защита от действий пользователя
Не только вредоносные программы, но и сами пользователи могут быть причиной частичного или полного отключения антивирусных средств. Имеет место распространенный предрассудок, что антивирусные средства являются основной причиной снижения производительности или появления сбоев в работе компьютера. Исходя из такого мнения, многие пользователи стремятся отключить антивирусную защиту либо отдельные ее функции каждый раз, когда они (пользователи) испытывают неудобства в работе.
С точки зрения администратора антивирусной безопасности подобные действия являются крайне нежелательными, поскольку компрометируют защиту сети в целом (речь не идет о действиях пользователей персональных антивирусов). Чтобы воспрепятствовать вмешательству пользователей в работу антивирусных средств, конечно, должны использоваться административные меры, но помимо них могут применяться и встроенные в антивирусные средства технологии ограничения действий пользователей.
К таковым могут относиться:
Пример. В Антивирусе Касперского для Windows Workstations применяется подход с двумя интерфейсами - интерфейсом пользователя и интерфейсом администратора. Разграничение определяется паролем (Windows 98/Me) либо правами пользователя в системе (Windows NT/2000/XP). В режиме администратора доступны все настройки и действия по отношению к антивирусу, тогда как в режиме пользователя настройки недоступны вовсе, а из действий доступно только выполнение некоторых задач - проверки всего компьютера, проверки сменных дисков, проверки произвольных объектов, обновления антивирусных баз и, возможно, выполнение других разрешенных администратором задач.
Дополнительные средства защиты связаны с применением системы управления и использованием политик, о чем и будет рассказано в соответствующей лекции.
Недопущение потери данных
Выполняя действия по предотвращению заражения и нейтрализации обнаруженных инфицированных объектов, антивирус неизбежно модифицирует файлы пользователя (при лечении или удалении зараженных файлов), что в редких случаях может привести к потере нужной информации. Чтобы этого не происходило, в ряде антивирусов применяется технология резервного копирования.
Пример. В Антивирусе Касперского для Windows Workstations реализован такой механизм, как резервное хранилище. Это специальный каталог, в который по умолчанию помещаются копии всех объектов, модифицируемых антивирусом, т. е. объектов подлежащих лечению или удалению. Объекты хранятся там в зашифрованном виде.
Второй важный аспект - обработка подозрительных объектов. Понятно, что лечение таких объектов невозможно в принципе, а удаление - опасно потерей данных, по причине ложного срабатывания. Разумным решением является изоляция таких объектов до выяснения обстоятельств.
Пример. Для подозрительных объектов в Антивирусе Касперского предусмотрено действие "Помещать на карантин", что на практике означает перемещение их в специальный каталог. В дальнейшем пользователь (администратор) может отправить эти файлы на анализ в Лабораторию Касперского и получить официальный вердикт, а кроме этого предусмотрена задача автоматической проверки карантинного хранилища после обновления антивирусных баз - вирусы, ранее обнаруженные эвристическим анализатором как неизвестные, в новой версии баз могут быть уже известными.
Наконец, стоит учитывать такой момент как конфликты АПО с прочими программами, установленными на компьютере. Если сами модули антивируса обычно перед выпуском новой версии тщательно тестируются и в подавляющем большинстве случаев не допускают подобных конфликтов, то обновления антивирусных баз и ядра выпускаются слишком часто, чтобы их можно было должным образом протестировать. По этой причине изредка возникают проблемы совместимости, которые, впрочем, оперативно устраняются выпуском исправленных обновлений или же просто следующей версией, если обновления выходят часто.
Тем не менее, ожидая исправленной или новой версии обновлений, пользователю необходимо как-то работать, а значит должен быть механизм, позволяющий при необходимости использовать не текущую версию антивирусных баз, а последнюю корректную.
Пример. В Антивирусе Касперского для решения этой проблемы реализован механизм отката обновлений антивирусных баз, который позволяет по желанию вернуться к использованию предыдущей версии баз, если текущая версия вызывает нарекания к работе антивируса.
Производительность
Основная идея повышения производительности состоит в исключении необязательных и/или многократных проверок. Например, при проверке по требованию происходит обращение к объектам файловой системы, что при прочих равных должно вызывать также и проверку при доступе. Однако, вполне понятно, что такая двойная проверка является излишней и поэтому практически во всех антивирусных продуктах объекты, сканируемые модулем проверки по требованию, никаким другими модулями не сканируются.
Если нет смысла проверять один и тот же объект два раза подряд (что очевидно), то возникает вопрос: каков допустимый интервал между двумя последовательными проверками одного и того же объекта? Ответ лежит на поверхности: до тех пор, пока состояние системы с точки зрения проверки этого объекта не изменилось. Важными параметрами в данном случае будут:
Отследить изменения в антивирусе - задача тривиальная. Соответственно стоит вопрос об отслеживании изменений в объектах и хранении данных об условиях предыдущей проверки. Здесь как раз и используется технология расчета и анализа контрольных сумм, которая обеспечивает две характеристики:
Пример. В Антивирусе Касперского для Windows Workstations (и в других версиях Антивируса Касперского под Windows) применяются уникальные технологии iStreams и iChecker. Обе они основываются на вычислении контрольных сумм проверенных объектов и отличаются только в том, где хранятся контрольные суммы.
При использовании технологии iChecker данные об объектах сохраняются в отдельной базе, что позволяет применять данную технологию не только к объектам файловой системы, но и к вложениям почтовых сообщений (вложения, имеющие одинаковую контрольную сумму, имя, размер, дату создания и пр. считаются идентичными).
Если же используется технология iStreams, контрольные суммы сохраняются в дополнительных потоках файловой системы NTFS, что накладывает естественные ограничения на область применения данной технологии.
Кроме автоматической сортировки объектов на те, которые нужно проверять и те, которые проверять смысла нет, для повышения производительности с успехом применяются также методы ручной сортировки.
Первый этап подобной сортировки выполняют эксперты компании-производителя, определяя типы файлов, которые могут быть заражены и которые по этой причине необходимо проверять. Остальные типы файлов считаются потенциально неопасными и проверять их рекомендуется только в особых случаях - при опасениях, что машина может быть заражена неизвестным вирусом, или во время протекания масштабной эпидемии.
Пример. В Антивирусе Касперского пользователю на выбор предлагается три подхода к определению проверяемых объектов:
Последние две опции призваны обеспечить один и тот же описанный выше эффект - проверять только потенциально заражаемые объекты - но отличаются реализацией. В первом случае (по формату) тип объекта определяется исходя из его внутренней структуры. Например, EXE-файл, переименованный в файл с расширением TXT, будет корректно опознан как исполняемый и проверен.
Второй способ ту же задачу решает на основании только расширения, т. е. переименованный EXE-файл проверен не будет. Этот способ быстрее, но не так надежен. Оптимальным компромиссом между надежностью и производительностью, рекомендованным экспертами Лаборатории Касперского, является выбор проверки заражаемых объектов по формату.
Следующим этапом сортировки объектов является реализация в антивирусе инструментов для гибкой настройки перечня проверяемых объектов. Проверяемые (или исключаемые) объекты могут определять по различным признакам. Наиболее часто реализуется исключение объектов по их идентификации в файловой системе компьютера - по принадлежности к определенному диску или каталогу, по маске имени и/или расширения.
Пример. Кроме исключений по идентификации объектов в файловой системе, Антивирус Касперского позволяет исключать объекты по их типу - архивы, почтовые базы, потенциально опасные программы, а также объекты по типу угроз - отдельные типы вирусов (настоятельно не рекомендуется), потенциально опасных программ, утилит двоякого назначения. Отдельно от исключения всех составных объектов можно настроить максимальный размер для таких объектов. Если это размер превышен, проверка не выполняется.
Кроме априорных подходов, когда объекты исключаются еще до начала их проверки, существуют и апостериорные - когда проверка объекта начинает выполняться и в зависимости от характеристик ее протекания принимается решение продолжать проверку (до окончания) или прекратить.
Пример. В Антивирусе Касперского имеется настройка апостериорного типа - прекращать проверку, если она длится более заданного интервала времени. При помощи этого метода можно нейтрализовать логические бомбы - специально сконструированные файлы, проверка которых занимает очень много времени, требуя большого количества ресурсов и препятствуя нормальной работе за компьютером.
Наконец, нередко применяются способы регулировки производительности вообще не зависящие от характеристик проверяемых объектов. Так, во многих антивирусах имеется возможность задать приоритет проверки (в смысле приоритета процесса, выполняющего сканирования). Встречаются и другие подходы.
Пример. Антивирус Касперского для Windows Workstations не использует механизм приоритетов для ограничения занимаемых системных ресурсов, вместо этого используется слежение за реальной долей процессорного времени, которая приходится на задачу сканирования. Если эта доля превышает заданный порог, проверка временно приостанавливается, чтобы выровнять средние показатели.
Регулировка использования системных ресурсов применяется обычно только для проверки по требованию.
Требования к антивирусам для рабочих станций
На основании приведенных выше рассуждений и примеров можно сформулировать основные требования к антивирусам для рабочих станций. Понятно, что эти требования будут отличаться для рабочих станций различных классов.
Требования к антивирусам для рабочих станций Windows
Как и раньше требования будут делиться на несколько категорий:
Требования к антивирусам для рабочих станций Linux/Unix
Категории требований будут теми же, но сами требования будут менее жесткими по описанным ранее причинам:
В целом антивирусная защита серверов не так сильно отличается от защиты рабочих станций, как, например, от защиты шлюзов. Основные угрозы и технологии противодействия им остаются теми же - смещаются только акценты.
Сетевые сервера как и рабочие станции естественным образом делятся на классы, согласно используемым операционным системам:
Принцип деления обусловлен характерными для различных операционных систем вирусными угрозами и, как следствие, различными вариантами в определении основной задачи антивируса.
В случае продуктов для защиты серверов деление на персональные и сетевые продукты отсутствует - все продукты являются сетевыми (корпоративными). У многих производителей вообще нет деления корпоративных продуктов на предназначенные для рабочих станций и файловых серверов - имеется единый продукт.
Специфические угрозы и способы противодействия
Все относящиеся к серверам специфические угрозы связаны не столько с особенностями серверных операционных систем, сколько с применением уязвимого ПО, характерного для серверов.
Сервера Microsoft Windows
Для серверов Windows актуальны все те же угрозы, что и для рабочих станций под Windows NT/2000/XP. Отличия заключаются только в преимущественном способе эксплуатации серверов, что выражается в ряде дополнительных атак, нехарактерных для рабочих станций.
Так, за серверами Windows редко непосредственно работают пользователи, а значит, почтовые клиенты и офисные приложения на серверах, как правило, не используются. Как следствие, требования к защите почты на уровне почтового клиента и дополнительные средства обнаружения макровирусов в случае серверов Windows менее востребованы.
Пример. Антивирус Касперского для Windows File Servers в отличие от Антивируса Касперского для Windows Workstations лишен модуля поведенческого анализа выполняемых макросов при работе с документами Microsoft Office и модуля проверки получаемой и отправляемой почты. Это не значит, что в продукте отсутствует защита от макровирусов и почтовых червей - как уже отмечалось, в конечном счете, все открываемые файлы проверяются модулем постоянной защиты файловой системы - просто специфика эксплуатации серверов не требует дополнительных средств защиты, как это было в случае с рабочими станциями.
С другой стороны на серверах Windows значительно чаще, чем на рабочих станциях могут использоваться такие службы как Microsoft SQL Server и Microsoft IIS. Как и сами операционные системы производства Microsoft (и не только Microsoft), эти службы могут содержать уязвимости, чем в свое время неоднократно пользовались авторы вирусов.
Пример. В 2003 году появился и буквально пронесся по Интернету червь Net-Worm.Win32.Slammer, использовавший уязвимость в Microsoft SQL Server 2000. Slammer не сохранял свои файлы на диск, а выполнялся непосредственно в адресном пространстве приложения SQL Server. После этого в бесконечном цикле червь выполнял атаку на случайные IP-адреса в сети, пытаясь использовать для проникновения ту же уязвимость. В результате активности червя были до такой степени перегружены сервера и каналы связи Интернет, что целые сегменты сети были недоступны. Особенно пострадала от эпидемии Южная Корея. Стоит отметить, что никаких других действий, кроме размножения червь не выполнял.
Пример. Еще раньше, в 2001 году, уязвимость в Microsoft IIS 5.0 была использована для распространения червем Net-Worm.Win32.CodeRed.a. Последствия эпидемии были не столь внушительны, как в случае с червем Slammer, но зато при помощи компьютеров, зараженных CodeRed.a, была произведена небезуспешная попытка DDoS атаки на сайт Белого Дома США (www.whitehouse.gov). CodeRed.a также не сохранял файлы на дисках пораженных серверов.
Особенность обоих червей в том, что модуль проверки файловой системы (хоть по запросу, хоть при доступе) против них бессилен. Эти черви не сохраняют свои копии на диск и вообще никак не проявляют своего присутствия в системе, кроме повышенной сетевой активности. На сегодняшний день основной рекомендацией по защите является своевременная установка патчей на операционную систему и используемое ПО. Другой подход заключается в настройке брандмауэров таким образом, чтобы порты, используемые уязвимыми службами были недоступны извне - разумное требование в случае защиты от Slammer, но неприемлемое для защиты от CodeRed.
Актуальными для серверов Windows остаются и черви, атакующие уже непосредственно уязвимые службы операционной системы, такие как Lovesan, Sasser, Mytob и др. Защита от них должна обеспечиваться комплексными мерами - использованием брандмауэров, установкой заплат, применением проверки при доступе (упомянутые черви при успешной атаке сохраняют свои файлы на жестком диске).
Учитывая характер атак, можно сделать вывод, что основными средствами защиты серверов Windows являются: модуль проверки файлов при доступе, модуль проверки файлов по требованию, модуль проверки скриптов, а основными технологиями - сигнатурный и эвристический анализ (а также поведенческий - в модуле проверки скриптов).
Сервера Novell Netware
Специфических вирусов, способных заражать Novell Netware, нет. Существует, правда, несколько троянов, ворующих права доступа к серверам Novell, но они все равно рассчитаны на выполнение в среде ОС Windows.
Соответственно, антивирус для сервера Novell Netware фактически не предназначен для защиты этого сервера. В чем же тогда его функции? В предотвращении распространения вирусов. Сервера Novell Netware в большинстве своем используются именно как файловые сервера, пользователи Windows-компьютеров могут хранить на таких серверах свои файлы или же запускать программы, расположенные на томах Novell Netware. Чтобы предотвратить проникновение вирусов на общие ресурсы сервера Novell, либо запуск/чтение вирусов с таких ресурсов и нужен антивирус.
Соответственно, основные средства, применяемые в антивирусе для Novell Netware - проверка при доступе и проверка по требованию.
Из специфических технологий, применяемых в антивирусах для Novell Netware необходимо отметить блокирование станций и/или пользователей, записывающих на сервер вредоносные программы.
Сервера Unix
Про сервера Unix можно сказать все то же, что и про сервера Novell Netware. Антивирус для Unix-серверов решает не столько задачу защиты самих серверов от заражения, сколько задачу недопущения распространения вирусов через сервер. Для этого применяются все те же два основных средства:
Пример. Антивирус Касперского для Unix/Linux File Servers включает модуль проверки при доступе, тогда как в Антивирусе Касперского для Linux Workstations такого модуля нет. Связано это с различными функциями рабочих станций и серверов Linux - в сети построенной исключительно (или большей частью) на Linux-станциях опасность заражения вирусами практически отсутствует, и поэтому острой необходимости в модуле, контролирующем все файловые операции, нет. Напротив, если Linux-компьютер активно используется для хранения и передачи файлов (особенно в Windows-сети), то он является, по сути, сервером и требует средств постоянного контроля файлов.
Многие известные черви под Linux используют для распространения уязвимости не в самой операционной системе, а в системном и прикладном ПО - в ftp-сервере wu-ftpd, в веб-сервере Apache. Понятно, что такие приложения используются чаще на серверах, чем на рабочих станция, что является дополнительным аргументом в пользу усиленных мер по защите серверов.
В отличие от серверов Novell, где поддержка сетей Microsoft является встроенной функцией, сервера Unix по умолчанию не приспособлены для передачи файлов по протоколу SMB/CIFS. Для этой цели используется специальный программный пакет - Samba, позволяющий создавать совместимые с Microsoft-сетями общие ресурсы.
Если обмен файлами происходит только по протоколам SMB/CIFS, то очевидно, не имеет смысла контролировать все файловые операции, достаточно проверять только файлы, передающиеся с использованием Samba-сервера.
Пример. В линейке продуктов Лаборатории Касперского есть специальное решение - Антивирус Касперского для Samba Server, предназначенное именно для защиты общих папок, созданных на Unix-серверах при помощи ПО Samba. В составе этого продукта нет модуля, контролирующего файловые операции, вместо него используется фильтр, встраиваемый в Samba и перехватывающий все передаваемые файлы.
Эксплуатационные требования и характеристики
Стабильная работа серверов, как правило, гораздо критичнее для сети в целом, чем функционирование отдельных рабочих станций. На серверах обрабатывается больше информации, они же зачастую являются местами постоянного хранения этой информации, в случае с серверами приложений, услугами сервера пользуется одновременно большое количество человек - все это накладывает повышенные требования к надежности и производительности антивирусного программного обеспечения, устанавливаемого на сервера. Помимо этих характеристик, важными остаются реализация управления, обновления и диагностики.
Управление
Инструменты и принципы управления, применяемые в антивирусах для серверов, в целом не отличаются от применяющихся в антивирусах для рабочих станций. Это и понятно: различия в назначении и в условиях применения не так велики. Тем не менее, определенная разница есть.
Как правило, сервера Windows предполагают автономную работу с минимальным вмешательством администраторов. Все необходимые службы и приложения настраиваются один раз и в дальнейшем работают согласно настройкам. В этой ситуации особой необходимости в наличии специализированного графического интерфейса для антивируса нет, достаточно наличия каких бы то ни было средств настройки - применяться они в любом случае будут нечасто.
Пример. Антивирус Касперского для Windows File Servers не имеет графического интерфейса подобного Антивирусу Касперского для Windows Workstations. Управление антивирусом выполняется либо через интерфейс командной строки, пригодный для запуска задач и проверки по требованию, либо через интерфейс Kaspersky Administration Kit - средства управления, позволяющего выполнять настройку антивируса и задач как локально, так и удаленно.
Что касается управления продуктами для Unix-серверов, здесь тоже нет ничего нового: применяется веб-интерфейс либо управление посредством редактирования конфигурационных файлов и запуска задач из командной строки в telnet- или ssh-сессии.
Продукты под Novell Netware, в том числе и не только антивирусные, как правило, управляются через стандартный инструмент ConsoleOne.
Обновление
Здесь вообще никакой разницы в сравнении с антивирусами для рабочих станций нет.
Диагностика
В антивирусах для файловых серверов, в целом, используются те же средства диагностики, что и в рабочих станциях - уведомления, отчеты. Однако иногда, для тщательной диагностики проблем производительности или других проблем, необходимо в реальном режиме времени сравнивать некоторые показатели работы компьютера, в том числе и показатели работы антивируса. Такого рода диагностика куда чаще бывает нужна на серверах, чем на рабочих станциях, и поэтому соответствующие средства диагностики, если и встречаются, то в антивирусах для защиты серверов.
На практике реализация такого рода диагностики выглядит как добавление в стандартный инструмент Windows - Performance Monitor- дополнительных счетчиков, как и в случае средств для защиты шлюзов или почтовых серверов. Как правило, счетчики включают:
и т. п. статистические данные
Надежность
В отношении надежности АПО для защиты серверов должно обладать теми же характеристиками, что и АПО для защиты рабочих станций:
При этом задействуются все те же технологии.
Тем не менее, повышенные требования к защите серверов должны учитываться при разработке антивирусного ПО для них, и они учитываются в виде улучшенной совместимости с другим распространенным серверным ПО. Следствием такого подхода также косвенно является урезание функционала серверного антивируса в сравнении с антивирусом для рабочих станций - чем меньше модулей содержит антивирус, тем меньше вероятность конфликтов или сбоев.
Пример. В Антивирусе Касперского для Windows File Servers отсутствует модуль защиты почты. Частично это связано с тем, что на серверах редко используются почтовые клиенты - это характерно для рабочих станций. Но кроме этого, модуль защиты почты осуществляет перехват сетевых соединений, что может служить потенциальной причиной конфликтов с другими сетевыми приложениями.
Производительность
Что касается производительности, то и в этом случае антивирусное ПО для серверов использует практически те же технологии, что и АПО для рабочих станций. Но не только.
В отличие от рабочих станций, сервера нередко могут работать на многопроцессорных платформах. С одной стороны этот факт не должен вызывать проблем в работе АПО, т. е. оказывать влияние на тестирование надежности. С другой стороны, антивирус вполне может использовать многопроцессорную архитектуру для повышения скорости проверки объектов.
Пример. В Антивирусе Касперского для Windows File Servers предусмотрена возможность использования параллельно нескольких антивирусных ядер. В связи с этим основная служба антивируса разделена на две составляющие:
Соответственно, количество сканирующих ядер, загружаемых в память компьютера. равно количеству процессоров. При этом процессоры Intel, использующие технологию HyperThreading, считаются эквивалентными паре процессоров.
Требование к антивирусам для серверов
Приведенные рассуждения и примеры позволяют сформулировать требования к антивирусам для серверов. Здесь различия в назначении не так разительны, как в случае рабочих станций и поэтому можно не делить требования в соответствии с классами серверов, а отмечать различия в соответствующих пунктах:
Как уже говорилось, в больших сетях система управления является тем необходимым инструментом, который позволяет контролировать состояние системы защиты серверов и рабочих станций в целом. В штатном режиме такой подход позволяет существенно снизить затраты на обслуживание, в условиях эпидемии - позволяет оперативно корректировать настройки и удаленно командовать работой антивирусов на узлах.
Цели и задачи
Каждым антивирусным средством можно управлять непосредственно: либо локально, либо, как в случае с продуктами под Novell Netware, Linux, Unix - удаленно при частичной помощи штатных средств этих операционных систем. Любые задачи по настройке и выполнению определенных операций могут быть решены таким образом.
Однако в случае, когда похожие настройки необходимо сделать не на двух, трех, пяти или даже десяти узлах, применять независимые средства управления для каждого из узлов становится крайне неэффективно. Если же еще учесть, что большую часть узлов сети составляют компьютеры под управлением ОС Windows, и что ОС этого семейства не обладают развитыми средствами удаленного управления, позволяющими изменять настройки программ, не мешая работе пользователей, то к необходимости независимой настройки прибавляется необходимость непосредственного присутствия администратора антивирусной безопасности для выполнения этих действий. В конечном итоге, управление сколько-нибудь большим числом защищенных узлов становится задачей крайне трудоемкой и малоэффективной.
Кроме того, если в сети случается инцидент, связанный с антивирусной безопасностью, штатные средства управления антивирусным средством либо оповещают об этом локального пользователя либо просто записывают информацию в отчет. В такой ситуации между моментом, когда произошел инцидент, и моментом, когда об этом стало известно администратору, может пройти значительное время - несколько часов или даже дней. В ситуации повышенной вероятности возникновения эпидемии такие задержки недопустимы.
Замечание. Имеющиеся в ряде антивирусов средства сетевого оповещения призваны заменить полноценную систему управления, которая в случае этих антивирусов является независимым продуктом, который лицензируется и приобретается отдельно от антивирусов.
При возникновении внештатной ситуации как никогда важной становится возможность оперативно получать информацию о состоянии защиты на всех защищаемых узлах и своевременно вносить коррективы в настройки, а также при необходимости обновлять антивирусные базы и проводить внеплановую проверку компьютеров. Если для выполнения этих действий администратору потребуется произвести полный обход территории сети, он полностью потеряет контроль за происходящим.
Таким образом, вырисовывается необходимость в дополнительном инструменте, который позволил бы решать следующие задачи:
Фактически, необходим инструмент, который позволял бы удаленно и централизовано решать задачи управления, обновления и диагностики системы антивирусной защиты. Такой инструмент принято называть системой управления или системой администрирования. Помимо упомянутых задач система администрирования обычно включает также функции, связанные с разворачиванием системы антивирусной защиты в сети - функции удаленной установки и деинсталляции антивирусных средств.
Пример. В линейке продуктов Лаборатории Касперского роль системы администрирования исполняет Kaspersky Administration Kit. Аналогичные по назначению системы имеются у большинства производителей антивирусного программного обеспечения.
Структура системы администрирования
Легко видеть, что задачи, решаемые системой администрирования, достаточно разнородны и не обязательно связаны между собой. По этой причине и система администрирования может быть легко представлена в виде совокупности нескольких подсистем, соответствующих задачам:
На практике эти подсистемы могут и не составлять единый продукт. Практически любая из подсистем может представлять собой отдельное решение.
Пример. В версии 4.5 Kaspersky Administration Kit удаленная установка была отделена от всех остальных функций системы управления и представляла собой отдельный инструмент, выполненный в виде независимого программного модуля, который, впрочем, считался частью Kaspersky Administration Kit.
В ряде антивирусов (например, Sophos) система обновления может строиться практически независимо от системы администрирования.
Также нередко (CA, eTrust, McAfee) для расширения функций системы диагностики (в первую очередь, системы уведомлений) используется отдельное решение.
Все же наиболее удачным выглядит решение, объединяющее в себе все необходимые подсистемы. Таким решением является Kaspersky Administration Kit. Аналогичной универсальностью характеризуются продукты для управления от Symantec, McAfee и Trend Micro.
Основные требования к системе администрирования
В данном случае требования можно сформулировать еще до обзора условий эксплуатации и применяемых технологий, поскольку в принципе требования к системе администрирования являются обобщением требований к управлению, обновлению и диагностике отдельных антивирусных комплексов:
Подсистема управления
Для того, чтобы эффективно осуществлять удаленное управление даже отдельными узлами, оснащенными антивирусным ПО, необходимо где-то хранить параметры доступа к этим узлам - адреса, идентификаторы и т.п. Т.е. вопрос о централизованном характере системы управления возникает буквально сразу же. Как показывает практика, именно централизованный вариант является наиболее удобным и эффективным, поскольку все системы управления построены по одному и тому описанному ниже принципу.
Система управления строится на базе трех компонентов:
Функции компонентов распределены следующим образом:
Защищенный узел сети с установленным агентом принято называть клиентом или клиентским компьютером того сервера управления, к которому подключен агент.
Пример. В Kaspersky Administration Kit структура решения полностью совпадает с описанной, имеются:
В других системах управления, встречаются варианты, когда сервер и консоль управления объединены в общий модуль, или же когда агент является составной частью антивируса, неотделимой от него
Совокупность всех агентов, подключенных к серверу управления приятно называть логической сетью или антивирусной сетью. Понятно, что в одной сети может существовать несколько логических сетей. Также понятно, что один и тот же узел может входить только в одну логическую сеть: если допустить обратное - получится полная неразбериха с правами и порядком удаленного управления антивирусами на узлах. Принимая во внимание возможность наличия нескольких логических сетей, возникает проблема их взаимодействия - подробнее об этом речь пойдет ниже.
Как только возникает вопрос об изменении настроек или о запуске задач одновременно на группе компьютеров, возникает и вопрос о структуре и взаимосвязи этих групп. Сегодня можно встретить два подхода к реализации работы с группами:
Первый подход обладает большей гибкостью, при желании можно назначить задачу произвольному набору компьютеров, в зависимости от того, как складывается ситуация. Однако этот подход не позволяет эффективно отслеживать состояние настроек антивирусной защиты на узлах. Действительно, в какой-то момент времени настройки узла могут быть изменены вместе с одной группой компьютеров, в другой момент - уже с другой группой, в третий момент - индивидуально. В результате априори узнать, какие настройки используются на конкретном узле не представляется возможным, что приводит к ненужной неразберихе и потере контроля над состоянием защиты.
При втором подходе гибкость, очевидно меньше, зато появляется возможность задавать постоянные настройки для групп компьютеров и контролировать сохранение этих настроек в неизменном виде. С таким подходом уже гораздо проще отслеживать уровень защиты.
Пример. В Kaspersky Administration Kit используются постоянные группы компьютеров, которые могут создаваться как полностью вручную, так и автоматически на основании структуры Windows-сети - доменов и рабочих групп. Каждый из узлов может входить только в одну группу.
Таким образом, складывается структура элементов управления:
Для чего вообще имеет смысл объединять компьютеры в группы? По сути, цели две:
Достижение первой цели возможно в любой структуре групп: как первого, так и второго типа. Действительно, нет никакого противоречия в том, что узел входит в две группы и на нем выполняются задачи, сформированные для каждой из групп. Вторая цель достижима только в структуре с постоянными группами, составы которых не пересекаются. Это тоже вполне понятно, если для группы заданы настройки, которые должны быть справедливы для всех узлов этой группы, то для узла входящего в две группы одновременно возникает противоречие: неясно, настройки какой группы на нем будут использоваться.
Пример. Создание задач в Kaspersky Administration Kit не ограничено структурой групп. Задачи могут быть групповыми, т. е. относящимися к конкретной группе, так и глобальными, что в данном случае означает возможность сопоставления задачи произвольному объединению узлов, не являющихся группой и даже относящихся к различным группам.
Как правило, настройки заданные на уровне группы называются политикой. Отличия в этих терминах можно кратко сформулировать следующим образом: настройки - это "как есть", а политика - "как должно быть". В силу императивного характера политик, они предполагают наличие неких механизмов контроля. Практикуется два подхода:
Понятно, что такая категоричность не всегда удобна - легко представить себе ситуацию, при которой некоторые настройки должны быть зафиксированы жестко, а некоторые могут быть изменены локальными пользователями без особого ущерба качеству защиты. Большинство систем управления позволяют выборочно отмечать обязательные и необязательные параметры политики.
Пример. В Kaspersky Administration Kit используется смешанный подход. В первую очередь имеются политики, отдельные настройки которых могут быть отмечены как обязательные или необязательные. Эти настройки охватывают все аспекты работы антивирусных средств. Изменение обязательных параметров на локальных компьютерах полностью заблокировано. Но также выделяются и рекомендуемые настройки защиты, при отклонении от которых формируется уведомление администратору антивирусной безопасности. Такая реализация позволяет использовать преимущества обоих подходов.
Помимо этого, в Kaspersky Administration Kit реализована гибкая система применения политик, основанная на том, что настройки и политики четко разделяются даже на уровне локальных компьютеров и хранятся независимо. Применение политики может происходить одним из трех способов на выбор администратора:
Нередко в составе группы естественным образом выделяется подгруппа клиентов, для которых требуется незначительно изменить политику или создать отдельную групповую задачу. В этом случае было бы удобно выделить подгруппу в отдельную группу, являющуюся элементом исходной группы, чтобы в ней продолжали действовать групповые задачи и политики исходной группы. Многие системы управления поддерживают такую возможность. В этом случае логическая сеть будет представлять собой иерархическую структуру групп. Тут же возникает вопрос о применении задач и политик в такой системе. Возможны разные походы.
Пример. В Kaspersky Administration Kit групповая задача относится ко всем элементам группы - клиентам и подгруппам. Политика точно так же относится ко всем элементам группы, если только на уровне одной из подгрупп она не переопределена, т. е. не задана другая политика. При этом обязательные параметры групповой политики на уровне подгрупп переопределены быть не могут и остаются обязательными в создаваемых политиках подгрупп.
Структура групп, настройки групповых задач и политик, а также нередко и данные диагностики - вся эта информация должна так или иначе храниться на сервере и быть доступной для анализа и обработки. Как правило, для этих целей используется внешний сервер баз данных, по сути - четвертый компонент системы управления. Чаще всего в системах управления применятся бесплатная модификация Microsoft SQL Server 2000 - Microsoft SQL Server Desktop Engine 2000 или коротко MSDE 2000
Пример. В Kaspersky Administration Kit также используется внешний сервер баз данных и именно MSDE 2000. Это ПО входит в поставку Kaspersky Administration Kit и включает в себя встроенный Service Pack 3, устраняющий уязвимость, используемую для распространения червем Slammer
Поддерживается в Kaspersky Administration Kit и работа с полноценным Microsoft SQL Server 2000
Кроме вопроса удобства, который выражается в механизмах групп, групповых задач и политик, существует также вопрос производительности системы управления. Например, если в организации имеется несколько филиалов, каналы связи между которыми весьма ограничены, одновременное применение политики может вызвать перегрузку канала связи с филиалом.
Чтобы избежать этой ситуации используются следующие методы:
Механизм иерархии серверов управления заключается в том, что одни сервера управления могут подключаться к другим. Соответственно подключаемый сервер будет подчиненным, а тот, к которому производится подключение - главным. При этом степень взаимодействия между главными и подчиненными серверами может быть разной.
Один из вариантов взаимодействия - подчиненные сервера согласно заданному расписанию передают на главный сервер данные диагностики, таким образом, чтобы на главном сервере имелась полная информация о состоянии защиты в сети. Недостатки данного подхода очевидны - настройку групп, групповых задач и политик придется выполнять независимо на каждом сервере, нет возможности создания задач для всех клиентов сети.
Второй вариант - группы управления привязываются к серверам управления, все управление происходит прозрачно, т.е. подчиненные сервера управления выполняют сугубо вспомогательную передаточную функцию, все действия по части управления выполняются на главном сервере управления. Недостатки - необходимость создавать отдельный сервер для каждой группы, низкая функциональность подчиненных серверов.
Применяются и другие, достаточно сложные для описания схемы реализации.
Пример. Иерархия Серверов администрирования реализована и в Kaspersky Administration Kit. Подчиненные Сервера входят в качестве элементов в состав групп главного Сервера, причем входят вместе со всей своей логической подсетью. Следовательно, к ним применяются групповые задачи и политики и такие задачи и политики называются унаследованными. Количество подчиненных Серверов, входящих в одну группу не ограничено
Принцип применения тот же, что и в иерархии групп - унаследованные задачи применяются ко всем клиентам подчиненного Сервера, унаследованные политики действуют также на всех клиентах, если только не переопределены на уровне групп или подгрупп подчиненного Сервера. Обязательные параметры по-прежнему переопределять нельзя и они остаются обязательными в создаваемых политиках.
Подчиненные Сервера остаются полноценными Серверами администрирования и позволяют выполнять все те же функции, что и главные Сервера. Единственное ограничение - переопределение политик, о котором говорилось выше. Структура групп, настройки задачи и политик, база событий хранятся независимо на всех Серверах администрирования. Передача данных о событиях происходит только по запросу в момент сбора информации для формирования отчета.
Доступ к подчиненным Серверам возможен как напрямую, так и через интерфейс главного Сервера администрирования.
Еще одним фактором иерархии серверов является ее глубина. Чаще всего можно встретить двухуровневую иерархию, где есть ровно один главный сервер управления, к которому подключены все остальные сервера управления. Однако есть реализации допускающие произвольную глубину иерархии.
Пример. Kaspersky Administration Kit позволяет создавать иерархию Серверов администрирования любой глубины. В этом случае один и тот же Сервер администрирования может выступать в роли подчиненного и в роли главного. Каждый Сервер администрирования может иметь только один главный Сервер и сколько угодно подчиненных.
Немаловажным аспектом системы управления является организация доступа к ее функциям. Реализация разграничения доступа может быть самой разной. Можно выделить следующие характерные схемы:
Пример. В Kaspersky Administration Kit используется третья схема реализации. Выделяется две группы пользователей - администраторы и операторы логической сети, первые имеют неограниченные права, вторые могут только просматривать настройки и создавать отчеты
Для идентификации, аутентификации и разграничения доступа используются средства Windows. Права администраторов логической сети получают пользователи с правами локальных администраторов компьютера, на котором установлен Сервер администрирования, и пользователи, входящие в локальную группу KLAdmins, права операторов логической сети получают пользователи, входящие в локальную группу KLOperators. Все прочие пользователи прав доступа к Серверу администрирования не получают
Подсистема обновления
Необходимость подсистемы обновления, общей для всей системы защиты (во всяком случае, для третьего уровня - защиты серверов и рабочих станций), на первый взгляд не так очевидна. Действительно, при наличии на всех узлах функций обновления и при наличии централизованной системы управления не составляет труда регулярно запускать задачи обновления на клиентах и контролировать состояние антивирусных баз.
Однако, следует учитывать, что при выполнении задачи обновления передается большее количество данных, чем при распространении настроек или при выполнении других задач управления. Следовательно, основная проблема обновления в больших сетях - проблема загрузки сети. У многих производителей антивирусного ПО регулярные обновления антивирусных баз могут составлять несколько сотен килобайт или даже несколько мегабайт. Если представить, что все клиенты одновременно обратятся к внешнему источнику обновления - серверу обновлений производителя - канал доступа в Интернет будет перегружен. Более того, при таком размере обновлений могут быть перегружены даже каналы локальной сети.
Пример. Пусть размер регулярных обновлений составляет в среднем 1 Мб, и пусть в сети имеется 1000 клиентов, которые требуется обновить. Следовательно, в процессе обновления через канал доступа к Интернет должно быть передано 1000 Мб информации. Если предположить, что канал доступа имеет пропускную способность 2 Мбит/с можно вычислить, что на обновление всей сети потребуется
т. е. больше одного часа.
На практике это будет означать одно из двух: либо значительная часть станций просто не получит доступа к источнику обновлений из-за перегрузки сети и не будет обновлена, либо доступ к сети Интернет другим программам и службам во время выполнения обновления будет затруднен.
Такая же проблема с загрузкой сети будет возникать и в ситуации, когда организация имеет несколько филиалов, пропускная способность линий связи между которыми ограничена.
Путей решения у этой проблемы фактически два:
Таким образом, система обновления - это набор средств и способов организации и контроля промежуточных источников обновления.
В общем случае система обновления может иметь такие типы структур:
Использование той или иной схемы диктуется размером и структурой сети организации. Так в небольших офисах вполне допустимо использование децентрализованной схемы. В сетях среднего размера, до нескольких сотен компьютеров, сосредоточенных в одной локальной сети удобно использовать централизованную схему. В крупных территориально распределенных сетях применяются иерархические или смешанные схемы, в зависимости от наличия каналов доступа к сети Интернет.
В рассмотренных схемах обновления не конкретизирована структура источников. На практике встречаются следующие их типы:
Разница между этими типами источников заключается в том, насколько легко они могут быть автоматизированы и насколько они поддаются контролю через систему управления.
Так, для обновления внутреннего FTP- или HTTP-сервера, администраторам потребуется использовать дополнительные средства для автоматической загрузки обновлений и размещения их на серверах. То же касается и общей папки сети Microsoft.
В случае с источником на базе клиента вопрос с автоматической загрузкой отпадает, однако дальнейший контроль источника обновлений в этом случае обычно отсутствует.
Пример. В Антивирусе Касперского для Windows Workstations (и для Windows File Servers) имеется опция загружать копию источника обновлений антивирусных баз в отдельный каталог для ретрансляции. В дальнейшем к этому каталогу можно представить доступ в рамках сети Microsoft, либо по протоколам FTP или HTTP. Тем не менее, проконтролировать, какая версия антивирусных баз хранится в источнике обновлений, возможности нет.
Наконец, наиболее функциональными источниками обновлений являются специализированные приложения, входящие, как правило, в состав системы администрирования и позволяющие контролировать размещенные на них файлы. Такие источники принято называть серверами обновления.
В силу того, что и сервера обновлений и сервера управления часто подразумевают наличие иерархической структуры (с одной и той же целью - снижение нагрузки на сеть) эти приложения бывают объединены. Иными словами, сервер управления нередко выполняет также функции и сервера обновлений.
Пример. В Kaspersky Administration Kit Сервера администрирования могут выполнять также и функции серверов обновления: загружать обновления из источника верхнего уровня и распространять их среди подключенных клиентов. Дополнительным преимуществом такого подхода является использование для передачи обновлений на клиенты транспорта системы управления - данные передаются непосредственно от Сервера администрирования к Агентам без необходимости в какой-либо дополнительной авторизации
В вопросе обновления клиентов очень важна своевременность. Антивирусные базы должны доставляться в кратчайшие сроки после их выпуска. С другой стороны, как уже было показано выше, одновременное обновление большого количества клиентов может приводить если и не к перегрузке сети (если используется эффективная система источников обновления), то по крайней мере к снижению ее эффективности. Чтобы этого не происходило, обновление в различных группах часто разносят по времени при помощи планирования запуска задач. Дополнительно используется метод случайной задержки, когда запланированные на одно время задачи стартуют не синхронно, а выдерживают паузу случайной длины в рамках заданного интервала. Например, создается расписание запуска обновления в 13:00 со случайно задержкой в пределах 20 минут.
В то же время, при начале вирусной атаки или высокой вероятности возникновения эпидемии можно пренебречь временным снижением эффективности сети ради экстренного обновления. Таким образом, возникает необходимость в двух режимах обновления:
Пример. В Антивирусе Касперского реализованы оба подхода. Естественно, возможно создание локальных, групповых или глобальных задач обновления, которые будут выполняться на клиентах согласно заданному расписанию. При этом администратор в любой момент может принудительно запустить задачу обновления. Есть и специальный режим проталкивания, когда обновление клиентов запускается автоматически после загрузки новых файлов антивирусных баз на Сервер администрирования. Преимущества такого подхода очевидны - запуск обновления на клиентах происходит только в тех случаях, когда есть что загружать и без неизбежной паузы возникающей при жесткой привязке запуска к определенному времени.
В системах, где сервера обновления отделены от серверов управления, проталкивание обычно реализуется путем посылки через систему управления на клиенты специального сигнала о необходимости обновиться.
Подсистема диагностики
Задача подсистемы диагностики - предоставить администратору антивирусной безопасности максимум информации о функционировании системы защиты для обеспечения принятия решений.
Как и в случае одиночного антивируса средства диагностики можно разделить на несколько классов:
Уведомления служат для информирования администратора антивирусной безопасности о событиях, которые возможно требуют безотлагательного вмешательства: например, об обнаружении вируса.
Организация системы уведомлений характеризуется в первую очередь тем, какие каналы доставки уведомлений поддерживаются. Наиболее характерными являются:
Пример. В Kaspersky Administration Kit имеется возможность отправлять уведомления по всем перечисленным каналам, кроме использования SNMP-последовательностей
Второй аспект реализации системы уведомлений - связь с системой управления. Как правило, система управления одновременно выполняет и функции системы уведомлений, но в тех случаях, когда система управления является платной, производитель нередко предоставляет упрощенные средства для организации доставки уведомлений. В этом случае в сети создается отдельный сервер уведомлений, который принимает сигналы о событиях от клиентов и преобразует их в уведомления различных видов.
Журналы работы, которые ведутся на клиентских компьютерах, в случае большой сети для анализа практически непригодны. Поэтому возникает вопрос о централизованном сборе и хранении информации обо всех или только о наиболее важных событиях, т. е. о централизованных журналах.
Пример. В Kaspersky Administration Kit для всех типов событий можно указать необходимость записи их в базу данных на Сервере администрирования для последующего анализа
С централизованными журналами тесно связаны средства генерации отчетов о работе сети. Эти отчеты позволяют оценить ситуацию по сети в целом, выявить наиболее проблемные участки, компьютеры, определить неявные проблемы и т.д.
Пример. В Kaspersky Administration Kit реализованы следующие типы сводных отчетов:
При создании отчета может запрашиваться информация от подчиненных серверов администрирования для более полного охвата сети. Отчет можно сузить до произвольной группы или набора компьютеров, до любого промежутка времени (там где это применимо).
Как правило, отчеты генерируются администратором антивирусной безопасности вручную по необходимости. Однако некоторые отчеты вполне целесообразно генерировать на регулярной основе автоматически: например, отчет о вирусной активности.
Пример. В Kaspersky Administration Kit имеется возможность генерировать отчеты согласно расписанию и отправлять их на почтовый ящик администратора антивирусной безопасности
Средства внедрения
Так же как и локальное управление всеми клиентами вызывает чрезмерные затраты времени и усилий, так и локальная установка антивирусной защиты обычно требует слишком большого количества ресурсов обслуживающего персонала. По этой причине система управления, как правило, оснащается средствами для проведения удаленной установки.
На практике встречаются следующие способы удаленной установки, отличающиеся ограничениями на условия применения и степенью вовлеченности пользователя в процесс установки:
Из всех описанных методов только форсированная установка через RPC является интерактивной и позволяет непосредственно после запуска выяснить, успешно она прошла или нет. Все остальные методы требуют ожидания действий пользователя - запуска программы установки, входа в систему. Даже форсированный режим установки через объекты групповых политик выполняет установку не тут же, а при регистрации компьютера в Active Directory. Т. е. на включенный компьютер такая установка произведена быть не может - требуется предварительная перезагрузка.
Учитывая ограничения каждого из методов, для организации внедрения обычно применяется следующая схема. Сперва выполнятся форсированная установка при помощи RPC, а затем - установка другими методами на оставшиеся компьютеры. После этого анализируется информация о результатах установки и на все оставшиеся незащищенными компьютеры антивирусное ПО и агенты устанавливаются вручную.
Пример. В Kaspersky Administration Kit применяются два способа установки:
При этом, если на компьютере уже установлен Агент администрирования, на него можно установить Антивирус Касперского форсированно, независимо от операционной системы клиента и от информации о реквизитах пользователя с правами администратора на удаленном компьютере - загрузка программы установки и ее запуск производятся непосредственно Агентом администрирования, для которого требуется только связь с Сервером администрирования.
Как видно из приведенного материала, третий уровень КСАЗ является наиболее сложным с точки зрения организации и функционирования. На нем применяется наибольшее количество разнообразных технологий, как непосредственно ориентированных на борьбу с вирусными угрозами, так и призванных обеспечить управление, обновление и диагностику антивирусных средств.
Основными отличительными особенностями этого уровня являются:
Наконец, третий уровень так или иначе присутствует в любой системе антивирусной защиты, даже когда речь идет о сети без шлюзов и почтовой системы.
10. Лабораторная работа: Антивирус Касперского 6.0 для Windows Workstations. Локальная установка и управление
Цель: ознакомиться с процессом инсталляции, принципами работы и управлением Антивирусом Касперского для Windows Workstations на операционных системах Microsoft Windows XP Professional или Microsoft Windows 2000 Professional.
Программное обеспечение:
Содержание работы:
Антивирус Касперского для Windows Workstations - это программный продукт, предназначенный для комплексной защиты рабочей станции от угроз связанных с работой в локальных вычислительных сетях и в интернет.
Продукт предназначен для защиты рабочих станций в корпоративной сети под управлением Kaspersky Administration Kit. При необходимости, Антивирус Касперского для Windows Workstations может работать автономно, в отсутствие сервера управления, без ограничения функций защиты.
Продукт объединяет функциональность антивируса, брандмауэра, антиспама и антибаннера и обеспечивает защиту компьютера пользователя от следующих угроз:
Для выполнения поставленных задач, в продукте реализованы следующие функции:
Установка
Перед началом установки необходимо убедиться, что параметры операционной системы соответствуют системным требованиям Антивируса Касперского для Windows Workstations и установка производится под учетной записью обладающей правами администратора. В случае невыполнения этих условий мастер установки выдает сообщение об ошибке, и установка прерывается.
Одновременная работа Антивируса Касперского для Windows Workstations c другими антивирусами и брандмауэрами может привести к возникновению ошибок, снижению производительности или полной потере работоспособности операционной системы.
Дистрибутив продукта доступен в виде инсталляционного файла в формате Microsoft installer - например, kav6ws.ru.msi. Где "kav" - аббревиатура названия продукта Kaspersky Anti-Virus, "6" - версия, "ws" - тип систем, для которых предназначен продукт (Workstations), "ru" - язык интерфейса.
При исполнении файла kav6ws.ru.msi, запускается мастер установки приложения, и появляется окно приветствия. Для продолжения установки нужно нажать кнопку Далее. При нажатии кнопки Отмена установка будет прервана.
В случае если установка выполняется на компьютер под управлением Microsoft Windows ХР Service Pack 2 с включенным брандмауэром Windows, необходимо выбрать режим взаимодействия Антивируса Касперского для Windows Workstations с брандмауэром:
После окончания копирования файлов открывается окно с сообщением об успешном завершении установки. Далее необходимо произвести предварительную настройку установленного продукта. Для перехода к этапу предварительной настройки следует нажать кнопку Далее.
Результат установки
После успешно завершенной установки на компьютере пользователя появляется папка Program Files\Kaspersky Lab\Kaspersky Ati-Virus for Windows Workstations\, - которая содержит файлы и программные модули антивируса, а также используемые файлы графической оболочки (каталог Skin) и каталог с сопутствующей документацией (Doc)
Также в процессе установки создается папка:
с подкаталогами, в которых хранятся:
В реестр Windows в процессе установки Антивируса Касперского для Windows Workstations вносится ветвь HKLM\SOFTWARE\KasperskyLab\.
В каталог операционной системы Windows\System32\drivers\ (или Winnt\System32\drivers\) устанавливаются драйвера:
Для Microsoft Windows NT-подобных операционных систем дополнительно в реестр вносятся ветви, отвечающие за параметры запуска службы Kaspersky Anti-Virus 6.0 и драйверов kl1.sys и klif.sys. Одноименные ветви создаются в HKLM\SYSTEM\CurrentControlSet\Services.
Также в реестре в список программ автозапуска добавляется ключ AVP со значением C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Workstation\avp.exe.
В список локальных служб добавляется служба Kaspersky Anti-Virus 6.0 запускаемая автоматически под системной учетной записью. Исполняемый файл службы avp.exe с ключом -r
При запуске продукта запускается два процесса avp.exe. Один из них запущен от имени системы и отвечает службе Kaspersky Anti-Virus 6.0, второй от имени пользователя - это процесс интерфейса.
В контекстном меню файлов и папок появляется пункт Проверить на вирусы, с помощью которого можно запустить задачу проверки по требованию выбранного объекта.
В главное меню Windows в раздел Программы добавляется папка Антивирус Касперского для Windows Workstations, в которой находятся:
На системной панели Windows появляется значок антивируса, с помощью которого пользователь может открыть графический интерфейс продукта. Значок также является индикатором состояния Антивируса Касперского для Windows Workstations.
Также надпись Антивирус Касперского 6.0 и значок продукта отображаются в правом верхнем углу экрана при запуске системы, показывая, что система находится под защитой Антивируса Касперского для Windows Workstations.
Принципы работы программы
Антивирус Касперского для Windows Workstations - это новое программное решение, объединяющее опыт всех предыдущих разработок Лаборатории Касперского. Продукт состоит из базового модуля, который выполняет функции антивирусного сканера, и набора опциональных компонентов, обеспечивающих всю остальную функциональность продукта.
Базовый модуль устанавливается в любой конфигурации и состоит из антивирусного сканера и модуля загрузки приложений.
Компоненты антивируса являются независимыми единицами и могут быть установлены в произвольных сочетаниях. С точки зрения выполняемых функций, компоненты Антивирус Касперского для Windows Workstations обеспечивают защиту компьютера в режиме реального времени.
Компоненты
В совокупности с задачами проверки по требованию и обновления Файловый Антивирус, Почтовый Антивирус, Веб-Антивирус и Проактивная защита обеспечивают антивирусную защиту компьютера
Каждому компоненту соответствует отдельная группа настроек, согласно которым компонент функционирует. Параметры общие для всех компонентов вынесены в группу настроек Защита.
Распределение функций компонентов защиты по информационным потокам выглядит следующим образом:
|
Поток |
Компонент |
|
Гибкие носители |
Файловый Антивирус |
|
Сетевые ресурсы |
Файловый Антивирус |
|
Анти-Хакер |
|
|
Электронная почта |
Почтовый Антивирус |
|
Анти-Спам |
|
|
Интернет |
Файловый Антивирус |
|
Веб-Антивирус |
|
|
Анти-Шпион |
|
|
Анти-Хакер |
Дополнительно Проактивная защита и Файловый Антивирус обеспечивают контроль активности приложений и проверку всех файлов, к которым происходит обращение.
Задачи
Инструментом для реализации функций базового модуля являются задачи двух типов:
Задачи, которые создаются при установке приложения, называются системными, и не могут быть переименованы или удалены пользователем. Созданные дополнительно задачи называются пользовательскими.
Системные задачи проверки по требованию (5 задач)
Все системные задачи проверки по требованию выполняют одну и ту же функцию проверки объектов при помощи сигнатурного и эвристического анализа.
Системные задачи обновления
Пользовательские задачи
Пользователь может дополнительно создать до четырех задач проверки по требованию, а также не более двух задач обновления.
Пользовательские задачи обновления, могут быть только задачами обновления сигнатур угроз и модулей приложения. Пользовательскую задачу отката обновлений создать нельзя.
Проверка по требованию
Задачи проверки по требованию используются для проверки объектов находящихся на жестких, сменных и сетевых дисках, а также в оперативной памяти компьютера. Целью таких проверок является обезвреживание вирусов и других вредоносных программ, которые каким либо образом были занесены в память компьютера (например, в то время как компоненты защиты были отключены).
Выявление вирусов, при проверке по требованию, осуществляется с помощью сигнатурного и эвристического анализа.
Системные задачи проверки по требованию не могут быть удалены или переименованы пользователем. Пользовательские задачи ограничений в настройке не имеют.
Всего существует пять системных задач проверки по требованию:
Файловый антивирус
Файловый Антивирус является наиболее важным из компонентов антивирусной защиты. Этот компонент обеспечивает перехват всех файловых операций и проверку содержимого файлов, к которым происходит обращение в режиме реального времени.
Проверка файлов осуществляется так же, как при работе задач проверки по требованию - с помощью сигнатурного и эвристического анализа. Для уменьшения загрузки системы в работе Файлового Антивируса также используются технологии iSwift и iChecker.
Почтовый антивирус
Почтовый Антивирус это компонент обеспечивающий проверку входящих и исходящих сообщений электронной почты.
Почтовый Антивирус перехватывает и проверяет все письма, которые принимает или отправляет пользователь по протоколам POP3, SMTP, IMAP и NNTP. Объектами проверки Почтового Антивируса являются тело письма и вложенные в письмо файлы. Также как и Файловый Антивирус, Почтовый Антивирус для проверки письма на наличие вирусов использует сигнатурный и эвристический анализ.
Веб-Антивирус
Компонент Веб-Антивирус обеспечивает антивирусную защиту компьютера пользователя во время работы в интернет. Веб-Антивирус состоит из двух элементов:
Проактивная защита
Проактивная защита - это средство противодействия еще не внесенным в базы вредоносным программам.
Механизм действия Проактивной Защиты опирается на анализ последовательности действий выполняемых приложениями и процессами. По каждому выполняемому действию, на основе разрешающих и запрещающих правил, принимается решение о том, является ли действие приложения опасным. Опасные действия в соответствии с настройками Проактивной защиты могут быть заблокированы или предоставлены на рассмотрение пользователю. Кроме блокирования, Проактивная защита позволяет откатить некоторые из действий приложений (например, изменение значений системного реестра, создание и изменение файлов).
Помимо анализа поведения приложений и процессов Проактивная защита контролирует исполнение VBA-макросов. В зависимости от настроек опасные VBA-макросы блокируются, или открывается всплывающее окно, запрашивающее действие у пользователя.
Компонент Проактивная защита реализован в виде четырех независимых элементов, остановка и запуск которых может выполняться отдельно:
Для операционных систем Microsoft Windows 98/Me доступен только один элемент Проактивной защиты - Проверка VBA-макросов
Анти-Шпион
Анти-Шпион - это компонент, который обеспечивает блокирование нежелательной рекламной информации при работе в интернет (баннеры, всплывающие окна), защиту от фишинговых атак и несанкционированного подключения к платным интернет ресурсам.
Анти-Шпион состоит из четырех независимых элементов:
Для операционных систем Microsoft Windows 98/Me элемент Анти-Дозвон будет недоступен
Анти-Хакер
Компонент Анти-Хакер - это персональный брандмауэр. В его функции входит контроль сетевых соединений в соответствии с установленными правилами и защита от сетевых атак.
Анти-Хакер состоит из двух элементов:
Анти-Спам
Анти-Спам - это компонент, который служит для защиты пользователя от нежелательной электронной почты, т.е. от спама.
Анти-Спам проверяет все входящие письма и, на основе комплексного критерия, определяет, является ли письмо спамом. В результате работы Анти-Спама письму может быть присвоен статус:
Для определения статуса письма, используются следующие критерии в перечисленном порядке:
Технологии iChecker(tm) и iSwift(tm)
Технологии iChecker и iSwift используются для уменьшения времени проверки файлов на наличие вредоносного кода, без снижения эффективности проверки. Сокращение времени проверки достигается за счет того, что файлы, которые не изменились с момента последней проверки, в течение некоторого времени не подвергаются повторной проверке. Период времени, в который файл не будет проверяться, вычисляется по специальному алгоритму, разработанному в Лаборатории Касперского. В некотором приближении, можно говорить, что время исключения файла из проверки пропорционально времени наблюдения файла (т.е. времени между первой и последней его проверками).
Разница между технологиями iChecker и iSwift заключается в способе определения, изменялся ли данный файл с момента последней проверки или нет:
Обновления сигнатур угроз и модулей приложения
Сигнатурные методы обнаружения вирусов являются наиболее точными и эффективными, однако, для поддержания этой эффективности, крайне необходимо наличие актуальных антивирусных баз. Поэтому обновление антивирусных баз является одной из самых критичных задач обеспечения антивирусной безопасности.
Учитывая частоту появления новых вирусов и высокую скорость их распространения, действительно эффективным сигнатурный метод становится только в случае оперативного выпуска сигнатур этих вирусов и доставки сигнатур на защищаемые компьютеры. Кроме сигнатур могут доставляться также измененные модули антивирусных продуктов: для исправления критических ошибок, для внедрения новых алгоритмов обнаружения и т.д. Именно этот процесс доставки и установки сигнатур и модулей называется обновлением.
Обновление - это мероприятие по загрузке и установке наиболее свежих версий антивирусных баз и модулей приложений
Интервал между появлением нового вируса и доставкой на клиентские компьютеры сигнатуры этого вируса зависит от двух факторов:
В отношении реакции на появление новых вирусов Лаборатория Касперского является одним из лидеров в антивирусной индустрии, что выражается в ежечасном размещении на серверах компании обновлений сигнатур угроз.
Веб-Антивирус, Проактивная защита, Анти-Шпион, Анти-Спам и Система обнаружения вторжений также используют специальные базы при осуществлении функций защиты.
Все базы данных Антивируса Касперского для Windows Workstations, используемые для выявления опасных объектов, объединены в единую базу - сигнатуры угроз.
Лаборатория Касперского выпускает три набора сигнатур угроз (антивирусных баз):
Стандартный набор используется всегда, дополнительные базы расширенного набора используются при включении опции Шпионское, рекламное ПО, программы скрытого дозвона, а параноидальный - при дополнительном включении опции Потенциально опасное ПО (riskware).
Задачи обновления делятся на два типа:
Сами антивирусные базы хранятся в папке Documents and Settings\All Users\Application Data\Kaspersky Lab\AVP6\Bases.
Источник обновлений
Источником обновлений могут выступать:
Настроить параметры доступа к сетевым HTTP/FTP ресурсам можно, нажав кнопку Параметры LAN. По нажатию открывается окно Настройка параметров LAN, в котором предлагается указать режим доступа к FTP-ресурсам (пассивный либо активный), тайм-аут соединения (промежуток ожидания ответа на запрос к серверу), а также задать параметры настройки доступа к прокси-серверу.
Обновляемые компоненты
Ниже приведена таблица с описанием баз, которые используются различными компонентами Антивируса Касперского для Windows Workstations .
|
Компонент |
Используемая база |
|
Поиск вирусов |
Антивирусная база - предназначена для проверки файлов с помощью сигнатурного анализа. Включает сигнатуры угроз вирусов, троянских и других вредоносных программ |
|
Файловый Антивирус |
|
|
Почтовый Антивирус |
|
|
Веб-Антивирус (при проверке с буферизацией) |
|
|
Веб-Антивирус (при потоковой проверке) |
Специальная сокращенная антивирусная база, содержащая сигнатуры вредоносных программ предназначенные для потоковой проверки. |
|
Проактивная защита (Анализ активности приложений) |
Критерии выявления опасной и подозрительной активности, а также подозрительных значений в реестре |
|
Анти-Шпион (Анти-Фишинг) |
Список адресов фишинг-сайтов |
|
Анти-Шпион (Анти-Баннер) |
Список масок запрещенных баннеров |
|
Анти-Хакер (Система обнаружения вторжений) |
Сигнатуры сетевых угроз |
|
Анти-Спам |
База контрольных сумм изображений, которые являются спамом. |
При выполнении задачи обновления, новая версия сигнатур может быть загружена с серверов Лаборатории Касперского или из локального каталога.
Новая технология обновления сигнатур угроз используемая в Антивирусе Касперского для Windows Workstations позволяет существенно уменьшить объем загружаемой информации. Уменьшение объема обновления достигнуто за счет того, что при обновлении загружается не полный набор сигнатур угроз, а разница между сигнатурами угроз на компьютере пользователя, и на сервере обновления
Откат обновления антивирусных баз
Откат обновления антивирусных баз необходим в двух случаях. Во-первых, если новые базы и обновления сканирующего ядра вызывают сбои в работе Антивируса Касперского или всей системы в целом. Во-вторых, если с новыми базами заведомо чистая программа обнаруживается как вирус.
Работа с инфицированными и подозрительными объектами
Во избежание потери важной информации, перед выполнением каких бы то ни было действий с зараженными объектами, будь то попытка лечения или удаление, они помещаются в специальное Резервное хранилище, откуда по необходимости могут быть извлечены. Отдельный статус подозрительных объектов - не зараженных, а лишь подозреваемых в инфицировании, предполагает выделение для них отдельного хранилища - Карантина и периодических проверок этого хранилища с целью определения окончательного статуса файлов при помощи новых наборов антивирусных баз.
Во избежание заражения инфицированными и подозрительными объектами, все помещаемые на Карантин и в Резервное хранилище файлы шифруются и, таким образом, перестают быть запускаемыми, в таком же виде объекты отправляются на исследование в Лабораторию Касперского.
Антивирус Касперского 6.0 для Windows Workstations. Руководство Администратора.
11. Лабораторная работа: Kaspersky Administration Kit. Развертывание системы управления антивирусными средствами Лаборатории Касперского
Цель: ознакомиться с процессом инсталляции, принципами работы Kaspersky Administration Kit и способами построения логической сети, задачами удаленной установки и обновления приложений Лаборатории Касперского.
Программное обеспечение:
Содержание работы:
Kaspersky Administration Kit предназначен для удаленного и централизованного решения основных задач по управлению и обслуживанию системы антивирусной защиты, построенной на продуктах компании Лаборатория Касперского.
В рамках Kaspersky Administration Kit реализованы следующие функции:
Состав и структурная схема
Kaspersky Administration Kit включает следующие компоненты:
Кроме этих ярко выраженных компонентов, Kaspersky Administration Kit включает также модули управления продуктами Лаборатории Касперского, в частности - модуль управления Антивирусом Касперского для Windows Workstations и модуль управления Антивирусом Касперского для Windows Servers. Указанные модули встраиваются в Консоль администрирования и обеспечивают корректное отображение в интерфейсе консоли параметров настройки каждого из продуктов. Также устанавливаются аналогичные модули для управления Сервером администрирования и Агентами администрирования.
Непосредственное отношение к Kaspersky Administration Kit имеет база данных, в которой Сервер администрирования хранит всю необходимую для работы информацию: настройки продуктов, информацию о событиях и другие служебные данные. В текущей версии Сервер администрирования поддерживает работу с Microsoft SQL Server 2000/2005 или его облегченной версией Microsoft SQL Server Desktop Engine 2000 (MSDE 2000)/Microsoft SQL Server Express Edition 2005. Также в последней версии была добавлена поддержка MySQL.
Установка Сервера администрирования
Развертывание Kaspersky Administration Kit начинается с установки центрального элемента системы управления - Сервера администрирования.
Прежде чем приступать к установке Сервера администрирования, следует учесть ряд требований к окружению.
Во-первых, Серверу администрирования для хранения настроек задач, политик, продуктов, событий и структуры логической сети необходим доступ к SQL-серверу баз данных. При этом SQL-сервер не обязательно должен быть установлен на том же компьютере, что и Сервер администрирования, допустима работа с SQL-сервером по сети.
Во-вторых, Сервер администрирования не может быть установлен на компьютер с установленным Агентом администрирования. Следовательно, перед установкой Сервера администрирования следует удостовериться в отсутствии на компьютере Агента администрирования, а в случае наличия этого компонента - удалить его. В процессе установки Сервера администрирования автоматически устанавливается Агент администрирования, подключенный к этому Серверу.
Подключение к Серверу Администрирования
Для установления защищенного соединения с Сервером администрирования на стороне Консоли администрирования должна храниться открытая часть ключа шифрования, т. е. сам сертификат. Поскольку при первом подключении на стороне Консоли администрирования сертификата Сервера администрирования еще нет, а SSL-соединение используется по умолчанию, отображается окно с запросом выбора способа получения сертификата:
В первом случае Консоль администрирования самостоятельно запрашивает у Сервера администрирования его сертификат, и использует этот сертификат для последующих подключений по протоколу SSL
Во втором случае можно вручную указать файл сертификата, который будет использоваться для аутентификации Сервера администрирования. Само собой, нужно быть уверенным, что выбран именно тот сертификат, который используется Сервером администрирования.
Разграничение полномочий администраторов
Разграничение доступа пользователей к Серверу администрирования реализовано на базе групп пользователей Windows-сети. Правом доступа к Серверу администрирования обладают следующие пользователи:
При этом пользователи, входящие в группу KLOperators, получают доступ в режиме "только чтение", т.е. не имеют права вносить изменения в настройки, выполнять задачи и другие административные действия, но могут создавать отчеты по имеющимся шаблонам. Остальные пользователи, имеющие доступ к Серверу администрирования, обладают неограниченными полномочиями.
Допускается одновременный доступ к Серверу администрирования нескольких пользователей, в том числе и в режиме полного доступа. При одновременном изменении параметров Антивируса Касперского в локальном интерфейсе и через Консоль администрирования действовать будут те настройки, которые применены позже.
Возможно создание дополнительных групп пользователей и раздача прав этим пользователям на различные объекты логической сети. При этом соблюдаются указанные ранее принципы - перед тем как давать права тому или иному пользователю, следует внести его в качестве пользователя операционной системы/домена, в котором установлен Сервер администрирования. Возможные права - чтение (возможность просмотра настроек), запись (возможность их изменения, а также создания и удаления объектов логической сети), а также выполнение (возможность запуска задач, создание отчета и т.д.).
Первое подключение к Серверу администрирования
Во время первого подключения к Серверу администрирования структура логической сети еще не создана и администратору предлагается сформировать ее. Об этом сигнализирует окно Добро пожаловать в Kaspersky Administration Kit. В окне предлагается либо Запустить мастер первоначальной настройки для создания базовой структуры, нажав одноименную кнопку, либо отказаться от запуска мастера, оставив структуру логической сети временно пустой. В дальнейшем мастер первоначальной настройки можно будет запустить из контекстного меню узла Сервера администрирования в любой момент.
Выбор способа формирования логической сети
В основном окне мастера первоначальной настройки выбирается способ создания структуры логической сети:
При выборе создания логической сети на основе Windows-сети или на основе предыдущей версии Kaspersky Administration Kit структура логической сети формируется автоматически без участия администратора.
Дальнейшие шаги мастера первоначальной настройки связаны с указанием параметров доставки уведомлений и созданием задач и политик по умолчанию.
Логическая сеть
Под логической сетью понимается структурированная совокупность связанных отношениями подчинения компьютеров с установленными элементами системы управления - Серверами администрирования и Агентами администрирования. Все Агенты администрирования в рамках логической сети подключены к Серверам администрирования этой логической сети. В любой логической сети имеется по крайней мере один Сервер администрирования
Структура логической сети, объекты управления
Компьютер, входящий в логическую сеть, называется клиентом Сервера администрирования или же клиентским компьютером по отношению к Серверу администрирования. Клиентскими компьютерами здесь являются рабочие станции или сервера под управлением Microsoft Windows, на которых установлены Антивирус Касперского и Агент администрирования, подключенный к Серверу администрирования
Клиентские компьютеры являются простейшими объектами управления, простейшими элементами логической сети.
Компьютер с установленным компонентом Сервер администрирования будет называться Сервером администрирования
Таким образом, в зависимости от контекста под Сервером администрирования понимается либо компонент Kaspersky Administration Kit, либо компьютер, на котором этот компонент установлен.
Сервера администрирования также являются объектами управления, т. е. элементами логической сети.
Более сложными элементами являются группы - именованные совокупности объектов управления: клиентов, Серверов администрирования и других групп
Допустима любая степень вложенности групп.
Группы, входящие в качестве элементов в другие группы, будут иногда для удобства называться подгруппами.
Каждая группа может включать произвольное количество клиентских компьютеров, Серверов администрирования и подгрупп. Иерархические отношения между объектами управления - клиентами, Серверами администрирования и группами - образуют структуру логической сети.
Необходимо отметить, что Сервер администрирования, находясь в составе группы, входит в нее вместе со своей логической подсетью.
По своей структуре группа логической сети полностью аналогична самой логической сети. Верно и обратное: логическая сеть может рассматриваться как группа верхнего уровня - все свойства и механизмы групп могут быть отнесены к логической сети целиком. Так, например, групповая задача или групповая политика может относиться сразу ко всей логической сети, т. е. относиться к логической сети, как к группе.
Контейнеры узла Сервера администрирования
Если развернуть любой узел Сервера администрирования, внутри него обнаружатся следующие элементы управления, которые далее будут называться контейнерами:
Структура контейнера Сеть
Контейнер Сеть содержит иерархическую структуру папок, являющуюся отражением структуры Windows-сети: доменам и рабочим группам соответствуют одноименные папки, компьютерам - элементы папок.
Контейнер При включении компьютера в контейнер Группы, он автоматически удаляется из папки контейнера Сеть. И наоборот, при удалении клиента из контейнера Группы, он автоматически помещается в папку контейнера Сеть, соответствующую его домену или рабочей группе. Таким образом, компьютер может быть добавлен в собственную логическую подсеть Сервера администрирования только один раз. Существует возможность добавить один и тот же компьютер в собственные логические подсети разных Серверов администрирования в одной логической сети, но поскольку Агент администрирования может быть подключен только к одному Серверу администрирования, управлять этим компьютеров можно будет только в рамках подключения к одному Серверу администрирования. В остальных логических подсетях управлять этим компьютером будет нельзя.
Процедура добавления группы
При выборе в контекстном меню контейнера Группы или одной из содержащихся в нем папок команды Создать, а затем пункта Группу, предлагается указать имя создаваемой группы.
Добавление нового инсталляционного пакета
Для добавления нового инсталляционного пакета необходимо, к примеру, вызвать контекстное меню контейнера Удаленная установка и последовательно выбрать Создать, Инсталляционный пакет. Можно для той же цели воспользоваться подменю Действие системного меню или же вызвать контекстное меню на пустом месте панели результатов.
В результате этих действий будет запущен мастер создания инсталляционного пакета, первым окном которого является окно приветствия.
После выбора имени инсталляционного пакета необходимо выбрать дистрибутив продукта, который будет устанавливаться. Здесь можно выбрать один из двух вариантов продолжения:
Набор параметров, которые необходимо задать в первом и во втором случае будет различным.
Если было выбрано создание инсталляционного пакета для приложения Лаборатории Касперского, то потребуется указать путь к файлу с расширением .kpd, который находится в составе дистрибутива приложения и содержит информацию о его названии и версии. После того как дистрибутив выбран, эти данные будут отображены в соответствующих полях.
Примечание. При выборе .kpd файла нужно быть уверенным, что он находится в корневом каталоге соответствующего дистрибутива, т. к. при создании инсталляционного пакета копируются все файлы из каталога с .kpd файлом - дополнительной проверки корректности не производится.
Второй случай предназначен не только для удаленной установки продуктов сторонних производителей, но и для удаленного запуска утилит, в том числе производства Лаборатории Касперского, которые не требуют установки и не снабжены сигнальным файлом с расширением .kpd.
Выбор лицензионного ключа
Если создается инсталляционный пакет для приложения Лаборатории Касперского, то можно включить в состав инсталляционного пакета лицензионный ключ, соответствующий устанавливаемому приложению. Пропускать этот шаг не рекомендуется, поскольку в противном случае после выполнения задачи удаленной установки потребуется создавать и запускать на клиенте задачу установки лицензионного ключа - до тех пор клиентское АПО не будет работать. Более того, добавить или изменить лицензионный ключ в уже собранном инсталляционном пакете нельзя.
Создание задачи удаленной установки
После того как инсталляционные пакеты созданы и настроены, процесс удаленной установки переходит к фазе создания задачи удаленной установки. Для этой цели можно воспользоваться либо общим мастером создания задачи, либо специализированным мастером создания задачи удаленной установки.
Задачи удаленной установки могут создаваться:
Для запуска мастера нужно в контекстном меню контейнера Задачи последовательно выбрать Создать, Задачу.
Еще одним способом создания задачи удаленной установки является выбор пункта Установить из контекстного меню инсталляционного пакета, после чего запускается мастер создания задачи удаленной установки, в работе которого отсутствуют шаги выбора типа задачи и инсталляционного пакета, а в окне выбора имени задачи значением по умолчанию является Установка <имя инсталляционного пакета>. После выбора имени задачи следует переход к выбору метода установки.
Выбор метода установки
В Kaspersky Administration Kit реализовано два метода удаленной установки:
Выбор метода определяется конфигурацией компьютеров, на которых будет запущена задача. При установке на компьютеры под управлением Microsoft Windows NT-подобных операционных систем (имеется RPC) , либо на компьютеры с уже установленным Агентом администрирования, предпочтительным является первый вариант, так как позволяет осуществить установку немедленно и оперативно получить информацию о ее результатах.
Выбор учетной записи
Если был выбран метод форсированной установки с использованием RPC, задача удаленной установки для того, чтобы успешно завершиться, должна запускаться с правами администратора на удаленном компьютере. По умолчанию все задачи выполняются с правами учетной записи, которая используется для запуска Сервера администрирования. Если эта учетная запись не обладает нужными правами на определенных для установки компьютерах, следует выбрать пункт Задать учетную запись и указать необходимые реквизиты в полях - Имя пользователя, Пароль и Подтверждение пароля.
В случае выбора установки при помощи сценариев запуска, учетная запись задачи должна обладать правами администратора домена, пользователям которого должны быть назначены сценарии запуска.
Создание задачи проверки по требованию
Проверка по требованию - это единственный тип пользовательских задач Антивируса Касперского непосредственно связанный с поиском вирусов.
Для создания задачи проверки по требованию необходимо в мастере создания задачи выбрать приложение Антивирус Касперского для Windows Workstations или Антивирус Касперского для Windows File Servers, после чего в поле Тип задачи указать Проверка по требованию - такой тип доступен для обоих продуктов.
Выбор настроек проверки по требованию
При проверке возможно использование одного из четырех уровней защиты:
Первые три уровня являются стандартными и характеризуются фиксированными настройками. Для задания нестандартных настроек необходимо нажать Подробно.
Областью проверки - могут быть как стандартные объекты выбираемые из списка, так и дополнительные объекты, задаваемые пользователем.
Стандартными объектами являются:
Изменять и удалять стандартные объекты нельзя. Добавлять в качестве новых объектов можно отдельные диски, папки или файлы, маски (спецсимволы *, ?) при этом использовать нельзя. Зато можно использовать переменные среды окружения, например, %WinDir% или %ProgramFiles%, чтобы включить проверку наиболее критичных областей на клиентских компьютерах, независимо от используемой операционной системы и буквы системного диска.
Стоит обратить внимание на тот факт, что при нажатии кнопки Добавить отображается структура файловой системы компьютера, на котором запущена Консоль администрирования, что может ввести в заблуждение.
Выполнение задачи проверки по требованию
При выполнении задачи проверки по требованию можно отслеживать прогресс ее выполнения на отдельных клиентских компьютерах. Для этого на закладке Задачи свойств клиентского компьютера нужно открыть окно свойств соответствующей задачи проверки по требованию (не обязательно локальной) на закладке Общие. В ходе выполнения задачи в графе Статус будет отображаться степень завершенности задачи в процентах. При открытии окна свойств задачи из контейнера Задачи на уровне группы или на глобальном уровне прогресс выполнения не отображается.
Использовать локальные задачи проверки по требованию может быть удобно в случае проблем на каком-то отдельном клиенте. В большинстве остальных случаев применение групповых задач проверки по требованию предпочтительнее, т. к. позволяет унифицировать настройки выполняемых задач и осуществить одновременную проверку сразу большого количества компьютеров, что особенно важно в условиях вирусной эпидемии.
Создание задачи получения обновлений Сервером администрирования
Задача этого типа на Сервере администрирования может быть только одна. Если она была создана в результате работы мастера первоначальной настройки, создать еще одну не удастся. Если же при создании логической сети мастер первоначальной настройки не использовался, либо если созданная им задача Получение обновлений Сервером администрирования была по каким-то причинам удалена, задачу потребуется создавать заново.
Для этого необходимо в контекстном меню контейнера Задачи глобального уровня последовательно выбрать пункты Создать, Задачу и когда дело дойдет до выбора типа задачи, указать в соответствующих полях:
В окне Настройки требуется указать источник обновлений для Сервера администрирования. Доступно три варианта, по умолчанию в списке источников присутствует только первый:
Вариант обновления с главного Сервера администрирования предлагается вне зависимости от того, является ли в действительности Сервер администрирования подчиненным.
Созданная задача получения обновлений Сервером администрирования является глобальной.
Задача обновления клиентов
Для организации обновления клиентов служит задача типа Обновление антивирусных баз и модулей приложения, относящаяся в продуктовой иерархии к Антивирусу Касперского (и для Windows Workstations, и для Windows File Servers). Задачу можно создавать на любом уровне иерархии - глобальном, групповом, локальном.
После выбора типа задачи требуется указать источник обновления в одноименном окне. Как и в задаче Получение обновлений Сервером администрирования, предлагается три возможности на выбор:
Также возможно указание HTTP-, FTP-сервера или сетевого каталога для получения обновлений из нестандартного источника
Обновление с Сервера администрирования, безусловно, означает обновление именно с того Сервера администрирования, к которому подключен клиент.
Контейнер Обновления
Узнать текущие версии обновлений, хранящихся на Сервере администрирования можно в контейнере Обновления. В панели результатов представлены все хранящиеся на сервере обновления. Антивирусные базы представлены отдельным пунктом. По каждому обновлению доступна следующая информация:
В окне свойств обновления доступна более подробная информация. Так в свойствах антивирусных баз можно в соответствующих полях узнать их Размер, Количество записей, а также Дату создания, т. е. дату и время, когда обновления были размещены на серверах Лаборатории Касперского.
Автоматическое проталкивание обновлений антивирусных баз
Также предусмотрена возможность организовать автоматическое обновление клиентов сразу после получения обновлений Сервером администрирования. Для этого нужно создать задачу обновления клиентов, и задать в качестве расписания запуска параметр Сразу после получения обновлений Сервером администрирования. Такие же задачи создаются в процессе работы мастера первоначальной настройки.
Смена Сервера администрирования
Задача типа Смена Сервера администрирования в продуктовой классификации является задачей Агента администрирования. В иерархической классификации задача Смена Сервера администрирования может быть как локальной, так и групповой или глобальной.
Использовать задачу Смена Сервера администрирования можно не только для фактического переподчинения клиентов одного Сервера администрирования другому, но и просто для изменения некоторых параметров подключения Агента администрирования к Серверу администрирования.
Для создания задачи такого типа нужно в мастере создания задачи после указания имени задачи в окне Приложение выбрать в поле Имя приложения строку Агент администрирования, а в поле Тип задачи - Смена Сервера администрирования, после чего нажать кнопку Далее и настроить параметры задачи с помощью мастера.
После выполнения задачи смены Сервера администрирования, клиенты, на которых задача завершилась успешно, будут недоступны с исходного Сервера администрирования - для управления ими нужно использовать Сервер администрирования, адрес которого был указан в задаче.
Следует быть осторожным и помнить, что при задании настроек задачи Смена Сервера администрирования не проверяется наличие работающего Сервера администрирования по указанному адресу и соответствие сертификата адресу Сервера администрирования. Следовательно, при ошибочном выборе адреса или сертификата клиенты после успешного выполнения задачи становятся неуправляемыми в том смысле, что для удаленного управления такими клиентами потребуется либо переустановить на них Агенты администрирования, либо создать Сервер администрирования с требуемым сертификатом по указанному в настройках задачи адресу.
Kaspersky Administration Kit 6.0. Руководство Администратора.
12. Лабораторная работа: Kaspersky Administration Kit. Особенности работы с иерархической структурой Серверов администрирования
Цель: ознакомиться с процессом подключения подчиненного Сервера администрирования, принципами и правилами наследования политики и задач Kaspersky Administration Kit, работой утилиты резервного копирования Сервера администрирования.
Программное обеспечение:
Для проведения данной лабораторной работы необходимо два компьютера, на которых установлен один часовой пояс и проведена синхронизация времени.
Содержание работы:
Сервера администрирования можно подключать друг к другу.
Подключаемый Сервер администрирования называется подчиненным, а тот, к которому производится подключение - главным
У одного Сервера администрирования может быть несколько подчиненных Серверов администрирования, но только один главный. Сервер администрирования нельзя подключить к самому себе или к его подчиненному Серверу администрирования.
Два Сервера администрирования считаются относящимися к одной логической сети, если либо один из них прямо или опосредованно (через цепочку последовательно подключенных друг другу Серверов администрирования) подключен к другому, либо если оба этих Сервера администрирования прямо или опосредованно подключены к одному Серверу администрирования. Все Сервера в логической сети, кроме одного, таким образом являются подчиненными Серверами администрирования.
Сервер администрирования, стоящий во главе иерархии, называется Главным Сервером администрирования
Структурированная совокупность всех компьютеров, прямо или опосредованно подключенных к произвольному Серверу администрирования в логической сети (не обязательно Главному) будет называться логической подсетью Сервера администрирования .
Совокупность всех компьютеров, непосредственно подключенных к произвольному Серверу администрирования, будет называться собственной логической подсетью Сервера администрирования.
Узел Сервера администрирования
В панели обзора Консоли администрирования на верхнем уровне расположен элемент Kaspersky Administration Kit, который включает в себя все объекты, относящиеся к управлению логической сетью.
На первом уровне расположены узлы Серверов администрирования, а также узел Локальный компьютер, предназначенный для управления Антивирусом Касперского, установленным локально. В качестве имени каждого узла фигурирует адрес соответствующего Сервера администрирования. Если соединение с Сервером администрирования не установлено, напротив имени узла Сервера администрирования указывается статус Не подключен. Отсутствие статуса означает, что Консоль администрирования подключена к этому серверу.
По отношению к узлу Сервера администрирования доступны следующие действия (через контекстное меню или подменю Действие системного меню):
Добавление подчиненного Сервера администрирования
При выборе в контекстном меню контейнера Серверы одной из групп пунктов Создать и Сервер администрирования запускается мастер добавления Сервера администрирования. Следующим после приветствия окном мастера является окно выбора имени Сервера администрирования.
В окне Адрес Сервера администрирования можно указать адрес подчиненного Сервера, но можно этого и не делать. Во втором случае изменения будут внесены только в настройки главного Сервера администрирования и для завершения подключения потребуется менять также настройки подчиненного Сервера администрирования. Если же указать адрес, то добавление можно завершить в рамках работы мастера.
При указании адреса следует руководствоваться теми же правилами, что и при подключении консоли администрирования к Серверу администрирования: если на подключаемом Сервере администрирования используются нестандартные порты, порт для подключения следует прописать через двоеточие после адреса.
Для взаимной аутентификации главного и подчиненного Серверов администрирования необходимо, чтобы на каждом из них хранился сертификат другого. Поэтому при добавлении Сервера администрирования требуется указать путь к его сертификату.
Если ранее был задан адрес подчиненного Сервера администрирования, то следующим шагом является настройка параметров главного Сервера администрирования, которые будут переданы подчиненному
При подключении подчиненного Сервера администрирования выполняются следующие действия:
Последние два действия будут выполнены, только если был указан адрес подчиненного Сервера администрирования. В противном случае их придется выполнять вручную на подключаемом Сервере.
На этапе подключения к подчиненному Серверу администрирования может оказаться, что Консоль администрирования запущена из-под учетной записи с недостаточными правами для доступа к подчиненному Серверу администрирования. В этом случае мастер добавления Сервера администрирования выведет окно с сообщением об ошибке подключения, после чего можно будет задать другие имя пользователя и пароль.
По окончании всех действий мастер выводит окно, сигнализирующее о завершении добавления.
Добавленный Сервер администрирования отображается в контейнере Серверы со статусом Не подключен.
Если на этапе добавления не был указан адрес подчиненного Сервера администрирования, или уже в процессе добавления не удалось осуществить подключение, потребуется задать настройки главного Сервера администрирования непосредственно в свойствах подчиненного. Для этого нужно будет подключиться Консолью администрирования непосредственно к подчиненному Серверу администрирования и изменить параметры иерархии в его свойствах.
Политики Антивируса Касперского
Kaspersky Administration Kit позволяет контролировать настройки продуктов Лаборатории Касперского, установленных на клиентах, при помощи механизма политик.
Политика - это набор параметров работы продуктов, который задается на уровне группы и относится ко всем клиентам группы
В силу того, что политика распространяется на клиенты группы, имеется возможность задавать политики только тех продуктов и компонентов, которые могут быть установлены на клиенте, а это:
Политика для клиентского АПО может находиться в одном из следующих состояний:
В каждой группе может быть создана только одна активная политика для каждого продукта. Кроме этого, политика может создаваться и на уровне логической сети в целом, поскольку, как уже было отмечено, логическая сеть обладает всеми свойствами группы и в большинстве случаев может рассматриваться как группа верхнего уровня.
Действие политик необходимо рассматривать в трех аспектах:
К настройкам клиентов относятся настройки локальных задач, а также настройки, непосредственно к задачам не относящиеся, например, настройки хранилищ, настройки запуска антивируса и настройки интерфейса.
Влияние политики на настройки клиентов
Для простоты удобно считать, что в политике и на клиенте параметры одни и те же, но их значения могут быть разными. Например, значением параметра Источник обновления на клиенте может быть Сервер обновлений Лаборатории Касперского, а в политике - Сервер администрирования. Точно так же и другие параметры.
В связи с тем, что у одного параметра может быть несколько значений, возникает вопрос о том, какие именно значения будут использоваться, скажем, при обновлении, как в приведенном выше примере. Для этого необходимо ввести понятие действующих значений параметров.
В политике кроме значений параметров задается также такой их атрибут как обязательность. Обязательные параметры обладают тем свойством, что не могут быть изменены нигде в области действия политики. В частности, изменение значений обязательных параметров в локальном интерфейсе Антивируса Касперского будет недоступно.
Общим правилом применения политик на клиентах является следующее: действующими значениями обязательных параметров являются значения политики, а необязательных - локальные значения, установленные на клиенте.
Кроме общего правила, применение политики может выражаться в изменении локальных значений параметров. Порядок внесения изменений определяется одним из трех доступных для выбора режимов:
Во втором и третьем режимах администратор логической сети имеет возможность повторить эффект первого применения политики, т. е. в любой момент времени принудительно переписать локальные значения обязательных параметров (второй режим) или всех параметров (третий режим) значениями из политики.
Влияние политик на глобальные и групповые задачи
Влияние политик на групповые задачи имеет смысл рассматривать на одном уровне, т.е. на уровне одной группы. Влияние политик на задачи подгрупп, или же влияние политики подгруппы на выполнение в данной подгруппе групповой задачи более высокого уровня несложно определить исходя из правил наследования политик и групповых задач.
Здесь, как и в случае влияния политик на локальные значения параметров клиентского АПО, имеет смысл говорить о значениях политики, значениях задачи и действующих значениях. В этом смысле влияние настроек политики на настройки групповой задачи выражается очень просто: применение политики никак не влияет на значения параметров в задаче, действующими будут настройки политики для обязательных параметров и настройки задачи для необязательных.
При создании задачи всегда можно задать произвольные значения параметров (в рамках допустимых значений, конечно), даже если политика существует и часть параметров фиксирует как обязательные. Ограничения политики вступают в силу при выполнении задачи (согласно описанному выше правилу) и при попытке изменить настройки задачи: значения обязательных параметров на уровне групповой задачи изменить нельзя.
Влияние политик на групповые задачи более высокого уровня или же на глобальные задачи выражается все той же формулой: действующими являются настройки политики для обязательных параметров и настройки задачи для необязательных. Ограничений на изменение настроек задачи политика более низкого уровня не накладывает.
Наследование политик
Политики также подчинены иерархии логической сети. И точно так же, как групповые задачи, групповые политики оказывают влияние на действующие настройки клиентов и задач не только на уровне группы, но и на уровне ее подгрупп, и на уровне логических подсетей Серверов администрирования, входящих в группу, и т. д. на всю глубину иерархии.
Рассматривая действие политик с учетом иерархии логической сети следует различать собственно иерархическое действие политик, т. е. то, как политика группы применяется на уровне подгрупп и подчиненных Серверов администрирования, и наследование политик, т. е. то как настройки политики группы более высокого уровня влияют на настройки политики подгруппы.
Иерархическое действие политик следует рассматривать только в отношении тех подгрупп, для которых не задана собственная политика. В этом случае для клиентов и задач подгруппы без каких-либо изменений будет действовать политика ближайшей вышестоящей группы. То же верно и в отношении подчиненного Сервера администрирования - в его логической подсети будет действовать политика группы, в которую он входит, либо политика ближайшей вышестоящей группы. Если же ни в одной из вышестоящих групп до самого верха иерархии, т.е. до уровня логической сети Главного Сервера администрирования политика не задана, значит в данной подгруппе или логической подсети никакая политика не действует.
В случае, когда на уровне подгруппы задана собственная политика, речь может идти только о воздействии вышестоящей политики на настройки политики подгруппы. Здесь как и везде раньше, имеет смысл говорить настройках вышестоящей политики, настройках политики подгруппы и действующих настройках политики подгруппы. В отношении клиентов подгруппы (и ниже по иерархии в смысле иерархического действия) политика подгруппы оказывает влияние на основе своих действующих настроек.
При каждом применении вышестоящей политики значения обязательных параметров (заданных обязательными в вышестоящей политике) на уровне политики подгруппы перезаписываются значениями из вышестоящей политики. Значения необязательных параметров вышестоящей политики никак не влияют на значения параметров политики подгруппы. Действующими значениями на уровне политики подгруппы являются значения обязательных параметров вышестоящей группы и значения необязательных параметров (не заданных обязательными в вышестоящей политике) политики подгруппы. В том числе это касается и атрибута обязательности: параметры, заданные обязательными в вышестоящей политике будут автоматически заданы обязательными и в политике подгруппы, но кроме этих унаследованных обязательных параметров, в политике подгруппы могут быть заданы обязательными и другие, дополнительные параметры, которые будут действовать как обязательные в пределах подгруппы.
Необходимо отметить, что режим применения политики хотя и настраивается в рамках политики, не может (в отличие от всех остальных параметров политики) быть задан в качестве обязательного параметра, а значит, режим применения вышестоящей политики не накладывает ограничений на выбор режима применения политики подгруппы.
Создание политик
Создание политик в Kaspersky Administration Kit позволяет унифицировать настройки, как самих приложений, так и выполняемых ими задач для всех клиентов выбранной группы, включая клиенты подгрупп и подчиненных Серверов администрирования, если для них не определена собственная политика.
Для создания политики Антивируса Касперского нужно в мастере создания политики указать соответствующее приложение. Политики Антивируса Касперского для Windows Workstations и Антивируса Касперского для Windows File Servers отличаются незначительно, и все эти отличия будут упомянуты по ходу изложения.
Необходимо помнить о том, что в группе для каждого продукта может быть создана только одна политика. И если политика для какого-то продукта уже существует, этот продукт из вариантов выбора в поле Имя приложения исключается.
Наличие унаследованных политик не препятствует созданию собственных.
Настройка уровня защиты для задач постоянной защиты объектов
При создании политики Антивируса Касперского мастер создания политики в зависимости от приложения, для которого создается политика, предлагает настроить ряд параметров антивирусной защиты и обновления или взаимодействия с Сервером администрирования.
В первую очередь потребуется указать, какие компоненты защиты будут затронуты политикой.
Параметры антивирусной защиты задаются раздельно для задач постоянной защиты объектов и для задач проверки по требованию. В первом случае на выбор предлагаются только стандартные уровни защиты:
Дополнительно возможно задание пользовательских настроек, отличающихся от предустановленных уровней.
Чтобы придать выбранным параметрам статус обязательных следует закрыть замок в правом верхнем углу группы параметров.
Примечание. Настройки политики будут применены к задачам постоянной защиты немедленно, независимо от того выполняются они или нет. При применении политики к выполняющейся задаче постоянной защиты происходит автоматический перезапуск задачи с новыми настройками
Иерархическое действие групповых задач
Если созданная задача проверки по требованию является групповой и в этой группе имеются подчиненные Сервера администрирования, то в сферу действия задачи целиком попадают подсети этих Серверов администрирования. Относятся ли подчиненные Сервера администрирования непосредственно к этой группе или к одной из ее подгрупп значения не имеет.
Унаследованная групповая задача отображается в контейнере Задачи уровня контейнера Группы на подчиненных Серверах администрирования. Иконка унаследованной задачи отличается от иконки обычной групповой задачи наличием на заднем плане изображения сервера.
При запуске на выполнение групповой задачи она выполняется на всех клиентах группы, ее подгрупп, подчиненных Серверов администрирования и т. д. на всю глубину иерархии.
Стоит отметить, что наследование групповой задачи ее подгруппами никак не отражается в контейнерах Задачи этих подгрупп. А в интерфейсе клиентского компьютера все нелокальные задачи обозначаются одинаково (значок задачи на фоне значка папки), независимо от того, на каком уровне иерархии эта задача была создана.
Если открыть окно результатов групповой задачи, то можно убедиться, что она запланирована для клиентов подгрупп и для подчиненных Серверов администрирования.
Получение сведений о лицензионных ключах
Способность Антивируса Касперского выполнять свою основную функцию напрямую зависит от наличия лицензионного ключевого файла. Если лицензионный ключ на клиенте отсутствует или закончился срок действия ключа, Антивирус Касперского будет работать с ограниченной функциональностью.
В связи с этим администратору важно иметь достоверную оперативную информацию обо всех лицензионных ключах, а также возможность удаленно устанавливать и обновлять лицензионные ключи на клиентах.
Перечень всех используемых в организации ключей представлен в контейнере Лицензионные ключи. О каждом ключе в панели результатов приведена следующая информация:
Если лицензионный ключ не используется ни одним из клиентов логической сети, его можно удалить из контейнера Лицензионные ключи, воспользовавшись командой Удалить из контекстного меню. Ошибочно удаленный ключ будет автоматически добавлен Сервером администрирования после плановой синхронизации с клиентом, на котором используется этот ключ.
Установка лицензионного ключа
Для удаленной установки нового лицензионного ключа следует воспользоваться мастером создания задачи либо выбрать в контекстном меню контейнера Лицензионные ключи пункт Добавить лицензионный ключ. В последнем случае запустится специальный мастер создания задачи установки лицензионного ключа.
После стандартных окон приветствия и выбора имени задачи потребуется указать продукт, которому эта задача будет соответствовать. В случае использования обычного мастера в окне Приложение кроме продукта нужно будет выбрать также и тип задачи - Установка лицензионного ключа. У специального мастера тип задачи предопределен, и нужно выбрать только приложение - Антивирус Касперского для Windows Workstations или Антивирус Касперского для Windows File Servers.
Резервное копирование базы Сервера администрирования
Для сохранения и восстановления резервных копий базы данных и настроек Сервера администрирования предназначена штатная утилита klbackup.exe, которая находится в каталоге установки.
Утилита позволяет сохранить или восстановить следующую информацию:
Синтаксис утилиты
При использовании утилиты резервного копирования klbackup.exe используется следующий синтаксис:
klbackup.exe [-logfile LOGFILE] -path BACKUP_PATH
[-use_ts]|[-restore][-savecert PASSWORD]
|
Параметр |
Описание |
|
-logfile |
необязательный параметр, указывающий утилите записывать информацию о процессе сохранения или восстановления резервной копии в файл отчета, если не задан, информация направляется в стандартный поток вывода |
|
LOGFILE |
имя файла отчета |
|
-path |
обязательный параметр для задания каталога хранения резервной копии |
|
BACKUP_PATH |
имя каталога хранения резервной копии |
|
-use_ts |
необязательный параметр, предписывающий сохранять резервную копию не в сам каталог BACKUP_PATH, а в его подкаталог с именем в формате klbackup YYYY-MM-DD # HH-MM-SS, включающем время и дату выполнения операции; использование этого параметра позволяет одной и той же командой резервного копирования создавать много последовательных копий, не затирая новыми копиями предыдущие |
|
-restore |
параметр, предназначенный для восстановления данных из резервной копии |
|
-savecert |
параметр, указывающий на необходимость сохранить или восстановить также и сертификат, используемый Сервером администрирования; при использовании этого параметра обязательно нужно указывать пароль |
|
PASSWORD |
пароль шифрования сертификата |
Если в режиме сохранения резервной копии без использования параметра -use_ts указать каталог, в котором уже есть файлы другой резервной копии, сохранения не будет произведено, а вместо этого будет отображено сообщение об ошибке
В интерфейсе Kaspersky Administration Kit также существует возможность создания резервных копий данных Сервера администрирования. Для создания такой задачи следует в контейнере Глобальные задачи указать Имя приложения - Kaspersky Administration Kit, Тип - Создание резервной копии данных Сервера администрирования
а) на закладке Файлы заблокируйте параметр Уровень защиты в положении Рекомендованный
б) на закладке Обновление параметр Источник обновлений - в положении Сервер Лаборатории Касперского
в) на закладке Дополнительно снимите отметку с пункта Запускать приложение при следующей перезагрузке компьютера
г) на закладке Применение выберите пункт Не изменять параметры. Нажмите Изменить сейчас.
Kaspersky Administration Kit. Руководство Администратора.
13. Лабораторная работа: Основные признаки присутствия вредоносных программ и методы по устранению последствий вирусных заражений
Цель: получить навыки обнаружения на компьютере вредоносных программ, изучить основные методы по устранению последствий вирусных инцидентов без использования антивирусного программного обеспечения.
Программное обеспечение:
Содержание работы:
Определения компьютерного вируса - исторически проблемный вопрос, поскольку достаточно сложно дать четкое определение вируса, очертив при этом свойства, присущие только вирусам и не характерные для других программ. Наоборот, давая жесткое определение вируса как программы, обладающей определенными свойствами практически сразу же можно найти пример вируса, таковыми свойствами не обладающего.
Приведем определение вируса согласно ГОСТ P 51198-98
Вирус - программа, способная создавать свои копии (необязательно совпадающие с оригиналом) и внедрять их в файлы, системные области компьютера, компьютерных сетей, а также осуществлять иные деструктивные действия. При этом копии сохраняют способность дальнейшего распространения. Компьютерный вирус относится к вредоносным программам
Еще одна проблема, связанная с определением компьютерного вируса кроется в том, что сегодня под вирусом чаще всего понимается не "традиционный" вирус, а практически любая вредоносная программа. Это приводит к путанице в терминологии, осложненной еще и тем, что сегодня практически любой антивирус способен выявлять все типы вредоносных программ, таким образом ассоциация "вредоносная программа-вирус" становится все более устойчивой.
Вредоносная программа - компьютерная программа или переносной код, предназначенный для реализации угроз информации, хранящейся в компьютерной системе (КС), либо для скрытого нецелевого использования ресурсов КС, либо иного воздействия, препятствующего нормальному функционированию КС. К вредоносным программам относятся компьютерные вирусы, трояны, сетевые черви и др.
Вирусы
К вирусам относятся:
Отдельно стоит сказать пару слов о макровирусах. Большинство электронных документов создаются и обрабатываются в формате MS Office, инструмент VBA (Visual Basic for Application), который можно использовать для создания макровирусов поставляется вместе с приложением MS Office. Такое положение дел приводит к тому, что на сегодняшний день макровирусы - наиболее часто встречающийся тип вирусов. Однако борьба с ними не вызывает особых проблем и сводится к изучению тела вредоносного макроса с помощью того же VBA на предмет выполняемых операций, контролю стартовых макросов AutoOpen, AutoClose, AutoSave, глобальных макросов FileOpen, FileSaveAs, FileSave, FileClose и ряда стандартных операций, таких как вызов API-функций, выполнения команд Shell и т. д. Процедура лечение макровирусов сводится к удалению тела макроса из документов и шаблонов MS Office.
Сетевые черви
Червь (сетевой червь) - тип вредоносных программ, распространяющихся по сетевым каналам, способных к автономному преодолению систем защиты автоматизированных и компьютерных систем, а также к созданию и дальнейшему распространению своих копий, не всегда совпадающих с оригиналом, осуществлению иного вредоносного воздействия
В зависимости от путей проникновения в операционную систему черви делятся на:
Трояны
Троян (троянский конь) - тип вредоносных программ, основной целью которых является вредоносное воздействие по отношению к компьютерной системе. Трояны отличаются отсутствием механизма создания собственных копий
Некоторые трояны способны к автономному преодолению систем защиты КС, с целью проникновения и заражения системы. В общем случае, троян попадает в систему вместе с вирусом либо червем, в результате неосмотрительных действий пользователя или же активных действий злоумышленника. Наиболее распространены следующие виды троянов:
Жизненный цикл вредоносных программ
Процесс размножения вирусов может быть условно разделен на несколько стадий:
Так же как для вирусов, жизненный цикл червей можно разделить на определенные стадии:
У троянов вследствие отсутствия функций размножения и распространения, их жизненный цикл меньше чем у вирусов - всего три стадии:
Это, само собой, не означает малого времени жизни троянов. Напротив, троян может незаметно находиться в памяти компьютера длительное время, никак не выдавая своего присутствия, до тех пор, пока не выполнит свою вредоносную функцию будет обнаружен антивирусными средствами.
Основные пути проникновения в систему и активации
Существует утверждение - любую вредоносную программу пользователь может победить самостоятельно, т. е. не прибегая к использованию антивирусных программ. Это действительно так, за успешными действия любой антивирусной программы стоит труд вирусных аналитиков, которые по сути дела вручную разбираются с алгоритмами работы новых вирусов, выделяют сигнатуры, описывают алгоритм работы вируса.
Сигнатура вируса - в широком смысле, информация, позволяющая однозначно определить наличие данного вируса в файле или ином коде
Примерами сигнатур являются: уникальная последовательность байт, присутствующая в данном вирусе и не встречающаяся в других программах; контрольная сумма такой последовательности
Таким образом, антивирусную программу можно рассматривать как средство автоматизации борьбы с вирусами. Следует заметить, что анализ вирусов требует от пользователя владения большим объемом специфических знаний в области программирования, работы операционных систем и т. д. Современные вредоносные программы используют сложные технологии маскировки и защиты своих копий, которые обуславливают необходимость применение специальных средств для их анализа.
Процесс подготовки вредоносной программой своих копий для распространения может существенно отличаться от простого копирования. Авторы наиболее сложных в технологическом плане вирусов стараются сделать разные копии максимально непохожими для усложнения их обнаружения антивирусными средствами. Как следствие, составление сигнатуры для такого вируса крайне затруднено.
При создании копий для маскировки могут применяться следующие технологии:
Сочетание этих двух технологий приводит к появлению следующих типов вирусов.
Рассматривая современные вирусные угрозы необходимо отметить, что более 90% процентов вирусных угроз в последнее время связаны с червями. Наиболее многочисленную группу в этом классе вредоносных программ составляют почтовые черви. Интернет-черви также являются заметным явлением, но не столько из-за количества, сколько из-за качества: эпидемии, вызванные Интернет-червями зачастую отличаются высокой скоростью распространения и большими масштабами. IRC и P2P черви встречаются достаточно редко, чаще IRC и P2P служат альтернативными каналами распространения для почтовых и Интернет-червей. Распространение через LAN также используется преимущественно как дополнительный способ распространения.
Кроме того, на этапе активации червей можно разделить на две большие группы отличающиеся как по технологиям активации, так и по срокам жизни:
Активация сетевого червя без участия пользователя всегда означает, что червь использует бреши в безопасности программного обеспечении компьютера. Это приводит к очень быстрому распространению червя внутри корпоративной сети с большим числом станций, существенно увеличивает загрузку каналов связи и может полностью парализовать сеть. Именно этот метод активации использовали черви Lovesan и Sasser. Под пассивным участием пользователя понимается, например, просмотр писем в почтовом клиенте, при котором пользователь не открывает вложенные файлы, но его компьютер тем не менее оказывается зараженным.
Активное участие пользователя в активации червя означает, что пользователь был введен в заблуждение методами социальной инженерии. В большинстве случаев основным фактором служит форма подачи инфицированного сообщения: оно может имитировать письмо от знакомого человека (включая электронный адрес, если знакомый уже заражен), служебное сообщение от почтовой системы или же что-либо подобное, столь же часто встречающееся в потоке обычной корреспонденции.
При заражении компьютера черви обычно производят следующие действия:
shell=Explorer.exe %имя червя%
что обеспечивает ему автозапуск при каждой перезагрузке Windows (но только под Win9x/Me).
Email-Worm.Win32.Atak.h в процессе инсталляции копирует себя с именем dec25.exe в системный каталог Windows и модифицирует файл win.ini для своего последующего запуска - добавляет полный путь к файлу dec25.exe в ключ run секции [windows]:
[windows]
run=%SystemDir%\dec25.exe)
Следует так же отметить, что в файле system.ini кроме секции [boot] вредоносные программы могут использовать секцию [Drivers]
Например, Email-Worm.Win32.Bagle.ax после запуска копирует себя в системный каталог Windows, после чего регистрирует в реестре скопированный файл: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run "Sysformat"="%System%\sysformat.exe
Например вирус I-Worm.Navidad. вносил следующие изменения:
HKEY_CLASSES_ROOT\exefile\shell\open\command {Default} = %SystemDir%\wintask.exe %1 %*)
Таким образом запуск всех ехе-файлов проходил через обращение к инфицированному файлу wintask.exe. В результате, если файл wintask.exe удалялся до правки реестра, операционная система теряла возможность запускать файлы с расширением .exe.
Например Email-Worm.Win32.LovGate.ad изменяет ключ системного реестра HKCR\txtfile\shell\open\command {default}="Update_OB.exe %1", таким образом, чтобы при открытии текстовых файлов получать управление.
Устранение последствий заражения
В связи с тем что, что черви практически не используют технологии шифрования и метаморфизма для маскировки своих копий, борьба с ним вручную несколько упрощается и сводится к следующему алгоритму действий:
Контрольный анализ процессов, ключей реестра, открытых портов. Если подозрительных процессов не обнаружено, ключи реестра не изменились, значит, процедуру дезинфекции компьютера можно считать успешной, в противном случае алгоритм придется повторить.
Тем не менее, учитывая тот факт, что современные черви могут использовать технологии присущие вирусам, устанавливать backdoor-компоненты, затрудняя, тем самым, процедуру анализа и обнаружения своих файлов, для полной уверенности компьютер после дезинфекции вручную настоятельно рекомендуется осуществить проверку антивирусным средством. Следует также отметить, что бороться вручную с вредоносными программами можно только постфактум - после того, как они поразили компьютер, в то же время использование антивирусного программного обеспечения в подавляющем большинстве случаев не допустит активации вредоносной программы на компьютере.
Вирусная энциклопедия www.viruslist.ru.