С развитием электронного обмена сообщениями изменяются и угрозы защите. Защитить сообщения можно с помощью следующих процедур.

В дни интерфейсных процессоров сообщений размером во всю комнату и сетей полностью на основе UNIX электронная почта стала убойным приложением, приведшим к появлению ARPAnet, благодаря своей способности доставлять сообщения в псевдореальном масштабе времени без необходимости платить за связь в зависимости от дальности передачи. Впоследствии очарование электронной почты было несколько замутнено появлением новых сервисов, таких, как WAIS, Gopher и, наконец, революционным World Wide Web.

Однако даже после того, как браузеры стали столь же привычными, как домашние бытовые приборы, кажущаяся неизменной концепция электронной почты продолжает эволюционировать. Преобразование двоичных кодов в текст осуществляется теперь прозрачным образом, а прикрепленные файлы мультимедиа стали привычными компонентами повседневного делового обмена сообщениями. Бесплатный доступ к электронной почте на базе Web является одним из самых распространенных применений браузеров Web, и место в корпоративной практике нашел даже немедленный обмен сообщениями (Instant Messaging, IM), а вскоре за ним должны последовать голос по IP (Voice over IP, VoIP) и унифицированный обмен сообщениями (Unified Messaging, UM).

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

В этой статье мы обсудим три подхода к сквозной защите обмена сообщениями, реализацию PKI и связанные с ней вопросы, тактику противодействия вирусам в электронной почте, проблемы защиты IM и опасности для UM.

ЗАЩИТА ИНФОРМАЦИОННОГО НАПОЛНЕНИЯ

Наиболее очевидным следствием полномасштабной реализации обмена сообщениями является необходимость управления его информационным наполнением. Если надежность источника и содержания факсимильного документа и голосовой почты не вызывает сомнения, то борьба за обеспечение целостности сообщений электронной почты продолжается (см. врезку «Защита серверов электронной почты»).

Вирусы и не затребованная массовая рассылка (спам) подрывают доверие к среде, которая может быть столь же надежна, как и телефонная связь. Двумя постоянными задачами управления информационным наполнением являются соблюдение конфиденциальности и целостности.

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

Для достижения этой цели предлагается по крайней мере три конкурирующих подхода, каждый на базе соответствующего комплекта протоколов. Первый подход опирается на Secure/MIME (S/MIME), он был предложен компанией RSA Security. Будучи расширением протокола кодирования MIME, S/MIME стал форматом де-факто для двоичных мультимедийных вложений в электронные сообщения. Хотя первый протокол S/MIME был разработан RSA, текущая версия S/MIME 3 базируется на спецификации IETF (RFC 2632, 2633 и 2634) и, таким образом, представляет собой открытый стандарт.

Благодаря включению сообщения в формате стандарта на криптографию с открытыми ключами N7 (Public Key Cryptography Standard #7, PKCS7) в тело MIME (см. Рисунок 1), S/MIME позволяет получателю идентифицировать личность отправителя с помощью шифрования с открытыми ключами. При таком подходе подпись сообщения просто сравнивается с открытым ключом отправителя. Цифровая подпись отправителя может быть включена в сертификат X.509v3 в разделе S/MIME тела сообщения.

S/MIME является наиболее широко распространенным способом обеспечения сквозной защиты информационного наполнения и пользуется поддержкой основных поставщиков решений для обмена сообщениями, включая Microsoft, Lotus, Netscape Communications и Novell.

Второй подход к обеспечению конфиденциальности электронной почты называется Pretty Good Privacy (PGP). Он был предложен Филиппом Циммерманом в виде бесплатного инструментария для UNIX, однако впоследствии его коммерческой реализацией занялась Network Associates, и теперь PGP доступен и для платформ Windows и Macintosh.

Хотя PGP мог применяться к составным вложениям сам по себе, имеющиеся предложения ориентируются на MIME как на структуру информационного наполнения и поэтому называются PGP/MIME. Кроме того, IETF в настоящее время работает над открытой версией PGP, называемой OpenPGP.

Как и S/MIME, спецификация PGP предполагает шифрование сообщений с использованием симметричного ключа (один и тот же ключ используется как для шифрования, так и для дешифрования данных), после чего он присоединяется к сообщению и шифруется с помощью технологии с открытыми ключами. Это исключает необходимость в шифровании текста сообщения посредством открытого ключа — традиционно весьма медленного процесса.

Однако, в отличие от S/MIME, технология PGP не предусматривает иерархического распространения (и подписи) открытых ключей. Вместо этого PGP опирается на концепцию «паутины доверия», в соответствии с которой пользователь получает открытые ключи надежными средствами (например, лично) и затем самостоятельно решает относительно принятия других ключей, подписанных теми же доверенными уполномоченными. Такой механизм прост для реализации на корпоративном уровне, но ему недостает масштабируемости иерархических PKI.

Третий подход к конфиденциальности составляет дуэт из Privacy Enhanced Mail (PEM) и MIME Object Security Services (MOSS). Задуманный еще в 1993 г., протокол PEM стал первой попыткой защитить обмен электронной почтой; он был опубликован IETF в качестве проекта стандарта в RFC 1421, 1422, 1423 и 1424. Однако его существенным недостатком была неспособность обрабатывать восьмибитовые текстовые сообщения (что необходимо для мультимедийных вложений), поэтому спецификация MOSS и была предложена в качестве замены PEM.

И PEM, и MOSS остаются, однако, высокоуровневыми спецификациями, и мало кто прилагает усилия для достижения совместимости между конкурирующими реализациями.

ВОПРОС ДОВЕРИЯ

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

Во-первых, это масштабируемость. Данный фактор часто упускается из виду в быстрорастущих организациях. Адекватна ли база сертификатов предполагаемой нагрузке? Можно ли тиражировать (и географически распределять) серверы сертификатов, не меняя при этом клиентов электронной почты?

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

Оборотной стороной регистрации является аннулирование сертификатов. Это в-третьих. При получении подписанного и/или зашифрованного сообщения электронной почты получатель должен проверить не только личность отправителя, но и полномочность сертификата. Будут ли сертификаты иметь дату истечения срока действия? Если да, то как ваши пользователи смогут узнать, что ключ был утерян или украден и что сертификат стал недействительным? Собираетесь ли вы периодически рассылать списки аннулированных сертификатов (Certificate Revocation List, CRL) или просто сделаете их доступными всем желающим проверить полномочность сертификата?

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

ДЕЗИНФЕКЦИЯ ВИРУСОВ В ЭЛЕКТРОННОЙ ПОЧТЕ

Недавние инциденты с вирусами Melissa и Love Bug со всей очевидностью продемонстрировали всем нам реальную угрозу: сегодня в глобальной сети Internet один вирус может поразить миллионы хостов практически по всему миру.

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

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

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

Во-вторых, использование адаптивной фильтрации подозрительной почты. Во время последних инцидентов большинство компаний имело возможность отфильтровывать как входящие, так и исходящие сообщения со словами «I Love You» в теме сообщения (фирменный знак этих вирусов).

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

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

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

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

ТЕПЕРЬ НЕ ТОЛЬКО ДЛЯ БОЛТОВНИ

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

Однако, если бы я был уверен, что поставщик находится за своим рабочим столом, то воспользовался бы инструментарием для обмена сообщениями, так как с его помощью я бы мог передать точный номер изделия и детальную спецификацию оборудования, которое хотел бы приобрести. Немедленный обмен сообщениями (Instant Messaging, IM) предлагает решение этой весьма насущной проблемы.

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

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

Вторая — разделение файлов. Эта часто имеющаяся у приложений IM возможность позволяет удаленным пользователям пересылать произвольные файлы на локальный хост по тому же самому соединению, что и трафик обмена сообщениями. Такие файлы могут быть исполняемыми и часто используются для распространения «червей» и троянских коней.

Третья — отказ в обслуживании (Denial of Service, DoS). Для поддержки приложений IM администратору часто приходится открывать произвольный диапазон портов на брандмауэре, которые могут быть использованы для проведения атак DoS.

Рынок IM находится под контролем небольшой группы провайдеров Internet, однако рабочая группа IETF работает над комплектом стандартных протоколов. В марте 2000 г. группа опубликовала проект, где описывается схема защиты IM. Весьма вероятно, что этот проект станет основой для стандартизованной спецификации.

Фундаментальное допущение в отношении защиты IM состоит в том, что сеть не заслуживает доверия и что информация может подвергнуться перлюстрации и злонамеренной модификации со стороны потенциальных злоумышленников. Проект идентифицирует «три S», три опасности IM: подсматривание (stalking), подделку (spoofing) и спам (spamming).

Подсматривание — это перехват данных IM при их передаче по Internet с целью определения местонахождения сети участника обмена в реальном времени. В настоящее время соответствующие организации работают над необходимыми протоколами контроля доступа и обеспечения невидимости.

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

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

По всей видимости, рабочая группа IETF собирается принять за основу ту же схему шифрования и идентификации, которая используется в настоящее время в протоколе S/MIME.

ЗЛОУПОТРЕБЛЕНИЕ УНИФИЦИРОВАННЫМ ОБМЕНОМ СООБЩЕНИЯМИ

Наверное, вам приходилось сталкиваться со следующей рекламой услуг (часто бесплатных): «Факсимильные, голосовые, пейджинговые, сотовые и электронные сообщения в одном легко доступном почтовом ящике Internet!» Предпосылка проста: использовать повсеместность Internet для доступа к нескольким разновидностям сообщений с помощью единого метода, часто на базе Web (см. Рисунок 2).

Рисунок 2. Унифицированный обмен сообщениями позволяет иметь доступ отовсюду. Кроме того, он сокращает расходы на связь за счет использования существующих локальных бюджетов доступа в Internet для извлечения сообщений из «универсального почтового ящика». Однако эта концепция несет в себе зловещие последствия для корпоративной защиты.

Системы унифицированного обмена сообщениями (Unified Messaging, UM) имеют двоякую цель: получение доступа к сообщениям из любой точки и сокращение расходов на связь за счет извлечения сообщений из «универсального почтового ящика» с использованием имеющихся локальных бюджетов доступа в Internet.

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

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

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

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

Во-первых, всеми способами следует избегать «спасения в неведении». Тот факт, что аналоговые голосовые сообщения оцифровываются для их извлечения с помощью электронной почты Internet, не означает, что они шифруются. Например, факс из отдела кадров будет просто храниться в одном из широко распространенных графических форматов (*.TIFF, *.JPG и т. п.).

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

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

К слову, если кто-то думает, что сотовая связь надежно защищена, то он ошибается: в 1997 г. шифровальщик Брюс Шнайер (из Counterpane Lab) обнаружил дыру в используемой в цифровых сотовых телефонах технологии шифрования.

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

БОЕВОЕ ДЕЖУРСТВО

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

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

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

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

Рамон Дж. Онтаньон — менеджер по разработке глобальных продуктов VPN в UUNET. С ним можно связаться по адресу: hontanon@uu.net.


Защита серверов электронной почты

Основное внимание уделяется, как правило, сквозной защите коммуникаций электронной почты. Однако атаки по типу «отказ в обслуживании» (Denial of Service, DoS) на серверы электронного обмена сообщениями проводятся достаточно часто, и практически всегда они являются следствием неправильной конфигурации сервера электронной почты. Следующие рекомендации приложимы к почтовым транспортным агентам на базе как UNIX, так и Windows, и их следует придерживаться во всех реализациях почты.

Во-первых, почтовый шлюз должен размещаться по внешнюю сторону брандмауэра или, по крайней мере, в демилитаризованной зоне (Demilitarized Zone, DMZ), чтобы злоумышленник не мог использовать его в качестве трамплина для скачка к другим защищенным корпоративным ресурсам. В идеале, общедоступный почтовый сервер (SMTP) должен быть отделен от частного сервера (POP3, Microsoft Exchange), к которому локальные пользователи обращаются для извлечения своей почты.

Во-вторых, трансляцию почты из неизвестных источников следует запретить. Серверы должны быть сконфигурированы на пересылку почты только в тех случаях, когда либо отправитель, либо получатель является локальным пользователем. Отправители сорной электронной почты коммерческого характера (т. е. спама) используют трансляцию для доставки своих сообщений множеству адресатов, до которых они иначе не дошли бы, так как были бы отфильтрованы на основании адреса отправителя (IP-адреса и домены отправителей спама содержатся в широко доступных «черных списках», см. врезку «Ресурсы Internet»). Трансляция чужой почты может превратить почтовую систему в «отмывочный пункт» для сорной коммерческой почты и сделать компанию частично ответственной за подобную незаконную практику.

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

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

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


Ресурсы Internet

Информацию о протоколе S/MIME можно найти на http://www.imc.org/rfc2633.

Информацию о PEM и MOSS можно найти на http://www.imc.org/rfc1421.

Internet Mail Consortium (IMC, http://www.imc.org) занимается пропагандой и развитием технологий электронной почты.

Координационный центр CERT публикует предупреждения об инцидентах в области защиты на http://www.cert.org (на настоящий момент им зафиксировано свыше 14 тыс. таких инцидентов).

Бесплатную версию Pretty Good Privacy (PGP) можно загрузить с http://www.pgpi.org.

Network Associates (http://www.nai.com) предлагает коммерческую версию PGP.

Некоммерческая организация Mail Abuse Prevention System (MAPS) занимается защитой систем электронной почты Internet от злоупотреблений, связанных с рассылкой спама. Обновляемый MAPS список известных отправителей спама можно найти на http://mail-abuse.org/rbl/.

Open Relay Behavior-modification System (ORBS) представляет собой проверенную базу данных почтовых серверов, о которых известно, что они пересылают чужой трафик. Ее можно найти на http://www.orbs.org.

Официальная страница Web рабочей группы IETF по Internet Messaging имеет адрес http://www.imppwg.org.

Поделитесь материалом с коллегами и друзьями