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


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


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

Выбирая средства защиты почтовой системы необходимо выяснить:

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


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

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


Схема работы антивирусного комплекса

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


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

Данные требования можно разделить на несколько категорий:

  1. Общие требования — требования, которые диктует жизненная необходимость - дешевизна, надежность, быстрота и пр.
  2. Требования к основному функционалу.Требования к основному функционалу делятся на две части - функционал комплекса и функционал его антивирусной составляющей. Первая часть вытекает из вида угроз, которым должен противостоять антивирусный комплекс для почтового сервера - распространение вредоносных программ с использованием транспорта электронной почты:
    • проверка всего почтового потока, проходящего через защищаемый почтовый сервер. При этом пользователь не должен иметь возможности открыть почтовое сообщение до окончания проверки антивирусным комплексом;
    • проверка всех тел сообщений и вложений, включая архивы. Проверка архивов, по сути, относится уже к антивирусному функционалу продукта, именно ядро поддерживает либо не поддерживает определенный формат архивации;
    • возможность задания различных действий в случае обнаружения инфицированного сообщения - удаление вложения, удаление всего сообщения, информирование пользователя об обнаружении вируса с приложением исходного письма;
    • высокая скорость реакции производителя на появления новых вирусов (следовательно, максимально короткий промежуток между выпуском обновлений антивирусных баз);
    • возможность лечения инфицированных объектов. Почтовые черви не в счет, т.к. они не поддаются лечению;
  3. Требования к управлению
    • масштабируемость — возможность легко переносить конфигурацию на множество аналогичных антивирусных комплексов;
    • удаленное администрирование — должна быть возможность удаленно проверять настройки антивирусного комплекса и, при необходимости, вносить изменения;
    • исключение пользователей из проверки — должна существовать возможность исключить определенных пользователей из проверки на наличие вирусов;
  4. Требования к обновлению.Наличие штатных средств обновления антивирусных баз, позволяющих обновлять базы с одного или некоторых из перечисленных ресурсов:
    • HTTP-сервер;
    • FTP-сервер;
    • локальные или сетевые папки;
    • возможность указать средству источник обновления;
    • возможность выполнять обновление вручную;
    • возможность запускать средство обновления в автоматическом режиме.
  5. Требования к диагностике
    • уведомления отправителю, получателю, администратору — должна быть предусмотрена возможность уведомления ответственных лиц, непосредственных отправителей и получателя инфицированного письма о факте обнаружения вируса. Также должна быть предусмотрена возможность модификации уведомлений;
    • ведение журнала работы.


Существуют требования, удовлетворение которых существенно упрощает задачу защиты от проникновения вирусов через почтовый поток.

  1. Карантин, реализация карантинного хранилища. Пользователю доставляется уведомление со ссылкой на место в карантине, где хранится вложение к его письму. Для получения вложения, пользователь обращается к администратору.
  2. Добавление информации о проверке в письмо — в письмо добавляется информация о том, что оно было проверено, а также статус проверки. Указание в таком сообщении версии использованных антивирусных баз, а также точного времени проверки позволит существенно упростить служебные расследования при поражении вирусами узлов сети.
  3. Генерация списка обнаруживаемых вирусов — при условии реализации предыдущего пункта, может пригодиться для точного определения состояния антивирусного комплекса во время проведения служебного расследования.
  4. Возможность выделения различных групп пользователей и задания различных настроек проверки для этих групп. Некоторые пользователи могут входить в группу риска, поскольку обрабатывают информацию, составляющую коммерческую либо государственную тайну. Требования к проверке корреспонденции таких пользователей должны быть более жесткими, чем обычные.
  5. Возможность модификации уведомлений, в том числе и для различных групп пользователей — для указания адресов и телефонов, по которым нужно обращаться с вопросами касательно антивирусной защиты.
  6. Возможность блокировки объектов, не прошедших проверку — вложения, которые нельзя проверить на наличие вирусов (архивы). В таких случаях антивирусный комплекс должен обладать возможностью блокировать сообщения, содержащие подобные вложения.
  7. Вирусная атака — обнаружение N вирусов в M минут, скорее всего, будет свидетельствовать о вирусной эпидемии либо атаке на сервер. Тогда нужно попытаться внести изменения в настройки самого МТА с тем, чтобы отсеивать зараженные письма на более раннем этапе, снижая, тем самым, нагрузку на сервер.


Microsoft Exchange

Результатом исследований антивирусными компаниями средств защиты файловых серверов, стало создание первых антивирусных комплексов для защиты Microsoft Exchange - MAPI-сканеры.


MAPI

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

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

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


Недостатки:

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


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


ESE
Extensible Storage Engine (ESE) API - ESE сканер разработанный компанией Sybari, как инструмент для производителей систем резервного копирования и предоставлял доступ ко всем объектам, доставляемым или извлекаемым из Information Store.
ESE сканер снял множество ограничений и проблем, связанных с MAPI-сканерами - увеличение нагрузки на сервер снялась за счет того, что письмо проверялось единожды, еще до поступления в Information Store. Исходящие сообщения также начали проверяться в ESE-сканерах. Те письма, которые не проверялись, не попадали в IS, что решило проблему с получением пользователем зараженного письма без проверки. Производилась также проверка по требованию при помощи ESE, таким образом, оставляя все преимущества, предоставляемые Single Instance Storage.

Недостатки:

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


VS API 1.0
Осознав важность антивирусной защиты в обеспечении безопасности информации, Microsoft выпускает Service Pack 3 к Microsoft Exchange, в который впервые включен специальный API для подключения средств антивирусной проверки - AV API 1.0., которое на практике оказалось не столь удобным и хорошим.

AVAPI позволял проверять на наличие вирусов вложения, хранящиеся в Information Store:

  • с помощью фоновой проверки, сканер проходит по всем вложениям, хранящимся в IS, с целью определить были ли они проверены последней версией антивирусных баз. Обнаруженные непроверенные вложения направляется на проверку. Достигнув последнего вложения, проверка считается завершенной;
  • с помощью проверки при доступе. Когда клиент запрашивает вложение либо пытается поместить вложение в IS, оно помещается в очередь на проверку. Для проверки используется только один поток.
Shema raboti AVAPI 1.0
Рис. 1. Схема работы AVAPI 1.0


Преимущества: возможность заблокировать письмо до его проверки, использование Single Instance Storage, возможность проверки исходящих сообщений.
Недостатки: невозможность отсылки уведомлений об обнаружении вируса, и невозможность обнаружения вирусов, внедренных в само тело письма.


VS API 2.0
Новая, переименованная версия антивирусного API, содержащая существенные улучшения в функционале.

Shema raboti VS API 2.0
Рис. 2. Схема работы VS API 2.0


В VS API 2.0 поддерживаются фоновая проверка и проверка при доступе, а также введена упреждающая проверка. Т.е. если в AVAPI 1.0 вложения проверялись только при доступе к ним пользователя, то в VS API 2.0 все поступающие в IS сообщения и вложения ставятся в очередь на проверку, получая при этом низкий приоритет. После завершения проверки всех сообщений с высоким приоритетом, ядро переходит к проверке сообщений с низким приоритетом. При обращении клиента к какому-либо низкоприоритетному сообщению, находящемуся в очереди, приоритет данного сообщения автоматически повышался.

Преимущества:

  • механизм проверки - в VS API 2.0 стал многопоточным, по умолчанию (и рекомендации Microsoft) количество сканирующих ядер равно 2*n +1, где n - количество процессоров сервера, на котором установлен Microsoft Exchange Server 2000;
  • фоновая проверка - по завершении проверки сканирующий поток не ожидает перезапуска Information Store, фоновую проверку можно запускать вновь;
  • API позволяет проверять на наличие вирусов, как вложения, так и тела сообщений. Снята проблема с формированием уведомлений адресату и отправителю инфицированных писем, а также с наполнением уведомлений администратору. VS API 2.0 позволяет получать отчеты о работе средств антивирусной защиты.


Недостатки:

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


Переход на Microsoft Exchange 2000 и выход VS API 2.0 позволили решить задачу защиты почтового потока через этот MTA, поскольку все основные производители средств антивирусной защиты достаточно быстро выпустили версию, поддерживающую новый VS API.


VS API 2.5
Вместе с выходом Microsoft Exchange Server 2003 вышла и новая версия VS API - 2.5., в которой было реализовано три механизма проверки - при доступе, фоновая и упреждающая.
В версии 2.5 была решена проблема невозможности проверки сообщений, не поступающих в Information Store, что позволило полностью контролировать почтовый поток через Microsoft Exchange Server вне зависимости от выполняемой им функции. Даже в случае если Exchange выполняет функцию релейного сервера, все проходящие сообщения могут быть проверены на наличие вирусов. К сожалению, VS API 2.5 может быть использован только в Microsoft Exchange 2003 Server.
Появилась возможность полного удаления (не замещения) инфицированных вложений либо всего зараженного письма, что позволяет не информировать пользователей о приходе им зараженных писем. Такая возможность особенно востребована в период вирусных эпидемий, когда поток инфицированных писем существенно доминирует даже над спамовыми рассылками.


Unix-системы

Если Microsoft Exchange преимущественно используется в качестве внутренней почтовой системы и средства групповой работы, MTA с открытым кодом чаще всего выступают в роли релейного сервера, именно они принимают почту из Интернет, передают ее внутренней почтовой системе и наоборот. В основном, такие системы работают на серверах под управлением FreeBSD/Linux.
Антивирусные комплексы для проверки почтового потока, интегрирующиеся с МТА с открытым кодом, обычно работают по следующей схеме. Предусмотрено три основных модуля:

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



Sendmail
При реализации средств антивирусной защиты для Sendmail необходимо выделить несколько этапов. AVP для Sendmail, осуществлял проверку почтовых сообщений в локальном и глобальном режимах. В локальном - проверялись письма, поступающие к пользователям почтового сервера. При этом исходящие письма, либо письма, передаваемые на другой сервер (при осуществлении релейных функций), на наличие вирусов не проверялись.
В локальном режиме проверка осуществлялась за счет подмены локального доставочного агента на почтовом сервера. Работа в глобальном режиме основывалась на переписывании адресов, т.е. каждому письму, поступившему на сервер, присваивался дополнительный доменный суффикс .avp. После чего все письма, содержащие суффикс, переправлялись на антивирусную проверку, где суффикс убирался, и проверенное письмо пересылалось дальше. В локальном режиме проверялся весь проходящий почтовый поток. Однако, из-за переписывания администраторами адресов для создания собственных фильтров, появилось большое количество конфликтов.
Начиная с версии 8.11.6, в Sendmail был встроен Milter API, позволяющий передавать почтовые сообщения на проверку внешним фильтрам.


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

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