Вирусы и средства борьбы с ними
         

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 сканеров были:

    Низкая информативность уведомлений, что, впрочем, скорее относится к реализации конкретных продуктовНевозможность проверить данные, не проходящие через Information Store (к примеру, если Exchange является релейным сервером, почтовый поток проходит только через SMTP-коннектор и не подлежит проверке)После прохождения проверки на входе в Information Store письмо доставляется в почтовый ящик пользователя, после этого пользователь волен принять его. Поэтому если на момент проверки ESE-сканер использовал устаревшие антивирусные базы, либо производитель АПО не успел выпустить новые базы вовремя, пользователь мог загрузить письмо с вирусом просто потому, что к моменту проверки антивирусный комплекс был не в состоянии обнаружить его. Промежуток между доставкой письма пользователю и его фактическим просмотром иногда бывает достаточно длинным и в этот период антивирусный комплекс может успеть получить еще одно обновление антивирусных баз. Следовательно, логичным развитием технологии проверки была бы повторная проверка всего хранилища после получения обновлений



MAPI


В MAPI-сканерах для получения доступа к почтовым сообщениям либо документам в папках общего доступа использовался Messaging Application Program Interface (MAPI). При получении уведомления о поступлении нового сообщения в ящик пользователя или нового документа в общую папку программа выполняла MAPI вход в ящик пользователя/папку и осуществляла проверку на наличие вирусов.

Позитивными моментами в сравнении с использованием антивирусных комплексов для защиты файловых серверов являлись:

Возможность проверки упакованных и заархивированных почтовых сообщенийСущественно более низкое количество конфликтов с Microsoft Exchange

Однако, имелся и ряд серьезных недостатков:

    Проверка осуществлялась путем такого же MAPI входа, какой выполняет и обычный клиент (к примеру, Microsoft Outlook). В силу отсутствия возможности блокировки непроверенных писем, пользователь мог успеть получить зараженное сообщение до того, как оно будет проверено. В такой ситуации доставка зараженного сообщения пользователю упирается в вопрос "кто успеет первым - почтовый клиент или антивирусный комплекс". Естественно, при больших нагрузках на сервер вероятность прохождения зараженного письма существенно возрастает, в свою очередь не следует забывать о том, что большие нагрузки на сервер могут быть и зачастую бывают вызваны очередной вирусной эпидемиейMAPI-сканеры не могли, в силу технологических особенностей, проверять исходящие почтовые сообщенияПринципы работы MAPI-сканера обуславливали существенное увеличение нагрузки на сервер при осуществлении антивирусной проверки. Дело в том, что вложение к письму, доставленное нескольким адресатам, хранится в базе вложений в единственном экземпляре, на него ссылаются письма всех адресатов (single instance storage). При выполнении проверки на наличие вирусов письма, направленного нескольким адресатам, антивирусный комплекс вынужден производить многократную проверку одного и того же файла, тем самым сводя на нет все преимущества реляционной базы Microsoft Exchange. После проверки вложение помещается обратно в Information Store, однако уже в качестве обновленного документа. Таким образом, после завершения проверки в ящиках всех адресатов письма, Information Store содержит множество копий одного и того же вложения, измененных антивирусным комплексомДополнительные ограничения связаны с реализацией уведомлений MAPI, а именно - возможностью уведомлять о приходе письма только первым 64 адресатам. Если письмо было адресовано большему количеству пользователей защищаемого сервера, MAPI-сканер не будет знать о поступлении нового сообщения еще и этим адресатам, таким образом письмо не будет проверено для определенного количества пользователей

Тем не менее, несмотря на большое количество ограничений, MAPI-сканеры были существенным шагом вперед, поскольку являлись специализированными средствами для проверки почтовых сообщений.



Microsoft Exchange


Острая необходимость в антивирусных комплексах, позволяющих проверять почтовые сообщения проходящие через сервер Microsoft Exchange, да и любой другой почтовый сервер, возникла в конце марта 1999 года. Melissa отлично продемонстрировала возможности электронной почты как средства распространения вирусов и определила важность задачи по созданию антивирусных комплексов для проверки почтового потока.

Текущей версией Microsoft Exchange была 5.5, однако попытки создания антивирусных комплексов для Microsoft Exchange проводились и ранее, в бытность версии 5.0.

