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

Нажмите для полного просмотра!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Методы верификации отправителя почтового сообщения Алексей Тутубалин lexa@lexa.ru «Ашманов и Партнеры». Доклад-сообщение содержит 22 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

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

Слайд 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 (неверный отправитель) получают

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