Методы верификации отправителя почтового сообщения Алексей Тутубалин lexa@lexa.ru «Ашманов и Партнеры»

Август 28, 2022

Главная
Информатика
Методы верификации отправителя почтового сообщения Алексей Тутубалин lexa@lexa.ru «Ашманов и Партнеры»

Содержание

3. Электронная почта - анонимна Любой почтовый сервер может отсылать почту с произвольным адресом отправителя. Классические технологии
4. Что же изменилось ? Возможностью анонимной посылки почты сегодня пользуются: для рассылки спама; для рассылки вирусов;
5. Постановка задачи Если научиться проверять отправителя, то это может отсеять большую долю сегодняшнего спама. Требования к
6. Авторизация SMTP-соединения Авторизация «своего» пользователя: использование: корпоративная почта, ISP, почтовые сервисы; не решает проблему входящей извне
7. Верификация содержания письма Пользователь-пользователь: верификация электронной подписью (S/MIME, PGP-mail): требуется обмен ключами, это задача пользователей. нужна
8. Авторизация по IP-адресу отправителя На основании уже существующих данных (reverse resolving в DNS): Не требует изменения
9. Yahoo Domain Keys Идея метода: публикация в DNS публичного ключа домена текст и заголовки сообщения подписываются
10. YDK: технические детали Пример записи в DNS: beta._domainkey.gmail.com text = "t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4…” Заголовки в письме:
11. YDK: перспективы Подход перспективный, но есть проблемы: при поддержке YDK на публичном сервисе можно получить любое
12. SPF Classic Владелец домена публикует в DNS «политику» - список IP-адресов с которых может исходить почта
13. SPF: проблема пересылок Неустранимое противоречие «Мягкая» политика не помогает от фальсификации адресов Жесткая политика приводит к
14. SPF Classic: прочие проблемы Массовая PR-компания породила массовое внедрение со множеством ошибок. «Политики по-умолчанию». Уровень поддержки
15. SPF и спам По данным CipherTrust, спамеры освоили SPF быстрее «нормальных» систем. Распространенность SPF на сегодня
16. SPF как фильтр спама Статус fail (неверный отправитель) получают Статус pass – 0.4% Статус softfail (владелец
17. SPF как источник дополнительных данных для антиспам - фильтра Для фильтра SpamTest на большом потоке сообщений:
18. SPF: рекомендации Публикация SPF-политики полезна, во всяком случае ее не будут придумывать за вас. публикация «жесткой»
19. SPF: рекомендации (2) При приеме почты нельзя принимать решение только на основании SPF Если первое условие
20. CallerID, SenderID CallerID – технология Microsoft с похожими на SPF идеями. SenderID – объединение SPF Classic
21. Выводы Ожидать кардинального технического решения проблемы подделки отправителя не стоит. Частные решения возможны, например YDK может
23. Скачать презентацию

Слайд 2

Слайд 3

Электронная почта - анонимна
Любой почтовый сервер может отсылать почту с произвольным

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

Слайд 4

Что же изменилось ?
Возможностью анонимной посылки почты сегодня пользуются:
для рассылки спама;
для

рассылки вирусов;
для рассылки мошеннических писем.
Подавляющее большинство рассылок происходит с компьютеров пользователей («зомби-машины»)
Как правило, используется поддельный адрес отправителя.
Обычно в поддельном адресе используется существующий домен.

Слайд 5

Постановка задачи
Если научиться проверять отправителя, то это может отсеять большую долю

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

Слайд 6

Авторизация SMTP-соединения
Авторизация «своего» пользователя:
использование: корпоративная почта, ISP, почтовые сервисы;
не решает проблему

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

Слайд 7

Верификация содержания письма
Пользователь-пользователь: верификация электронной подписью (S/MIME, PGP-mail):
требуется обмен ключами, это

задача пользователей.
нужна поддержка в клиентских программах
ради разового обмена почтой никто не будет меняться ключами.
Сервер-сервер: Yahoo Domain Keys
публикация ключей и политики их использования в DNS
требуется модификация почтовых серверов как для простановки подписи, так и для её верификации.

Слайд 8

Авторизация по IP-адресу отправителя
На основании уже существующих данных (reverse resolving в

DNS):
Не требует изменения инфраструктуры, уже широко применяется.
Отсутствие достоверных данных о структуре чужих сетей ограничивает применимость.
Новые методы
дополнительные данные в обратной DNS-зоне (MTA Mark, Selective Sender, MX Out)
дополнительные данные в DNS домена отправителя (SPF Classic, CallerID, SenderID, RMX)

Слайд 9

Yahoo Domain Keys
Идея метода:
публикация в DNS публичного ключа домена
текст и заголовки

сообщения подписываются
на приемной стороне подпись проверяется
Достоинства
«достоверность» является свойством письма, а не почтовой сессии
Недостатки
при внедрении на публичном сервисе, можно получить любое нужное количество подписанных сообщений.

Слайд 10

YDK: технические детали
Пример записи в DNS:
beta._domainkey.gmail.com text = "t=y; k=rsa;

p=MIGfMA0GCSqGSIb3DQEBAQUAA4…”
Заголовки в письме:
DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from...
b=Gjon4OA2c8NfLCBauZskv99Eks....

Слайд 11

YDK: перспективы
Подход перспективный, но есть проблемы:
при поддержке YDK на публичном сервисе

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

Слайд 12

SPF Classic
Владелец домена публикует в DNS «политику» - список IP-адресов

с которых может исходить почта данного домена:
"v=spf1 +ip:192.168.0.0/16 +mx ?all“
Каждый элемент списка состоит из префикса и диапазона IP-адресов. Возможны такие префиксы:
+ pass - разрешающий префикс. +all почта «из данного домена» может приходить с любого адреса
- fail - запрещающий префикс. –ip:10.0.0.0/8 – почта не может приходить с этого адреса.
~ softfail «нейтрально-отрицательный» префикс. «Адрес может не быть разрешенным».
? neutral «нейтральный» - владелец адреса не может ничего сказать про данный IP.
В ходе SMTP-сессии реальный IP-адрес посылающей стороны сравнивается со списком от владельца домена, после чего принимается решение о статусе письма.

Слайд 13

SPF: проблема пересылок
Неустранимое противоречие
«Мягкая» политика не помогает от фальсификации адресов
Жесткая политика

приводит к потерям при пересылках (forward) писем: в процессе пересылки адрес отправителя сохраняется, а IP-адрес посылающей стороны – нет.
Для внедрения жестких SPF-политик требуется модификация ПО на почтовых серверах «третьих сторон».

Слайд 14

SPF Classic: прочие проблемы
Массовая PR-компания породила массовое внедрение со множеством ошибок.
«Политики

по-умолчанию». Уровень поддержки технологии невысок, поэтому существующие реализации технологии позволяют «придумать» политику домена если ее нет.
Потенциально-опасный механизм «exists» - отправитель письма может следить за его путем по вашей сети.
Спамеры уверенно осваивают SPF.

Слайд 15

SPF и спам
По данным CipherTrust, спамеры освоили SPF быстрее «нормальных» систем.
Распространенность

SPF на сегодня недостаточна, чтобы быть эффективным антиспам - средством.

Слайд 16

SPF как фильтр спама
Статус fail (неверный отправитель) получают <4% спам -писем.
Статус

pass – 0.4%
Статус softfail (владелец домена не уверен) – 5-8% спама и около 1% нормальной почты.
Уровень поддержки технологии вырос с 8% в июле до 13% в октябре.

Слайд 17

SPF как источник дополнительных данных для антиспам - фильтра
Для фильтра SpamTest

на большом потоке сообщений:
примерно для 0.5% сообщений статус SPF более «жесткий», чем результат работы Spamtest.
Примерно для 0.4% сообщений, статус более «мягкий» (доля совпадает с долей «pass» в потоке спама).
Вывод: польза от SPF сомнительна.

Слайд 18

SPF: рекомендации
Публикация SPF-политики полезна, во всяком случае ее не будут придумывать

за вас.
публикация «жесткой» политики будет приводить к потерям исходящей почты
публикация «мягкой» политики может привести к ее игнорированию получателями
Нужен нейтральный вариант, например:
+ip:10.0.0.0/24 ~all
+ip:192.168.0.0/24 ?all

Слайд 19

SPF: рекомендации (2)
При приеме почты нельзя принимать решение только на основании

SPF
Если первое условие соблюдено, то SPF может быть полезным источником данных для антиспам-системы.
К несчастью, основные публично-доступные реализации SPF не удовлетворяют условию 1 (исключение: SpamAssassin)

Слайд 20

CallerID, SenderID
CallerID – технология Microsoft с похожими на SPF идеями.
SenderID –

объединение SPF Classic и CallerID:
Базовые идеи от SPF
Синтаксис от CallerID
Методика определения адреса отправителя – от CallerID
SenderID не был поддержан IETF и сообществом OpenSource, перспективы туманны.

Слайд 21

Выводы
Ожидать кардинального технического решения проблемы подделки отправителя не стоит.
Частные решения возможны,

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

Методы верификации отправителя почтового сообщения Алексей Тутубалин lexa@lexa.ru «Ашманов и Партнеры»

Содержание

Электронная почта - анонимнаЛюбой почтовый сервер может отсылать почту с произвольным

Что же изменилось ?Возможностью анонимной посылки почты сегодня пользуются:для рассылки спама;для

Постановка задачиЕсли научиться проверять отправителя, то это может отсеять большую долю

Авторизация SMTP-соединенияАвторизация «своего» пользователя:использование: корпоративная почта, ISP, почтовые сервисы;не решает проблему

Верификация содержания письмаПользователь-пользователь: верификация электронной подписью (S/MIME, PGP-mail):требуется обмен ключами, это

Авторизация по IP-адресу отправителяНа основании уже существующих данных (reverse resolving в

Yahoo Domain KeysИдея метода:публикация в DNS публичного ключа доменатекст и заголовки

YDK: технические детали Пример записи в DNS: beta._domainkey.gmail.com text = "t=y; k=rsa;

YDK: перспективыПодход перспективный, но есть проблемы:при поддержке YDK на публичном сервисе

SPF Classic Владелец домена публикует в DNS «политику» - список IP-адресов

SPF: проблема пересылокНеустранимое противоречие«Мягкая» политика не помогает от фальсификации адресовЖесткая политика

SPF Classic: прочие проблемыМассовая PR-компания породила массовое внедрение со множеством ошибок.«Политики

SPF и спамПо данным CipherTrust, спамеры освоили SPF быстрее «нормальных» систем.Распространенность

SPF как фильтр спамаСтатус fail (неверный отправитель) получают <4% спам -писем.Статус

SPF как источник дополнительных данных для антиспам - фильтраДля фильтра SpamTest

SPF: рекомендацииПубликация SPF-политики полезна, во всяком случае ее не будут придумывать

SPF: рекомендации (2)При приеме почты нельзя принимать решение только на основании

CallerID, SenderIDCallerID – технология Microsoft с похожими на SPF идеями.SenderID –

ВыводыОжидать кардинального технического решения проблемы подделки отправителя не стоит.Частные решения возможны,

Похожие презентации