Как уже говорилось выше, первоначально для проверки почтового потока применялись средства защиты файловых серверов. Понимая неудачность и неполноту таких решений, антивирусные компании продолжили исследования. Их результатом стали первые антивирусные комплексы для защиты Microsoft Exchange - MAPI-сканеры.



Общие сведения


В силу того, что по разным оценкам от 80 до 95 процентов вирусов проникает в корпоративные сети через электронную почту, проверка почтового трафика является одной из важнейших задач обеспечения антивирусной безопасности организации. При этом под почтовым трафиком понимается SMTP-поток. Антивирусные комплексы для защиты почтовых систем не проверяют данные, передаваемые по протоколам IMAP и POP при обращении пользователей к своим персональным внешним по отношению к организации ящикам, поскольку это - задача антивирусного комплекса для защиты рабочих станций. Задачей антивирусного комплекса для почтовой системы является проверка и всего потока писем, поступающих и исходящих из почтовой системы организации.

Использование антивирусных комплексов для почтовых систем необходимо для обеспечения безопасности информации, однако возникает вопрос какие комплексы и как должны быть использованы для защиты сетей. Практическое применение, естественно, зависит от схемы построения почтовой системы организации, а также используемых MTA (Mail Transfer Agent).



Postfix


В случае с Postfix отсутствовала первая историческая итерация - сам МТА изначально планировался способным передавать сообщения на проверку внешним фильтрам. Именно поэтому отсутствовали различия и в способах интеграции - предложенным механизмом воспользовались абсолютно все производители средств антивирусной защиты.



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.


Требования к антивирусному комплексу для проверки почтового потока


