Привет, я процитирую свой на этот репорт с HackerOne:
к сожалению, электронная почта действительно изначально не защищена от подделки адреса. Существует стандарт DMARC который позволяет защититься от подделки, но работает только на письмах соответствующих стандарту RFC 5322 и только для отправителей, настроивших политику DMARC. В настоящее время достаточно много писем не соответствует этому стандарту и проверить на них DMARC невозможно. Постепенно мы «закручиваем гайки» для нестандартных писем. Сейчас на таких письмах (и в некоторых других ситуациях) показывается уведомление о возможной подделке адреса, что видно на скриншоте, поэтому пользователь предупрежден и мы не считаем данную ситуацию ошибкой.
P.S. duma.gov.ru в принципе не публикует политику DMARC, поэтому защитить письма от этого домена от подделки стандартными средствами невозможно.
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
Return-Path это заголовок письма, в который при локальной доставке в ящик подставляется содержимое SMTP конверта MAIL FROM, поэтому, хотя это и не совсем одно и то же, термины часто используются как эквивалентные, чтобы не путать с From: (RFC5322.From) — заголовком письма.
Так запретите, только сразу запретите еще юзеров Yahoo, AOL и все крупные корпорации, т.к. у них тоже строгий DMARC, а с этого года придется запретить gmail, hotmail/outlook и Yandex, т.к. они тоже анонсировали внедрение строгого DMARC. В общем лучше вообще сразу всех запрещать, чтобы много раз в конфигурацию не лазить.
Или таки, как в mailman надо настроить dmarc_moderation_action с действием Munge From, но это как-то менее радикально, да еще и документацию читать надо.
Пожалуйста, но этой статье больше года и вряд ли политика DMARC домена mail.ru может влиять на вашу рассылку. Если ваша рассылка попадает под политики DMARC, значит вы ее неправильно делаете.
Да. Тарантул вообще декларируется не как NoSQL хранилище данных, NoSQL это скорей побочная черта архитектуры, а вообще это сервер приложений LUA. LUA в том числе можно использовать в декларативном стиле, но совсем не обязательно, т.к. это гораздо более удобный и гибкий язык, чем TSQL или PL/SQL. А поддержка SQL в анонсирована в разрабатываемых версиях Tarantool.
но что будет делать система фильтрации, если аналогичная проблема появится в Joomla?
Притворюсь, что не понял, что это риторический вопрос :)
Давайте я еще чтобы продемонстрировать мысль усложню задачу, и представим, что атака пошла сразу с миллиона джумл, чтобы дешифровать весь трафик не хватит никаких ресурсов и надо срочно спасать клиента. Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей, можно по имеющимся IP-классификаторам, можно по сигнатурам TLS-хэндшейка, одного коннекта с одного IP хватает для классификации. В атаке участвует 1,000,000 джумл — для «грубой» классификации пропустим миллион коннектов от джумл прежде чем их грубо отфильтруем. Дальше трафик гарантированно не от джумл пропустил бы обычным путем, % грубо отфильтрованных коннектов на который хватает мощности пустил бы на дешифровку и анализ и состсавил черный список (с джумлами) / белый список (с false positive'ами «грубого» классификатора), остальные коннекты, на которые не хватает ресурсов просто пустил бы в блекхол. Да, зарежем на время людей с проксями на хостингах или возможно какие-то поисковики — и фик с ними. И так пока большая часть атаки не будет отфильтрована блеклистом. По мере роста блеклиста мощность атаки и процент коннектов, уходящих в блекхол будет снижаться, не думаю что потребуется больше нескольких минут, чтобы митигировать ее блеклистами до уровня, когда можно обработать весь трафик. Так что джумлы с вордпрессами не очень пугают, потому что можно быстро сделать грубый фильтр на пассивный трафик.
А вот IoT с Андроидами это очень страшно, да, потому что такое не прокатит.
Для нейтрализации же потребуется канал шириной от 20 Гбит/с, возможность обрабатывать трафик прикладного уровня на полной пропускной способности соединения и расшифровывать все TLS-соединения в реальном времени
Атака со статических адресов и для блокировки должно быть достаточно блеклиста, а для построения блеклиста должно быть достаточно зарулить/дешифровать какой-нибудь небольшой процент соединений. Есть какая-то причина дешифровать весь трафик?
На самом деле, все еще интересней, в большинстве случаев можно обнаружить подозрительные узлы даже пассивно по используемому cypher suite, отличие от популярных браузеров будет весьма значительное.
Не совсем так. Тут есть определенная путаница с терминами. В NTFS термин «аттрибут» используется для записи с данными, в этом плане данные файла и альтернативные потоки тоже являются аттрибутами. Указанные вами аттрибуты хранятся как часть аттрибута $STANDARD_INFORMATION, т.е. $STANDARD_INFORMATION от альтернативного потока отличает только тип аттрибута, альтернативные потоки имеют тип $DATA.
но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).
Это не так. Собственное в NTFS нет как таковых фиксированных аттрибутов, вместо этого есть понятие альтернативных потоков файла. В основном потоке данных содержится собственно содержимое файла, в альтернативных — все что угодно. Это могут быть разрешения (DACL), информация для аудита (SACL), сведения об источнике файла (например что файл загружен через Интернет) и вообще все, что угодно, включая POSIX-совместимые аттрибуты. Набор альтернативных потоков у каждого файла может быть свой.
P.S. и ИМХО это очень красивый подход.
Практически все списки рассылки, по крайней мере в дефолтной конфигурации, доставляют копию отправителю, если он подписан на списки рассылки. Так проще, например, отфильтровать письма, без необходимости лазить по нескольким папкам. Если не хочется получать письма от себя, то фильтр действительно настроить не сложно.
Это зависит от рассылки и от того почему она попадает в спам. Например, если она попадает в спам потому, что распознается как спам и каждое письмо приходит с уникального адреса, то нажатие на кнопку «Не спам» действительно не даст гарантированного результата, лучше сделать соответствующий фильтр в настройках и поставить чтобы он применялся к спаму.
В поддержку в любом случае имеет смысл обратиться, если вы считаете что какие-то неспамные письма некорректно попадают в спам.
Magic не используется в нормальном режиме работы, это решение на случай сбоя, примерно такое же, как зеркалирование. Сбои происходят относительно редко. Вероятность коллизии для 32-битного счетчика на много порядков меньше вероятности, что два диска с данными на которых хранятся две копии одного файла выйдут из строя с интервалом не более минуты и обе копии файла будут гарантированно утеряны, не смотря на зеркалирование в разных датацентрах. Еще больше вероятность утери информации из-за действий пользователя. Вероятность отказа есть всегда, ее нельзя свести к нулю, ее можно свести к допустимому уровню. Эта технология не пригодна для хранения информации стоимостью миллиард долларов за файл (возможно, она может быть доработана до такого уровня, но такой задачи нет), но она вполне пригодна для хранения корпоративной и пользовательской переписки и корпоративных и пользовательских данных, т.к. она заведомо надежней чем RAID 1 или 5 в корпоративном сервере и уж тем более, чем незеркалированный диск в домашнем компьютере.
Вы (как и многие продавцы и вендоры) забываете, что пользователь работает не только с вами и читает не только ваши рассылки.
Ответьте на простой вопрос: что пользователь должен делать чтобы отказаться от ваших маркетинговых рассылок всех, полностью, навсегда? Вы обязаны предоставить пользователю такую возможность и она должна быть простой. Кнопка «Отписаться» предназначена именно для такого действия, и пользователь к этому привык. Если у вас есть возможность отказаться от какой-то категории писем — предоставьте пользователю и ту и другую возможность в шапке письма (например «перестать отслеживать товар» и «отказаться от всех рассылок»). Кнопка «Отписаться» должна соответствовать последнему действию, потому что именно таковы ожидания пользователя, он ничего не знает о внутренней классификации рассылок тех 50 компаний и сервисов на которые он подписан и хочет отказаться именно от вас, а не от информации про айфон.
Если вы боитесь, что пользователь может использовать кнопку некорректно — не добавляйте заголовок List-Unsubscribe, но от необходимости добавлять ссылку на общую отписку вас это не избавляет, потому что так хочет пользователь.
Механизм помещения рассылки в спам по персональным фильтрам на самом деле выгоден всем, и вам в том числе, т.к. ограждает вас от падения репутации, вы зря его так боитесь. На тех письмах что сами попали в спам пользователь уже не нажмет «Спам». Если пользователь будет продолжать получать от вас письма в Inbox и будет продолжать кликать на них спам — вы рано или поздно заработаете такую репутацию, что будете попадать в спам по умолчанию.
Для транзакционных писем, не связанных с маркетингом и обязательно должны быть получены в Inbox, т.к. требуют срочной реакции (например, ссылка на сброс пароля или запрос дополнительной информации от менеджера) можете использовать уникальный идентификатор типа номера заказа в адресе отправителя, чтобы они не попадали под ранее созданные фильтры, но в целом избегайте использовать слишком много разных адресов. Даже для информационных транзакционных писем (например информации о размещении заказа и статусе оплаты) не следует делать уникальные адреса, т.к. пользователь может захотеть создать по ним фильтр и складывать в папку, если они будут продолжать приходить в Inbox это будет его раздражать. Такую же реакцию пользователь ожидает на отписку и пометку спамом.
Это значит, что именно этот адресат, нажав на «Отписаться» перестанет получать во «входящие» письма об изменениях в вашем каталоге, а если по какой-то причине вы продолжите их присылать, то именно у этого адресата эти письма будут складываться в спам.
Насколько я понимаю, это именно то, что он ожидает.
Вы все рассылки и транзакционные письма письма шлете с одного адреса? Не надо так делать, адрес должен идентифицировать рассылку, это помогает пользователю фильтры настраивать. Не шлете? Значит все будет ровно так, как ожидает пользователь.
P.S. Ну и сама описанная атака на практике мало что дает атакующему — если он контролирует содержимое обоих писем, то что ему мешает сразу отправить подмененные реквизиты?
Проблема критична, например, в случае SSL, т.к. можно сделать два разных запроса на получение сертификата, и получить подпись, которая действительна для обоих. При этом например один запрос на свой домен, а другой на чужой, или один простого сертификата на имя домена, а во втором добавить роль удостоверяющего центра. Это как раз примеры, в которых использовались коллизии MD5.
Не совсем так. Вы описали chosen-prefix collision attack, в то время как сейчас для SHA-1 пока идет речь о возможности просто нахождения коллизии с теоретической оценкой сложности 2^80 вычислений. Для сравнения, для MD5 сейчас существуют алгоритмы нахождения коллизии за ~2^16 вычислений, в то время как для заданного префикса требуется ~2^50 вычислений.
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
Или таки, как в mailman надо настроить dmarc_moderation_action с действием Munge From, но это как-то менее радикально, да еще и документацию читать надо.
да.
Да. Тарантул вообще декларируется не как NoSQL хранилище данных, NoSQL это скорей побочная черта архитектуры, а вообще это сервер приложений LUA. LUA в том числе можно использовать в декларативном стиле, но совсем не обязательно, т.к. это гораздо более удобный и гибкий язык, чем TSQL или PL/SQL. А поддержка SQL в анонсирована в разрабатываемых версиях Tarantool.
Притворюсь, что не понял, что это риторический вопрос :)
Давайте я еще чтобы продемонстрировать мысль усложню задачу, и представим, что атака пошла сразу с миллиона джумл, чтобы дешифровать весь трафик не хватит никаких ресурсов и надо срочно спасать клиента. Именно в этом случае, я бы сделал примерно так: разграничил трафик от браузеров и от хостинговых сетей, можно по имеющимся IP-классификаторам, можно по сигнатурам TLS-хэндшейка, одного коннекта с одного IP хватает для классификации. В атаке участвует 1,000,000 джумл — для «грубой» классификации пропустим миллион коннектов от джумл прежде чем их грубо отфильтруем. Дальше трафик гарантированно не от джумл пропустил бы обычным путем, % грубо отфильтрованных коннектов на который хватает мощности пустил бы на дешифровку и анализ и состсавил черный список (с джумлами) / белый список (с false positive'ами «грубого» классификатора), остальные коннекты, на которые не хватает ресурсов просто пустил бы в блекхол. Да, зарежем на время людей с проксями на хостингах или возможно какие-то поисковики — и фик с ними. И так пока большая часть атаки не будет отфильтрована блеклистом. По мере роста блеклиста мощность атаки и процент коннектов, уходящих в блекхол будет снижаться, не думаю что потребуется больше нескольких минут, чтобы митигировать ее блеклистами до уровня, когда можно обработать весь трафик. Так что джумлы с вордпрессами не очень пугают, потому что можно быстро сделать грубый фильтр на пассивный трафик.
А вот IoT с Андроидами это очень страшно, да, потому что такое не прокатит.
Атака со статических адресов и для блокировки должно быть достаточно блеклиста, а для построения блеклиста должно быть достаточно зарулить/дешифровать какой-нибудь небольшой процент соединений. Есть какая-то причина дешифровать весь трафик?
На самом деле, все еще интересней, в большинстве случаев можно обнаружить подозрительные узлы даже пассивно по используемому cypher suite, отличие от популярных браузеров будет весьма значительное.
Это не так. Собственное в NTFS нет как таковых фиксированных аттрибутов, вместо этого есть понятие альтернативных потоков файла. В основном потоке данных содержится собственно содержимое файла, в альтернативных — все что угодно. Это могут быть разрешения (DACL), информация для аудита (SACL), сведения об источнике файла (например что файл загружен через Интернет) и вообще все, что угодно, включая POSIX-совместимые аттрибуты. Набор альтернативных потоков у каждого файла может быть свой.
P.S. и ИМХО это очень красивый подход.
В поддержку в любом случае имеет смысл обратиться, если вы считаете что какие-то неспамные письма некорректно попадают в спам.
Ответьте на простой вопрос: что пользователь должен делать чтобы отказаться от ваших маркетинговых рассылок всех, полностью, навсегда? Вы обязаны предоставить пользователю такую возможность и она должна быть простой. Кнопка «Отписаться» предназначена именно для такого действия, и пользователь к этому привык. Если у вас есть возможность отказаться от какой-то категории писем — предоставьте пользователю и ту и другую возможность в шапке письма (например «перестать отслеживать товар» и «отказаться от всех рассылок»). Кнопка «Отписаться» должна соответствовать последнему действию, потому что именно таковы ожидания пользователя, он ничего не знает о внутренней классификации рассылок тех 50 компаний и сервисов на которые он подписан и хочет отказаться именно от вас, а не от информации про айфон.
Если вы боитесь, что пользователь может использовать кнопку некорректно — не добавляйте заголовок List-Unsubscribe, но от необходимости добавлять ссылку на общую отписку вас это не избавляет, потому что так хочет пользователь.
Механизм помещения рассылки в спам по персональным фильтрам на самом деле выгоден всем, и вам в том числе, т.к. ограждает вас от падения репутации, вы зря его так боитесь. На тех письмах что сами попали в спам пользователь уже не нажмет «Спам». Если пользователь будет продолжать получать от вас письма в Inbox и будет продолжать кликать на них спам — вы рано или поздно заработаете такую репутацию, что будете попадать в спам по умолчанию.
Для транзакционных писем, не связанных с маркетингом и обязательно должны быть получены в Inbox, т.к. требуют срочной реакции (например, ссылка на сброс пароля или запрос дополнительной информации от менеджера) можете использовать уникальный идентификатор типа номера заказа в адресе отправителя, чтобы они не попадали под ранее созданные фильтры, но в целом избегайте использовать слишком много разных адресов. Даже для информационных транзакционных писем (например информации о размещении заказа и статусе оплаты) не следует делать уникальные адреса, т.к. пользователь может захотеть создать по ним фильтр и складывать в папку, если они будут продолжать приходить в Inbox это будет его раздражать. Такую же реакцию пользователь ожидает на отписку и пометку спамом.
Насколько я понимаю, это именно то, что он ожидает.
Проблема критична, например, в случае SSL, т.к. можно сделать два разных запроса на получение сертификата, и получить подпись, которая действительна для обоих. При этом например один запрос на свой домен, а другой на чужой, или один простого сертификата на имя домена, а во втором добавить роль удостоверяющего центра. Это как раз примеры, в которых использовались коллизии MD5.