Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Аутентификация отправителей e-mail и борьба со спамом

Кристофер Бирс

Технология аутентификации отправителей электронной почты позволяет резко сократить поток почтового мусора. Мы проанализировали три разновидности такой технологии.

Согласно отчету Security Threat Report компании Symantec и исследованиям компании Forrester Research, почтовый мусор составляет до 67% всего трафика электронной почты Интернета. Другими словами, из каждых десяти приходящих в вашу сеть сообщений только три заслуживают внимания.

Самый распространенный на сегодняшний день метод борьбы со спамом состоит в использовании ПО, которое для каждого пользователя пытается определить, какое из поступивших сообщений является спамом, а какое — легитимной почтой. Фильтрация сообщений, без сомнения, полезна, однако работающие со стопроцентной точностью спам-фильтры в настоящее время, к сожалению, отсутствуют; ошибочное же принятие легитимного сообщения e-mail за спам вообще является недопустимым для бизнеса. Целесообразно ли сочетать технологии аутентификации отправителей сообщений с ПО фильтрации электронной почты с целью добавления еще одного уровня защиты от настырных спамеров? Как раз это мы и решили выяснить в данном обзоре.

Что у спамеров на уме?

Системы электронной почты и протокол SMTP изначально разрабатывались без учета необходимости защиты (возникшей впоследствии) почтовых ящиков от спама. Что общего у электронной и обычной почты? Если вы пишете своему приятелю в Калифорнию на бумаге, вас никто не принуждает указывать на конверте точный адрес получателя или обратный адрес, относить письмо для отправки в строго определенное почтовое отделение или даже помещать в конверт именно то письмо, которое нужно. Аналогично системы e-mail не заставляют отправителей сообщений указывать для них точный адрес назначения и точный обратный адрес, использовать определенный почтовый сервер или печатать правильный текст в теле сообщения. Так вот, спамеры в полной мере с выгодой для себя используют эти послабления, к примеру никогда не указывая в своих сообщениях корректные обратные адреса. Они поддерживают списки, включающие сотни тысяч электронных адресов, рассылают по ним все сообщения без разбору в надежде, что значительный процент этих сообщений достигнет адресатов. Ясно, что в этом деле они преуспели.

Спамеры очень любят открытые ретрансляторы (open relays) — серверы, доставляющие почту нелокальным пользователям, поскольку такой ретранслятор позволяет замаскировать идентифицирующую спамера информацию. Ответственные почтовые администраторы все чаще и чаще закрывают такие ретрансляторы на своих системах. Призванные отслеживать открытые ретрансляторы сервисы, получившие название “черные списки реального времени”, вместе с серверным ПО, блокирующим приходящую с известных источников спама почту, немного ослабили возможности ретрансляции, вынудив спамеров искать другие методы распространения почтового мусора.

Но к их счастью, популяризация широкополосного доступа и слабая защита конечных узлов открыли им дорогу к сотням тысяч постоянно действующих компьютеров, подключенных к Интернету по высокоскоростным соединениям. Используя уязвимости в системе сетевой защиты (обычно путем инфицирования домашних ПК “троянами” или вирусами), спамеры инсталлируют на домашние компьютеры ПО ретрансляции e-mail, превращая их в почтовые серверы открытой ретрансляции. Чтобы противостоять спамерам, Интернет-провайдеры начали заносить в “черные списки” IP-адреса из пулов DHCP других Интернет-провайдеров, поскольку почту следует ретранслировать, задействуя лишь свои SMTP-серверы исходящей почты. Однако, зная, что Интернет-провайдеры не смогут заблокировать SMTP-серверы без полной остановки службы e-mail, спамеры усовершенствовали ПО ретрансляции таким образом, чтобы почта доставлялась на исходящие SMTP-серверы своих Интернет-провайдеров.

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

Аутентифицируйтесь!

