Современные системы аутентификации отправителя: SIDF и DKIM

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

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

SIDF

Разработанная Microsoft технология аутентификации Sender ID Framework (SIDF) требует публикации в DNS так называемых SPF-записей. SPF-запись вносится интернет-провайдером или владельцем домена в свой файл зон DNS-сервера и представляет собой текстовую запись всех IP-адресов серверов исходящей почты с указанием домена.

Принимающий сообщение SMTP-сервер запрашивает наличие SPF-записи в соответствующем файле в DNS. При наличии записи производится проверка IP-адреса отправляющего сервера по списку авторизованных к рассылке IP-адресов. Механизм SIDF предусматривает проверку адреса отправителя не только на уровне SMTP, но и адресов, указанных в теле письма в строке «From» («Отправитель»). По окончании проверки письмо соответствующим образом помечается (сервисы Hotmail и MSN отражают результаты проверки в особом окне), и SIDF разрешает серверу получателя провести анализ сообщения на основе репутации, контента и прочих критериев, установленных местным регламентом.

Использование SIDF, по заверениям разработчиков, не требует изменения инфраструктуры, обновления программного обеспечения и не зависит от программного обеспечения клиента и сервера.

Как показала практика, внедрение данной технологии в корпоративный обиход требует постоянного внимания и активности, а при наличии обширной потенциальной клиентуры, не всегда обеспеченной поддержкой SIDF, приходится затрачивать определенные усилия на настройку бесперебойной работы корпоративного почтового сервера и сохранение легитимных писем, не прошедших проверку на подлинность отправителя. Кроме того, SIDF страдает от проблем с пересылкой сообщений и неудобна для пользователей мобильной связи, использующих различные SMTP-серверы. «Обкатка» SIDF показала, что ее использование обходится вовсе не так дешево, как изначально предполагалось, и затраты на техническую поддержку могут быть весьма значительными.

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

По оценке Microsoft, SIDF защиoftn более 8 миллионов доменов; технологию используют такие компании как Alt-N, Barracuda, Cloudmark, Exchange Hosted Filtering, Iconix Message Systems, Port25 Solutions, Secure Computing, Sendmail, Sonic Wall, Strongmail, Symantec и Tumbleweed. Тем не менее, по данным MediaPost, только 43% легитимной почты сертифицируется Sender ID, а open-source сообщество пока предпочитает обходиться собственными решениями.

DKIM

Технология DKIM, объединяющая спецификации Yahoo DomainKeys и Cisco Internet Identified Mail (IIM), не только обеспечивает верификацию отправителя, но и гарантирует целостность доставленного электронного послания. Механизм DKIM предусматривает сопровождение писем шифрованной цифровой подписью, добавляемой в служебный заголовок письма и невидимой конечному получателю.

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

Технология DomainKeys работает как стандартная криптосистема. Для каждого сервера генерируется одна или несколько пар ключей для асимметричного шифрования. Открытый ключ публикуется в DNS и вносится в запись txt-ресурса политики субдомена domainkey. Закрытый (приватный) ключ «привязан» к политике и загружается поддерживающим DKIM почтовым ПО.

В связи с возможностью модификации электронных сообщений в процессе пересылки они по мере необходимости преобразуются согласно требованиям SMTP-стандарта (7-бит MIME), то есть обретают форму, в которой и будут представлены адресату. Сервер-отправитель (или пользовательский почтовый агент) затем с помощью закрытого ключа генерирует шифрованную подпись, которая отражает информацию, взятую из заголовков письма. Во избежание злоупотреблений DKIM-подпись должна обязательно включать данные из читаемых адресатом полей From («От»), Sender («Отправитель»), Subject («Тема»), Date («Дата»), To («Кому»).

DKIM-подпись ставится отдельным заголовком к письму и предваряет все прочие заголовки. Заголовок DKIM может выглядеть следующим образом:

Поддерживающее DKIM ПО принимающей стороны удостоверяет легитимность шифрованной подписи, извлекает из нее имя домена и запрашивает открытый ключ и записи txt-ресурса у сервера DNS. С помощью считанного из DNS ключа система-реципиент генерирует DKIM-подпись и сравнивает ее с полученной, фиксируя результат. При подтверждении полномочий заявленного в письме отправителя письмо доставляется адресату в соответствии с местным регламентом; не прошедшая проверку корреспонденция сбрасывается, отклоняется или отправляется в карантин. Поскольку открытый ключ в любой момент может быть заменен или отозван отправителем, рекомендуется производить верификацию своевременно.

В отличие от Sender ID, DKIM при верификации отправителя опирается на имя домена, так как разработчики данной технологии считают, что оно стабильнее IP-адреса и точнее идентифицирует реального адресата. Эта технология исключает проблемы с переадресацией сообщений, присущие SIDF.

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

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

Процедура обновления ПО упрощается, если сервер уже поддерживает прототип DKIM – DomainKeys. В настоящее время разработаны DKIM-плагины для многих популярных MTA. DomainKeys успешно используется в почтовых сервисах Yahoo и Google (Gmail). Поддержка проверки отправителя по технологии DomainKeys имеется в SpamAssassin начиная с версии 3.1.

Спецификации DKIM предложены IETF к публичному обсуждению и оценке в качестве проекта стандарта аутентификации RFC 4871. Публикация формального проекта и его официальное утверждение, после которого можно будет стандартизировать новый заголовок в качестве расширения SMTP, будет способствовать более широкому внедрению данной технологии.

Аутентификация и проблема спама

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

Системы аутентификации осваивают не только легальные пользователи, но и спамеры. Компьютерные мошенники нередко прибегают к законной регистрации доменных имен, схожих с именами распространенных онлайн-сервисов (например, verify-paypal.com). Легальные организации, в свою очередь, могут просто не внести соответствующие записи и ключи в DNS и стать жертвами фальсификаторов. Рассылать спам могут и зомби-компьютеры – «подлинные» отправители, с точки зрения SIDF и DKIM. Тем не менее, возможность проследить нелегитимную рассылку до IP-адреса или домена позволяет принять надлежащие меры и повышает вероятность поимки ее инициаторов.

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

В принципе технологии SIDF и DKIM комплементарны и могут использоваться совместно. Создатель SPF Мен Вонг (Meng Wong) разработал проект сети Unified SPF, поддерживающей одну и более систем аутентификации отправителя в зависимости от настроек системного администратора. Вонг уверен, что разнообразие – это преимущество, а не предмет для войны стандартов.