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

Категория: Информатика
Нажмите для полного просмотра!
Методы верификации отправителя почтового сообщения Алексей Тутубалин lexa@lexa.ru «Ашманов и Партнеры», слайд №1Методы верификации отправителя почтового сообщения Алексей Тутубалин 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 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

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

Слайд 1


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

Слайд 2


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

Слайд 3


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

Слайд 4


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

Слайд 5


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

Слайд 6


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

Слайд 7


Верификация содержания письма Пользователь-пользователь: верификация электронной подписью (S/MIME, PGP-mail): требуется обмен ключами, это задача пользователей. нужна поддержка в клиентских программах ради разового обмена почтой никто не будет меняться ключами. Сервер-сервер: Yahoo Domain Keys публикация ключей и политики их использования в DNS требуется модификация почтовых серверов как для простановки подписи, так и для её верификации.
Описание слайда:
Верификация содержания письма Пользователь-пользователь: верификация электронной подписью (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)
Описание слайда:
Авторизация по IP-адресу отправителя На основании уже существующих данных (reverse resolving в DNS): Не требует изменения инфраструктуры, уже широко применяется. Отсутствие достоверных данных о структуре чужих сетей ограничивает применимость. Новые методы дополнительные данные в обратной DNS-зоне (MTA Mark, Selective Sender, MX Out) дополнительные данные в DNS домена отправителя (SPF Classic, CallerID, SenderID, RMX)

Слайд 9


Yahoo Domain Keys Идея метода: публикация в DNS публичного ключа домена текст и заголовки сообщения подписываются на приемной стороне подпись проверяется Достоинства «достоверность» является свойством письма, а не почтовой сессии Недостатки при внедрении на публичном сервисе, можно получить любое нужное количество подписанных сообщений.
Описание слайда:
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....
Описание слайда:
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 при пересылке). Пропуск подписанных писем мимо фильтра породит злоупотребления, нужен отдельный рейтинговый сервис.
Описание слайда:
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-адрес посылающей стороны сравнивается со списком от владельца домена, после чего принимается решение о статусе письма.
Описание слайда:
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-политик требуется модификация ПО на почтовых серверах «третьих сторон».
Описание слайда:
SPF: проблема пересылок Неустранимое противоречие «Мягкая» политика не помогает от фальсификации адресов Жесткая политика приводит к потерям при пересылках (forward) писем: в процессе пересылки адрес отправителя сохраняется, а IP-адрес посылающей стороны – нет. Для внедрения жестких SPF-политик требуется модификация ПО на почтовых серверах «третьих сторон».

Слайд 14


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

Слайд 15


SPF и спам По данным CipherTrust, спамеры освоили SPF быстрее «нормальных» систем. Распространенность SPF на сегодня недостаточна, чтобы быть эффективным антиспам - средством.
Описание слайда:
SPF и спам По данным CipherTrust, спамеры освоили SPF быстрее «нормальных» систем. Распространенность SPF на сегодня недостаточна, чтобы быть эффективным антиспам - средством.

Слайд 16


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

Слайд 17


SPF как источник дополнительных данных для антиспам - фильтра Для фильтра SpamTest на большом потоке сообщений: примерно для 0.5% сообщений статус SPF более «жесткий», чем результат работы Spamtest. Примерно для 0.4% сообщений, статус более «мягкий» (доля совпадает с долей «pass» в потоке спама). Вывод: польза от SPF сомнительна.
Описание слайда:
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
Описание слайда:
SPF: рекомендации Публикация SPF-политики полезна, во всяком случае ее не будут придумывать за вас. публикация «жесткой» политики будет приводить к потерям исходящей почты публикация «мягкой» политики может привести к ее игнорированию получателями Нужен нейтральный вариант, например: +ip:10.0.0.0/24 ~all +ip:192.168.0.0/24 ?all

Слайд 19


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

Слайд 20


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

Слайд 21


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

Слайд 22


Спасибо за внимание Пожалуйста, задавайте вопросы.
Описание слайда:
Спасибо за внимание Пожалуйста, задавайте вопросы.

Скачать

Похожие презентации
Mypresentation.ru
Загрузить презентацию