Технология DKIM на страже вашей почты
DKIM-сигнатуры за последнее десятилетие смогли прочно укорениться в обширном списке средств для борьбы со спамом. Несмотря на то, что многим пользователям почтовых сервисов термин DKIM совсем не знаком, именно эта система «за кулисами» уберегает наши почтовые ящики от многих видов нежелательной почты, а также защищает часть мирового почтового трафика от ложного попадания в категорию «спам».
В этой статье мы рассмотрим устройство DKIM на фоне его стремительного развития с момента зарождения и до нынешних дней, выявим основные преимущества и недостатки этой технологии, а также исследуем типичные спамерские приемы по подделке DKIM-сигнатур.
Концепция DKIM Технология DKIM (DomainKeys Identified Mail) обеспечивает верификацию отправителя и гарантию целостности доставленного электронного сообщения. Подтверждение пользователя происходит на основе электронной подписи письма, создаваемой с применением асимметричной криптографии. Данная подпись добавляется в служебные заголовки письма и передается незаметно для конечного пользователя.
Проверка DKIM-подписи происходит автоматически на стороне получателя, основывается она на данных из DKIM-заголовка и публичного ключа шифрования, полученного с DNS домена отправителя. Если указанный домен не был авторизован для рассылки полученного сообщения, то письмо может быть помечено подозрительным на спам или фишинг, в зависимости от политики получателя. К письмам, успешно прошедшим DKIM-проверку, почтовые клиенты относятся более лояльно, чем к тем, которые ее не прошли. В то же время, электронные сообщения, не содержавшие DKIM-заголовков как таковых, обрабатываются в стандартном режиме.
История DKIM История DKIM начинается в 2003 году с самостоятельной разработки технологии DomainKeys (прародитель DKIM) Марка Делани (Mark Delany) в рамках его работы в Yahoo. Уже через два года Yahoo получает патент на DomainKeys, и целый ряд крупнейших вендоров начинают совместно составлять первую рекомендательную версию стандарта.
Параллельно с развитием технологии DomainKeys в 2003–2007 годах компания Cisco запускает свой проект «Identified Internet Mail» (IIM), основанный на схожей идее аутентификации по сигнатуре письма.
В 2007 IETF публикует стандарт DomainKeys RFC 4870 (уже объявленный устаревшим на тот момент) и первый стандарт DKIM RFC 4871. Далее стандарт DKIM серьезно уточняется и обновляется в 2009 (RFC 5672). В 2011 IETF решает объединить спецификации IIM и DKIM в финальный стандарт RFC 6376.
Несмотря на публикацию нового стандарта, многие компании в 2012 году все еще использовали устаревшую версию стандарта от 2007 года, что породило ряд интересных исследований уязвимостей DKIM, о которых мы упомянем ниже.
Принцип работы DKIM основывается на стандартном асинхронном шифровании.
5 основных этапов работы DKIM: Для каждого сервера генерируется пара (или несколько пар) из закрытого и открытого ключей шифрования. Закрытый ключ помещается на сервере отправителя и используется для создания соответствующих DKIM-заголовков для всей исходящей почты клиента. Открытый ключ помещается владельцем домена в его файл DNS-зоны в виде специальной TXT-записи, и она становится доступна для всех желающих. Письмо с DKIM-подписью пересылается получателю (см. ниже). С помощью полученного с DNS-сервера открытого ключа проверяется подлинность отправителя письма. Пересылка письма с DKIM-подписью Отправка письма.Пользователь отправляет письмо, и оно принимается почтовым сервером отправителя. Создание подписи.Почтовый сервер добавляет новый заголовок «DKIM-Signature». Заголовок содержит подпись, составленную на основе закрытого ключа шифрования, тела письма, его заголовков, текущего времени, и других параметров. Пересылка подписанного письма.Письмо с новым заголовком «DKIM-Signature» пересылается получателю. Прием письма — валидация.Почтовый клиент получателя письма анализирует DKIM-заголовок и на основе публичного ключа выносит вердикт — признаются ли отправитель и письмо подлинными. Валидация DKIM-заголовка Последний этап — валидация письма — представляет особый интерес.Основные этапы:
Отправка DNS запроса.Почтовый клиент/сервис делает DNS запрос, содержащий доменное имя, с которого предположительно было отправлено письмо.
Получение публичного ключа шифрования.Из тела ответа DNS-сервера выбирается соответствующая TXT-запись, содержащая публичный ключ шифрования.
Анализ DKIM-заголовка:
Каждый тег внутри заголовка дешифруется из Base64 в текстовое представление.
Каждая полученная строка дешифруется с использованием ранее полученного публичного ключа.
Вынесение вердикта.Последним этапом является сравнение текста и заголовков письма с дешифрованной информацией из заголовка DKIM. При любом найденном несоответствии выносится вердикт dkim=fail, а если содержимое совпадает — dkim=pass.
Структура DKIM-заголовка
Типичный заголовок DKIM-Signature состоит из списка тегов вида «тег=значение». Имена тегов короткие и в большинстве случаев состоят из 1–2 символов.
Пример:
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=foursquare.com; h=from: to: subject: mime-version: content-type; s=smtpapi; bh=9UsnWtzRLBWT7hnQc8V2RF4Ua4M=; b=IgnW7QsK2LBp0VQJ4FJcLv9MmHBvD 2Ch6jPxQ/Hkz+TX2WXyWkGbScx4gbZeWj3trqN4LUVvTf2U+htG4Wsg6sQAKqvnC neTeDvcmm225CKji0+MSXL8VK6ble8mkk14EAwWDP8+DJMwL2f7v/wp6QEdd7jqY q/fX+TY5ChIYHQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=foursquare.com; h=from: to: subject: mime-version: content-type; s=smtpapi; bh=9UsnWtzRLBWT7hnQc8V2RF4Ua4M=; b=IgnW7QsK2LBp0VQJ4FJcLv9MmHBvD 2Ch6jPxQ/Hkz+TX2WXyWkGbScx4gbZeWj3trqN4LUVvTf2U+htG4Wsg6sQAKqvnC neTeDvcmm225CKji0+MSXL8VK6ble8mkk14EAwWDP8+DJMwL2f7v/wp6QEdd7jqY q/fX+TY5ChIYHQ= Теги и их описания Основные теги:
Тег Описание тега b содержимое письма (тело + заголовки, закодировано в Base64) bh хэш канонизированного тела письма (также в Base64) d доменное имя отправителя, проставившего подпись h список подписанных заголовков Дополнительные теги:
Тег Описание тега a основной алгоритм для генерации сигнатуры v версия системы s селектор для разделения пространства имен для «d=» тега c алгоритм для приведения тела письма и заголовков к каноническому виду q список алгоритмов для получения публичного ключа x время истечения сигнатуры i подпись клиента, проставившего DKIM-подпись (в quoted-printable) l размер тела письма в количестве октетов, включенных в криптографический хэш t таймстамп проставленной сигнатуры z копии заголовков на момент проставления сигнатуры Основные методы атак на DKIM Простейшие атаки Первые попытки использования DKIM спамерами мы наблюдали еще в далеком 2009 году. В основном, они сводились к добавлению заголовков, содержимое которых только отдаленно походило на валидный DKIM. Очень мало внимания спамеры уделяли корректности самой подписи, что порождало весьма интересные случаи.
К примеру, в этой рассылке спамеры используют один и тот же заголовок для всех писем в рассылке (настоящий DKIM-заголовок должен быть всегда разным для отличных писем, так как он основывается на теле письма, времени и прочих уникальных факторах).
Подделка тегов На других образцах мы видим, что спамеры скопировали DKIM-подпись от стороннего легитимного сайта и от письма к письму в рассылке меняют содержимое лишь одного из DKIM-тегов в заголовке, забывая, что другие теги также зависят от контента письма и тоже должны измениться.
Похожие ошибки систематически допускались спамерами в прошедшие годы.
Наиболее популярными из них были:
Спамеры корректно генерируют «b»-тег, отвечающий за описание тела письма, но забывают про «bh»-тег (хэш от тела). Домен, указанный в теге «d», не соответствует адресанту и вообще никак не связан с письмом. Указана некорректная временная отметка («t»-тег), которая относится к дате в далеком прошлом. Легитимные DKIM в спаме Спамеры, как и обычные системные администраторы, способны настроить почтовые серверы и домены, которыми они владеют, для генерации легитимных DKIM-заголовков. Несмотря на это, до последнего времени корректные DKIM-заголовки были весьма редки в спаме.
Во многом это связано с трудоемкостью настройки серверной части DKIM для генерации валидных сигнатур. Однако со временем на порядки увеличилось количество доменов, участвующих в рассылке, что в итоге сделало атаки на DKIM более эффективными. И спамерам пришлось научиться более умело оперировать DNS-записями своих множественных доменов.
В примере ниже мы видим идеально сгенерированную DKIM-сигнатуру и корректную TXT-запись домена, которые вместе приводят к вердикту «dkim=pass».
Такая дополнительная работа для спамеров вполне оправдана — многие почтовые сервисы относятся более лояльно к письмам с корректными DKIM-сигнатурами, и у спамерской рассылки в итоге имеется больше шансов оказаться не заблокированной фильтрами и попасть в почту пользователя.
Наш продукт Kaspersky Security for Linux Mail Server, помимо простых проверок на наличие вердикта «DKIM=fail» в заголовках письма, отлавливает также письма, где использованы все перечисленные спамерские приемы, и либо помечает их спамом, либо повышает спамерский вес письма.
Уязвимости и недостатки DKIM DKIM не дает никаких гарантий. Основываться только на DKIM неоправданно, так как: а) Спамеры, как и обычные пользователи, вполне способны корректно настроить работу DKIM на своем собственном домене.b) Возможны ситуации, когда часть писем от домена приходит без DKIM-заголовка. Например, при использовании одним доменом нескольких почтовых серверов с различными настройками, или при других сценариях.
По этим причинам стандарт советует никак не «наказывать» письма без DKIM-сигнатур.
Неустойчивость к изменению структуры письма. DKIM-сигнатура перестает быть валидной даже при небольших изменениях в порядке заголовков сообщения, при добавлении новых заголовков или любых минорных изменениях текста заголовков. Такие добавления/изменения весьма часто происходят при обработке письма серверами-пересыльщиками на пути к адресату и считаются нормальными.
Уязвимость коротких ключей шифрования. Согласно исследованию Зака Харриса (Zach Harris), опубликованному в Wired в октябре 2012, все DKIM-сигнатуры, подписанные с помощью закрытых ключей длиной менее 1024 бит, являются уязвимыми. Более того, аутентификацию с использованием 384-битных ключей Харрису удалось взломать всего лишь за сутки средствами своего ноутбука. С другими требованиями к DKIM можно ознакомиться в нашей публикации в блоге, посвященной этой новости.
Весьма интересно, что это исследование позволило Харрису в 2012 отправить сообщения Ларри Пейджу и Сергею Брину, подделав DKIM-заголовки и оформив письма как их личную переписку друг с другом.
Недавно многие компании, в том числе Google и Microsoft, начали активную популяризацию отказа от шифрования с использованием коротких ключей. Несмотря на это, в мире по-прежнему остаются многочисленные почтовые серверы, подписывающие DKIM с использованием ключей шифрования некриптостойкой длины.
Преимущества DKIM Корректно составленная DKIM-сигнатура подтверждает, что данное письмо было отправлено с указанного домена. DKIM является мощным средством построения репутации для доменов на основе множества писем, полученных в течение некоторого времени (чем активно пользуются различные антиспам-решения, а также участники DKIM reputation project). Использование DKIM дает еще один признак, по которому на стороне пользователя можно принять решение — доверять отправителю письма или нет. Как использовать DKIM? DKIM используется комплексно вместе с другими технологиями репутационного анализа почты. В то время как большинство современных сервисов электронной почты и почтового ПО уже поддерживают проверку легитимности DKIM, при использовании своего домена или при установке собственного почтового сервера полезно убедиться, что DKIM настроен корректно.
Установка DKIM для корпоративной почты Многие онлайн сервисы корпоративной почты поддерживают установку DKIM в несколько кликов, однако от администратора потребуется вручную отредактировать файл DNS зоны домена и добавить соответствующие TXT-записи.
Например, так выглядит процесс активации DKIM-сигнатур для сервиса Gmail for Work.
Открыть панель администратора своего домена по адресу https://admin.google.com
Выбрать пункт меню Приложения (Apps).
Далее выбрать Gmail из списка приложений.
Подтвердить намерение активировать Email-аутентификацию и выбрать пункт «Generate new record».
Сервис сгенерирует содержимое новой TXT-записи, которое нужно поместить в файл DNS зоны вашего домена. Для этого откройте панель управления доменом, найдите раздел ручного управления зоной, создайте новую запись типа TXT, и скопируйте в нее значения, предоставленные сервисом Gmail. Итоговое содержимое записи зоны должно выглядеть, например, так:
google._domainkey IN TXT v=DKIM1; k=rsa; p=(сгенерированный публичный ключ)
Дополнительным этапом можно создать еще одну TXT-запись для поддержки политики SPF. Для сервиса Gmail for Work она выглядит так: @ IN TXT v=spf1 include:_spf.google.com ~all
Данная запись авторизует почтовые серверы Google отсылать почту с вашего доменного имени и в результате обратная верификация на стороне получателя будет приводит к вердикту spf=pass.
Вскоре после выполнения всех действий (часто уже через 20 минут, но может занимать до 48 часов), письма отправленные с вашего домена станут помечаться флагом dkim=pass и spf=pass, подтверждая легитимность отправителя.
Если у вас возникли проблемы при настройке, то могут оказаться полезными инструкции от Google Apps по настройке DKIM, а также по созданию SPF записи. Для описания процедуры редактирования файла зоны своего домена обращайтесь к документации вашего регистратора.
Установка DKIM на собственный почтовый сервер Процесс установки DKIM на своем почтовом сервере является менее тривиальным. Мы приведем краткое описание настройки DKIM для почтового агента Postfix на сервере с дистрибутивом семейства Debian. Установка DKIM для других почтовых клиентов и ОС производится аналогично. Для деталей обращайтесь к документации интересующего почтового клиента, а также к информации на сайте проекта OpenDKIM.
Основные этапы:
Установите Postfix MTA и следующие пакеты OpenDKIM из официальных репозиториев, в зависимости от своего дистрибутива postfix opendkim opendkim-tools
Сгенерируйте приватный ключ для создания DKIM-сигнатур. Для этого вам понадобится указать свое доменное имя и селектор, который можно выбрать произвольно (используется далее). $ opendkim-genkey -r -s selector -d yourdomain.com
Поместите сгенерированный ключ в произвольный файл в любой директории с ограниченным доступом на сервере и укажите путь до файла в конфигурационном файле ниже.
Скопируйте пример конфигурационного файла из файла /etc/opendkim/opendkim.conf.sample в /etc/opendkim/opendkim.conf и отредактируйте следующие опции, в зависимости от вашего домена и выбранного селектора: /etc/opendkim/opendkim.conf Domain yourdomain.com KeyFile /path/to/the/key Selector selector Socket inet:8891@localhost UserID opendkim
Создайте новую TXT-запись в файле DNS зоны вашего домена (также смотрите примеры настройки зоны для Gmail for Work выше). Не забудьте указать значение селектора, выбранного на предыдущих шагах. Запись должна иметь вид: selector._domainkey IN TXT v=DKIM1; k=rsa; p=…
Проверить корректность TXT-записи домена можно простым запросом утилитой host:
host -t TXT selector._domainkey.yourdomain.com
Однако имейте в виду, что TXT-запись может не обновляться до нескольких часов из-за кэширования данных вашим DNS-провайдером.
Последним этапом является интеграция opendkim в Postfix. Для этого отредактируйте конфигурационный файл /etc/postfix/main.cf и добавьте в него следующие данные: /etc/postfix/main.cf smtpd_milters = inet: localhost:8891 non_smtpd_milters = inet: localhost:8891
После этого установка завершена и достаточно запустить сервис opendkim. sudo service opendkim start
Отображение проверки DKIM Большинство публичных почтовых сервисов поддерживают DKIM-сигнатуры, проверяют их корректность незаметно для пользователя и используют полученные вердикты для собственных систем борьбы со спамом.
Некоторые сервисы стараются сделать DKIM-проверку более наглядной и помечают письма, успешно прошедшие валидацию DKIM-сигнатуры.
Например, в сервисе Gmail письма с подтвержденным отправителем, успешно прошедшие ряд проверок на отправителя, помечаются знаком защищенного соединения:
Включить поддержку этой функции можно в Настройки (Settings)→ Лаборатория (Labs)→ «Значок проверенного сообщения» (Authentication icon for verified senders).
Сервис Yandex.Mail по умолчанию поддерживает отображение наличия цифровой подписи у письма в виде иконки 
рядом с именем домена.
Альтернативы DKIM Технология DKIM имеет различных конкурентов и стала основой для других решений для аутентификации отправителя.
Sender Policy Framework (SPF) SPF также использует DNS для хранения информации и служит средством подтверждения подлинности домена отправителя. В отличие от DKIM, в случае SPF в DNS хранится не публичный ключ, а список серверов, с которых разрешена отправка email-сообщений. В итоге, SPF позволяет подтвердить подлинность лишь домена, но не текста или заголовков сообщения.
Тем не менее, технология SPF более распространена, чем DKIM, и поддерживается подавляющим большинством email-клиентов и почтовых сервисов.
Pretty Good Privacy (PGP) PGP является самым популярным алгоритмом для шифрования email-сообщений в мире и позволяет шифровать все сообщение целиком, при условии, что обе стороны заранее сгенерируют закрытые и открытые ключи и обменяются открытыми ключами. Несмотря на схожесть в реализации, DKIM не пытается соперничать с PGP, а является лишь надстройкой над обычной концепцией email-сообщений с возможностью валидации отправителя.
Domain-based Message Authentication, Reporting and Conformance (DMARC). DMARC является относительно свежим методом аутентификации, который сочетает в себе как технологию SPF, так и DKIM. Система была впервые представлена в 2011 году, и многие крупнейшие вендоры на рынке проявили желание ее использовать. В 2013 технология DMARC уже защищала более половины почтовых ящиков в мире, все еще не являясь официальным стандартом, что в очередной раз доказывает успешность технологии DKIM, которая лежит в основе DMARC.
Полный текст статьи читайте на Лаборатория Касперского