Требования к антивирусному комплексу для проверки почтового потока можно разделить на несколько категорий:

    Общие требования — требования, которые диктует жизненная необходимость - продукт должен быть дешевым, надежным, быстрым и пр. Все параметры, которые могут быть перечислены в этом разделе, относятся и к другим антивирусным комплексам, да и вообще ко всему, разрабатываемому с целью дальнейшего использования.Требования к основному функционалу. Требования к основному функционалу следует также разделить на две части - собственно, функционал комплекса и функционал его антивирусной составляющей. Первая часть логичным образом вытекает из вида угроз, которым должен противостоять антивирусный комплекс для почтового сервера - распространение вредоносных программ с использованием транспорта электронной почты. Проверка всего почтового потока, проходящего через защищаемый почтовый сервер. При этом пользователь никоим образом не должен иметь возможности открыть почтовое сообщение до того как оно будет проверено антивирусным комплексом Примером такого комплекса может выступать сегодня практически любой антивирус для почтовой системы любого производителя, это же касается и других требований из разряда обязательных. Тем не менее, в силу технологических особенностей, проверка всего исходящего через Microsoft Exchange Server почтового потока стала возможной сравнительно недавно и только для одной версии этого продукта. Речь об этом пойдет ниже.

    Проверка всех тел сообщений и вложений, включая архивы. Проверка архивов, по сути, относится уже к антивирусному функционалу продукта, именно ядро поддерживает либо не поддерживает определенный формат архивации Пример. В Антивирусе Касперского для Unix Mail Server проверяются и тела сообщений, и вложения, при этом количество поддерживаемых форматов архивов и упаковщиков является рекордным.

    Возможность задания различных действий в случае обнаружения инфицированного сообщения - удаление вложения, удаление всего сообщения, информирование пользователя об обнаружении вируса с приложением исходного письма.
    Требования к уведомлениям описаны ниже.

    Не считая приведенного ранее требования по возможности проверки архивов, а также вполне логичного общего пожелания - ловить как можно большее количество вирусов - существует еще одно особенно важное в случае почтового потока требование к производителю антивирусного комплекса.

    Высокая скорость реакции производителя на появления новых вирусов (следовательно, максимально короткий промежуток между выпуском обновлений антивирусных баз). Возможность лечения инфицированных объектов. Менее критичное требование применительно к проверке почты, поскольку большинство вредоносных программ, выявляемых в почтовом потоке являются червями, не поддающимися лечению. Пример. Во всех антивирусных комплексах Лаборатории Касперского для проверки почты реализована функция лечения обнаруженных вирусов. Правда, на практике можно вылечить не более 1% обнаруживаемых вредоносных программ.



    Требования к управлению

    Масштабируемость — возможность легко переносить конфигурацию на множество аналогичных антивирусных комплексов.Удаленное администрирование — сотрудник отдела защиты информации должен иметь возможность удаленно проверять настройки антивирусного комплекса и, при необходимости, вносить изменения.Исключение пользователей из проверки — должна существовать возможность исключить определенных пользователей из проверки на наличие вирусов. К примеру, это могут быть сотрудники отдела защиты информации либо другие лица, которым по служебной необходимости должен приходить абсолютно весь почтовый поток.

    Требования к обновлению. Наличие штатных средств обновления антивирусных баз, позволяющих обновлять базы с одного или некоторых из перечисленных ресурсов: HTTP-серверFTP-серверЛокальные или сетевые папкиВозможность указать средству источник обновленияВозможность выполнять обновление вручнуюВозможность запускать средство обновления в автоматическом режиме

    Требования к диагностике

    Уведомления отправителю, получателю, администратору — должна быть предусмотрена возможность уведомления ответственных лиц, а также непосредственных отправителя и получателя инфицированного письма о факте обнаружения вируса.


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



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

    Карантин — кроме удаления и доставки пользователю сообщения, возможна реализация карантинного хранилища - в этом случае пользователю доставляется уведомление со ссылкой на место в карантине, где хранится вложение к его письму. При необходимости получить вложение, пользователь обращается к администратору. Вторичность карантина при проверке почтового потока объясняется большим количеством червей в сравнении с остальными вредоносными программами, и, как следует, низкую эффективность помещения объектов на карантин. Пример. В Антивирусе Касперского для Unix Mail Server имеется возможность помещать подозрительные, инфицированные и непроверенные объекты на карантин.

    Добавление информации о проверке в письмо — в конец проверенного письма, либо в служебный заголовок добавляется информация о том, что письмо было проверено, а также статус проверки. Указание в таком сообщении версии использованных антивирусных баз, а также точного времени проверки позволит существенно упростить служебные расследования при поражении вирусами узлов сети. Требование не является обязательным, поскольку относится скорее к удобству управления антивирусной защитой сети в целом, а не только проверкой почтового потока. Генерация списка обнаруживаемых вирусов — может пригодиться для точного определения состояния антивирусного комплекса во время проведения служебного расследования, при условии реализации предыдущего пункта Возможность выделения различных групп пользователей и задания различных настроек проверки для этих групп — логичное продолжение требования к возможности исключения пользователей из проверки.


    Некоторые пользователи, наоборот, могут входить в группу риска, поскольку обрабатывают информацию, составляющую коммерческую либо государственную тайну. Требования к проверке корреспонденции таких пользователей должны быть более жесткими чем обычные. Пример. Такой функционал реализован в Антивирусе Касперского для Unix Mail Server. Группы проверки определяются как маски адресов отправителей и получателей. При получении письма, программа последовательно просматривает условия всех групп. При совпадении масок отправителя и получателя, письмо проверяется согласно настройкам группы. Если письмо может быть отнесено к нескольким группам, оно относится к первому встреченному совпадению. Если письмо не удовлетворяет требованиям ни одной из групп - оно проверяется на общих условиях

    Возможность модификации уведомлений, в том числе и для различных групп пользователей — может пригодиться для указания адресов и телефонов, по которым нужно обращаться с вопросами касательно антивирусной защиты. Пример. Антивирус Касперского для Microsoft Exchange Server позволяет модифицировать уведомления всем трем типам пользователей. Большое количество встроенных макросов позволяет сделать уведомление максимально детализированным.

    Возможность блокировки объектов, не прошедших проверку — в некоторых случаях проверить вложение на наличие вирусов не представляется возможным — к примеру, если это часть многотомного архива либо архив, защищенный паролем. В этом случае антивирусный комплекс должен обладать возможностью блокировать сообщения, содержащие подобные вложения. Вирусная атака — при обнаружении N вирусов в M минут иногда полезно уведомить администратора об этом факте. Подобное поведение продукта скорее всего будет свидетельствовать о вирусной эпидемии либо атаке на сервер. В обоих случаях администратор может попытаться внести изменения в настройки самого МТА с тем, чтобы отсеивать зараженные письма на более раннем этапе, снижая, тем самым, нагрузку на сервер Пример. Подобный функционал реализован в рамках продукта ScanMail for Microsoft Exchange компании Trend Micro.Вообще же следует отметить, что обнаружение вирусной атаки относится, скорее, в подсистеме защиты рабочих станций и серверов. Впрочем, лишний функционал лишним не бывает.