Технологии аутентификации отправителей e-mail нацелены на дальнейшее сокращение потоков спама. На рассмотрение Инженерной группы по развитию Интернета (Internet Engineering Task Force — IETF) в свое время были представлены разнообразные предварительные версии таких технологий; наиболее интересными из них являются SPF (Sender Policy Framework), Sender ID и DKIM (Domain Keys Identified Mail). В 2003 г. производитель специализированных e-mail-устройств — компания IronPort опубликовала информацию еще по одной технологии аутентификации e-mail — SMTPi, правда, сегодня эти сведения можно найти лишь посредством поисковых машин в Web-архивах.

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

В дополнение к вышесказанному отметим, что службы репутации отправителей, в том числе Bonded Sender Program компании Return Path и одноименный сервис компании Habeas, способны для каждого почтового домена рассчитать вероятность распространения спама. По мере расширения использования технологии аутентификации отправителей e-mail эти сервисы будут оценивать репутацию доменов все точнее, позволяя ПО фильтрации делать более обоснованные выводы о принадлежности тех или иных сообщений к спаму.

Что такое SPF?

Специально формируемые службой DNS текстовые записи SPF, сообщающие другим почтовым серверам о том, с каких почтовых серверов вы разрешаете отправлять исходящие сообщения e-mail, являются чем-то вроде записей “reverse MX”. В записи SPF также указывается уровень доверия, позволяющий принимающей почтовой системе определять аутентичность принимаемых сообщений.

Вам ничего не стоит позволить принимающим серверам e-mail читать ваши SPF-записи. Однако, чтобы заставить ваш сервер принимать к рассмотрению SPF-записи других серверов, вам придется модифицировать ваше ПО электронной почты. Технологию SPF поддерживают ПО безопасности e-mail, противоспамные устройства и обычное ПО MTA (Message Transfer Agent), но, для того чтобы они смогли корректно обрабатывать информацию SPF, настраивать их придется очень тщательно. Если ваш шлюз SMTP не поддерживает SPF, то вам необходимо приобрести новый: согласно исследованиям компании Forrester, от 25 до 30% всех доменов e-mail публикуют записи SPF, и это свидетельствует о том, что данная технология аутентификации отправителей e-mail является сегодня самой популярной.

SPF позволяет проверить, действительно ли отправителю (envelope sender), чей адрес указан в поле “from” протокола SMTP, разрешено посылать сообщения с данного передающего сервера. Например, серверы исходящей почты домена AOL ни при каких обстоятельствах не должны передавать сообщения с адресами отправителей домена Hotmail. Когда поддерживающий SPF принимающий сервер e-mail получает такое сообщение, он “просматривает” запись SPF для Hotmail и определяет, что передающему серверу AOL не разрешено отправлять e-mail от имени почтового сервера Hotmail. Основываясь на значении уровня доверия, возвращаемом службой DNS Hotmail в ответ на SPF-запрос, принимающая e-mail-система может предпринимать соответствующие действия.

Все записи SPF начинаются со строки инициализации v=spf1, что является признаком записи SPF. Сразу же после этой строки приводится список авторизованных передающих серверов e-mail. SPF поддерживает такие ключевые слова, как ptr, оно определяет все хосты, доменные имена которых заканчиваются именем проверяемого домена, и mx, определяющее все хосты MX (список разрешенных ключевых слов приводится по адресу: www.open spf.org/mechanisms.html). Эти ключевые слова помогают администраторам, автоматически добавляя в запись соответствующие хосты.

Последний компонент записи SPF определяет уровень доверия (fail — отправитель сообщения подделан, сообщение может быть отвергнуто; softfail — сообщение не соответствует жестким критериям аутентичности отправителя, но нельзя быть уверенным, что адрес отправителя подделан; pass — отправитель сообщения не подделан, сообщение может быть пропущено; neutral — недостаточно информации, чтобы оценить сообщение; серверу следует принять сообщение, но назначить дополнительную проверку другими средствами), обеспечивающий принимающий сервер e-mail ценной информацией для принятия решения.

