Достаточно простой пример поддельного письма
Для начала немного теории. Электронная почта — это очень удобная вещь, обладающая достаточно серьезным недостатком: письмо очень легко подделать. Вы не всегда можете быть уверены, что это письмо отправил банк, а не какой-то злой хакер, который хочет украсть ваши деньги. Для защиты от этого были придуманы такие вещи, как SPF и DMARC (о них уже много раз писали на Хабре: раз, два и три). Если описывать эти технологии коротко, то они позволяют сказать, кто может отправлять письма от этого домена и что надо делать с поддельными письмами.
Подделка писем при правильном использовании может быть весьма опасной: подумайте, как отреагирует человек, если ему придет не тупой спам, а достаточно адекватное письмо с домена банка с просьбой сменить пароль или с рекламой нового банковского сервиса, на котором можно авторизоваться с помощью основного аккаунта и получить кучу бонусов? Я уверен, что многие поверят этому письму и что-то сделают.
Получается, что БинБанк забыл о такой проблеме и оставил своих пользователей под угрозой. Я немедленно написал в техподдержку письмо, где рассказал об этом. Через некоторое время я получил вежливый ответ от банка, в котором он извиняется за то, что я испытал неудобства.
Когда я понял, что техподдержка вообще не заинтересована в этом, я решил посмотреть, какие еще банки подвержены такой проблеме.
Я выбрал следующие банки из рейтинга banki.ru:
- Сбербанк
- ВТБ
- Тинькофф
- Газпромбанк
- Открытие
- РоссельхозБанк
- Альфабанк
- Московский Кредитный Банк
- Промсвязьбанк
- ЮниКредит Банк
- БИНБАНК
- Росбанк
- Райффайзенбанк
- Акционерный Банк «Россия»
- Рост Банк
- Совкомбанк
- Ак Барс
- Банк Уралсиб
- Банк Русский Стандарт
- Национальный банк «Траст»
- Ситибанк
- Авангард
- Модульбанк
- ДельтаКредит
- Транскапиталбанк
- СМП Банк
- Сетелем Банк
- Локо-Банк
- Банк Санкт-Петербург
После я посмотрел, используют ли они SPF и DMARC. Есть довольно опасное заблуждение, что SPF достаточно для защиты домена от подделки писем: фактически, многие почтовые сервисы игнорируют SPF (привет, mail.ru), плюс SPF не защитит вас от поддельных писем от несуществующих поддоменов. Обязательно стоит использовать DMARC.
Радует то, что у все банков, кроме четырех (Промсвязьбанк, Акционерный Банк «Россия», Совкомбанк, Уралсиб) хотя бы был настроен SPF.
Пять банков (Сбербанк, Газпромбанк, БИНБАНК, Росбанк и Ситибанк) почти смогли настроить DMARC, но установленная ими политика (none) не требует никаких действий с поддельными письмами.
И только один банк на момент проверки был защищен: это Тинькофф. Вероятно, существование программы вознаграждений за найденные уязвимости и адекватная служба безопасности что-то значат.
В целом, результаты оказались очень грустными: только один банк из 28 защищен (я почти уверен, что и другие банки, которые не попали в список, имеют подобную проблему).
Я отправил каждому банку письмо с описанием проблемы. И вот тут стало совсем грустно: после недельного ожидания и повторной отправки писем я получил всего четыре адекватных ответа (это Промсвязьбанк, РоссельхозБанк, Сбербанк и Ситибанк). Остальные проигнорировали письма или отправили стандартное сообщение о том, что мое обращение принято и я получу ответ в ближайшее время (нет). Отдельный привет Газпромбанку, который захотел общаться только по телефону.
С момента отправки последнего уведомления об уязвимости прошло больше месяца (последнее письмо было отправлено 6 марта), результаты следующие: Сбербанк успешно внедрил DMARC, БинБанк начал что-то делать, а Тинькофф просто молодец. Остальные банки, похоже, решили ничего не делать.
На самом деле, ситуация ужасная: во всех системах бывают уязвимости, но когда информацию в готовом виде приносят прямо под нос, возможно, можно что-то сделать? Наверное, хотя бы ответить на письмо?
И да, эта статья ни в коем случае не поощряет мошенничество и отправку поддельных писем от имени банков.
UPD 1: Я не включил Банк Санкт-Петербург в список банков выше, хотя отправлял туда письмо. Исправил это.
Комментарии (86)
xsash
13.04.2017 14:41+5Ладно спам от имени банка… Я не мог 3-4 месяца достучатся до людей на тему xss на сайте сбера (дочка в другой стране) и на странице авторизации в онлайн банкинг.
В итоге достучался, признали, но чет даже спасибо не сказали по итогу.
Вот реально, в следующий раз проще продать в даркнетеLyazar
14.04.2017 03:17Да, на сайте сбера сложно найти страницу с адресом, куда можно написать о проблемах, но если постараться, то можно найти тут, и в самом низу будет почта fraudmonitoring@sberbank.ru
xsash
14.04.2017 07:14+1оу, вы таки меня плохо знаете )) я писал туда, я открывал тикет, я обращался через сбертех… потом начал «спамить» по linkedin высматривая хоть какое-то начальcтво близкое к IT
Merkat0r
14.04.2017 15:05Они могут не толь не сказать спасибо, а еще и пригласить на беседу с товарищем следователем, где вы узнаете что на вас открыто дело и вы пока что свидетель :) На… их
autuna
13.04.2017 15:01+5На самом деле, ситуация ужасная: во всех системах бывают уязвимости, но когда информацию в готовом виде приносят прямо под нос, возможно, можно что-то сделать? Наверное, хотя бы ответить на письмо?
Понимаете какая штука… AFAIK, большая часть банков, наcколько я понимаю (если здесь есть их представители, пусть меня поправят), так или иначе все риски перевешивают на клиентов. Достаточно прочитать их официальные документы. Поэтому они и не дёргаются, ИМХО.
akagroundhog
14.04.2017 14:33Не все банки вообще по поводу информационной безопасности настолько сильно заморачиваются. Конечно, у них есть и СБ, и регламенты, и процедуры, но касаются они в первую очередь тех аспектов информационных систем, которые имеют дело с финансовыми движениями и персональными данными клиентов. Такой безопасностью они занимаются. А настраивать DMARC на почтовом сервисе не у всех руки доходят. У банков, позиционирующих себя как современные и высокотехнологичные, доходят, но таких у нас немного.
JokerKZ
13.04.2017 15:06+1Извините за беспокойство, можете написать как проверить настроен ли DMARC?
Или если уже есть готовые статьи как провести проверку, то поделиться ссылкой
jok40
13.04.2017 16:51Достаточно простой пример поддельного письма
Интересно было бы взглянуть на заголовки этого поддельного письма.Dmitry_4
14.04.2017 09:56Интересно, кто поведется на такое письмо
akagroundhog
14.04.2017 13:39Ну, есть большое количество людей, которые и банками, и электронной почтой пользуются, но с компьютером «на Вы». Это не значит, что эти люди плохие, глупые или заслужили быть обманутыми. Аудитории хабра, конечно, непонятно, как это, не посмотреть на заголовки, но за пределами этой аудитории есть люди, которые этого не умеют. И хотя в итоге виноват всё равно тот, кто перешёл по подозрительной ссылке и ввёл свои реквизиты на левом сайте, банки тоже должны максимально заботиться о безопасности своих клиентов, а не только о лично своей.
Dmitry_4
14.04.2017 14:14Тут дело не в технической грамотности. Дурачков разведут так, что они сами свои деньги со счета снимут и 'нищим' или цыганам отдадут.
redmanmale
13.04.2017 16:51+11> Подделываем письма от крупнейших российских банков
Вы подняли важную тему, но заголовок не соответствует содержанию.
В статье с таким названием ожидаешь увидеть примеры саморучно созданных поддельных писем с попытками обойти антифрод почтовых сервисов.
Плюс неплохо было бы увидеть хотя бы выдержку из переписки с банками.
z3apa3a
13.04.2017 16:59+8многие почтовые сервисы игнорируют SPF (привет, mail.ru), плюс SPF не защитит вас от поддельных писем от несуществующих поддоменов
Во-первых, SPF вообще не защитит от поддельных писем, т.к. SPF проверяет не адрес отправителя из заголовков письма, который видит пользователь, а адрес отправителя из конверта, и ничего не мешает использовать в конверте валидный адрес, для которого пройдет проверка SPF, а во From указывать любой другой.
Во-вторых блокировка по SPF не допустима в принципе для публичных почтовых служб, т.к. она приведет к блокированию любых «inderect flow», например пересылок и список рассылки. Блокировать письма по SPF могут себе позволить корпоративные получатели, при условии что они понимают, что это не даст возможносмти использовать списки рассылки и редиректы. Сам стандарт (RFC 7208) это учитывает, и не требует блокировки по SPF, как использовать SPF каждый получатель решает сам.
Gruffi33
14.04.2017 03:05Не правда Ваша…
SPF запись указывает — какой сервер может отправлять почту от имени этого домена.
При жесткой настройке "-all" — все письма, пришедшие с других серверов реджектятся.
2 pyrk2142
Yandex не поддерживает DMARC отчетов… фактически — проверяет только по SPF и DKIM.z3apa3a
19.04.2017 18:51Зачем вы делаете такие утверждения? Они не соответствуют ни стандарту
https://tools.ietf.org/html/rfc7208
ни общепринятым практикам.
SPF запись указывает какие сервера авторизованы отправлять почту с данным envelope-from или HELO. Он ничего не говорит о том, что делать с информацией об авторизации и не требует блокирвания почты. Вот DMARC как раз говорит.Gruffi33
19.04.2017 21:02https://ru.wikipedia.org/wiki/Sender_Policy_Framework
SPF позволяет владельцу домена, в TXT-записи, соответствующей имени домена, указать список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.
Для этого служат ключи a, mx и ip — разрешать серверам из A или MX записи DNS, либо явно указать адрес сервера.
Строка завершается «-all» — указанием того, что сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Также может использоваться «~all» — в этом случае письмо, не прошедшее верификацию, не должно быть отклонено, но может быть изучено более тщательно (SoftFail).
Я вообще то именно об этом и говорил.
Если пользоваться RFC7208, на который Вы ссылаетесь, то пожалуйста:
An additional benefit to mail receivers is that after the use of an
identity is verified, local policy decisions about the mail can be
made based on the sender's domain, rather than the host's IP address.
This is advantageous because reputation of domain names is likely to
be more accurate than reputation of host IP addresses since domains
are likely to be more stable over a longer period. Furthermore, if a
claimed identity fails verification, local policy can take stronger
action against such email, such as rejecting it.
P.S. Главное при настройке SPF не забыть PTR настроить. А то не сработает.z3apa3a
20.04.2017 02:43Так вы сами-то поняли что процитировали из стандарта?
SPF используется, чтобы при принятии решения основываться на информации не об IP адресе, а о домене, потому что репутация домена может быть более точной, чем репутация IP адреса. /это и есть основной момент/. Более того, если идентичность не подтверждена, _локальная политика_ _имеет возможность_ /can а не MAY/ предпринять более строгие действия против таких писем, такие как блокирование их.
В RFC есть 3 возможных предписания, определяемых стандартом, они указываются прописными буками: MUST (строгое предписание), SHOULD (не строгое предписание) и MAY (разрешение). Здесь (и далее в RFC) не определено, как именно использовать результат проверки политики, более того в явном виде расписаны разные подходы и их риски и указано, что выбирать должен тот, кто реализует локальную политику (local policy).
Ну а то, что неправильное представление об SPF кочует из головы в голову, и статья в википедии написана по итогам таких городских легенд, а не стандарта (как и большая часть других статей википедии на технические темы) — это да.Gruffi33
21.04.2017 21:48Ок. Спорить не буду. Главное — результат.
При том, что при настройке SPF все таки проверялся именно rDNS по IP, а левые китайские письма были гуглом отвергнуты (увидел их только в отчете DMSRC) :)
z3apa3a
20.04.2017 02:53Пункт 2.6
Note, however, that the protocol establishes no
normative requirements for handling any particular result.
Discussion of handling options for each result can be found in Section 8.
8.4. Fail
A «fail» result is an explicit statement that the client is not
authorized to use the domain in the given identity. Disposition of
SPF fail messages is a matter of local policy. See Appendix G.2 for
considerations on developing local policy.
WGH
15.04.2017 09:51Два перечисленных пункта противоречат друг другу. Списки рассылки как раз «перепаковывают» письмо в новый конверт, сохраняя лишь старый From, поэтому SPF их не блочит.
z3apa3a
16.04.2017 13:52Списки рассылки созданные с помощью менеджеров рассылок (Sympa, Mailman и т.п.) — да, но средствами самого MTA (например в Postfix или MS Exchange) — нет.
inkvizitor68sl
13.04.2017 19:38+2Ну проблема начинается с того, что dmarc придумали несколько компаний, они его внедрили и на этом всё закончилось.
Про SPF и DKIM пишут на каждом углу, в каждом мануале, у каждого «mail related» сервиса в документации. А про dmarc пишут примерно нигде. Сам с удивлением впервые читал про dmarc в январе этого года.
brainfair
14.04.2017 05:01+2Я уже как то писал (в какой то теме про настройку почты из ссылок что были даны в теме), что просто необходимо внедрить жесткую политику отбивания всех писем без настроенного SPF, DKIM, DMARC иначе «успешные администраторы» так и будут ставить голый postfix или exchange и просто добавляя в DNS MX записи. Пока крупнейшие игроки не пойдут на такие меры почта так и будет оставаться 99% спамом и источником распространения вредоносов.
Alexsandr_SE
14.04.2017 12:49Если внедрить такую политику, то очень много писем будут просто пропадать и не доходить к получателю. Не годится.
brainfair
14.04.2017 14:52+1Именно поэтому должен быть собран какой-то совет принимающий такое глобальное решение, куда бы вошли все крупные игроки почтовых сервисов, внедрение разбить на несколько этапов, провести массовые информационные рассылки и медиа освещения, не блокировать, а посылать большее число писем в спам без dkim и dmarc, постепенно всем кому нужно перелезут на это. Как по мне единственный кто способен провернуть что-то это гугл, он двигает цифру вперед. Согласитесь немного похожая ситуация с sha1, когда хром сначала начал помечать сайты, а недавно и вообще перестал их открывать. Надо что бы была инициатива, но пока она слишком пассивна даже со стороны крупнейших.
dmitry_ch
14.04.2017 09:13Сам видел ситуацию, когда один из банков настроил, как они думали, «по RFC» свой антиспам, в результате чего часть писем от клиентов с правильно настроенным SPF и DKIM стала банком отбиваться (550 и все дела). Банк же отвечал, что у них все в порядке, и ничего не менял. В результате подстраивались клиенты, потому что для бизнеса важнее не «правильно», а чтобы «работало».
В жизни ровно так же. Начни почтовые сервисы отбивать все письма с кривыми заголовками, и люди начнут уходить с этих сервисов, а не пинать своих корреспондентов корректно настраивать их, удаленные почтовики.
И, да, почтовые системы банков, равно и как их веб-серверы и сервисы, как бы не обязаны работать без ошибок. Это, может, и не официальная позиция, но часто слышится именно такая мысль — у нас настроено как мы осилили, менять нам очень сложно бюрократически, так что мы скажем, что у нас точно все ок, а жаловаться все равно некому.
Так что заголовок статьи…
P.S. А как на mail.ru вы заполучили иконку банка в отображении письма, если это привязывается только только при настроенном DKIM?brainfair
14.04.2017 15:02Не спорю бывают и такие ситуации, самолично пару раз за год точно провожу информационные беседы с специалистами контрагентов, но подстраиваться под кого-то это вообще как можно? 550 это же получатель не найден =)
dmitry_ch
14.04.2017 15:06550 — это еще «у ит-ников нет мозга».
Я видел лично почтовый сервер, который при превышении rate-limit-ов делал не 421, а 550 — т.е. не временно не помогу принять, а тупо «не приму».
А в банках… У них, как мне кажется из опыта, чаще боятся что-то поменять, тупо напирая, что они правы, а весь мир — нет, чем внимательно подумать и что-то изменить. Потому что за изменение получат по голове из-за дисциплины, а что кто-то внешний мучается — это вообще не проблема. Если вдуматься, банки так себя ведут не только с почтой, правда же? Хочется думать, что это только в плохих банках и только плохие работники так себя ведут, но я пока опыт такой имею.brainfair
14.04.2017 15:22Ну да печаль, к сожалению данная статья нам и рассказывает о том что из всех банков только в Тинькоффе и еще паре банков…
ps: по молодости пытался устроится в местный сбер, перспективы там были хорошие, работы уйма, тк местные айтишники представляли из себя дядек ведущих учет оборудования и настроек в экселе, но вместо меня взяли что-то типо «племянника двоюродного брата вон той тёти начальницы».
Temmokan
14.04.2017 09:52Может, mail.ru и игнорирует SPF, но в технических заголовках таки есть признаки его проверки:
Authentication-Results: mxs.mail.ru; spf=pass (mx221.i.mail.ru: domain of example.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=john.doe@example.com smtp.helo=out1-smtp.messagingengine.com; dkim=pass header.d=example.com; dkim=pass header.d=messagingengine.com Received-SPF: pass (mx221.i.mail.ru: domain of example.com designates 66.111.4.25 as permitted sender) client-ip=66.111.4.25; envelope-from=john.doe@example.com; helo=out1-smtp.messagingengine.com; Received: from out1-smtp.messagingengine.com ([66.111.4.25]:40619) by mx221.i.mail.ru with esmtp (envelope-from <john.doe@example.com>) id 1cyuwy-0002Ah-GD for someuser@bk.ru; Fri, 14 Apr 2017 09:43:22 +0300
(письмо отправлено несколько минут назад, выше заменены адреса исходного ящика и ящика на mail.ru)Gruffi33
14.04.2017 11:32+1Да не игнорирует mail SPF. Это не верно. Вот что поддерживают сервисы:
Google — SPF, DKIM, DMARC
Yandex — SPF, DKIM (отчеты DMARC не поддерживаются)
Mail.ru — SPF, DKIM, DMARC
Для Mail есть два важных момента — правильная настройка PTR записи и отсутствие «прецедента» — т.е. чтобы ранее почта с этого ящика не попадала в спам (иначе она даже со всеми заголовками так и будет в спам падать), или у нее не стоял маркер «Не спам» — тогда и без заголовков не будет в спам попадать.
Последние недели две как раз разбирался с этими настройками, так что говорю по «горячим следам» :)
RoboShop
14.04.2017 18:14Немного в тему, а для статьи мало. Так же нашёл дыру в доступе к личным данным у одной из крупнейших транспортных компаний в стране. Можно по номеру накладной узнать все данные получателя — фио, телефон, адрес. Полный игнор моих писем.
Lipsec
14.04.2017 18:14Ого! Интересно, однако…
Хорошо что я отказалась от услуг Ситибанка и ушла (по совету друга) в Тинькофф. Теперь точно знаю, что не зря. Спасибо за статью, полезно.
Creditpower2015
14.04.2017 18:14О чем вы говорите? SPF, DKIM, DMARC… Сейчас банки больше озабочены выживанием, не отвлекайте их. Нашли к чему придраться. ))) За последние 2 года ликвидировано более 300 банков! У половины даже сайтов нормальных нет. Например рнбк. Первый попавшийся взял. Такое впечатление что делал любимый сынуля или доча директора. Вклад я бы не доверил банку с таким сайтом, а вот кредит, можно б было взять. Возможно он следующий на ликвидацию, вот и не парится. И так, банки засыпают, просыпается…
776166
16.04.2017 13:54+3На практике банки сами по себе те ещё спамеры. И всё время нарушают закон о рекламе, рассылая ненужную рекламу без возможности отписки.
DjOnline
19.04.2017 14:19Столкнулся с тем, что сами почтовые системы препятствуют отписке. Например рассылка по клиентам содержит заметную ссылку «Отписаться», заголовок Link-unsubscribe. Но по какой-то причине часть писем попала в спам к примеру в mail.ru (иногда из-за превышение скорости рассылки), и все ссылки в письме становятся неактивными, включая ссылку на отписку, что в свою очередь повышает недовольство клиентов.
правда фактическая ссылка ведет на сайт школы Первоуральска и там лежит _doc.js файл…
saipr
18.04.2017 14:31А что мешает нашим банкам использовать электронную подпись по ГОСТ в своей переписке с клиентами?
Nicks_TechSupport
18.04.2017 19:00Потому что это банально дорого, бизнес не одобрит такое внедрение просто так.
Условно говоря, бизнес зарабатывает деньги, а ИТ их тратит. Ни один бизнес не одобрит внедрение токенов и ЭЦП, пока это не будет выгодно.saipr
18.04.2017 20:15Это немного не так. У многих банков сегодня есть даже УЦ. Для подписи рассылки надо иметь только один сертификат банка пусть даже с токеном (1500 руб). С другой стороны уже сегодня есть облачный токен и его для начала
можно протестировать.
Nicks_TechSupport
18.04.2017 20:19К сожалению, картинка не грузится.
Простите, я немного не понял вашу идею.
Если мы говорим о рассылке клиентам через систему ДБО банк-клиент, то вы несомненно правы, именно так это и делается.
Я подумал, что Вы предлагаете каждому сотруднику бана выдать собственную ЭЦП для общения с клиентами.
Конкретизируйте будьте добры.saipr
18.04.2017 20:26Последнее было бы здорово. И облачный токен (думаю здесь картинки грузятся) решит проблему цены.
Nicks_TechSupport
18.04.2017 20:38Вот я про то же и говорю, каждому пользоателю банка выдавать токен- задача финансово банку невыгодная. Насчёт облачного не уверен, недавно относительно только на токены перешли по ДБО, до сотрудников пока не дошли.
Gruffi33
19.04.2017 21:23А что мешает пользователям для безопасности использовать переписку в интернет-банке?
IgorBelyakov
20.04.2017 13:45Эта тема больше про физиков, которые, в большинстве, не проверяют получаемые письма.
Nicks_TechSupport
21.04.2017 01:51Уверяю Вас, бухгалтерия предприятия тоже не првоерит такие письма. Их задача годовой баланс свести да налогов поменьше заплатить, а не за письмами следить...
Velibekov
18.04.2017 20:42+1Пока петух не клюнет…
Вот когда кто-нибудь, перейдя по левой фишинговой ссылке потеряет деньги, а после, будуси послынным банком, подаст на него в суд, тогда уже в банке зашевелятся.
Помнится, как-то девушка отсудила у Qiwi 91.860 потерянных денег и 45.390 штрафа. Так после этого, даже если и отключаете в настройках безопасности СМС подтверждение платежей, они через некоторое время включаются автоматом)
Zalechi
19.04.2017 09:05Ребята, мне одному здесь кажется, что эта старинная версия транспорта писем устарела? Давно обратил внимание на проблемы связанные с протоколами передачи писем. О сюда возникает два решения:
— написать корневой протокол с нуля, который чёрт побери исправит все недочёты,
— уйти напрочь от систем почтовых протоколов.
1) Ну что ей Богу, тяжко создать современный протокол, в котором чётко буду стандартизированы и обозначены правила создания, передачи, обработки этих старинных писем?.. IMAP SMTP POP DMARK DKIM SPF PTR(записи в DNSах). Всё это «тупое» наложение друг на друга, и когда это кончится?
2) Что такого уникально в протоколах передачи писем, что нельзя реализовать в… Мало служебной информации? Простота? Какой ещё аргумент в нашем современном мире может помешать реализации современного прикладного кода, который бы не удовлетворял всем потребностям? Вайбер, Скайп, Аська, я не знаю что — уже танцевать и печь пиццу умеют, а тут это…
Да я сторонник лаконичного, простого и порой примитивного кода/протоколирования, но ё-моё, мы живём в век информационных технологий… У нас холодильники — умные… А с другой стороны, ну что сложнов реализации такого простого действия в стеке протоколов ТЦП/АйПи:
-указать отправителя,
-указать получателя,
-фиг с ним указать тему сообщения,
-задать тело сообщения,
-прикрепить данные любого типа в сообщение.
Так что бы ни одно из этих полей не пересекалось друг с другом, в том плане, что взломать тело сообщения есл в файл заложен хак. Так что бы нельзя было скомпрометировать отправителя или получателя, пока не взломаешь сервис по стороннему протоколу(ну атм получил рут от сервера, разхешил доступы, слил базу, там не знаю что)…
Поправьте меня… Вот что надо на консорциуме обсуждать.DjOnline
19.04.2017 17:40Как сказали выше, цифровая подпись DKIM и SPF- это хорошее решение для валидации что это отправил именно этот отправитель с этого домена. Но какого чёрта не проверяется поле From, именно в котором указывают поддельный адрес отправителя?
z3apa3a
19.04.2017 19:14Потому что у вас не полная информация.
SPF изначально делался не для защиты адреса отправителя, а для авторизации отправляющего сервера, с целью борьбы со спамом с затроянленных хостов. Поэтому он работает только на уровне SMTP-конверта, который не имеет отношения к содержимому письма, включая заголовки. Исторически, был протокол Sender ID предложенный Microsoft, который предусматривал проверку SPF именно для From для авторизации отправителя. Sender ID не взлетел и больше не используется.
DKIM это в принципе не протокол авторизации, это протокол создания подписи. Подпись может поставить любая сторона, не обязательно автор письма. Есть «парный» к нему протокол ADSP который предусматривает авторизацию отправителя с помощью DKIM. Но от протокола ADSP отказались в пользу DMARC, сейчас он имеет статус «исторический».
DMARC как раз и нужен для того, чтобы авторизовать поле From по SPF и DKIM.
Gruffi33
19.04.2017 21:25Как не проверяется? очень даже…
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xxx.ru; s=xxxx; t=1492426725; bh=pwzLgR2pGqW6aspLjklDqqBxmFxsfsSjhHUIHkjKKj; h=Date:From:Subject:To:From; b=DkbORL1TI12FqH=
z3apa3a
19.04.2017 19:06Вайбер, скайп и аська это централизованные сервисы управляемые одной компанией, которая обеспечивает авторизацию пользователя и подтверждает его подлинность. Закрытость позволяет легко вносить любые изменения в протокол, т.к. не надо думать о совместимости с кучей сторонних реализаций.
Электронная почта — это федеративный сервис, не имеющий центральных серверов или единой обслуживающей компании. Отсюда и проблемы с авторизацией отправителя и изменения в протокол вносить невозможно, т.к. это поломает имеющиеся реализации, поэтому они принимаются отдельными стандартами, и это нормально. Просто их надо поддерживать, а многие администраторы по-прежнему считают что почта это «древний протокол» RFC 821 / RFC 822. А это не так. Кстати, о древности протокола: текущая версия SMTP (RFC 5321) это 2008 год. Текущая версия XMPP (Jabber) для сравнения, это 2004й год.Zalechi
19.04.2017 20:44Уважаю Ваши познания, но! Вы мне сказки не рассказывайте(я в хорошем смысле, бо адрес википедии мы знаем)… Что такое мессенджеры и их IM-протоколы мы тоже знаем. Закрытые они, открытые, это всё не причём. Кстати — ещё меня до сих пор удивляет, что есть огромные проблемы с DNS-серверами и на втором месте проблемы BGP-протокола.
И так имеем три весомы глобальные проблемы и дальше мой чарт:
1) E-почта — выставил на первое место, так как эксплуатация доступна множеству;
2) DNS — удостоен второго места, так как дыр полно, они значимые, но их эксплуатация требует болших навыков и/или вложений;
3) BGP — третье место, так как значимость огромная, но эксплуатация требует, как серьёзных знаний, так и зачастую оборудование, доступ непосредственно к корневым рутерам провайдеров.
В данной статье мы обсуждаем электронную почту, на ней и остановимся. У меня к Вам(Зараза, да и ко всему комьюнити) такой вопрос, постановка задачи —
Дано:
— отправитель,
— получатель,
— тема сообщения,
— тело сообщения(желательно современно форматированное, любого размера допустимого сервисом),
— вложения(любого типа, размера допустимого сервисом),
— шифрование(важный атрибут).
Требуется:
— описать стандарт/протокол,
— реализовать сервис.
Вот пусть эксперты мне носом ткнут, в чём мать его проблема? Где Вы в частности нашли проблему, что по заданному стандарту нельзя будет реализовать данный сервис на частном сервере? Я приведу такой пример. ФейсБук — да его ломают, как и всё что есть в этом мире, да там я не знаю что, но вот мой профиль как был много лет не скомпрометирован, так и есть. Кстаи на мейл.ру, такая же тема. ДА вообще я не знаю где бы мой профиль слился. Ахда, на вордпрессе базу стырили(не меня засками, не там знаю что, а всю базу хрякнули) — точно. Ну вот… То есть есть защищённые сервисы, которым ожно доверить секурность базы в которой вы зарегитесь. Тепероь представим, что ФБ или МАЙЛ.РУ сделали слой, в котором все вышеуказанные мною потребности задачи, реализовали. Ну и в конце концов код этот открытый или приватный уже не важно, это второстепенно, но главное, что хрен ты залез туда и что-то подменишь.
Что не так?vikarti
19.04.2017 21:27В чем проблема?
Если вы хотите заменить e-mail — то кто будет переписывать весь код под новый протокол?
Вот допустим есть у меня почтовый сервер в JIRA, который отправляет почту по SMTP без авторизации вообще (при этом сообщения в итоге доходят со всем чем полагается — DKIM и так далее, а послать спам получится только из внутренней сети). На каком основании мне, как пользователю версии которая все же на поддержке, требовать от Atlassian поддержки вашего нового протокола? С их стороны ответ будет «все ж работает».
Кто сделает поддержку нового протокола в: Apple Mail for OS X, Mail.app for iOS (включая ту версию что на iOS6, у меня в семье три таких девайса и они вполне используются). В Gmail (и штатном почтовом клиенте андроида который обновляется через Play Services) ладно -Google может быть и реализует «еще один» протокол.
Если mail.ru откажется этот суперпротокол поддерживать (или скажут что сделаем как раз после WebDAV в cloud.mail.ru) то, как я буду отправлять почту конкретному пользователю на mail.ru с которым активная переписка годами но с mail.ru его заставить будет… сложно.
Что будет если я через полгода в магазине потребую отправить чек мне на e-mail (магазин обязан выполнить это требование из-за 54-ФЗ), и указанный мной адрес поддерживает только суперпротокол новый? Или наоборот магазин только его поддерживает вместо SMTP+DKIM+… Отказать магазин мне не имеет права но зато вполне может сказать что раз в законе e-mail а не суперпротокол то давайте e-mail-адрес.
Кстати а какое шифрование? Кто будет решать какие алгоритмы? Почему должен использоваться нестандартный RSA а не совершенно стандартный* ГОСТ?
Вот и получаем что либо придется делать параллельную систему и медленно убеждать всех что таки да — она лучше традиционной. Возьметесь? А вас видимо при этом будут спрашивать — «Лучще ЧЕМ? И почему этот функционал не внедрить в существующую e-mail как расширение?»
Либо придется жестко сломать существующую систему и порушить вообще хождение электронной почты а всех разработчиков — заставить выпустить обновления. Кто будет заставлять?
Если же вам хочется сделать протокол для общения в пределах вашего белопушистогого сервиса — так в чем проблема сделать? И делают. ProtonMail например — с упором на шифрование внутри сервиса. (А если отправка/прием извне — ну обеспечат что могут).
Zalechi
19.04.2017 23:14+1Чёрт побери, я поднял фундаментальный вопрос. Да чёрт возьми, не я первый кто об этом думал. И чёрт возьми, сколько дерьма нашей цивилизации надо съесть, что бы реализовать СТАНДАРТ RFC/ISO, который имплантирует любой игрок, начиная частником/лабораторщиком, кончая крупным? То есть пока чума не снесла пол Европы и пока Настродамус не ткнул дураков носом в дерьмо, о том, что трупы надо сжигать… Какой ядерный взрыв должен быть, что бы сука мейл ру принял эту разработку?
Меня это мучает, это безразличие, эта лень и импотенция, эта капиталистическая стена. И таких примеров миллион — бездумные войны, невежественная международная политика, тупая а не адекватная глобализация, неравенство классов. Вместо того, что бы разрабатывать лекарства и всем миром колонизировать луну, марс, — 1 процент человечества наращивает богатсва, а остальные прислуживают… И такого полно в нашем мире, но этоне значит что я должен молчать и сложа руки смотреть, как почтовые протоколы хереют.brainfair
20.04.2017 05:32Зачем снова придумывать, что-то новое и опять напарываться на новые баги, глюки и недороботки нового протокола, когда как раз smtp + spf + dkim + dmarc при правильной настройке и есть тот самый идеальный протокол для децентрализованной передачи email!
Если все будут проверять dkim и отбивать по жесткому dmarc если не прошло, то в тот же час у нас пропадет 99% спама, останется только спам с валидных, но зараженных серверов.
Другое дело, что нельзя просто так взять и включить это везде, потому что мало кто это поддерживает.
Чем больше будут закручиваться гайки крупнейшими игроками, тем менше будет возможностей рассылать спам. И именно это и надо развивать, а не придумывать что-то новое со своими свистоперделками и багами, которые так же придется допиливать. Да и кто сейчас будет переписывать весь тот легаси работающий по smtp если вдруг кто-то скажет «все сорри парни с 2018 года smtp в интернете больше не будет работать».Zalechi
20.04.2017 09:28Как вам такой вариант?:
— SMTP 2.0.
Вся эта связка smtp + spf + dkim + dmarc — в одном флаконе. Издаётся новая спецификация, затем разработчики сервиса, как это обычно и происходит — выпускают релиз ПО. Чё-то, как-то, когда надо всех перевезти на WIN10 они умудряются это сделать. Или пример перехода всех с WIN98/W2K на WINXP вообще был молниеносный. Так тут всё проще, пользователь и не заметит этот переход, вся забота ляжет на СИСАДМИНОВ. Ну а вы свой OUTLOOK, так или иначе переустановите. Да и переход данный можно произвести плавно. Слушайте мы живём в такое время, что… Все эти проблемы мне видятся решаемыми.
Да я идеалист, перфекционист. И что?
Если не произвести эту унификацию, то конечно сложней заставить админов настраивать какие-то связки. А тут всё в одном флаконе — загрузил, настроил и поддерживай.
Даже если возникнут сложности согласования с другими протоколами транспорта данных, или там с ДНС обслуживанием. То это даже классно. Всё к чертям менять. Или так и будем лечить зубы стамеской, прикладывать подорожник к ранам? Ё-моё. Значит строить мобильники в виде смартфонов у Джобса нашлись силы и характер, что бы заставить конструкторов выпустить первый полноценный смартфон — Айфон. А вы почитайте, как он заставлял(настаивал) конструкторов разрабатывать эту первую модель. Ломал стереотипы и инженерные препятствия…brainfair
20.04.2017 10:46+1Появится в этой связке новая возможность подделывать письма или баг связанный со спецификацией, и сделают smtp 2.0 + какой нить abrablockkadabra новый, и снова все пойдет по новой и опять… Поэтому «не стоит выдирать сразу на корню все свои зубы и идти к стоматологу за новой вставной челюстью, достаточно чистить зубы и не есть сладкое».
ps: кто-то уже предложил блокчейнт в smtp применить? А то это модно сейчас )))Zalechi
20.04.2017 16:16Это вы товарищ лошадей притормозите и поясните мне… Как можно в строго прописанном правилами протоколе эксплуатировать баг? Я не программист, но вы меня направьте и поясните по следующим вопросам.
1) Отправитель письма. $formuser — данные которого прочитаны из поля защищённой базы данных сервера. Если нет доступа к базе, то что тут можно эксплуатировать? Как подменить? Или часто от вашего лица в вк или фб отправляют мессаджи?
2) Получатель письма. $recieveuser — данные которого проверяются на сервере ресипиента по той же схеме, что и данные отправителя.
3) Тема письма. $subject — простое(или форматируемое) поле заданной длины на сервере, выделите ему 20/80/N байт в зависимости от ваших мощностей… Какая тут эксплуатация?
4) Тело письма. $body — простой или форматированный текст, мождно сравнить с полем «Тема письма».
5) Вложенный файл(ы). $attaches — буфер ограниченый размерами и возможностями серверной мощности, в который можно пихануть любой тип фала.
6) Шифровка. $#! — заворачивайте вышеуказанные поля в капсулу, которую сможет развернуть лишь получатель.
7) Служебная информация. $mailinfo — информация описывающая время отправки/получения письма и прочее. Тоже можно завернуть.
Вот теперь по пунктам объясните в чём проблема? Не надо меня и мои зубы голословно лечить стамеской без без наркоза в XXI веке. Если можно? То есть какой-то вайбер, мессенджер, лайн, скайп, аська это могут делать, а вот нам с вами такое не под силу? Где собака зарылась? Думайте Стиву Джобсу конструкторы/дизайнеры тоже рот не пытались закрыть, мол — телефон не сможет работать без стилуса, и тд… Ничего, справились под нажимом мечтателя и руководителя.
Fragster
20.04.2017 17:26Вам намекают, что «говорить — не делать реальное дело». Ну и https://xkcd.com/927/ никуда не девается.
Zalechi
20.04.2017 21:36Послушайте, давайте не будем тут проводить пустую полемику. какие-то намёки давать без аргументов. Задача была поставлена. Расписана по пунктам. Если вы программист/инженер с опытом разработки протоколов/стандартов, то добро пожаловать в диспут. Заткните меня или ткните носом, что бы я успокоился. А иначе, — упорства мне не занимать, здоровых амбиций тоже. Ваш комикс про кодировку символов, или там например про частные протоколы передачи сообщений, или Бог знает чего ещё… Кодеки например. Это не предмет данного разговора. Вас не заваливают многомиллиардным мусором: кодеки, символы или сообщения.
Здесь речь о массовых архаичных дырах интернета, если можно так выразиться.brainfair
21.04.2017 04:13Вы приводите в пример Джобса, но он не повторял то что уже есть называя другим именем, ваше предложение больше похоже на китайцев делающих клоны айфонов под своими именами. Протокол и стандарты уже придуманы, надо просто развивать их повсеместное использование.
Вы пытаетесь надавить на то, что ваш новый стандарт (не отличающийся от текущего) будет лучше и без изьянов, но вы человек, вы не можете предосмотреть всех проблем и недочетов, которые могут появится в процессе эксплуатации, а они будут и снова пойдут правки и доработки стандарта новыми костылями и снова все пойдет по кругу (ну и да тут уместен комикс про стандарты).
vikarti
20.04.2017 16:47Нужно было — MS и Джобсу. Они и прилагали усилия.
Где можно посмотреть на вашу эталонную реализацию СуперПротокола (допустим в виде патчей на Postfix и Thunderbird)?
Про внедрение силой — уж сколько времени IPv6 внедряют? Который реально нужно внедрять и который решает много реальных проблем, которые без него (или аналога, но на который просто уже нет времени) не решить.
с BGP кстати не так — не работали вы с маленькими AS. Куча хостеров с удовольствием согласятся вашу AS и /24 PI анонсировать даже если у вас 1 сервер. Да, попросят дополнительно разумную денежку. А еще — повесят фильтры чтобы вы не смогли проанонсировать совсем уж полный бред.Zalechi
20.04.2017 23:18Модель я представил выше. Она проста как два пальца об асфальт. Её реализация не в моих руках, — не программист, и как Стив я не вижу проблемы её реализовать — было бы стремление и амбиции.
IPv6 — внедрён, работает. Полный переход затянулся, но я неготов обсуждать это. Гипотетически проблем нет вроде. И опять таки — в чём проблема всех заставить и перейти? В ЧЁМ??? То етсь когда новая версия скайпа выходит, вы быстро её обновляйте, а вот новую версию протокола айпи вам что мешает?
Я вообще BGP знаю на уровне основных постулатов. Знаю Что там есть АС-ки и и они анонсируются програничными рутерами. Детали не знаю, тонкости настроек тоже. Но, знаю, что там есть проблемы, и их надо решать, бо протокл былсоздан на заре интренета и имеет изъяны, как и почтовые протоколы, как и сервис ДНС.
Ток это неумоляет моего стремления исправить это.
fryday
21.04.2017 02:51Вероятно, существование программы вознаграждений за найденные уязвимости и адекватная служба безопасности что-то значат.
Так вроде же только грозились устроить bug bounty? Насколько знаю, так нигде и не развернули программу.
Ну на счет адекватности СБ, или как минимум уважения к клиенту я бы поспорил.
Gruffi33
21.04.2017 21:522 pyrk2142
Кстати… не все так плохо…
Received-SPF: pass (google.com: domain of noreply@psbank.ru designates 193.200.10.122 as permitted sender) client-ip=193.200.10.122;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of noreply@psbank.ru designates 193.200.10.122 as permitted sender) smtp.mailfrom=noreply@psbank.ru;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=psbank.ru
MrRitm
22.04.2017 00:07Дык все просто! Надо выяснить почтовый адрес какой нибудь шишки из интересующего банка и отправить ему уведомление о проблеме причем подделав письмо так, чтобы выглядело как будто оно от его коллеги.
Мне тут рассказали про «одминов» сбера. Те еще любители поработать… Очень гордые птицы — пока не пнешь — не полетит :-) Так что тут движуха должна начинаться не снизу (с тех. поддержки) а сверху (от руководителя который получил поддельное письмо и осознал весь ужас и позор ситуации).
Реально стремно, когда в конторе ООО «Рога и копыта» сынком директора за пиво все настроено как положено, а у крупного банка за очень отдельные деньги как-то не очень…
Buton
Заголовок в стиле life news. Мне кажется правильным будет сначала рассказать кто из крупнейших почтовых сервисов поддерживает DMARC. Насколько я понимаю без поддержки этой технологии почтовым сервисом толку от нее будет мало.
pyrk2142
На удивление, DMARC поддерживают очень многие: Gmail, Mail.ru, Yandex и т. д. Я бы даже сказал, что письма для большинства пользователей проходят такую проверку.
Nicks_TechSupport
Банк Санкт-Петербург Вам ответит скоро я думаю. Письмо дошло до руководителя СБ банка.
pyrk2142
Буду рад, если банк ответит.
Nicks_TechSupport
Да, должен по идее. Как минимум рассмотрят уж точно, т.к. уже передано ответственным лицам.
Zalechi
Естественно и очевидно. Если вы имейте свой домен, сервера с веб-мордами, фронт сервисами, всякими енд-сервисами, Вы являйтесь банком, то уверен почтовый сервис вы тоже выгуливайте. Если же Вы используйте сторонний почтовый сервис, то Вы как пользователь стороннего сервиса, имеете право и нуждайтесь в том, что бы обратиться к провайдеру данной услуги для расширения диапазона используемых протоколов и политик.