Далее в этой главе будут рассмотрены антивирусные комплексы для защиты наиболее часто встречающихся внешних и внутренних почтовых систем - Microsoft Exchange и MTA с открытым кодом для Unix - Sendmail и Postfix.


Unix-системы


Если Microsoft Exchange преимущественно используется в качестве внутренней почтовой системы и средства групповой работы, MTA с открытым кодом чаще всего выступают в роли релейного сервера, именно они принимают почту из Интернет, передают ее внутренней почтовой системе и наоборот.

Как правило, такие системы работают на серверах под управлением FreeBSD/Linux. Исторически разработкой антивирусных комплексов, работающих на этих операционных системах занимались только компании постсоветского пространства, Лаборатория Касперского и Доктор Веб. В последнее время, правда, к ним примкнули и некоторые западные разработчики - компании Trend Micro и Symantec также обратили свое внимание на Linux. К FreeBSD и вообще всему BSD-семейству это, правда, не относится.

Антивирусные комплексы для проверки почтового потока, интегрирующиеся с МТА с открытым кодом обычно работают по следующей схеме. Предусмотрено три основных модуля - модуль интеграции с МТА (разный для разных МТА, впрочем, возможна и универсализация), его задача - принять сообщение у почтового сервера и передать на проверку антивирусному модулю. Антивирусный модуль, постоянно пребывающий в оперативной памяти сервера (работающий в daemon-режиме), осуществляет проверку и возвращает модулю-перехватчику в зависимости от результатов проверки и возможностей конкретного продукта, либо вердикт, либо вылеченное вложение. Наконец, третий важный компонент осуществляет обновления антивирусных баз.



Возможные схемы защиты


Выбор средств защиты почтовой системы опирается на выяснение двух ключевых факторов:

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

Возможно несколько схем работы почтовой системы, оказывающих влияние на построение подсистемы защиты почты. В общем случае организация может использовать либо не использовать средство групповой работы (Microsoft Exchange либо Lotus Notes/Domino), использовать либо не использовать релейный сервер (в Интернет выставляется не основной почтовый сервер организации, а дополнительный сервер, осуществляющий трансляционные функции между Интернет и внутренним почтовым сервером), почта может быть разделена на внешнюю и внутреннюю с различными схемами маршрутизации (выделяется два сервера либо один и тот же сервер обслуживает два различных домена). Дополнительные варианты налагает использование в сети двухсегментной структуры с жестким разделением между сегментами.

Наиболее часто задаваемым вопросом в этом случае является следующий: "Если в сети используется два и более почтовых серверов с выделенным релейным сервером, достаточно ли будет установить антивирусный комплекс на релейный сервер?"

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

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

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

Вторым немаловажным фактором является схема работы самого антивирусного комплекса. Здесь возможны два варианта - антивирусный комплекс интегрируется с почтовой системой либо же встраивается в существующую систему в разрыв. Как правило, используется первый вариант, второй имеет смысл использовать либо если невозможно найти антивирусный комплекс, который интегрировался бы с почтовой системой (такое бывает, например, при использовании почтовой системы собственной разработки), либо при введении дополнительного релейного сервера между шлюзом и внутренним почтовым сервером для проверки всего поступающего из Интернет SMTP-потока.

Наиболее плохим, но тем не менее также используемым вариантом сегодня остается установка антивирусного комплекса для файлового сервера на сервер почтовый. В этом случае некоторые зараженные письма будут обнаружены, однако подобная практика вызывает множество конфликтов в работе обеих систем.Дополнительно необходимо помнить о том, что вложения в письма закодированы при помощи MIME, а также могут быть заархивированы. Сегодня немногие антивирусные комплексы для защиты рабочих станций и файловых серверов предоставляют такой функционал. Это связано с тем, что проверка архивов и закодированных сообщений существенно увеличивает нагрузку на сервер/рабочую станцию.


в обеспечении безопасности информации, Microsoft


Осознав важность антивирусной защиты в обеспечении безопасности информации, 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


переименованная версия антивирусного API, содержит


Новая, переименованная версия антивирусного 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 на первые роли в определении лучшего вновь вышли вторичный функционал продукта, надежность работы и, самое главное, скорость реакции производителя на выпуск новых вирусов.


с выходом Microsoft Exchange Server


Вместе с выходом 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 сегодня одинакова для всех производителей.