Записи SPF публикуются не только поставщиками услуг e-mail, включая AOL, Hotmail и RoadRunner, но и крупными компаниями, подобными Bank of America, eBay и Ticketmaster. Ticketmaster возвращает любому проверяющему ее записи SPF лицу значение уровня доверия fail, AOL — neutral, а все другие — softfail.

Можно просмотреть записи SPF, используя инструментальные средства генерации запросов DNS и определяя тип записей ресурсов как TXT. SPF-запись Bank of America выглядит следующим образом:

$ host -t txt bankofamerica.com

bankofamerica.com

text ”v=spf1 a:sfmx02.bankofamerica.com a:sfmx04.bankofamerica.com a:vamx04.bankofamerica.com

a:vamx02.bankofamerica.com a:txmx02.bankofamerica.com

a:txmx04. bankofamerica.com a:cr-mailgw.bankofamerica.com

a:cw-mailgw.bankofamerica.com ~all”

Преимущества технологии SPF очевидны: вы просто добавляете записи в DNS, чтобы другие почтовые службы могли проверить ваши данные SPF; вероятно, усовершенствуете свое ПО MTA, наделив его функциями поддержки SPF, и отныне можете использовать записи SPF других провайдеров e-mail с целью нейтрализации распространенных технологий рассылки спамерских сообщений с некорректными адресами отправителей с некорректных серверов SMTP.

Хотя мы призываем всех сконфигурировать записи SPF для своих почтовых доменов (в конце концов, вы ничего не теряете), эта технология все же имеет свои ограничения. Самое важное из них — недостаточно эффективное подавление фишинга, обусловленное проверкой адреса отправителя (envelope return address), а не адреса, указанного в поле “from”, который пользователи видят в окне своего почтового клиента. Таким образом, при фишинге спамер сможет легко обойти SPF, используя корректный адрес в поле “from” конверта и корректный исходящий сервер e-mail, обманув при этом пользователя ложными контентами и адресами “from”, отображаемыми в окне почтового клиента.

Кроме того, SPF является проблемой для мобильных пользователей, которые, меняя Интернет-провайдеров, вынуждены менять и используемые ими исходящие серверы SMTP. В таком случае адреса отправителей (envelope sender) уже не будут соответствовать записям SPF их основных Интернет-провайдеров и передача сообщений e-mail заблокируется. С этой проблемой можно справиться, реализовав функцию SMTP AUTH (в любом случае это неплохая идея), позволяющую пользователям аутентифицироваться на серверах SMTP под своими учетными именами и паролями. Вдобавок SPF создает проблемы для таких университетских сервисов переадресации e-mail, как alumni accounts (учетные записи выпускников колледжей и университетов). Чтобы эти сервисы эффективно функционировали, Интернет-провайдеры должны использовать метод переадресации почты (remailing), состоящий в замене исходного адреса отправителя SMTP (envelope sender) новым адресом.

• На Web-странице www.openspf.org/ находится программа-мастер, которая поможет вашей организации сформировать записи SPF. На ноябрь 2005 г. были опубликованы SPF-записи более 1,7 млн доменов. Описание предварительной версии спецификации SPF IETF находится по адресу www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt.

Sender ID

Обратносовместимое расширение технологии SPF — Sender ID является методом аутентификации отправителей e-mail, поддерживаемым Microsoft и реализованным в сервисах Hotmail и MSN. Эти сервисы отображают результаты проверки Sender ID в окнах своих почтовых Web-интерфейсов. Ранее называвшаяся Caller ID технология Sender ID использует те же самые TXT-записи ресурсов DNS, что и SPF. Основное различие между SPF и Sender ID состоит в том, что последняя проверяет адреса “from”, содержащиеся в теле сообщения e-mail, а не только адреса отправителя уровня SMTP (envelope sender).

