Любой администратор электронной почты знает, что нужно защищать от вирусов и спама сообщения, пересылаемые Microsoft Exchange Server. Но не всегда почтовый антивирус защищает операционную систему Windows, под управлением которой работает Exchange Server. Примером может служить антивирус Forefront Protection for Exchange [FPE], проверяющий исключительно поток почты. Поэтому возникает вопрос, а нужно ли устанавливать дополнительно файловый антивирус на Exchange Server, чтобы защитить сервер от файловых вирусов и троянов?
В документации по Exchange Server нет рекомендаций Microsoft о том, что файловый антивирус на почтовых серверах использовать не следует. В то же время существуют статьи Microsoft по особым настройкам файловых антивирусов на почтовых серверах, где написано:
This topic describes the effects of file-level antivirus programs on computers that are running Microsoft Exchange Server 2010. If you implement the recommendations described in this topic, you can help enhance the security and health of your Exchange organization.
Существует множество причин, по которым, все же не стоит устанавливать файловый антивирус на Exchange Server. Перечислим лишь некоторые из них.
- Антивирус всегда служил основным генератором проблем в Exchange Server, что подтверждают жалобы пользователей на форумах TechNet. Пропадание писем, переполненные очереди сообщений, задержки при доставке сообщений, зависание серверов – вот лишь не полный перечень проблем, вызываемых некорректной работой антивирусов.
- Даже если антивирус корректно написан и настроен, то обновление антивируса может вызвать проблемы.
- Антивирус будет дополнительно потреблять память и процессорное время сервера, что обязательно скажется на производительности сервера в худшую сторону.
Если внимательно подумать, то откуда взяться вирусам на Microsoft Exchange Server?
- На сервере нет никакого программного обеспечения, кроме Microsoft. Никакие сторонние файлы на него не переписываются.
- Администраторы управляют Exchange Server удаленно, через PowerShell, изредка заходя через RDP, устанавливая обновления.
- У каждого администратора есть две учетные записи – пользовательская и администраторская. Администраторская запись используется редко, исключительно для управления серверами.
- На всех рабочих станциях установлен локальный антивирус, даже если какой-нибудь файл будет записан на сервер, то его обязательно проверит локальный антивирус.
- Выхода в Интернет с серверов нет, серверы защищены файерволами.
Поэтому ответ на вопрос будет такой.
Файловый антивирус можно устанавливать на Exchange Server, но лучше этого не делать, т.к. вреда будет больше, чем пользы.
Почтовый сервер совмещает другие роли – например файлового сервера. К серверу имеют доступ много разных администраторов или сервер находится на удаленной площадке и к нему есть доступ у местных администраторов. Требования аудиторов или стандартов компании. Не всегда они разумны.
Если же вы все таки решили использовать файловый антивирус на Exchange Server, то рекомендую ознакомиться с правильной настройкой антивируса для почтового сервера. Для этого необходимо исключить из проверки определенные папки, процессы и расширения файлов. Список довольно внушительный и не известно, как это повлияет на скорость работы антивируса.
Понравилась публикация? Хотите получать новые прямо в свой почтовый ящик? Нет ничего проще, подпишитесь на рассылку прямо сейчас.
Собственно столкнулись недавно с этой проблемой.
На сервере, где есть транспортная служба, стояли одновременно и FPE и антивирус.
В FPE было добавлено правило, вырезать все exe файлы из архивов и т.п. С чем собственно он прекрасно справляется, а вот антивирус как раз наоборот видит вирусы в exe, и блокирует/удаляет файлы. В итоге все заканчивается без каких либо проблем, почта не пропадает, службы не умирают, очередь не виснет.Но в любом случае, таких ситуаций лучше не допускать
*Правило делали, так как FPE не срабатывал на половину вирусов и пропускал файлы. А пользователи очень любят открывать invoice.PDF.exe из архивов 🙂
Полностью с тобой согласен, но лично мне как-то, вот не комфортно от осознания факта того что на сервере нет антивируса, даже не то что бы антивируса а возможности хотя бы раз в месяц запустить проверку, и я бы наверное поступил следующим образом, такой случай даже описан в курсах Лаборатории Касперского. В антивирусном сервере создать отдельную группу серверов, к группе привязать политику в которой будет указано что файловый антивирус выключен, создать задачу проверки на вирусы с некими разумными параметрами и я так думаю что с исключением проверки баз Exchange ну и к примеру 1 раз в неделю\месяц эту задачу запускать …
MS пишет же, что использование файлового антивируса увеличит безопасность, поэтому можно. У меня серверов штук 11 наверное, лишний софт — лишние проблемы 🙂
Однозначно использовать, если нет то существует сильная возможность пропустить факт заражения или взлома сервера.
Только не говорите что у нас все железно, защищено и на каждый сервер у вас выделенная учетная запись администратора и пр…
Случаи бывают разными, а грамотно настроенный антивирус является дополнительной подстраховкой.
Серег, в моем случае вреда больше, чем пользы.
Тем более никто не написал, что у меня установлен такой-то файловый антивирус и он отлично работает лет 5 с Exchange Server.
Пишу, просто для статистики: всё время существования у нас exchange (пока что 3 года) с установленным на нём сначала FEP, а теперь SCEP и прописанными по статьям микрософта исключениями — ни разу проблем не было.
Ну и отлично, к сожалению, далеко не у всех так и в случае возникновения проблем с Exchange служба поддержки сразу же спросит, какой антивирус у вас установлен и его нужно будет удалить для дальнейшего поиска решения.
я тож хачу danilandrosov@mail.ru
Антивирус нужен обязательно, но действительно не каждый антивирус корректно работает в Exchange, что выражается в зависании сервера. Проверенно без проблем работает Eset File Security, после инсталляции он сам анализирует и добавляет все, что касается Exchange в исключения.
Острая необходимость в антивирусных комплексах, позволяющих проверять почтовые сообщения проходящие через сервер Microsoft Exchange , да и любой другой почтовый сервер , возникла в конце марта 1999 года. Melissa отлично продемонстрировала возможности электронной почты как средства распространения вирусов и определила важность задачи по созданию антивирусных комплексов для проверки почтового потока.
Текущей версией Microsoft Exchange была 5.5, однако попытки создания антивирусных комплексов для Microsoft Exchange проводились и ранее, в бытность версии 5.0.
Как уже говорилось выше, первоначально для проверки почтового потока применялись средства защиты файловых серверов. Понимая неудачность и неполноту таких решений, антивирусные компании продолжили исследования. Их результатом стали первые антивирусные комплексы для защиты Microsoft Exchange - 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, производители антивирусных средств были вынуждены искать другие пути решения проблемы. Таким путем стало использование 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-сканер использовал устаревшие антивирусные базы, либо производитель АПО не успел выпустить новые базы вовремя, пользователь мог загрузить письмо с вирусом просто потому, что к моменту проверки антивирусный комплекс был не в состоянии обнаружить его. Промежуток между доставкой письма пользователю и его фактическим просмотром иногда бывает достаточно длинным и в этот период антивирусный комплекс может успеть получить еще одно обновление антивирусных баз. Следовательно, логичным развитием технологии проверки была бы повторная проверка всего хранилища после получения обновлений
Осознав важность антивирусной защиты в обеспечении безопасности информации, 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.
Новая, переименованная версия антивирусного 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 и, следовательно, проверено. Также недостатками являются сравнительно высокая нагрузка при проверке в фоновом режиме и, что важнее, невозможность полностью удалить инфицированное письмо, возможно лишь замещение инфицированного вложения на уведомление об обнаружении вируса.
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 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 сегодня одинакова для всех производителей.
Позволяет вручную задавать условия фильтрации электронной почты и действия, которые необходимо выполнить с отфильтрованными сообщениями. Есть три независимых набора правил, по одному для каждого:
• Защита почтового транспорта
• Защита базы данных почтовых ящиков
• Сканирование базы данных по требованию
ВАЖНО!
Неправильно определенные правила для сканирования базы данных по требованию могут привести к необратимым изменениям в базах данных почтовых ящиков. Прежде чем начинать первое сканирование базы данных с помощью правил, создайте самую актуальную резервную копию баз данных почтовых ящиков. Кроме того, настоятельно рекомендуется убедиться в том, что правила работают в соответствии с ожиданиями. Для проверки настройте в правилах только действие Записать в журнал событий , поскольку другие действия могут внести изменения в ваши базы данных почтовых ящиков. После проверки можно добавить деструктивные действия правила, например Удалить вложение .
Щелкните Изменить , чтобы открыть Список правил, в котором можно добавить новое правило или изменить имеющееся. Также можно определить условия и действия, которые отличаются для правил в зависимости от того, для чего эти правила используются: для защиты почтового транспорта, базы данных почтовых ящиков или сканирования базы данных по требованию. Это обусловлено тем, что эти виды защиты обрабатывают сообщения немного по-разному (особенно защита почтового транспорта).
Правила разделены на три уровня и оцениваются они в следующем порядке:
• Правила фильтрации (1) : правило, оцененное перед сканированием модулем защиты от спама и вирусов.
• Правила обработки вложений (2) : правило, оцененное во время сканирования модулем защиты от вирусов.
• Правила обработки результатов (3) : правило, оцененное после сканирования модулем защиты от вирусов.
ПРИМЕР
Цель: Отправить на карантин сообщения, содержащие вредоносные программы, или защищенное паролем, поврежденное либо зашифрованное вложение
Создайте следующее правило для модуля Защита почтового транспорта :
Тип: Результаты сканирования на наличие вирусов
Операция: не является
Параметр: Очищена
Тип: Переместить сообщение в карантин
ПРИМЕР
Создайте следующее правило для модуля Защита почтового транспорта :
Тип: Результат SPF
Операция: является
Параметр: Не пройдена
Тип: Задать значение вероятности нежелательной почты
Значение: 5 (задайте значение в соответствии с параметром SCLJunkThreshold командлета Get-OrganizationConfig вашего сервера Exchange. Подробности см. в статье о действиях при достижении порогового значения SCL)
ПРИМЕР
Цель: Удалить сообщения от определенных отправителей
Создайте следующее правило для модуля Защита почтового транспорта :
Тип: Отправитель
Операция: является/является одной из
Параметр: spammer1@domain.com, spammer2@domain.com
Тип: Автоматически удалить сообщение
ПРИМЕР
Откройте набор правил Защита почтового транспорта , выберите Запретить вложения файлов, в которые вложен архив и щелкните Редактировать .
Добавление нового условия
Тип: IP-адрес отправителя
Операция: не/не является одной из
Параметр: 1.1.1.2, 1.1.1.50-1.1.1.99
ПРИМЕЧАНИЕ.
Если добавлено новое или изменено существующее правило, автоматически запускается повторное сканирование сообщений с применением новых или измененных правил.
Если для уровня защиты почтового транспорта и базы данных почтовых ящиков отключить защиту от вирусов в меню настроек или дополнительных параметров (F5) > Сервер > Защита от вирусов и шпионских программ , это повлияет на условия правил выше.
• Результаты сканирования на наличие вирусов
• Вложение защищено паролем
• Вложение является поврежденным архивом
• Содержит поврежденный архив
• Содержит защищенный паролем архив
Кроме того, если для уровня почтового транспорта отключить защиту от вирусов в меню настроек или дополнительных параметров (F5) > Сервер > Защита от вирусов и шпионских программ , это повлияет на действия правил выше.
Читайте также:
Пожалуйста, не занимайтесь самолечением!При симпотмах заболевания - обратитесь к врачу.
Copyright © Иммунитет и инфекции
