Защита почтовых систем

Microsoft Exchange

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

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

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

MAPI

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

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

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

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

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

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

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