Как следствие, технология Sender ID подавляет фишинг более эффективно, чем SPF, поскольку проверяет адреса “from”, которые пользователи видят в окнах своих e-mail-клиентов. Начать использовать Sender ID так же просто, как и SPF: все, что вам нужно,— это добавить записи в DNS, дав возможность другим просматривать их. Однако, как и SPF, Sender ID нарушает функционирование университетских служб переадресации e-mail и создает неудобства для мобильных пользователей, использующих различные серверы SMTP.

Но самая крупная проблема Sender ID связана с бесплатным лицензионным соглашением Royalty-Free Sender ID Patent License Agreement компании Microsoft. Ряд организаций, в том числе и Apache Software Foundation, AOL, Free Software Foundation (FSF) и Open Source Initiative (OSI), выразили недовольство комитету IETF по поводу содержащихся в соглашении формулировок, что, очевидно, замедлило темпы внедрения технологии Sender ID. В этих организациях считают, что ни одной компании не следует предоставлять право интеллектуальной собственности на столь фундаментальные спецификации, лежащие в основе сети Интернет. Microsoft и поставщики ПО с открытым исходным кодом, похоже, погрязли в таких терминах, как “непередаваемый”, “не подлежащий сублицензированию”, и в формулировках, которые при смене торговой марки или редистрибуции технологии Sender ID заставляют конкурентов контактировать с Microsoft, предоставляя этому софтверному гиганту прекрасную возможность завладевать чужими коммерческими секретами.

Мы рекомендуем вам внедрить SPF и подождать, когда решатся разногласия по патентной лицензии Microsoft. Как SPF, так и Sender ID являются предварительными спецификациями IETF, однако мы считаем, что внедрение SPF идет более быстрыми темпами, и поэтому уверены в том, что первым стандартом IETF станет технология SPF.

• Описание технологии Sender ID можно найти в Интернете по адресу www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx. Предварительные спецификации технологии Sender ID комитета IETF тоже находятся в Интернете по адресу www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01 и www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.

Как насчет DKIM?

Спецификация Domain Keys компании Yahoo была объединена с аналогичной спецификацией, разработанной компанией Cisco Systems под названием Internet Identified Mail, и в настоящее время называется DKIM. Две эти компании объявили о своем сотрудничестве в данной области в середине 2005 г., представив на рассмотрение комитета IETF обновленную документацию, поддерживаемую по меньшей мере десятком организаций. В основе предложенного ими метода аутентификации отправителей e-mail лежит подписывание исходящих сообщений посредством секретного ключа. Принимающие серверы e-mail “удостоверяются” в том, что почтовое сообщение отправлено с известной системы-источника посредством открытых ключей, предоставляемых сервером DNS, и, кроме того, в отличие от SPF и Sender ID проверяют целостность сообщений. Спецификация DKIM еще не является стандартом.

Конфигурирование почтовой инфраструктуры DKIM является более сложным делом, чем настройка SPF и Sender ID. Так как исходящую почту необходимо снабжать цифровой подписью, то ПО исходящего почтового сервера должно быть модифицировано таким образом, чтобы могло выполнять необходимые вычисления и изменения сообщений. Как и в случае с SPF и Sender ID, если вы хотите проверять подлинность сообщений DKIM, вам придется модифицировать также принимающую e-mail-систему. Имеются версии ПО DKIM для многих популярных MTA. Для использования DKIM вам придется обновить ПО своего почтового сервера.

Чтобы обеспечить подписывание исходящих сообщений e-mail, необходимо инсталлировать поддерживающее DKIM ПО исходящей почты (ваше текущее ПО может поддерживать DKIM после осуществления неких модификаций). Кроме того, ставить цифровую подпись под сообщением e-mail можно после того, как будет сгенерирована пара “открытый ключ — секретный ключ”. Открытый ключ вносится в запись TXT ресурсов политики субдомена domainkey. Компания Yahoo использует политику подписывания сообщений, называющуюся s1024, поэтому ее открытый ключ можно найти по адресу s1024._domainkey.yahoomail.com. Секретный же ключ загружается поддерживающим DKIM почтовым ПО и “привязывается” к политике, позволяя, таким образом, ставить цифровую подпись под сообщением e-mail.

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

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=o3PMxZIlFKjVfLJUugi1uubwjHnE0IIu1tsDG/ c6SwXYfW842s1df01fR+UF0QmnVhVCaTa3x NiGZZeqSITw6oLLNv5zvdCqd6BrkkkuucPPxvTV/ VuM9Uhw5R9bNU50Fg+B89/ RmkciPJkluHEX+RLaZ3d/P1adg+edL1Pwxbo= ;

По достижении сообщением принимающей почтовой системы DKIM последняя может задействовать данный заголовок для проверки подлинности этого сообщения. Используя содержащуюся в разделе DomainKey-Signature информацию, принимающий сервер сначала считывает с сервера DNS открытый ключ, а затем записи ресурса TXT для политики s1024._domainkey.yahoo.com.

Применяя найденный на сервере DNS открытый ключ, корректный алгоритм (a=) и конкретные заголовки (h=), найденные в сообщении e-mail, принимающая система может сгенерировать цифровую подпись и сравнить ее с полученной. Это позволяет принимающей системе убедиться в том, что отправка сообщения e-mail была разрешена и оно действительно было послано с передающей системы, адрес которой указан в письме. Если цифровая подпись является подлинной, то принимающая система может доставить сообщение пользователю, в противном случае она сбросит его, отклонит или отправит в карантин.

Чтобы пресечь спам и фишинг, принимающие серверы e-mail способны создавать политики, запрещающие передачу сообщений от поставщиков почтовых услуг, заведомо поддерживающих технологию DKIM, без заголовков DKIM. Если принимается лишенное заголовка DKIM сообщение e-mail, адрес “from” которого указывает на компанию Yahoo, использующую технологию DKIM, то это сообщение можно совершенно безболезненно сбросить или удалить. Технологию DKIM задействуют многие крупные поставщики почтовых услуг, включая Yahoo и Google.

Основным недостатком технологии DKIM является то, что она требует использования поддерживающих ее серверов как для исходящей, так и для входящей почты. Эта технология изначально устраняет проблему переадресации сообщений, присущую технологиям SPF и Sender ID и позволяющую спамерам продолжать распространять нежелательные сообщения. Однако спамер может послать одно сообщение через сервер DKIM, а затем переадресовать его или повторно передать другим пользователям. И хотя это сообщение будет, по всей видимости, иметь подлинную подпись, прибудет-то оно с сомнительного сервера-источника, а это обуславливает необходимость дальнейшего усовершенствования входящих почтовых серверов с целью более надежного выявления подделок такого рода.

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

Принцип работы технологии DKIM описан в документе, находящемся в Интернете по адресу antispam.yahoo.com/domainkeys. Черновики этого стандарта можно найти по следующим адресам: www.ietf.org/internet-drafts/draft-allman-dkim-base-01.txt, www.ietf.org/internet-drafts/draft-allman-dkim-ssp-01.txt и www.ietf.org/internet-drafts/draft-delany-domainkeys-base-03.txt..





  
10 '2006
СОДЕРЖАНИЕ

инфраструктура

• Коммутаторы для центров обработки данных

• Организация подходящей сетевой инфраструктуры для RFID

• Тестируем корпоративные продукты wiki

• Лучшие экспонаты выставки Interop Las Vegas 2006

• NAS для масс

информационные системы

• Дорожная карта Unix

• Спецификации и стандарты Web-сервисов

• ESB как становой хребет SOA

сети связи

• IMS для корпоративных пользователей

кабельные системы

• Многомодовое «меню»

• Заземление в центрах обработки данных

• Аутентификация отправителей e-mail и борьба со спамом

защита данных

• Азы протокола WPA2

• Настройка групповой политики в Active Directory

новые продукты

• Новые мощные серверы компании R-Style Computers


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх